W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Telecon 2017-02-01 [css-speech] [css-ui] [css-display] [cssom-view]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 1 Feb 2017 21:27:37 -0500
Message-ID: <CADhPm3sTiUi9iibZpc+G0F4=Pn6y9VMbeBaQQ4SKNKPGyOMowA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 2 February 2017 02:28:44 UTC