W3C home > Mailing lists > Public > www-style@w3.org > November 2013

[CSSWG] Minutes TPAC F2F 2013-11-11 Mon IV: Outline Properties, VTT ::cue pseudo-element, CSS Counter Styles

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Nov 2013 07:33:11 -0500
Message-ID: <CADhPm3sA5TL9GUShrMNJrHZZhX5_prh9c=rf3UF0+_c=EQhqXQ@mail.gmail.com>
To: www-style@w3.org
Outline Properties
------------------

  - Krit brought up that the current spec states that everything painted
         gets filtered/blended and that might be an issue with focus
         rings and scrollbars.
  - RESOLVED: Effects affect scrollbars and focus rings. We may work on
              controls later.

VTT ::cue pseudo-element
------------------------

  - RESOLVED: CSSWG is fine with TTMLWG working on this, with ongoing
              feedback.

CSS Counter Styles
------------------

  - Difficulties handling of large numbers in Hebrew without a separator
         was discussed.
  - It was decided to defer on a solution for now.

=====FULL MINUTES BELOW======

Outline Properties
------------------
  ScribeNick: fantasai

  krit: I would like to discuss outline property.
  krit: Right now the spec says that every painted thing gets filtered/
        blended.
  krit: Turns out that outline property is also used for focus rings,
        and that is very important a11y. For this reason, it seems not
        useful to have the focus ring be filtered etc.
  krit: We should masking/filters/blending not affect the focus ring.
  dino: What about scrollbars?
  krit: Good question, right now even scrollbars are affected.

  TabAtkins: ... more general issue
  TabAtkins: Also an issue of 3d transforms
  TabAtkins: Problem is authors often use it as an extra border effect.
  krit: So you're saying that outlines should be part of rendering, not
        a11y?

  dbaron: Were you talking about outline with scrollbars, or scrollbars
          with filters?
  krit: The latter.
  krit: I was just focused on outline, but Dean asked what about things
        like scrollbars.
  krit: So now we can ask, should filters/blending affect
        outline/scrollbars?
  krit: So the key question is outline same as focus ring?

  <TabAtkins> Right. While implementors use 'outline' to do focus ring,
              *authors* use 'outline' as a second border.
  <TabAtkins> And so treating 'outline' as a focus/a11y thing ends up
              breaking author use.
  <TabAtkins> I think we should just make focus outlines separate and
              not controllable by authors, only by browser/user prefs.

  dbaron: 2.1 is interesting in a few ways- one is that it actually
          gives two different options for where outline property can be
          drawn in painting order.
  dbaron: I think that was despite all implementations using one of
          them, though I think because preference was for implementors
          to switch to the other one.
  dbaron: I think outline property was intended to do focus rings.
  dbaron: So it should do focus rings right, and if happens to work for
          other things fine.
  dbaron: But we get push back from authors when we do things for making
          focus rings work right.
  dbaron: If I had done things from scratch, I would have made focus
          ring a pseudo-element with a small set of properties that
          could apply.

  krit: We still have question of whether focus ring should be can
        affected by filters.
  krit: Do we want to discuss focus and outline, or masking?

  ScribeNick: SimonSapin

  krit: I would like to start with a11y of masking & filters.
  krit: Who thinks a11y of scrollbars or focus rings are a problem?
  plinss: I think filter effects on scroll bars is asking for troubles.
  <TabAtkins> Scrollbars have long been stylable already, which has
              potentially bad effects on a11y.
  <TabAtkins> (I'm planning to go ahead and spec that at some point
              soon.)
  <TabAtkins> So I don't see the problem with letting filters affect
              them too.
  <TabAtkins> WebKit/Blink/IE all let you arbitrarily style scrollbars.

  dino: Filters can change position of elements?
  krit: Yes.
  dbaron: It is a problem for filters to not affect these things,
  dbaron: And it may be a problem for them to affect these things.
  krit: I don't see a problem with letting filter effects affect them
        too.
  krit: That doesn't need to be specified because it's already the case.
  krit: Scrollbars are different from focus rings.
  krit: Implementations, Firefox and Webkit do in most cases,
  krit: There is an exception for SVG,
  krit: HTML, we do filter and mask focus ring,
  krit: Firefox does it for SVG,
  krit: Firefox applies focus ring on everything
  <krit> http://codepen.io/adobe/pen/wLrxu
  krit: IE does filter and clip the focus ring.
  krit: There interoperability between IE and Firefox.
  krit: Do we see a negative effect on a11y? do we care?
  <TabAtkins> I care, but I don't think that making an exception for
              'outline' is the solution. I think we should disconnect
              focus ring from 'outline' and just deal with it.
  <TabAtkins> That way focus rings can be more accurate/useful when 3d
              transformed, etc.
  plinss: There's a potential negative effect, we may want to control.
  plinss: You can filter different parts/layer of elements, maybe UI
          widgets is just another layer.
  plinss: Let it apply for now, later have ability to control.
  krit: Can we resolve on that?
  <TabAtkins> +1

  Bert: We don't have a solution.
  Bert: My concern; There's 2 kinds of applications. Fancy applications
        with filters and everything, want control,
  Bert: On the other hand, there's reading a document. Don't want
        scrollbars to change,
  Bert: It would interfere with the ability to read the document.
  Bert: If control to the user or author?
  Bert: Switch "I don't want the author to interfere."
  Bert: For myself, go fullscreen for readability. That's lost if
        scrollbars are not there.
  <TabAtkins> If you're reading a document, and the author's screwing
              with scrollbars, that's a broken document. ^_^

  ChrisL: Author precedence vs. user precedence is solved with UA,
          author, and user stylesheets
  ChrisL: You should be able to switch with user stylesheets.
  <TabAtkins> * { filter: none; }
  <TabAtkins> * { filter: none; /* I just want to read a document,
              dammit. */ }

  Bert: That's not good enough both ways. Filter is on scrollbar, but
        there's still no control on width of the scrollbar. Already
        that's not good enough
  krit: It's not just filters, all effects.
  krit: It's fine if we want to fix it in the future to make sites more
        accessible.
  Bert: Even in document mode, some filters might be useful, but for
        content only.

  <TabAtkins> Authors can ruin your document reading/scrolling
              experience already, in plenty of ways, if they're hostile
              or incompetent.
  <TabAtkins> body { overflow: hidden; }, and do all scrolling in JS.
  <TabAtkins> overflow:hidden;height:100%;

  krit: Now, no resolution for this. Do we want an issue in the spec?
  krit: Or address the issue later?
  plinss: We can defer, but let's solve it if we can.
  krit: We can solve it by saying "it should never affect" or "it should
        affect" however Bert wants more control.
  plinss: We can add controls in the future.
  plinss: Can we live without it for a while?

  <TabAtkins> Again, filters are but one way someone can incompetently
              ruin someone's experience. It's nothing new, nor is it
              particularly easy to misuse. We're worrying too much about
              this.

  plinss: Also concerns are: Filter on scrollbar may or may not be
          useful. Do we want to clip? Does it make scrollbars
          unreachable?

  [dbaron reads TabAtkins's comments]

  plinss: Can we resolve than filters just affect UI?
  plinss: And at some point work on controls?
  <dbaron> +1
  fantasai: Leave them undefined.
  dbaron: There's no need.

  RESOLVED: Effects affect scrollbars and focus rings. We may work on
            controls later.

VTT ::cue pseudo-element
------------------------

  plinss: As long as they inform us of this is happening, we're ok with
          the TTML WG working on this

  RESOLVED: CSSWG is fine with TTMLWG working on this, with ongoing
            feedback.

  [discussing topics]
  plinss: Sounds like we're out of agenda for today
  dino: http://www.w3.org/TR/css-text-decor-3/#text-decoration-skip-property
  fantasai: counter styles?

CSS Counter Styles
------------------

  fantasai: I'm correcting things in the algorithms
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0378.html
  fantasai: This is about Hebrew, how to support 1000.
  fantasai: We need a group separator feature.
  fantasai: There are lots of digits valid in English, a separator is
            needed in Hebrew.
  fantasai: The spec has no separators now, that limits Hebrew to small
            numbers.
  fantasai: We could add the feature. That solves the Hebrew problem and
            allows comma for English.

  <TabAtkins> The Hebrew style is acceptable to everyone as it is right
              now.
  <TabAtkins> The only remaining issue is some feedback about Chinese
              and Korean informal styles.

  fantasai: We cando it now, or defer.
  <TabAtkins> Defer!
  SteveZ: The commenter said he'd never seem numbers beyond that
          limitation.
  SteveZ: +1 for Tab's defer
  plinss: Anyone against deferring?

  plinss: So we can't do commas in Latin? That seems like an oversight.
  fantasai: It's not hard to do. "<character> <number of digits>", then
            we don't have to deal with this spec for 10 years.

  <Bert> (Add a note somewhere to say the system is known to be
         unsatisfactory for Hebrew beyond 400?)

  <TabAtkins> Here's the only issue that's still open:
http://dev.w3.org/csswg/css-counter-styles/issues-lc-20130718.html#issue-11
  <TabAtkins> It would be cool if some Korean and Chinese speakers there
              at TPAC could review it.

  SteveZ: Is it clear what happens with separators in all counter
          styles?
  dbaron: If we do English commas, people will want to do Indian style
          grouping.
  SteveZ: The standard large number for Indian is 100k, "lakh", they
          don't count in millions.
  * leif lakh 1,00,000 crore 1,00,00,000

  <TabAtkins> You can fake English commas up to 10k, same as I fake the
              CJK styles.
  <TabAtkins> That's more than enough. We *really* don't need to
              optimize for a counter style displaying 1billion.
  <glazou> Why not?
  <TabAtkins> additive-symbols: "10," 10000, "9," 9000, etc.
  <SimonSapin> Glazou, in ordered lists and page numbers?
  <glazou> Right.
  <TabAtkins> glazou: Because then I'd need to basically specify CLDR?
  <TabAtkins> Which is a cool idea, but not something I'm interested in
              for this spec.
  <glazou> I can perfectly imagine an ordered list of 6 billions human
           beings in an XML instance.
  <TabAtkins> glazou: I challenge you to display a list of 6 billion in
              a browser.
  <TabAtkins> Particularly with Blink/WebKit's terrible, terrible
               O(n^2) counter implementation.
  <glazou> I challenge you to be able to think of a browser doing
            partial rendering.
  <TabAtkins> glazou: 6 billion DOM nodes'll still eat your entire
               computer's RAM
  <glazou> Today's computer RAM, sure,
  <glazou> And my or your computer's RAM.
  <glazou> in R&D or NSA, not an issue
  * sgalineau in the future, people will list all human beings in one
              XML document!
  <glazou> or stars in the sky, more poetic :-)

  plinss: I'm not hearing interest, defer?

  <TabAtkins> Yes, #11 is still open. Please find Korean and Chinese
             speakers and point them at it.
  <TabAtkins> You people are IN CHINA. I think you can find a few.
  <TabAtkins> No reason to talk about it right now.

  dbaron_: The issue tracking link at the top of the spec links to no
           issues in Bugzilla.
  <dbaron_> http://dev.w3.org/csswg/css-counter-styles-3/ says
            "Issue Tracking" ->
