Digital Publishing Interest Group Teleconference

22 Feb 2016



Tzviya Siegman, Dave Cramer (dauwhe), Romain Deltour (rdeltour), Charles LaPierre, Deborah Kaplan, Chris Maden, Bill Kasdorf, Heather Flanagan, Leonard Rosenthol, Ayla Stein (astein), Alan Stearns (astearns), Luc Audrain (laudrain), Ben De Meester (bjdmeest), Daniel Weck, Bert Bos, Ivan Herman, Nick Ruffilo, Karen Myers
Markus_Gylling, Peter Kreutzberger
Tzviya Siegman


last week's minutes

<tzviya> https://www.w3.org/2016/02/08-DPUB-minutes.html

tzviya: any comments?
... approved.

update on EPUB 3.1

Tzviya: I put together some notes
... Markus is traveling to an EPUB/EDUPUB summit

<tzviya> http://www.idpf.org/epub/31/spec/epub-spec.html

tzviya: rdeltour put together some excellent slides on this
... lots of people here are on the EPUB31 wg
... goals: alignment with owp, a11y, consolidation, and simplification
... released the first ED in January, which is very "aggressive"
... but there are some placeholders
... there's a spec reorg with umbrella doc
... move nav to publications
... big feature: can use either serialization of html
... before EPUB was only xhtml serialization
... this forces several things
... so we have to replace epub:type with DPUB-ARIA module
... not fully replaced yet
... there's work in progress on a browser-friendly format (BFF)
... which is related to PWP
... we've proposed a limited metadata set
... but there's been pushback
... require wcag 2.0 conformance
... will also write a11y module
... epub should comply with a11y module

... new core media types, new css profile

Tzviya: removed NCX!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
... and guide, trigger, switch, epub:type
... there will be a f2f in April in Bordeaux
... and an April draft which will be the last major change
... then can decide on deferring features etc
... lots of this dovetails what we've been doing in this group
... anything I left out?

<rdeltour> my EPUB 3.1 slides for whomever is interested: http://rdeltour.github.io/xmlprague2016-epub31/

dauwhe: you said it all :)

tzviya: in eleven minutes!
... topic: CSS/Houdini F2F update

CSS/Houding F2F update

astearns: CSSWG met in Sydney
... and 2 days of houdini beforehand
... houdini is a longer-term effort to make CSS more extensible
... did 4 first drafts
... [1] custom properties and values
... [2] typed OM, a better version of CSS OM
... [3] is worklets, running constrained scripts at interesting times
... [4] custom paint, using worklet to add your own painting code
... these are all FPWD
... there are experiments ongoing in Chrome
... but hope to be able to use these interoperably in the future
... then the CSS meeting proper
... mostly on edge-case details, some testing, interoperability
... no terribly big things
... but four things interesting to this group
... 1. Microsoft is working on a new draft actually specifying table behaviour
... with emphasis on interop
... 2. we discussed handling extended color display
... there are more devices with extended capability, and we need to specify colors for those devices and color matching
... 3. we did talk about char alignment in table, made a bit of progress on edge cases
... 4. and there's been work on a test suite for writing modes, with 900 new test cases
... and then get writing modes closer to REC
... we did talk about font metrics in Houdini
... just defining the problem a little bit better
... what do people actually need to find out?
... what font is actually being used? what measurements are on-screen, like baselines
... and the raw font data
... working on bits and pieces

astearns: that's the summary.

ivan: back to Houdini
... I was surprised, I though that custom properties was in mainstream CSS docs

astearns: CSS custom properties are in the CSSWG, we have a draft, and it's shipped in browser, but it's level 1
... you can't choose if they inherit, and the value is just a bare string
... we did that intentionally
... the houdini draft allows you to more stuff
... it can be more than bare string, it can inherit, can have script attached
... it's version 2

ivan: another question... has anything been discussed on pagination?

astearns: there some edge cases on pagination discussed
... like column-balancing
... we're now considering pagination in everything we do
... you need to define what happens at page breaks
... there wasn't anything discussed in the general case of a paginated view

ivan: my understanding is a bit limited
... so far, the impression I have is that
... we are trusting or hoping that Houdini will give us the possibility to do pagination in a more portable way
... I'm worried that I don't hear about it

