/irc-logs / w3c / #css / 2012-12-12 / end

Options:

# Session Start: Wed Dec 12 00:00:00 2012
# Session Ident: #css
# [00:07] * Joins: SimonSapin (~simon@public.cloak)
# [00:16] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [00:52] * sylvaing_away is now known as sylvaing
# [01:20] * Quits: arno (~arnog@public.cloak) (Ping timeout: 60 seconds)
# [01:38] * sylvaing is now known as sylvaing_away
# [01:42] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [01:51] * heycam is now known as heycam|away
# [01:58] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [02:02] * Joins: rhauck (~Adium@public.cloak)
# [02:03] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:05] <jdaggett> hmmm
# [02:05] <jdaggett> dev.w3.org appears to be down...
# [02:05] <jdaggett> 503 error == great sadness in poohville
# [02:21] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
# [02:22] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [02:59] * heycam|away is now known as heycam
# [03:00] <fantasai> jdaggett: http://lists.w3.org/Archives/Public/www-style/2012Dec/0148.html
# [03:00] <fantasai> jdaggett: Think that should close http://www.w3.org/Style/CSS/Tracker/issues/292 ?
# [03:01] <jdaggett> hmmm, what about the normal case?
# [03:02] <jdaggett> i.e. line-break: auto/normal/whatever
# [03:02] <jdaggett> seems like there's still an issue of priorities b/t the two props
# [03:03] <jdaggett> it seems like what you and koji want to spec is clearly line-break has higher priority
# [03:03] <jdaggett> fantasai: ^
# [03:03] <fantasai> jdaggett: normal just says "use the normal rules"
# [03:03] <fantasai> jdaggett: so there's no conflict :)
# [03:03] <fantasai> sorry
# [03:03] <fantasai> "usual" rules
# [03:04] <jdaggett> so line-break: normal; word-break: keep-all; means what?
# [03:04] <fantasai> jdaggett: means use the usual line-break rules, except you can't break between two letters
# [03:05] <jdaggett> so line-break has higher priority effectively
# [03:05] <jdaggett> i just think the spec needs to be explicit about that
# [03:05] <fantasai> not really
# [03:05] <fantasai> line-break says that you can break before small kana for 'line-break: normal'
# [03:06] <fantasai> but 'word-break: keep-all' says you can't break between letters, not even when line-break says you can
# [03:06] <fantasai> so 'word-break: break-all' has less priority than 'line-break'
# [03:06] <fantasai> but 'word-break: keep-all' has more
# [03:07] * Joins: dbaron (~dbaron@public.cloak)
# [03:07] <jdaggett> uh, please leave the issue open for another day...
# [03:07] <fantasai> ok...
# [03:07] <fantasai> I think the spec is clear now, though
# [03:08] * jdaggett is writing tests for case insensitivity which is giving him a headache
# [03:08] <fantasai> aww
# [03:08] * fantasai wrote a test for case insensitivity, maybe it helps...
# [03:08] * fantasai tries to find it
# [03:09] * jdaggett why isn't the internationalization group doing this instead of only writing a single, quirks mode test...
# [03:09] <jdaggett> http://people.mozilla.org/~jdaggett/tests/casesensitivity-classid.html
# [03:09] * fantasai probably because they don't have many person-hours, and they're overloaded already
# [03:09] <jdaggett> http://people.mozilla.org/~jdaggett/tests/casesensitivity-tagnames.html
# [03:09] <jdaggett> http://people.mozilla.org/~jdaggett/tests/casesensitivity-inputs.html
# [03:10] <jdaggett> http://people.mozilla.org/~jdaggett/tests/casesensitivity-jsmimetype.html
# [03:10] <jdaggett> http://people.mozilla.org/~jdaggett/tests/casesensitivity-charset.html
# [03:10] <jdaggett> Gecko rendering of iframes sucks...
# [03:10] <jdaggett> and the Opera/Gecko handling of dotted uppercase I is peculiar
# [03:11] <jdaggett> i.e. the <input type="radio"> case with a dotted I
# [03:12] <fantasai> data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8c3R5bGU%2BDQo6bm90KHN0eWxlKSB7IGRpc3BsYXk6IGJsb2NrOyB9DQphw6lyacOfIHsgYmFja2dyb3VuZDogZ3JlZW47IH0NCmFlcklTUyB7IGJhY2tncm91bmQ6IGdyZWVuOyB9DQpBZXLEsXMgeyBiYWNrZ3JvdW5kOiBncmVlbjsgfQ0KQUVSSVRIIHsgYmFja2dyb3VuZDogZ3JlZW47IH0NCjwvc3R5bGU%2BDQoNCjxhw6lyacOfPmNhc2UtbWF0Y2g8L2HDqXJpw58%2BDQo8QcOpUmnDnz5BU0NJSS1mb2xkPC9Bw6lSacOfPg0KPEHDiVJpw58%2BTGF0aW4tZm9sZDwvQcOJUmnDnz4NCjxhw6lyaVNTPkVzemV0LWZvbGQg[CUT]
# [03:12] <fantasai> # [22:36] <fantasai> (this is selector matching; would need another test for tag-closing)
# [03:12] <fantasai> um
# [03:12] <fantasai> wrong paste buffer
# [03:12] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2011
# [03:13] <fantasai> that's a test for selector tag name matching
# [03:13] <jdaggett> ah, someone with multiple paste buffers, leave the simple life for others...
# [03:14] * fantasai would prefer one, but this is an OS quirk
# [03:14] <fantasai> afaict, Gecko and Chrome do ASCII-insensitivity, while Opera does Unicode lowercasing (not case-folding)
# [03:15] * fantasai hasn't tested IE
# [03:15] <jdaggett> nope
# [03:15] <jdaggett> the plot is much thicker than that
# [03:15] <jdaggett> especially for attributes
# [03:15] <fantasai> oh, I am not surprised at alllll
# [03:16] <jdaggett> plus, implementations vary across platform
# [03:16] <jdaggett> which means there are likely OS dependencies involved
# [03:17] <fantasai> >_<
# [03:17] <jdaggett> my favorite: a <mark> tag with the kelvin sign works just fine...
# [03:17] <jdaggett> very useful indeed
# [03:17] <fantasai> ...
# [03:17] <fantasai> That might be an artifact of Unicode normalization
# [03:17] <fantasai> since that gets folded to ASCII in NFC, IIRC
# [03:17] <jdaggett> no
# [03:18] <jdaggett> if there was normalization going on, you'd see matches in the case of diacritics
# [03:18] <jdaggett> which i tested for :P
# [03:18] <jdaggett> http://people.mozilla.org/~jdaggett/tests/casesensitivity-classid.html
# [03:18] <jdaggett> note the russian case
# [03:18] <jdaggett> (scroll down to see attribute selectors)
# [03:19] <jdaggett> and naturally webkit/osx doesn't deal with non-BMP characters
# [03:23] <fantasai> Sounds like the results are going to be all kinds of fun to analyze...
# [03:23] <jdaggett> in terms of casefolding.txt, webkit appears to be doing C only, while gecko/opera are doing C+S with bugs
# [03:23] <jdaggett> yup
# [03:23] <fantasai> heh
# [03:23] <jdaggett> no one is doing F
# [03:23] <fantasai> can the bugs be explained by lowercasing instead of case-folding?
# [03:24] * fantasai noted some issues with Opera that looked that way
# [03:24] <jdaggett> do you have a testcase for that?
# [03:24] <fantasai> yeah, the one I posted
# [03:27] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2011
# [03:27] <fantasai> The last set, Turkish i, seems to work that way
# [03:27] <fantasai> if Opera was lowercasing both and then matching, the results would be what we see there
# [03:27] <jdaggett> hard to know what they're doing
# [03:28] <fantasai> Because they match capital dotted i to ASCII i
# [03:28] <fantasai> but don't match lowercase dotless i to anything
# [03:28] <fantasai> it's already lower-case, so it wouldn't be affected by a lowercasing operation
# [03:28] <fantasai> and nothing lowercases to it by default
# [03:29] <fantasai> whereas dotted capital I lowercases to ASCII i
# [03:29] <fantasai> Another problem here is canonicalization
# [03:29] <fantasai> e.g. what an OM returns
# [03:29] <jdaggett> ah, good point
# [03:29] <fantasai> if we are case-insensitive and do it by transforming the case from what the author put in *and return that*
# [03:30] <fantasai> it's going to be REALLY confusing
# [03:30] * jdaggett looks for his aspirin supply...
# [03:30] <fantasai> and in that case, if we are doing that, I'd go with an Unicode operation
# [03:30] <fantasai> ...
# [03:31] <fantasai> but if we're just matching
# [03:31] <fantasai> ASCII insensitivity should be okay, because the author can just assume things are case-sensitive and have things work
# [03:31] <fantasai> by writing things in the same case all the time
# [03:31] <jdaggett> i think the problem here is that until we have a solid alg for what the case insensitive match is
# [03:32] <jdaggett> it's hard to see how all this effort is worth it
# [03:32] <fantasai> We have several :)
# [03:32] <fantasai> that's the issue
# [03:32] <fantasai> if we just had one, we'd use it and be done =)
# [03:32] <jdaggett> i have seen no algorithmic def'n of what "full" unicode case matching means in this context
# [03:33] <jdaggett> everyone talks about it as if it's a single thing
# [03:33] <jdaggett> while the unicode docs make it very clear there are a number of things that need to be decided
# [03:33] <fantasai> "# B. To do a full case folding, use the mappings with status C + F."
# [03:33] <jdaggett> and normalization?
# [03:34] <jdaggett> kind of silly to do F without normalization
# [03:34] <fantasai> I think our policy thus far has been that normalization doesn't exist...
# [03:34] <fantasai> Don't ask, don't tell. :)
# [03:34] <jdaggett> like i say, someone needs to lay out the full algorithm
# [03:34] <jdaggett> unicode has this:
# [03:34] <jdaggett> http://www.unicode.org/reports/tr31/
# [03:35] <jdaggett> not exactly easy peasy, lemon squeezy
# [03:35] <fantasai> not exactly, no.
# [03:35] <fantasai> anyway, I gotta run. :)
# [03:35] <fantasai> ttyl
# [03:48] * Quits: lmclister (~lmclister@public.cloak) ("")
# [03:53] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [05:28] * heycam is now known as heycam|away
# [05:43] * Joins: cabanier (~cabanier@public.cloak)
# [06:05] * Joins: cabanier1 (~cabanier@public.cloak)
# [06:07] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [06:27] * Joins: cabanier (~cabanier@public.cloak)
# [06:27] * Quits: cabanier1 (~cabanier@public.cloak) (Client closed connection)
# [06:49] * Joins: dbaron (~dbaron@public.cloak)
# [06:56] * heycam|away is now known as heycam
# [07:00] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [07:39] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [08:00] * Joins: SimonSapin (~simon@public.cloak)
# [08:06] * Joins: glazou (~glazou@public.cloak)
# [08:06] <glazou> hmmm fantasai gone apparently
# [08:06] <glazou> fantasai: yt?
# [08:07] <glazou> has anyone any idea where this section comes from ? http://dev.w3.org/csswg/mediaqueries4/#pointer
# [08:11] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [08:11] * Joins: SimonSapin (~simon@public.cloak)
# [08:12] * Quits: glazou (~glazou@public.cloak) ("bbl")
# [08:51] * heycam is now known as heycam|away
# [09:11] * Joins: cabanier (~cabanier@public.cloak)
# [09:23] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:41] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [10:05] * Joins: teoli (~teoli@public.cloak)
# [10:23] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [10:25] * Joins: SimonSapin (~simon@public.cloak)
# [10:36] * Joins: drublic (~drublic@public.cloak)
# [11:09] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [11:21] * leaverou is now known as leaverou_away
# [11:31] * Quits: {Darktears} (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [11:31] * Joins: {Darktears} (~darktears@public.cloak)
# [12:06] * Joins: drublic_ (~drublic@public.cloak)
# [12:06] * Quits: drublic (~drublic@public.cloak) (Ping timeout: 60 seconds)
# [12:15] * Quits: drublic_ (~drublic@public.cloak) (Client closed connection)
# [12:19] * Joins: drublic (~drublic@public.cloak)
# [12:45] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [12:45] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [13:10] * leaverou_away is now known as leaverou
# [13:32] * leaverou is now known as leaverou_away
# [13:55] * leaverou_away is now known as leaverou
# [14:15] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [14:42] * Quits: heycam|away (~cam@public.cloak) (Ping timeout: 60 seconds)
# [16:35] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
# [16:57] * Joins: danielfi_ (~danielfilho@public.cloak)
# [16:57] * Quits: danielfilho|w (~danielfilho@public.cloak) (Client closed connection)
# [17:00] * Joins: SteveZ (~chatzilla@public.cloak)
# [17:12] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
# [17:22] * Joins: glazou (~glazou@public.cloak)
# [17:22] * Joins: Zakim (zakim@public.cloak)
# [17:23] * Joins: RRSAgent (rrsagent@public.cloak)
# [17:23] <RRSAgent> logging to http://www.w3.org/2012/12/12-css-irc
# [17:23] <glazou> Zakim, this will be Style
# [17:23] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 34 minutes
# [17:23] <glazou> RRSAgent, make logs public
# [17:23] <RRSAgent> I have made the request, glazou
# [17:31] * Joins: cabanier (~cabanier@public.cloak)
# [17:33] * Joins: jet (~jet@public.cloak)
# [17:34] * Joins: arno (~arnog@public.cloak)
# [17:37] * Joins: antonp (~Thunderbird@public.cloak)
# [17:42] * Joins: lmclister (~lmclister@public.cloak)
# [17:51] * Joins: arno1 (~arnog@public.cloak)
# [17:51] * Joins: sylvaing (~sylvaing@public.cloak)
# [17:52] * Quits: lmclister (~lmclister@public.cloak) ("")
# [17:52] * Quits: arno (~arnog@public.cloak) (Ping timeout: 60 seconds)
# [17:53] <Zakim> Style_CSS FP()12:00PM has now started
# [17:53] <Zakim> +plinss
# [17:53] * Joins: florian (~florian@public.cloak)
# [17:55] <Zakim> +??P50
# [17:55] * Joins: lmclister (~lmclister@public.cloak)
# [17:55] <florian> Zakim, I am ??P50
# [17:55] <Zakim> +florian; got it
# [17:56] <Zakim> +hober
# [17:56] <Zakim> +??P55
# [17:56] <glazou> Zakim, ??P55 is me
# [17:56] <Zakim> +glazou; got it
# [17:56] <Zakim> +[Microsoft]
# [17:56] <sylvaing> Zakim, [Microsoft]has me
# [17:56] <Zakim> I don't understand '[Microsoft]has me', sylvaing
# [17:56] <sylvaing> Zakim, [Microsoft] has me
# [17:56] <Zakim> +sylvaing; got it
# [17:57] * Joins: leif (~leif@public.cloak)
# [17:57] * Joins: oyvind (~oyvinds@public.cloak)
# [17:57] * Joins: smfr (~smfr@public.cloak)
# [17:57] * Joins: glenn (~gadams@public.cloak)
# [17:58] <Zakim> +smfr
# [17:58] <smfr> why doesn't the conf. bridge let me type the code sooner?
# [17:58] * Joins: cabanier1 (~cabanier@public.cloak)
# [17:58] * Quits: cabanier (~cabanier@public.cloak) (Client closed connection)
# [17:58] <Zakim> + +34.93.192.aaaa
# [17:58] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
# [17:58] <glazou> smfr: same thing happened to me
# [17:58] * hober smfr: srsly
# [17:58] <Zakim> +leif
# [17:58] <antonp> Zakim, aaaa is me
# [17:58] <Zakim> +antonp; got it
# [17:58] * Joins: SimonSapin1 (~simon@public.cloak)
# [17:58] * Quits: SimonSapin (~simon@public.cloak) (Client closed connection)
# [17:58] <smfr> it has enough acronyms, it should be able handle this!
# [17:59] * Joins: JohnJansen (~JohnJansen@public.irc.w3.org)
# [17:59] <Zakim> +??P37
# [17:59] * {Darktears} is now known as darktears
# [17:59] <Zakim> +fantasai
# [17:59] <sylvaing> smfr, probably runs on a PDP-11 in MIT's basement
# [17:59] * hober smfr: because it's really, really important for you to know that zakim is a customized Compugenix Contex conferencing system
# [17:59] <darktears> Zakim, ??P37 is me
# [17:59] <Zakim> +darktears; got it
# [17:59] <Zakim> +??P78
# [17:59] <glenn> zakim, ??p78 is me
# [17:59] <Zakim> +glenn; got it
# [18:00] * hober s/Compugenix/Compunetix/
# [18:00] <Zakim> +[Microsoft.a]
# [18:00] * sylvaing you know, maybe that voice is a real dude sitting in front of a panel with a bunch of connecting wires
# [18:00] <smfr> hober: http://www.compunetix.com/ix/assets/pdfs/products/CONTEX_240_480.pdf
# [18:00] * Quits: cabanier1 (~cabanier@public.cloak) ("Leaving.")
# [18:00] <Zakim> +SteveZ
# [18:00] <Zakim> +SimonSapin
# [18:00] <smfr> "The CONTEX conferencing platform is the most reliable in the industry. CONTEX systems feature continuous real-time diagnostics, hot-swappable and self-healing system designs and are built to military standards with patented space-division switching architecture"
# [18:00] <glenn> that's ralph swick talking
# [18:00] * TabAtkins_ sylvaing, you know, that explains the existential dread in the voice.
# [18:00] <JohnJansen> Zakim, Microsoft has JohnJansen
# [18:00] <Zakim> +JohnJansen; got it
# [18:01] * Joins: rhauck (~Adium@public.cloak)
# [18:01] * sylvaing 'military standards': the qualifier that always explains EVERYTHING
# [18:01] <Zakim> +[Microsoft.aa]
# [18:01] <glazou> sylvaing: military… you think of the html5 and CSS3 logos ?-)
# [18:01] <Zakim> + +1.832.797.aabb
# [18:01] <arronei> zakim, microsoft has me
# [18:01] <Zakim> +arronei; got it
# [18:01] <TabAtkins_> zakim, aabb is me
# [18:01] <Zakim> +TabAtkins_; got it
# [18:01] * leif instead of living standards they have killing standards
# [18:02] <Zakim> +??P92
# [18:02] * hober glazou: speaking of which, when did this group resolve on that logo? :)
# [18:02] <glazou> we never did
# [18:02] * sylvaing yeah, let's talk about the logo!
# [18:02] <TabAtkins_> ScribeNick: TabAtkins_
# [18:02] <TabAtkins_> plinss: Any additions?
# [18:02] <TabAtkins_> glazou: If florian is here, we can discuss the MQ issue.
# [18:03] <TabAtkins_> florian: yeah, I'm here, and we can discuss it.
# [18:03] <smfr> Agenda: http://lists.w3.org/Archives/Public/www-style/2012Dec/0147.html
# [18:03] <TabAtkins_> fantasai: Maybe discuss setting up a call for text-related issues before bringing it to the WG, with a time that actually works for Japan?
# [18:03] <TabAtkins_> fantasai: And just a subset of people that are interested.
# [18:04] <TabAtkins_> Topic: Flexbox issue
# [18:04] <plinss> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
# [18:05] <TabAtkins_> rossen: We needed to consider the case from last week... I think we respondedto it on the mailing list.
# [18:05] <TabAtkins_> rossen: The behavior you're proposing as a change to the spec is okay with us.
# [18:05] <TabAtkins_> rossen: A separate issue was raised int he same thread.
# [18:05] * Joins: tantek (~tantek@public.cloak)
# [18:05] * SimonSapin1 is now known as SimonSapin
# [18:06] <TabAtkins_> rossen: The cross size of items affecting the main size, due to intrinsic aspect ratios.
# [18:06] * Joins: Rossen (~Rossen@public.cloak)
# [18:07] <TabAtkins_> TabAtkins_: As the algorithm currently sits, once the main size is set, the cross size cant' affect it any more.
# [18:07] <Rossen> http://jsfiddle.net/69qda/4/
# [18:07] <TabAtkins_> Rossen: One remaining problem we ahve with this is that in such cases you might end up with overlapping items.
# [18:08] <Zakim> -smfr
# [18:08] <Zakim> +smfr
# [18:09] <fantasai> TabAtkins_: You should never end up with overlapping items.
# [18:09] <fantasai> TabAtkins_: Chrome is wrong here right now; that's just a bug.
# [18:09] <fantasai> TabAtkins_: Changing the cross-size after resolving flexible lengths is not allowed to go back and affect the main size again.
# [18:10] <TabAtkins_> Rossen: So we determine the main size based on this, we'll lay out all the items to figure out the line-breaks, then determine their cross size.
# [18:10] <TabAtkins_> Rossen: In this case, once the cross size is determined, it'll drive the main size of the image.
# [18:11] <Zakim> +Lea
# [18:11] <TabAtkins_> Rossen: So we'll go and reevaluate the linebreaks.
# [18:11] <TabAtkins_> TabAtkins_: That behavior is incorrect per spec.
# [18:12] <TabAtkins_> Rossen: Right. I think our current behavior sometimes results in better results, but we need to make sure it's sane.
# [18:12] <TabAtkins_> Rossen: sometimes, of course, you might push the item that is stretching to the next line, and when things get reevaluated, things stretch which shouldn't.
# [18:12] <TabAtkins_> Rossen: So there are problems with this behavior, but we want to minimize by default overlaps of flex items.
# [18:13] <TabAtkins_> Rossen: This is specifically about the multiline case, where the cross size can't be determined ahead of time.
# [18:14] * Quits: jet (~jet@public.cloak) (Client closed connection)
# [18:15] <TabAtkins_> TabAtkins_: As the spec currently stands, the result is sometimes ugly (doesn't honor the item's ratio), but it's stable and easy. I don't think it's possible to do something else without a "layout repeatedly until you reach a stable state" thing.
# [18:15] <TabAtkins_> Rossen: Okay, let's work out details on the list and pick it up again next week just in case.
# [18:16] <TabAtkins_> Topic: Animation issues
# [18:17] * fantasai notes dbaron is not here today
# [18:17] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16116
# [18:17] * TabAtkins_ we can try to work out ones that don't need dbaron
# [18:17] <sylvaing> http://dev.w3.org/csswg/css3-animations/#animations
# [18:17] <TabAtkins_> sylvaing: This one is a terminology issue that Dirk noticed in the spec.
# [18:18] <TabAtkins_> sylvaing: There's a diagram that talks about "intrinsic style", but doesnt' define what that means.
# [18:18] <fantasai> TabAtkins_: Seems like what it means is the style without Animations applied
# [18:19] <darktears> initial style -> final style (after animation run)
# [18:19] <TabAtkins_> sylvaing: The intent of the bug was to say that it should point to an existing phrase.
# [18:20] <fantasai> static style / animated style?
# [18:20] <TabAtkins_> smfr: Do we have a document listing the terms for th existing style levels?
# [18:20] <fantasai> http://dev.w3.org/csswg/css3-cascade/
# [18:20] <TabAtkins_> fantasai: Cascade.
# [18:21] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14784
# [18:21] <TabAtkins_> TabAtkins_: Even if we don't define a new term, the diagram is wrong and should have a short phrase rather than "specified" and "computed" style.
# [18:21] <TabAtkins_> sylvaing: next is some grammar issues.
# [18:21] <TabAtkins_> sylvaing: One is user-defined ident case-sensitivity, which is still pending.
# [18:21] * Joins: krit (~krit@public.cloak)
# [18:22] <TabAtkins_> sylvaing: Another is that the animation and transition specs both define the timing functions, and we should reallyd efine it onlyl once.
# [18:22] * Quits: SteveZ (~chatzilla@public.cloak) (Client closed connection)
# [18:22] * Joins: SteveZ (~chatzilla@public.cloak)
# [18:22] <TabAtkins_> sylvaing: Can we define that Animations is dependent on Transitions for this?
# [18:22] <TabAtkins_> [several]: yeah
# [18:22] <TabAtkins_> sylvaing: Now about the user-ident stuff, how is that going?
# [18:22] <TabAtkins_> fantasai: jdaggett just wrote a bunch of tests for it, and posted to the list.
# [18:23] <TabAtkins_> glazou: I pinged i18n about it too.
# [18:23] * fantasai actually not sure if it's posted to the list yet, didn't see
# [18:23] * fantasai goes looking
# [18:23] <TabAtkins_> RESOLVED: Transitions defines the timing functions, Animations has normative dependency on Transitions for them.
# [18:23] * plinss I saw it on www-style this morning
# [18:23] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15251
# [18:23] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0149.html
# [18:23] <TabAtkins_> sylvaing: This bug is about prose in the spec along the lines of...
# [18:23] <sylvaing> posted here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0542.html
# [18:24] <sylvaing> wrong link: http://lists.w3.org/Archives/Public/www-style/2011Dec/0144.html
# [18:24] * plinss fantasai - http://www.w3.org/mid/1545635835.4991697.1355317846925.JavaMail.root@mozilla.com
# [18:25] <TabAtkins_> sylvaing: Spec says that animation-start events are dispatched for each animatino-name in the list, but impls don't fire if the @keyframes rule is empty.
# [18:25] <TabAtkins_> smfr: I think we should define more strictly when an animation runs, and just say that empty keyframes don't run an animation.
# [18:26] <TabAtkins_> TabAtkins_: Is there any compat impact for just making an empty @keyframes invalid?
# [18:26] <TabAtkins_> sylvaing: I was thinking about that. There's a potential compat case - if a keyframe "foo" is overridden by another "foo" which is empty, it'll hide it.
# [18:27] <TabAtkins_> smfr: I think it makes sense to have it be valid, so you can start with an empty @keyframes rule and fill it with script.
# [18:27] <TabAtkins_> TabAtkins_: Makes sense.
# [18:27] <TabAtkins_> smfr: I think we can define that a side-effectof an animation running is that animations fire, and empty keyframes don't run.
# [18:29] <TabAtkins_> sylvaing: Missing 0% and 100% keyframes are filled in by the UA, so one's never actually empty, right?
# [18:29] <TabAtkins_> TabAtkins_: Those don't show up in the OM, thoguh - we just fill in values to the actual animation.
# [18:29] <TabAtkins_> sylvaing: Okay, so I'm okay with that. We can specify that an animation runs only if it has one or more valid keyframes.
# [18:29] <TabAtkins_> RESOLVED: Animations only "run" (fire start events, etc) if they have at least one valid keyframe.
# [18:30] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14785
# [18:30] * Quits: SteveZ (~chatzilla@public.cloak) (Client closed connection)
# [18:30] <TabAtkins_> sylvaing: Next is display:none effects.
# [18:30] <TabAtkins_> sylvaing: display:none stops animations.
# [18:30] <TabAtkins_> sylvaing: We didn't clearly write down when you go from display:none to non-none.
# [18:30] <TabAtkins_> sylvaing: Our assumptions in IE is that animations will start, but not transitions.
# [18:31] <TabAtkins_> sylvaing: I think it's reasonable to agree ont he animations thing now, but maybe not transitions without dbaron around.
# [18:31] * Joins: SteveZ (~chatzilla@public.cloak)
# [18:31] <TabAtkins_> TabAtkins_: I agree about animations.
# [18:32] <TabAtkins_> RESOLVED: When an element changes from display:none to display: non-none, animations start immediately.
# [18:32] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14774
# [18:32] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0214.html
# [18:33] <TabAtkins_> sylvaing: This is about adding animation-play-state:paused when an animation isn't yet running.
# [18:33] <TabAtkins_> sylvaing: Today, FF and IE10 freeze the animation on its first frame (or dont' show anything, if it's delayed).
# [18:33] <TabAtkins_> sylvaing: Related, what if you're in delay, and you flip to pause.
# [18:34] <TabAtkins_> TabAtkins_: I think dbaron said that FF just freezes the remaining delay and continues with it when you unpause.
# [18:34] * Joins: cabanier (~cabanier@public.cloak)
# [18:35] * Joins: jet (~jet@public.cloak)
# [18:35] <TabAtkins_> sylvaing: [checking whether animation-fill-mode affects the immediately-paused animation]
# [18:37] <TabAtkins_> TabAtkins_: Does it fire an animationStart event? I think it should, since it's already displaying the start of the animations.
# [18:37] <TabAtkins_> sylvaing: Based on quick testing, looks like IE and FF don't. But we think that it should?
# [18:37] <TabAtkins_> TabAtkins_: yeah.
# [18:37] <TabAtkins_> sylvaing: What effects would this have on elapsedTime? I think it's relative to the animation, not absolute.
# [18:37] <TabAtkins_> smfr: I think so - the time the animation ahs already been running.
# [18:37] <smfr> ^elapsedTime
# [18:38] <TabAtkins_> RESOLVED: An initially-paused animation is still started (fires start events, etc.)
# [18:38] <smfr> and it may be paused during the delay phase
# [18:39] <TabAtkins_> RESOLVED: Animations can be paused during their delay phase, which freezes the remaining delay to be applied after it unpauses.
# [18:39] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14787
# [18:40] <Zakim> -hober
# [18:40] <TabAtkins_> sylvaing: Is it intentional that animation-play-state can't be applied int he shorthand?
# [18:40] <Zakim> +hober
# [18:40] <TabAtkins_> smfr: I think it was intentional, because of potential ambiguity collision with animation names, and low possibility of usefulness.
# [18:41] <TabAtkins_> sylvaing: I'm fine with that.
# [18:41] <TabAtkins_> RESOLVED: animation-play-state is not in the shorthand on purpose
# [18:41] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14786
# [18:42] <glazou> Zakim, mute me
# [18:42] <Zakim> glazou should now be muted
# [18:42] <glazou> Zakim, unmute me
# [18:42] <Zakim> glazou should no longer be muted
# [18:42] <smfr> agreed
# [18:42] <TabAtkins_> sylvaing: The behavior of animation-play-state as a list isn't defined. I imagine it's just the same as the other properties (cycled until it reaches the length of animation-name list)?
# [18:43] <TabAtkins_> RESOLVED: animation-play-state has the same list behavior as the other animation properties, matching the length of animatino-name.
# [18:43] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20092
# [18:43] <plinss> s/animatino-name/animation-name/
# [18:44] <TabAtkins_> sylvaing: Tab had a proposal to add the ability to have "adjacent" keyframes, which are explicitly next to each other.
# [18:44] <TabAtkins_> sylvaing: Today you have to hack around it with "50%" and "50.00001%" or similar.
# [18:44] <TabAtkins_> florian: Sounds useful, but we have to finisht he current level, so I'd prefer to delay it.
# [18:44] <TabAtkins_> fantasai: Agreed.
# [18:45] <TabAtkins_> RESOLVED: Look into "adjacent keyframes" for level 4, but not for the current level.
# [18:45] <TabAtkins_> sylvaing: The rest are animation/transition stuff that we want dbaron for, or some interrelated bugs I need to work on.
# [18:46] <TabAtkins_> Topic: 'pointer' MQ
# [18:46] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [18:46] <TabAtkins_> glazou: The pointer MQ hasn't been discussed in the group.
# [18:46] <TabAtkins_> glazou: It may have been a side discussion, but hasn't been official.
# [18:47] <TabAtkins_> glazou: I don't want to put the burden on florian specifically, but it's a good chance to remind people on hwo the group should work. Editors can make proposals, but it shouldn't show up in the draft until it's been discussed in the group.
# [18:48] <Zakim> +[IPcaller]
# [18:48] <TabAtkins_> florian: My understanding is that when we're close to LC, nothing hits the draft until it's been discussed, but early on it's looser - we can put things int he draft so that there's *something* to discuss.
# [18:48] <tantek> Zakim, IPcaller is tantek
# [18:48] <Zakim> +tantek; got it
# [18:48] <TabAtkins_> florian: It's true that it's been in the draft longer than intended before discussion, but both I and the group have been busy.
# [18:48] <glenn> an editor's draft is an "Editor's
# [18:49] <glenn> "Editor's" draft
# [18:49] <glenn> what goes into an ED does not have to have be discussed by the group beforehand
# [18:49] * Zakim glenn, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [18:49] <TabAtkins_> glazou: What I'm hoping for is just that, if you add something to an ED, even early on, just drop an email to the group with a pointer to it.
# [18:49] <glenn> s/what/... what/
# [18:49] <tantek> glazou: when you add something to an ED, please send an email to the list
# [18:49] <TabAtkins_> glazou: That way we know about your new feature and can discuss it.
# [18:50] <TabAtkins_> glazou: I just want to make sure that we don't fall into the same trap again.
# [18:51] <TabAtkins_> glazou: [doesn't quite like the syntax]
# [18:51] <TabAtkins_> florian: I'd like to describe why I put the feature in, before discussing details.
# [18:51] <TabAtkins_> florian: My impression is that media features are... screen is used everywhere, but things like "handheld" are failures.
# [18:51] <TabAtkins_> florian: So move away from media types, and move toward media features.
# [18:52] <TabAtkins_> florian: Right now, since the mobile browsers dont' advertise themselves as "handheld", there's no good way to figure out when your'e on one.
# [18:52] <TabAtkins_> florian: [touch things arent' accurate with pointer, and you can't hover]
# [18:53] <tantek> what is it that makes a media type "special"?
# [18:53] <tantek> I think that changes too fast at this point
# [18:53] <TabAtkins_> florian: I think "print" isnt' nearly as much of a failure, but still, I'd like to add features to let you detect the *relevant thing* about being on a paper.
# [18:53] <Zakim> -SimonSapin
# [18:53] <tantek> there are no fixed axiomatic descriptions of such media types - that's what we've learned (with the exception of print)
# [18:53] <TabAtkins_> florian: 'pointer' for the level of accuracy and 'hover' for whether you can or not are, through side discussion, things that appear to be useful.
# [18:53] <fantasai> florian: I'm not very strongly attached to these specific media queries, but the general direction I think is the right way to go.
# [18:54] <fantasai> glazou: Accuracy of pointer depends on the zoom level.
# [18:54] <Zakim> +SimonSapin
# [18:54] <TabAtkins_> glazou: The accuracy of the pointer depends on the zoom level.
# [18:54] <TabAtkins_> florian: The property should describe the accuracy of the pointer at the default level.
# [18:54] * tantek agrees with glazou
# [18:54] <TabAtkins_> florian: You can make things more accurate, but it would be inconvenient for the user.
# [18:54] <TabAtkins_> hober: I raised the same point as daniel just now.
# [18:55] * Quits: arno1 (~arnog@public.cloak) ("Leaving.")
# [18:55] <TabAtkins_> hober: I think the underlying problem is that media queries in the past that have failed are because they're exclusive.
# [18:55] <TabAtkins_> hober: We should fix that first.
# [18:55] * glazou will have to leave exactly at the top of the hour because of another conf call
# [18:55] <TabAtkins_> hober: My concern in relation to the pointer media query is that, I think it's main use is to increase the size of touch targets.
# [18:56] <TabAtkins_> hober: If zoom doesn't increase these, my concern is that well get ugly-looking websites.
# [18:56] <TabAtkins_> florian: This just affects the default level of the button size, etc. When you zoom, they just scale appropriately.
# [18:56] <tantek> I also dislike the 'pointer' media query
# [18:57] <tantek> changes based on screen resolution etc.
# [18:57] <Zakim> -glazou
# [18:57] * TabAtkins_ tantek Uh, what? No it doesn't.
# [18:57] <smfr> gtg
# [18:57] * Quits: smfr (~smfr@public.cloak) (smfr)
# [18:57] <Zakim> -smfr
# [18:57] <TabAtkins_> TabAtkins_: Just to counteract everyone else, I love the media query.
# [18:57] <tantek> TabAtkins, how you'd use the mediaquery changes on pixel density
# [18:57] <tantek> fantasai: also concerned about coarse vs. fine
# [18:57] * sylvaing coarse/fine makes me think of coffee
# [18:57] * glazou thinks the pointer MQ should be removed from spec at this point
# [18:58] <tantek> I agree that "coarse" is bad
# [18:58] <TabAtkins_> tantek: No, it wouldn't. Can you give an example of why you think that?
# [18:58] * TabAtkins_ has stopped minuting.
# [18:58] * glazou tantek 'coarse' is not understandable by people with low ecnglish knowledge
# [18:58] <tantek> TabAtkijns, screens have different pixel densities, thus different "fuzziness" of what finger taps hit
# [18:58] <TabAtkins_> fantasai: [some concern about the definition of fine/course being unclear]
# [18:58] <fantasai> fantasai: how coarse is coarse? how does that inform the design?
# [18:58] <tantek> "coarse" doesn't capture it
# [18:59] <tantek> also "coarse" sounds like "CORS"
# [18:59] <Zakim> -SteveZ
# [18:59] <Zakim> -TabAtkins_
# [18:59] <Zakim> -hober
# [18:59] <Zakim> -[Microsoft.aa]
# [18:59] <Zakim> -fantasai
# [18:59] <Zakim> -[Microsoft]
# [18:59] <Zakim> -leif
# [18:59] <Zakim> -glenn
# [18:59] <Zakim> -??P92
# [18:59] <Zakim> -antonp
# [18:59] <Zakim> -plinss
# [18:59] <Zakim> -darktears
# [18:59] <tantek> another reason not to use that term
# [18:59] <Zakim> -florian
# [18:59] <Zakim> -SimonSapin
# [18:59] <TabAtkins_> tantek: Sub-pixel accuracy is completely swamped by gross size.
# [18:59] * Quits: JohnJansen (~JohnJansen@public.irc.w3.org) ("Page closed")
# [18:59] <Zakim> -tantek
# [18:59] <Zakim> -[Microsoft.a]
# [18:59] * Parts: florian (~florian@public.cloak) (florian)
# [18:59] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:59] <TabAtkins_> Seriously, 2x pixel density might vary the size fo the touch target by ~ 1/200th of an inch.
# [18:59] * Joins: liam (liam@public.cloak)
# [18:59] <TabAtkins_> That's irrelevant when we're talking about 10px high versus 20px high.
# [19:00] * Joins: SimonSapin1 (~simon@public.cloak)
# [19:00] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [19:00] * Quits: leif (~leif@public.cloak) (Ping timeout: 60 seconds)
# [19:00] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [19:00] <tantek> I also think that these are a bit present-context (this year's devices) anachronistic.
# [19:01] <tantek> part of the reason handheld and TV failed is that they were stuck with the definition of technologies that were fixed in time and obsoleted during the course of being on the WG!
# [19:01] <tantek> handheld predated large screen smartphones - which is why no "large screen mobile" devices or sites bother with "handheld"
# [19:01] <tantek> (they just use m.example.com instead of example.com)
# [19:02] <tantek> similarly with TV - was based on old analog TV resolutions, constraints ("safe area", refresh rates, single pixel line problems)
# [19:02] <tantek> that reminds me. we need to turn both the TV Profile and the Mobile Profile into Notes.
# [19:04] <Zakim> disconnecting the lone participant, Lea, in Style_CSS FP()12:00PM
# [19:04] <Zakim> Style_CSS FP()12:00PM has ended
# [19:04] <Zakim> Attendees were plinss, florian, hober, glazou, sylvaing, smfr, +34.93.192.aaaa, leif, antonp, fantasai, darktears, glenn, [Microsoft], SteveZ, SimonSapin, JohnJansen,
# [19:04] <Zakim> ... +1.832.797.aabb, arronei, TabAtkins_, Lea, tantek
# [19:06] * Quits: oyvind (~oyvinds@public.cloak) (oyvind)
# [19:07] * Quits: SimonSapin1 (~simon@public.cloak) (Ping timeout: 60 seconds)
# [19:14] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [19:26] <TabAtkins_> tantek: I agree with you there - trying to slice things into media type categories is a losing proposition.
# [19:26] <TabAtkins_> Phones to tablets to mini-books to laptops to ultrabooks to desktops are more or less a continuum these days, not separable categories.
# [19:27] <tantek> right, the hardware spectrum is filling out
# [19:27] <tantek> there *are* differences in usage patterns which strongly affect design - e.g. in "mobile" situations, you need simple clear interfaces that are focused on only a very small number of actions
# [19:28] <tantek> as opposed to when sitting a desk
# [19:28] <tantek> but "handheld" vs. "screen" does not (and will not) give you that
# [19:28] <TabAtkins_> Right, but even then, that's not really a device category. I sometimes am doing normal browsing on my phone and want the full site, and sometimes want the abbreviated easy-to-use version.
# [19:28] <TabAtkins_> I don't think you can hit that with CSS.
# [19:28] <tantek> exactly, you can be sitting at your desk using your smartphone
# [19:29] <tantek> where you can give it plenty of attention / focus / concentration, and read little details because you're not walking down the street
# [19:29] <tantek> well - we could create a media selector for inertial sensors
# [19:30] * Joins: krit (~krit@public.cloak)
# [19:30] <tantek> it's probably worth looking at all the hardware sensing WebAPIs and seeing if there is a useful higher level CSS media query selector equivalent for any of them.
# [19:31] <tantek> like we do with orientation and screen aspect ratios
# [19:31] <tantek> also, touch targets are harder to hit when walking rather than standing, or sitting
# [19:32] <tantek> so "coarse" doesn't cover it
# [19:32] <tantek> on the subject of including things in drafts to get discussion - I'm a fan of course
# [19:32] <tantek> I'm even ok with such experiments/brainstorms making it out to public working drafts
# [19:33] <tantek> I've added / removed plenty of things like that in the past, and getting them into public working drafts is what helped make the discussion happen.
# [19:33] <tantek> of course that was before public EDs became so prevalent, so maybe it doesn't apply any more?
# [19:33] <tantek> I can also see some value in whatever is in a WD (vs. ED) having some degree of consensus from the WG
# [19:34] <tantek> although that seems to vary from WG to WG, culturally as it were
# [19:34] <tantek> so there's nothing you can conclude about W3C public WGs as a whole in that regard. It could be one person's idea. It could be strongly agreed by the whole group.
# [19:35] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 60 seconds)
# [19:36] <sylvaing> I'd rather be able to add things to the WD though I'd be fine with marking it with some class that styles in a way that says 'this is only my opinion and was not discussed by the group ever'
# [19:37] <sylvaing> s/WD/ED
# [19:49] <TabAtkins> tantek: We can theoretically get into the exact correct size for touch targets based on various data, but it's not necessary. Having two values is sufficient for real-world use-cases while still being useful.
# [19:49] <TabAtkins> (Similar to how we have only three light levels - those are the minimal useful set for covering the use-cases.)
# [19:50] <TabAtkins> sylvaing: Daniel's point that an editor should at least drop a mail to the group about it immediately is fine, I think.
# [19:54] * Quits: SteveZ (~chatzilla@public.cloak) (Client closed connection)
# [19:54] * Joins: SteveZ (~chatzilla@public.cloak)
# [19:54] * Joins: florian (~florian@public.cloak)
# [19:54] * Parts: florian (~florian@public.cloak) (florian)
# [19:58] <tantek> TabAtkins - not sure about two values being sufficient. Existing UIs fail at this.
# [19:58] <tantek> E.g. touch keyboards *suck* for when your walking (nearly impossible to use)
# [19:59] <tantek> s/your/you're
# [19:59] <tantek> there's at least three levels (crappy names on purpose) : mobile-coarse, stationery-coarse, and fine
# [20:02] <TabAtkins> tantek: I think touch keyboards kinda suck all the time, personally. They're a compromise between screen space and normal keyboard layout.
# [20:04] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [20:06] * Joins: florian (~florian@public.cloak)
# [20:08] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [20:10] * Joins: SteveZ_ (~chatzilla@public.cloak)
# [20:10] * Quits: SteveZ (~chatzilla@public.cloak) (Client closed connection)
# [20:10] * SteveZ_ is now known as SteveZ
# [20:24] * Joins: rhauck (~Adium@public.cloak)
# [20:26] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [20:27] * Quits: lmclister (~lmclister@public.cloak) ("")
# [20:33] * Parts: florian (~florian@public.cloak) (florian)
# [20:39] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [20:40] * Joins: cabanier (~cabanier@public.cloak)
# [20:44] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [20:55] * Zakim excuses himself; his presence no longer seems to be needed
# [20:55] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [21:07] * Joins: arno (~arnog@public.cloak)
# [21:12] * Quits: jet (~jet@public.cloak) (jet)
# [21:21] * Joins: drublic (~drublic@public.cloak)
# [22:33] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:02] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [23:02] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [23:05] * Joins: heycam|away (~cam@public.cloak)
# [23:11] * heycam|away is now known as heycam
# [23:15] * Joins: jet (~jet@public.cloak)
# [23:24] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:25] * Joins: jet_ (~jet@public.cloak)
# [23:25] * Quits: jet (~jet@public.cloak) (Client closed connection)
# [23:26] * jet_ is now known as jet
# [23:35] * Joins: sylvaing (~sylvaing@public.cloak)
# [23:48] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:49] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [23:54] * Quits: jet (~jet@public.cloak) (Client closed connection)
# [23:55] * Joins: jet (~jet@public.cloak)
# Session Close: Thu Dec 13 00:00:00 2012

The end :)