- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Nov 2013 07:33:11 -0500
- 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