astearns: that's a fair point
... we did talk a bit about custom layout which would allow us to do pagination in browsers
... but less progress has been made on that, because it's harder
... and we want to get the first experiments done like values and paint
... layout is hard
... you should be concerned

tzviya: what else should this group be doing?

astearns: we would not have had the discussion about edge cases in char alignment if we hadn't been pushed by use cases
... if there are other areas where current CSS is not interoperable, or there isn't something you need
... more use cases would spur more discussion

dave: we've tried to push this in CSS. There is strong opposition. MS thinks pagination is the responsibility of the app developer

ivan: it's like pushing the corpse around

TimCole: for both char alignment and pagination, is there interest in demanding cases from STEM and math?

... was talking to co-chair of Math WG about difficulties even with mathjax
... we probably could get some good use cases
... of sensitive alignment issues that come up in math

astearns: not at all. I'd love to see specific cases from math layout
... the problem domain is huge
... but if there are bits and pieces we can make progress on
... I'd like to have those cases

TimCole: how quickly do you need these?

tzviya: we've talked about having Peter attending a CSSWG F2F
... we may not need to rush this, but we know it's a huge area

astearns: a good strategy would be to have use cases and discuss them before bringing them to CSSWG
... next meeting is May in SF

ivan: and TPAC?

astearns: yes

ivan: my question is less to alan in this case
... but I come back to this pagination issue
... I understand what dave says
... we had this discussion a half-year ago and said houdini is our saviour
... I have this impression we're getting nowhere
... we need a group to look at this in a more proactive way
... what can we do to push this issue?
... something should be done

astearns: I don't want to give the impression that Houdini is diverging from where we want to get
... there's some progress. Properties and values is a necessary step. The worklets are necessary, because that's where you will put your code
... next step is a custom layout hook for the worklet
... that's not yet in a working draft, but it is in discussion, and we plan on getting there

ivan: that's good
... I don't fully understand the remark of dave on microsoft's reaction

astearns: so the houdini approach would work with microsoft, so someone could build pagination on top of their platfomr
... they are further ahead than other browsers as they have paginated ereaders etc working well
... since they support regions etc
... Microsoft's reluctance is to have this overflow paged notion which has moved out of the current overlow spec
... because part of that spec was a step backwards from what they already had

ivan: that's less alarming

tzviya: any other comments about pagination?
... we have been working on issues related to personalization and media queries

tzviya: I'm getting mixed messages on where that stands
... user stylesheets are pretty much dead
... so what's the status of user personalization with CSS and houdini

astearns: it's a known problem that the majority of the WG wants a solution, but we have no idea how to solve it

ivan: is it worth setting up some sort of a joint task force or whatever between these two groups?
... the publication reader/user community is used to these user personalizations
... if this is not available on the web it's a major problem
... if this is still an open discussion/brainstorm, maybe this will help out

astearns: I like that idea
... there are people who are not otherwise interested in epub would be interested in personalization

ivan: who is interested?

tzviya: I'm interested

