- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 1 Feb 2017 21:27:37 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Consider visibility in 'speak: auto'
------------------------------------
- RESOLVED: speak: auto matches the AAM computation in how it
takes visibility: hidden and display: none into
consideration
New CR publishing request for CSS UI 3
--------------------------------------
- RESOLVED: New CR publication for CSS UI 3
CSS Display
-----------
- Instead of creating a new display property value for visually
hiding an element while making it available for AT, fantasai
believed that the speak property would solve the use case and
proposed a few options to ensure it's ready.
- Several people in the group indicated that they didn't
believe that speak would work as it was designed to work
linearly (i.e. ebooks) not with the AT.
- RESOLVED: Do not add speak property to display module.
- RESOLVED: Leave flow-root name as-is.
- RESOLVED: Transition to CR for CSS Display.
Make colorDepth/pixelDepth return useful information again
----------------------------------------------------------
- There was a positive response to returning useful information.
- Since this does have a high possibility of misuse/abuse, there
was a desire to see the use cases and examples clearly spelled
out before changing the spec.
- Discussion will continue on github
(https://github.com/w3c/csswg-drafts/issues/993)
and then return to the group for resolution.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0000.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Bert Bos
Tantek Çelik
James Craig
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Michael Miller
Rachel Nabors
Simon Pieters
Anton Prowse
Melanie Richards
Florian Rivoal
Alan Stearns
Steve Zilles
Regrets:
Tab Atkins
Daniel Glazman
Jen Simmons
Geoffrey Sneddon
Lea Verou
Greg Whitworth
Scribe: dael
Consider visibility in 'speak: auto'
====================================
Rossen: Let's get going.
Rossen: As usual, are there any extra agenda items?
Rossen: I'll take that as a no.
Rossen: Before we jump in, yesterday we did have the inaugural
call for the a11y/CSS TF.
Rossen: We had a number of attendees from CSS & APA.
Rossen: We did jump into one or two technical discussions that
weren't resolved, but we discussed speak and speak-as.
Rossen: With that I wanted to see if fantasai made it?
fantasai: I'm here.
Rossen: So let's jump into speak: auto
<dael> https://github.com/w3c/csswg-drafts/issues/511
fantasai: The issue was that some of the a11y folks during TPAC
asked us to consider visibility when keying the speak:
auto value because currently they account for display
and visibility.
[pause for jcraig to join]
Rossen: While we wait for jcraig...um.
Rossen: Is there a reason to not just resolve?
Rossen: This is the same as the algorithm for name and
description. It matches exactly. I'd be interested in if
there are are any reasons to not do otherwise.
Rossen: We can wait on jcraig before we resolve, but I'd be
interested to hear from the rest.
Bert: Seems to me a bit confusing if visibility: hidden equates to
speak: none. It's more like volume 0. It takes up space. The
audible translation takes time.
fantasai: That's true in a strict sense, but people are doing
layouts with layers so the space isn't perceived as
taking up space. Having to go as volume 0 would just be
a bunch of dead silence which is useless. Even if visual
layout where you leave space you don't in the aural
canvas.
fantasai: I don't think it's useful normally. If you really want
it you can set volume to 0 yourself.
<jcraig> +1 to fantasai's comment. we don't want dead air (radio
term) or periods of unexplained silence
Rossen: I'm not 100% sure what it means to take audio to 0. Do you
meant the entire volume of the current instance of this
web content?
<ChrisL> it would be the volume of the element set on, not globally
Rossen: Plus this matches the name computation algorithm.
jcraig: I agree with fantasai's comment. We don't want dead air. I
think I agree with Jessie and others that by default
visibility and display should effect speech output.
<dbaron> Things work correctly in terms of descendants being able
to override visibility:hidden with visibility:visible (
but descendants being unable to override display:none),
right?
<ChrisL> that would imply a sort of auto value, which depends on
display and visibility
<fantasai> dbaron, 'speak: always' is intended to override
'display: none' for speech output, and does per spec
<fantasai> rossen raised it as a concern... it is definitely a
desired feature to have something invisible to the
visual rendering and rendered to speech
Rossen: Anyone else?
Rossen: To dbaron's question: this is in fact the behavior we
support in edge
Rossen: This is what's currently specced by AAM spec.
Rossen: My expectation would be this property matches that
behavior as well.
Rossen: I see chatter on IRC. Is there a reason it's not on call?
[troubles with un-muting]
dbaron: As long as the auto value does the right thing for display
and visibility for descendants that seems fine.
fantasai: That's a good point. I'll be careful when I edit in the
spec to make sure that works correctly.
Rossen: Let's call for consensus
Rossen: Proposed resolution: Speak: auto matches the AAM
computation in how it takes visibility: hidden and
display: none into consideration.
Rossen: Objections?
RESOLVED: speak: auto matches the AAM computation in how it takes
visibility: hidden and display: none into consideration
New CR publishing request for CSS UI 3
======================================
<Florian> https://lists.w3.org/Archives/Public/www-style/2017Jan/0074.html
Florian: If anyone has reviewed I'm happy to hear about it. There
is a DoC and an updated change section. I think we're
close to PR. I'm in the middle of completing the test
suite. They'll be written by end of this week. Majority
pass in 2 browsers.
tantek: I concur. It's in good shape.
<fantasai> +1 to publishing
ChrisL: I looked at DoC. Looks complete. Changes looks good. It
looks in order.
Rossen: Objections?
<ChrisL> +1
RESOLVED: New CR publication for CSS UI 3
Rossen: ChrisL you'll help?
ChrisL: Yes. First step is transition request.
<ChrisL> I will do the transition request
<fantasai> thanks Chris! ^___^
CSS Display
===========
Create a display property value for visually hiding an element while
making it available for AT
--------------------------------------------------------------------
fantasai: I'll start with create a display property value for
visually hiding an element while making it available for
AT
<Rossen> https://github.com/w3c/csswg-drafts/issues/560
fantasai: There were several Github issues asking for something to
have display: none in visual rendering but have content
rendered to speech.
fantasai: I said it's the speak property, but no one implements
it. It's been in CR for 4 years.
fantasai: Question there, which is the last comment on the link,
is what do we want to do.
<fantasai> https://github.com/w3c/csswg-drafts/issues/560#issuecomment-270094051
fantasai: 1) Do nothing and tell people to implement speak
2) split speech into 2 levels so speak is 1.
3) move speak property to display module so that it is
easier to see and goes to CR with display.
fantasai: What do you, the WG, think we should do?
<Bert> (I kinda like option 3..._)
dbaron: I'm skeptical that speech module solves this. It seems to
be a thing about a separate aural rendering than AT. It's
a separate presentation not an assistive view of the
presentation.
dbaron: I'm inclined toward something more related to display.
dbaron: Maybe that's not other peoples understanding of speech,
though.
<tantek> going to go out on a limb and note that the Speech module
was never really incubated (or nothing passed the
experimental emacs impl which was an earlier draft and
does it even still work?). It's a perenial example of an
aspirational spec that's been stuck in the CSSWG :(
Rossen: Speaking with my impl hat, I have to say we've made a
number of decisions and have held display:none for a
number of years and features. We've never had a reason to
break the seal of a display:none subtree in the DOM. This
sounds like it will.
Rossen: I'm sure implementors have various optimizations on how
they compute those subtrees. I'm skeptical to see that
this is something we should proceed with for
implementation and because this property goes against much
of what HTML AAM tries to define in terms of how name
computation and text computation happens for purposes of
AT text sentences.
Rossen: So I'm personally, as an impl, against that.
jcraig: As an implementor of UA and assistive tech, I think the
speak property is insufficient here. A lot of people don't
understand how AT works and the full explanation is too
long, but this is a secondary tree...similar to DOM but
not 1:1. What we'd be asking the UA to do is expose these
elements based on the speak property.
jcraig: The switch interface user uses the same AT. Even a braille
screen reader for those that are blind would want the same
info. This is something more along the lines of display or
hidden properties. We've talked about doing this with an
aria override:
<jcraig> hidden aria-hidden="false"
jcraig: There's complexities there, but that would over ride.
That's as clean as possible, but only impl in webkit right
now.
<Rossen> it is also implemented in Edge
jcraig: Having a CSS override you may want to consider, but I
don't think speech is right.
jcraig: Also, most of CSS Speech is linearized, not about
something accesses by assistive technology users.
jcraig: CSS Speech is clearly more targeted at linearized speech
(e.g. audiobooks) than to navigated speech (e.g. screen
readers).
<tantek> jcraig, but how do we know it even does a good job at
"linearized speech (e.g. audiobooks)" ?
<jcraig> tantek, it was mostly written by the daisy org... ask the
authors? I posted some comments during that time for AT,
but they were rejected in favor of linearized audio.
<tantek> jcraig, does the daisy org have a representative in this
WG?
<tantek> we should just publish CSS Speech module as a Note and
give up on the specifics in that module since there's
been zero implementer interest for four years.
fremy: I wanted to say I agree with the interpretation by dbaron
that speech is for ebooks, not a11y. We should use aria
properties for a11y.
<RachelNabors> I concur.
fremy: I don't think we should do anything more in speech.
<bradk> 'aria-display: block'
<jcraig> bradk, please no aria-* props in CSS
<bradk> jcraig, just thinking something-display that overrides
display, for AT only.
<RachelNabors> I love interactive stuff and accessibility. But...
we have ARIA for this. And it's more broadly
supported. Why would I use this? Isn't this just
one more thing for accessibility minded front end
devs to remember to use? Overwhelming.
<fantasai> RachelNabors, It lets you control the show/hide of an
element in CSS, and to do so differently for a11y than
for visual
<fantasai> RachelNabors: We shouldn't be replacing ARIA in
general, but this makes sense to me -- sometimes the
visual presentation makes certain parts of the document
redundant, and you want to hide them visually
Florian: To react to your earlier point, I was surprised because
it sounded like that you weren't against moving the speak
property, but was against how the speak property worked.
<tantek> yes that is what I heard also
Florian: Is that solved because you expect separate UAs to impl
that? Or did I miss something?
Florian: Is the fact that you seem to object to the feature
resolved by that you expect the property impl by UAs only
doing linear?
Rossen: I'll echo jcraig a bit. We did an aria implementation in
Edge a few months ago and the clean representation for
a11y is what jcraig said. We build separate trees that are
added to what we have and those trees are based on style
info among other things. Style trees themselves are built
on cascade. One of the strongholds in cascade is the
display:none which obscured the entire subtree of that
element. Now if we add additional burden because a
speak:normal could be in there there could be holes in the
display:none. That's a long stretch.
Florian: Are you objecting to this property implemented by desktop
browsers or existing?
<dbaron> I've viewed the speech module as a thing that's not
expected to have anything to do with browsers.
Rossen: I'm against how speak:normal is defined. Speak:none we
could take in addition to things we do. We can add another
thing to look at, but going to speak:normal that could be
anywhere in any sub-tree incl display:none is something I
think will be difficult to impl and go against the
stronghold of display:none
Florian: Okay, now it seems like you object to how speak:normal is
already defined?
Rossen: Yes. Since this spec was before my time I haven't had the
chance to give my opinion at the time. Also, this spec
hasn't had update from impl and perhaps there's a reason.
Florian: fantasai asked about moving the property and I'm getting
that you object to how it works, not moving it.
Rossen: Yes.
<tantek> how long do we wait before we give up on CSS Speech and
publish it as a Note?
Rossen: So I see a bunch of talk on IRC. I want to bring the
conversation back to the call. Lots of people are talking
about this being a note and not a spec. If you folks want
to discuss, please put yourself on the queue.
jcraig: To clarify the conversation with tantek he asked how we
know it's good for linear. The authors were from the daisy
coalition. I assume they know what they were doing for
linear. I put comments about how it won't work for AT, but
I believe they were not accepted.
<tantek> perhaps with the IDPF merger we can encourage the Daisy
org to join the CSS WG
jcraig: I posted some related comments in the CSS speak issue.
jcraig: I also object to the way it's implemented currently, but
not enough to object to the change of value name. THere's
larger issues.
* fantasai found a bunch of comments from jcraig on css-speech,
all of them seem to have responses from the editor
<jcraig> fantasai... editors responded. comments not accepted,
ensuring css-speech mostly relevant for linearized
speech, not AT usage
Rossen: Let me try and summarize.
Rossen: It sounds like we're not done with speech module or speak
properties. There's rising opinions about the behavior and
tech decisions.
Rossen: The original topic was if we should move speak or
speak:auto to display module. Given this chatter about the
property, the display module is fairly far along CR track,
it would be a pity to see the speak property holding this
spec back.
Rossen: I would suggest to not move the speak property into
display module. If we have it anywhere we can discuss
separately.
<tantek> agreed with that reasoning
Rossen: I would like to hear if there are objections to keeping
speak property where it is now.
RESOLVED: Do not add speak property to display module
Rename flow-root
----------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/964
Rossen: We have a second issue: rename flow-root
fantasai: There was a motion to rename flow-root value for display
and the thread doesn't seem to have concluded on a
better alternative. flow and flow-root are two values
for inner display type, one of which creates a new
formatting context and one doesn't.
fantasai: It's intended to indicate a correspondence. flow-root
indicates the new context.
fantasai: The word flow was chosen because you don't get a new
formating context, you participate in the old one.
fantasai: The other reason is there is a content type for elements
in HTML that allows the mixture. It's called flow.
That's the type of formatting this indicates.
fantasai: It's not just about block formatting context, but also
inline level.
fantasai: Not having better suggestions I say leave as-is, but I'm
open to other suggestions.
Rossen: This is a call for bikeshed.
<Florian> I think it is fine as is
Rossen: Anyone have a different name to propose?
* bradk thinks 'flow-root' is fine and easily understandable
<astearns> I'm fine with flow-root - was hoping for a better
suggestion but haven't seen one
Rossen: Objections to leave flow-root as is?
RESOLVED: Leave flow-root name as-is.
CR Resolution
-------------
Rossen: Taking display to CR. Are we ready to resolve?
fantasai: There are no open issues. All edits are made and pushed
out.
fantasai: Only issue filed against the WD is this one on renaming.
We have impl shipping. I think we should move forward.
<astearns> how is the test suite?
<fantasai> no idea :(
Rossen: Objections to publishing CR of CSS Display?
ChrisL: Again, this is a transition request.
Rossen: Correct.
<tantek> ship it!
<ChrisL> +1
RESOLVED: Transition to CR for CSS Display.
[Bert will do this transition request]
Make colorDepth/pixelDepth return useful information again
----------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/993
zcorpan: It's a new issue.
zcorpan: It's proposing to make these properties useful again. I
changed them in 2015 to always return 24 to address the
fingerprinting issue.
zcorpan: Some implementations do have 24 hard coded.
zcorpan: It's proposed to make them return other values because
it's useful for deep color screens.
zcorpan: I wanted to check the thinking of the WG.
zcorpan: And we should make sure same features in MQ are aligned
with the CSS OM.
Florian: Is this something we'd like to discuss with both specs or
is it better with source-set and things like that? Which
would limit fingerprinting a bit.
zcorpan: I don't think you can do it with a source set like thing
because this is for spec colors in CSS or canvas. Not for
images, really.
zcorpan: For images you can use deep color already.
Rossen: This is device specific correct?
zcorpan: Right.
dbaron: I think...I'm fine with this being useful as long as the
spec is clear what the value means. Some impl were
returning what the bit depth was semantically before the
hard code and some were returning number of bits in the
memory layout that the graphics card liked
dbaron: There are some context where when you have rgb data you
back a bite of r, of g, of b. There are some context where
you want 32 bytes aligned. Sometimes this differs per
video driver. Some impl exposed this.
dbaron: Apparently some people wanted that, but most people didn't.
Florian: Why?
dbaron: I think they were messing with low-level canvas things.
dbaron: That was the only way they could get what they wanted at
the time.
dbaron: I advocated this shouldn't expose differences between how
video drivers do memory layout.
dbaron: Spec should be clear one way or the other.
<ChrisL> bits per component vs bits per pixel. spec needs to be
clear.
<ChrisL> also for 5-6-5 red green blue = 16
ChrisL: I completely agree with zcorpan this should return bit
depth summed for number of components.
ChrisL: If you have 5-6-5 it's easier to do the sums.
ChrisL: I also agree this should return actual bit depth, not any
other padding.
ChrisL: I'm also happy to contribute or review text for this. I
understand this well and I'm happy to work with the
editors.
smfr: I wanted to point out that bit or px depth isn't good to
display if the display is wider than srgb
smfr: This number would return 24 of the new mac displays. I don't
think we want to encourage this. Color gamut MQ is better.
ChrisL: Absolutely.
ChrisL: There is some correlation, but it's not necessarily true.
ChrisL: People shouldn't make assumptions on that value.
smfr: There are also floating point px formats. You shouldn't
assume this gives the integral number.
ChrisL: Right. I've only seen that in image editors. Could you
send something explaining what you mean on floating point
px format?
smfr: Oo the mac you can create px buffers
ChrisL: Okay. Yeah.
<zcorpan> pull request from mounir:
https://github.com/w3c/csswg-drafts/pull/994
<ChrisL> thanks, will review PR
zcorpan: I also wanted to point out there's a pull request for the
spec. Anyone that wants to review, please go ahead.
Rossen: Where does this leave us on the issue? There were some
people in value of changing as long as they are true and
useful. Also, there was some feedback about how is it
really going to be used and will people use it in place of
color gamut MQ.
Rossen: Are we leaning toward not changing in favor of encouraging
the color gamut or do we try and define as true as
possible?
ChrisL: I'd be in favor of defining correctly and giving example
in spec of how not to use it.
Florian: Given that this has potential for misuse, but I'm also
wondering how reliable this will be because we don't want
the number for the layout on graphics card...do we want
the bit depth on the browser, the screen, the graphics
card?
<ChrisL> good point about dithered 6bit/component TN displays
Florian: Combining these things, I'd like to see specific use
cases because if it might be impl wrong and has potential
for misuse, I want to make sure we're doing it for a
reason.
ChrisL: You bring up a good point. We need to discuss what to give
in [use case around dithering]
Florian: And what's the use case to let us decide and given that
case what would the author want to see?
<zcorpan> related issue for canvas: https://github.com/whatwg/html/issues/299
zcorpan: There has been discussion in HTML for adding both deep
and wide colors for a canvas.
zcorpan: Some of your points are in that thread.
zcorpan: Whatever we come up with is already exposed there with
info on wide colors.
Florian: The thread seems different between how to define and how
to query. If you're painting through the canvas you won't
make your page lighter by making a 12 bit and 8bit
canvas. Or not? I'm confused on use cases.
zcorpan: If you use more bits than device can handle you use more
memory. But sure. We should read this thread and think
for a while.
Rossen: Are you okay with deferring that resolution, zcorpan ?
zcorpan: Sure.
Rossen: It would be great to summarize this or express that we had
some points in favor as long as we have a good definition
of the value. I peeked at the pull and I don't think
that's near defining it.
Rossen: Let's postpone. Please bring this back when the discussion
matures and we'll call the resolution at that time.
Rossen: That takes us to the end of our agenda. We're 1 minute
from the end of the call.
Rossen: I don't recall any topic ever taking 1 minute, so I'll end
the call now.
Received on Thursday, 2 February 2017 02:28:43 UTC