<tzviya> https://www.w3.org/2016/02/08-DPUB-minutes.html
tzviya: any comments?
... approved.
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
... WE WANT FEEDBACK
... WE WANT FEEDBACK
... 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
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
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