https://www.w3.org/Bugs/Public/buglist.cgi?component=Counter%20Styles&product=CSS&resolution=---
            -> "Zarro Boogs Found"

  <dbaron_> Could you give us a URL for issue 11?
  <fantasai> http://dev.w3.org/csswg/css-counter-styles/issues-lc-20130718#issue-11
  <TabAtkins> dbaron_: Yeah, I wasn't listing the LC issues in bugzilla.
  <TabAtkins> I did:
http://dev.w3.org/csswg/css-counter-styles/issues-lc-20130718.html#issue-11
  <dbaron_> Since the "Issue Tracking" link at the top of the spec
            doesn't seem to be useful.

  fantasai: we'll track down some native speakers for issue 11.
  * krit We don't just need Chinese people, but people also speaking
         English. A much harder problem.
  <TabAtkins> Nah, there's enough translators around to work.
  <koji> I can ask Bobby for Chinese, Tab, can you ask Jungshik for
         Korean?

  plinss: Come back to this tomorrow?

  * glazou reminds the WG he has a lot of koreans in his address book
           now...
  * fantasai suggests glazou take an action item for issue 11 then :)
  ACTION: GLAZOU TO ASK KOREA ABOUT CSS
  <trackbot> Created ACTION-594 - Ask korea about css [on Daniel Glazman
             - due 2013-11-18].

  fantasai: Zhiqiang Zhang is sitting in on the meeting tomorrow - he
            was at TTWF and is strongly bilingual.

  plinss: We're adjourned for the day

[Meeting Ended]
Received on Wednesday, 20 November 2013 12:33:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 November 2013 12:33:39 UTC