<ivan> trackbot, start telcon
<trackbot> Date: 17 August 2015
<NickRuffilo> scribenick: Tzviya_Siegman
<NickRuffilo> JKJK
<NickRuffilo> scribenick: NickRuffilo
<HeatherF> The host can mute, but then the muted person cannot unmute themselves.
<mgylling> http://www.w3.org/2015/08/10-dpub-minutes.html
Markus: "Any objections to approving?"
Masses: Silence
Markus: "While in admin mode - in order to show up in the attendee list, you have to do "present+ in IRC""
<ayla_stein> * present+ ayla_stein
Markus: "We wanted to make sure Deborah is around for the ARIA description for described-at. So we're going to start with that."
<clapierre1> +1
+1
<HeatherF> +1
Markus: "OK - ARIA Described-at meeting recap."
Deborah: "It was fine - it could have gone much... differently..."
<tzviya> current requirements for extended descriptions: http://www.w3.org/dpub/IG/wiki/Publisher_requirements_for_extended_descriptions
Deborah: "Instead of going to the group
saying "we need it" we re-wrote the list of requirements that publishing
needed. We don't care what makes us do these things, but we need a
consistent way to do this without polyfills. There were lots of people
and publishers in the meeting - even though they ended up not speaking
up..."
...: "There was some tech conversation but in the end what I think
happened that what we were asking for was not some specific
implementation, or something with legacy issues - that we had
suggestions but did not have strong feelings on how the functionality
should be implemented. They brought up valid questions about making
things easy to implement while not making it present for those that
don't want it. We did convince them that what we wanted was reasonable."
...: "Tzviya and others are polishing up the wording and requirements. The one thing that came out of this meeting is that we agreed it was too complicated to talk about backwards compatibility. For any number of reasons, that publishing requires older technology - so worrying about backwards compatibility was one of the things dragging us down - if you have newer tech, then you will be able to have access to this feature - but probably not in older browsers. Unfortunately IE is now being considered an older browser"
<ChrisL> edge is the new IE and is
installed by default in Windows 10 which is a free upgrade
...: "We decided to push forward."
Tzviya: "Thank you to all who stayed for the full time - it was long but worth it. Also, even if you were in the meeting and didn't say anything. I know our friends from ARIA and PF were appreciative. it meant alot that people showed up."
Ivan: "Let's add one point that Markus did HEROIC scribing during that meeting."
<ChrisL> "Mobile Safari is the new IE6"
Ivan: "I wanted to check if my impressions
were right if this was an apple VS anybody else - was this correct? The
other thing is that it seems that the solution is the details element -
in which case then Apple will reject..."
... "I had a slightly disagreeable feeling that the reaction of apple is
that 'this is already implemented, so we won't make any change." Maybe I
misunderstood..."
Chris: "The old IE vs Edge is a temporary phenomenon - Windows 10 replaced IE with Edge - so you get rid of it..."
Deborah: "As far as Ivan's perspective - (I want to thank everyone for showing up - as well as Markus for scribing!) It does seem true that the needs of the meeting were being driven by the goals of one manufacturer. Someone said: 'This seems like what longdesc is, and all it needs is more info' and the manufacturer said: 'we will not do it.' While it may be strange and frustrating that the goals of ARIA/HTML are being so influenced by one browser, at the same time, it looks like we WILL achieve most of our requirements. Details isn't perfect, and it won't work out-of-the-box (not sure everyone is willing to make those changes) but it's closer than we have ever gotten in the past."
Tzviya: "I'm not entirely sure that Details is what we will arrive that. It seemed that way in the meeting, but we still need to make a grid of requirements and options and see what we arrive at. We set forth requirements - if details is the solution, then we'll go with it. There was silence when long-desc was brought up and didn't end until the browser said 'objection'."
Ivan: "yes, we do need to make the grid. One of the good things of last week - through Deborah's list - was a new fresh view from a different domain. It was an eye opener for an old debate that was going on for a decade. That wiki and Deborah's requirements are wonderful."
Brady: "Quick Q about details: it seems like in the one demo I've seen of it, it was used to show the camera settings a picture was used. is there a way to show 'this is the accessability text'. So can you have multiple notes?"
<dauwhe> https://html.spec.whatwg.org/multipage/forms.html#the-details-element
Deborah: "It's work that needs to be done. Details is not connected to a thing - so you'd need to connect it to an ARIA thing. it's not designed to be hidden... The semantic meaning that publishing would need - to say 'this is a role that always means this is a description, so that all readers can deal with it the same way - that is what isn't there. It isn't perfect, but it's also not part of the spec yet, so there is room to improve it."
Brady: "Although it's implemented, and exists, it doesn't do what we want it to do.' is what I hear from publishers.."
Peter: "I wanted to 2nd brady from math's perspective - even for accessibility - you may want to embed several different formats, a typical usage is that you might have speech text, some you want a LaTex, so you may want to have multiple descriptions for multiple views. MathML has a framework for this purpose, which I don't think is highly useful because of the state of support for MathML. I think the details sounds like a more realistic path."
Ivan: "To answer one of the specific questions, the 'details' element is a general block element. has only 2 special elements - the first required child element is a 'summary' and the 2nd is the user-agent default is 'display:none;' That's all it is, so if you take a FIGURE element, is that you can put as many detail child elements. Apart from the summary, you can put into the details element whatever you want. It is generic - so it's both good and bad, because it's difficult to know what a specific detail element is made for."
markus: It does not allow the re-use of details or information, which is one requirement. "
<ChrisL> oh, I was supposed to look at one of those sections. sorry, was travelling. agree that publish early and often is good so +1 to publish
Dave: "I subscribe to publish-early publish-often, so lets get it out with more eyeballs and community feedback. Only half tongue-in-cheek. Since we've started on this document, there have been progress on the 2 highest priority items. Apple and Google have been working on things (hyphens bug for example)"
Markus: "Is the target a note?"
Dave: "A working Draft..."
Ivan: "This is what we did with LatinReq as well. We mimic the req track, so we publish notes..."
dave: "Working draft is an accurate description. Note implies a degree of finality."
Markus: "Should we ask the W3C staff to get things going?"
Dave: "Are there more comments before we push it through?"
+1 push
Chris: "I haven't had a chance to get my edits in, but I can get them in next round..."
<mgylling> +1 push
Tzivya: "There is a little section called 'accessibility'. I know ARIA is planing on getting very involved with CSS. We want to note the generated content issue, but we will at least wnat to note what may or may not be our problem."
dave: "If you have things you want to add, please do..."
<ChrisL> Generated content is an issue for many reasons (like selectability and searchability) as well ass accessibility
Tzviya: "The fact that generated content creates an issue says alot, but if you'd like me to write a paragraph or so, getting it out before the next face-to-face is important..."
Ivan: "Practicalities, the 2 possible dates, this coming thursday or 2 weeks from tuesday. It's up to you Dave. If you want to have the publication request should go out tomorrow to the webmaster... This is not RESPEC, it's the CSS workflow..."
<ChrisL> Oh good, Bikeshed
Ivan: "You will have to produce the final version so that I can push it up..."
Chris: "i'm also here the rest of this week - ivan if you have any questions"
<tmichel> I am here this week also.
Dave: "I think I can just change the status to working draft and it'll be OK."
Ivan: "No figures - just text? One HTML file?"
DavE: "Yes"
<ChrisL> shortname approval
Ivan: "Wait, one minor thing we have to settle today. This is a new document. I will have to contact Ralph to get authorization for the dpub-pagination as a short name"
Chris: "Yes."
Ivan: "Ok, I will send a request after this call."
Dave: "Short name is an interesting question. in the spec the URL is mainly because we're hosting it in the same GITHUB as latin-req. I call it DPUB-CSS-Priorities"
Ivan: "I don't care, just tell me what it is."
Dave: " I'll send you the file and info"
Markus: "Tzviya - you wanted to add a paragraph for generated content?"
Tzviya: "I think it's OK to go ahead without it..."
Dave: "I'll send it tomorrow morning US time... "
Ivan: "That's afternoon my time."
Dave: "Ok, so by EOD my time"
<ChrisL> yes, needs a recorded decision
Ivan: "For short-name we need official concensus"
<dauwhe> dpub-css-priorities is shortname proposal
<ChrisL> yes, needs a recorded decision for shortname and another to actually publish
Markus: "dpub-css-priorities"
+1
<tzviya> +1
<clapierre1> +1
<pkra> +1
<ivan> +1
<ChrisL> +1
<Bill_Kasdorf> +1
<mgylling> +1
<Vlad> +1
<Jeff_Xu> +1
<tmichel> thierry +1
<lrosenth> +12
<lrosenth> +1
<brady_duga> +1
<ayla_stein> +1
<pbelfanti> +1
<ivan> RESOLUTION: ask for the dpub-css-priorities short name and FPWD publication
Ivan: "^^"
Markus: "User style sheets and
personalization. it's being discussed in epub web whitepaper. For many
of us it's a big unknown and it's an oft-requested feature to taylor
presentations dynamically. This sessions is primarily about what is
going on and what we can do to improve this situation."
...: "Chris will give us an intro and brief on what is going on with
this and how the lay of the land works."
<tzviya> http://www.w3.org/TR/css-cascade-3/#cascading-origins
Chris: "There are 3 sources. User-agent, which it applies to all content. It was a polite fiction, but it actually works. Then there are the document stylesheets, then lastly with the highest priority are the stylesheets provided by the user. Been in since CSS1, and lets a user change font-size, etc. There are some problems. Firstly, it's not consistently implemented. Chrome may have removed it... More importantly, users do not know they can do this - similar to alternate stylesheets."
...: "For example, you could have a reading stylesheet,
a highlight stylesheet, etc. Users want to see content on the page that
says 'pick bigger font' not go through hoops to load a CSS. On a
low-level, it is implemented, but on a high-level, it is unused (it is
not made easy)"
... "There are other problems beyond the UI. Modern web content is
heavily tweaked - so it's easily broken. Lots of current web-design
makes it so that changing styles could easily break things - so it is
not the right place to do restyling. Another solution is browser
preferences. This has the advantages that it isn't in the cascade - but
overrides things. No one says you need to use the same CSS overrides on
every page. Even attaching a custom CSS to a bookmark. There are no
mechanisms for users to share stylesheets. I'm starting to think this is
a nice little feature that it is puny for the job we want to do - and
they don't have the facility to construct these things themselves..."
...: "We need a new mechanism for advanced customization of styles."
<ChrisL> yes, I thought the normal browser is what we were talking about here
Leonard: "Obviously you're talking in
respect to the browser as the user agent. In the context of publications
- while we may use a browser engine, we're creating a custom application
around it (or some wrapper) so from a technical perspective, many of the
things should be pushed into the engine..."
... "So there is no technical limitation - it comes down to UI
implementation."
<ChrisL> I forgot to mention the lack of support for @document rules which would help
Markus: "The styling in the document is so complex, that it still needs to be addressed."
Nick: "UI solution to complexity is to be able to customize CSS for specific "div" or "sections"
<ChrisL> more on @document http://www.w3.org/TR/2012/WD-css3-conditional-20120911/#at-document and https://developer.mozilla.org/en-US/docs/Web/CSS/@document
Tzivya: "add an additional layer for user-specific-stylesheets. Reading systems are relying on browser or user-agent functionality. We don't want reading systems to roll their own functionality."
<HeatherF> I need to drop of for another call. Good call today!
Leonard: "UI should be the reading system - functionality should be the browser"
Brady: "We do have some simple UI - for instance books - it's lots of text with a bunch of paragraphs. Just making the font bigger is hard to do - making text 120% bigger is a complex thing to do in CSS. Often requires going through CSS styles, adjusting font properties... And then it gets crazier... We still have failures in certain peices of content - even when you have full control of CSS. This doesn't even get into when you want to change only some of the font-families. When you have a custom font, you amy not want to replace certain pieces."
Brady: "User-style-sheets are interesting idea, but they don't require the power needed, and they are too complicated."
Dave: "Just to illustrate some of the problems we have in the ebook world today - around this idea - amazon for example says that we cannot apply 'text-align' property to items in body text. They claim they cannot build a reading system if you have something that may over-ride. We do have headaches because of this. I'd also like to point out - are existing mechanisms in CSS enough... We need something beyond what the cascade does... There are some houdini ideas around custom parsing of CSS. How do we expose our requirements to that effort?"
Leonard: "I know many people focus on book publishing - but i would like to point out that the issues and concerns extend way beyond books - and we need to keep in mind magazines, manga, etc. Is this a solution we'd like to solve with existing technology or do we need something new. How much backwards compatibility is needed? Something like we did with CSS prioritization may be needed."
Markus: "Requirements again would probably be one things that could help."
Ivan: "Do browser manufactures care in the first place? Are they trying to solve this? Or is this a problem that the browser manufacturers recognize that it should be solved - but it has never been a priority?"
Chris: "Not sure they don't want to do it or
oppose it, but they do not seem motivated to implement it."
... "Haven't heard that it should be removed or that it's a
mis-feature."
Ivan: "Charles, then next steps.."
Charles: "Quick point on Nick's comment on limiting regions to be modified. I have a slight issue in regards to disabilities. If you cannot change the color, and you're color-blind, you may not be able to read it."
<lrosenth> +100 to Charles - accessibility needs to override…(I like the dyslexic font example, but colour is good too)
Markus: "How do you think the DPUB interest group can best help you think about this issue."
Chris: "It would be good to have examples of the types of customization that would be required. Should we beef them up? Should we invent a new mechanism? These are all primarily use-case driven."
Markus: "That's what I hoped you would
answer."
...: "We'll be producing another document - with example and publishing
domain. Not exclusively trade books, but all types of customization and
personalization. Things that are either being done with lots of
fiddling, or things that we want to do today but cannot. That's one new
work item..."
Leonard: "I'll happy to help"
<tzviya> I will write some use cases, and ARIA WG Is interested in observing/contributing to some extent
Thanks dave!
Markus: "Nick is the owner of this document."
<ayla_stein> ha!
<ChrisL> I'm happy to review, but don't have use cases to contribute
<clapierre1> also happy to review
Markus: "As tzviya reminded us - ARIA working group is also heading into this area
Thanks to all for being here!
<pkra> bye.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/exception/objection/ Found ScribeNick: Tzviya_Siegman WARNING: No scribe lines found matching ScribeNick pattern: <Tzviya_Siegman> ... Found ScribeNick: NickRuffilo Inferring Scribes: Tzviya_Siegman, NickRuffilo Scribes: Tzviya_Siegman, NickRuffilo ScribeNicks: Tzviya_Siegman, NickRuffilo Present: Markus Tzviya_Siegman Dave_Cramer duga ivan Deborah_Kaplan Heather_Flanagan Peter Krautzberger Thierry Ayla Stein Bill_Kasdorf Charles LaPierre Paul_Belfanti NickRuffilo ChrisL paul Julie_Morris Leonard Rosenthol Karen Jeff_Xu Vlad Regrets: Paul Luc Ben Ayla AlanS Agenda: http://www.w3.org/mid/55CD1C5A.6030302@gmail.com Found Date: 17 Aug 2015 Guessing minutes URL: http://www.w3.org/2015/08/17-DPUB-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]