<Bert> (I'd be interested.)

lrosenth: I'm interested

tzviya: We'll reach out to alan about this

lrosenth: with respect to personalization
... there's no technical restrictions
... that allows one within the application to switch style sheets
... what's the limitation? Is it just making the browser itself do that?

ivan: what worries me
... is that the current practice in CSS deployment today is such that
... the CSS that you apply to an HTML page can be incredibly complicated
... in some cases you might want to change a background color
... 'cause you have no idea where to put it, because it might be overwritten
... there is !important, but it might not always do the trick
... but there might need to be finer control
... which might have to come from the authors, and not require the end user to understand the whole structure
... that worked when CSS was simple

lrosenth: I hear that
... as we move forward with the TF we will need to go in with are specific pain points that we don't see as resolvable today

tzviya: any other questions about CSS F2F?

ivan: we had a discussion around a11y, whether some features of a browser or a machine is easy to query from the author
... with some sort of a media query
... this came up from a11y
... I saw some conflicting messages on whether it's possible or planned in CSSWG
... a more general thing. Media queries are very useful
... what is the mechanism to define new media
... plans to make it more extensible?

astearns: I've heard discussion of custom media queries
... we talk about this all the time
... we do want to avoid a MQ to target a specific device or browser rather than a capability

dauwhe: was the problem about using MQs for user preferences rather than device capabilities?

ivan: yes, that did come up

tzviya: we should discuss this in the task force

astearns: if there are media queries around a11y that have been discussed there, I'd love to see posts on CSS ML
... so CSSWG can thing about what a11y folks need

tzviya: we've been working on DPUB-ARIA module and extended image descriptions

Extended image descriptions

tzviya: there's a proposal to work with existing html elements, particularly the details and summary elements

<tzviya> https://rawgit.com/w3c/aria/issue1009/aria/aria.html#aria-details

tzviya: the proposal is to add aria-details to aria 1.1
... AT would be able to detect an extended desc inside the details element
... (reads from spec)
... this accomplishes most of our goals for extended descs
... but we did want all users to see it; this is where the MQ comes in
... we think this is in pretty good shape. any questions?

ivan: If I look at example 21

tzviya: and 22

ivan: is it so that by default the content of a details element is not visible
... is this the expected behaviour in browsers?

tzviya: yes

dkaplan3: i believe the current behaviour is not visible but has a visible control

tzviya: thanks

ivan: ok

tzviya: in chrome there's an arrow icon

dkaplan3: at the moment it's still in draft, so it could change

<astearns> intended - not currently interoperably

ivan: to go back to Alan's question for specific use cases
... what would have been nice to have is that
... on the one hand, I can set in my user preference that I always want to see details by default
... and the CSS knows about that and can properly style the content of the details element
... is that what we want but don't have

dkaplan3: there's so many things we asked for :)
... that is not how aria details is going to work. it doesn't have a native visual control
... it has to be available whether or not hidden by css
... it can be an id or url, so can be on or off page
... so it can replicate longdesc
... could point to hidden off screen, or point to something visible
... we didn't get... unless you are using a screen reader, you will never know it's there
... I think that's a problem for all of ARIA
... which need to be available to people not using AT
... the current philosophy of the browser folks and many wg people is that ARIA should only be exposed to AT

<Daniel_Weck> +1 to "more aria stuff needs to be available to all"

dkaplan3: but I think much more aria stuff needs to be available to all

astearns: you mentioned aria details could just be a link
... example 22 is still linking to an element, and the element contains a link
... are you talking about just having a link in aria details

ivan: otherwise we are back to longdesc

tzviya: aria-details is modifying details itself

dkaplan3: I was combining in my head what we got out of two different elements

tzviya: aria-details exists so there can be more than one, and so AT can know there's an extended description

Bill_Kasdorf: but there's not a link

tzviya: it just identifies this thing identifies an extended description

<Daniel_Weck> "Unlike aria-describedby, authors must ensure the content is not hidden and is included in a container that exposes the content to the user as it is expected that the assistive technology user navigate to the content to access it."

ivan: i am confused. what's the difference between aria-details and aria-describedby

tzviya: describedby is limited

ivan: I still fail to understand the difference, aside from aria-desribedby by can have more than 1

dkaplan3: we wanted was one feature of longdesc, which was the semantic inflection that the thing you're looking at is an extended description
... people use describedby all the time; we wanted to the semantic markup to say this is an extended description
... this works almost exactly like aria-describedby, but aria-details is "this is a description that does extended description of the visual object"

ivan: but there's no described-at
... that would be the formal objection target

<tzviya> https://rawgit.com/w3c/aria/action-2006/aria/aria.html#aria-linktype

tzviya: the other new element is aria-linktype
... which looks a lot like the rel attribute, describing the type of link
... aria-linktype=footnote

<rdeltour> aria-describedby is used to compute the text alternative = markup is flattened as a string value

tzviya: so this will aid AT in knowing what type of link
... but the link vocab will be frozen
... we're working on defining those terms this week

ivan: that's great; it's important for 3.1
... so will replace aria-role=noteref

tzviya: I rushed through that
... we haven't filled in the language yet
... we're over time. anything else?

<dkaplan3> I am checking on github, but I am almost sure that when I saw the new attributes, they had the features I was describing. I'm checking to see if they used it and it has changed.

<clapierre> this looks interesting too

tzviya: thanks all

<clapierre> aria-roledescription (property)

<clapierre> [ARIA 1.1] Defines a human-readable, author-localized description for the role of an element.

<ivan> trackbot, end telcon

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/23 09:45:03 $