/irc-logs / w3c / #css / 2014-11-19 / end

Options:

# Session Start: Wed Nov 19 00:00:00 2014
# Session Ident: #css
# [00:03] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:19] * Joins: estellevw (~estellevw@public.cloak)
# [00:31] * Joins: tantek (~tantek@public.cloak)
# [00:49] * Quits: tantek (~tantek@public.cloak) (tantek)
# [00:51] * Joins: jdaggett (~jdaggett@public.cloak)
# [00:59] * Joins: tantek (~tantek@public.cloak)
# [01:03] * Joins: Florian (~Florian@public.cloak)
# [01:12] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [01:21] * Joins: shans_ (~shans@public.cloak)
# [01:21] * Quits: thinkxl_ (~thinkxl@public.cloak) (Ping timeout: 180 seconds)
# [01:30] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [01:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [01:37] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [01:55] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [01:56] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [02:01] * Joins: estellevw (~estellevw@public.cloak)
# [02:32] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:08] * Quits: jrossi (~jrossi@public.cloak) ("Leaving.")
# [03:32] * Joins: dwim (~dwim@public.cloak)
# [03:50] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [04:04] * Joins: estellevw_ (~estellevw@public.cloak)
# [04:08] * Quits: estellevw (~estellevw@public.cloak) (Ping timeout: 180 seconds)
# [04:08] * estellevw_ is now known as estellevw
# [04:26] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [05:08] * Quits: panzana` (~panzana@public.cloak) (Client closed connection)
# [05:14] * Joins: panzana` (~panzana@public.cloak)
# [05:23] * Quits: dholbert (~dholbert@public.cloak) ("dholbert")
# [05:26] * Joins: dholbert (~dholbert@public.cloak)
# [07:45] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:32] * Joins: svillar (~sergio@public.cloak)
# [08:49] * Quits: estellevw (~estellevw@public.cloak) (estellevw)
# [08:49] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [08:49] * Joins: jdaggett (~jdaggett@public.cloak)
# [08:52] * Joins: dbaron (~dbaron@public.cloak)
# [09:22] * Joins: jrossi (~jrossi@public.cloak)
# [09:28] * Quits: nikos (~uid28403@public.cloak) ("Connection closed for inactivity")
# [09:28] * Joins: antonp (~Thunderbird@public.cloak)
# [09:36] * Joins: glazou (~glazou@public.cloak)
# [09:38] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:50] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:08] * Quits: jrossi (~jrossi@public.cloak) ("Leaving.")
# [10:19] * Joins: jrossi (~jrossi@public.cloak)
# [10:47] * Joins: Florian (~Florian@public.cloak)
# [10:49] * Quits: jrossi (~jrossi@public.cloak) ("Leaving.")
# [11:00] * Joins: jrossi (~jrossi@public.cloak)
# [11:20] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 180 seconds)
# [11:57] * Joins: lajava (~javi@public.cloak)
# [12:08] * Quits: jrossi (~jrossi@public.cloak) ("Leaving.")
# [12:10] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [12:34] * Joins: Florian (~Florian@public.cloak)
# [12:46] * Joins: darktears (~darktears@public.cloak)
# [13:45] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:47] * Joins: Florian (~Florian@public.cloak)
# [14:18] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [14:30] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [14:52] * Quits: lajava (~javi@public.cloak) (Client closed connection)
# [15:09] * Joins: jdaggett (~jdaggett@public.cloak)
# [15:10] * jdaggett is now known as jdaggett|slumber
# [15:20] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [15:27] * Joins: lajava (~javi@public.cloak)
# [15:35] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [15:35] * Joins: Florian (~Florian@public.cloak)
# [16:01] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [16:03] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:11] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:15] * Quits: glazou (~glazou@public.cloak) (glazou)
# [16:26] * Quits: shepazu (schepers@public.cloak)
# [16:28] * Joins: shepazu (schepers@public.cloak)
# [16:46] <zcorpan> "However, when the value of overflow on the root element is auto, any scroll bars are assumed not to exist." http://dev.w3.org/csswg/css-values/#viewport-relative-lengths
# [16:46] <zcorpan> TabAtkins: fantasai: ^ why?
# [16:46] * Joins: thinkxl (~thinkxl@public.cloak)
# [16:47] <zcorpan> context: https://twitter.com/simevidas/status/534875180150312960
# [16:48] <zcorpan> (also the spec doesn't say what should happen when overflow is not auto)
# [16:51] <SimonSapin> zcorpan: maybe so that things don’t jump around when the `overflow: auto` scrollbar appears or disappears based on content changes?
# [16:52] <zcorpan> SimonSapin: (1) that already happens for things styled with width:XY% (2) the layout will break apart if the things wrap when the scrollbar is present
# [16:56] <SimonSapin> I’m just speculating. I remember this being discussed, but I don’t remember the actual reason.
# [17:00] * Joins: dbaron (~dbaron@public.cloak)
# [17:04] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [17:05] * Joins: c_palmer (~c_palmer@public.cloak)
# [17:07] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:10] <TabAtkins> zcorpan: So vw/etc dying depend on layout to resolve.
# [17:11] <TabAtkins> Dying = don't
# [17:12] <TabAtkins> All other overflow values either always or never generate scrollbars, so they don't need special language.
# [17:16] * Joins: glazou (~glazou@public.cloak)
# [17:16] * glazou changes topic to 'logs: http://krijnhoetmer.nl/irc-logs/css/ - 2014-11-19 telcon agenda: http://lists.w3.org/Archives/Public/www-style/2014Nov/0353.html'
# [17:16] * Joins: Zakim (zakim@public.cloak)
# [17:17] <glazou> Zakim, this will be Style
# [17:17] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 44 minutes
# [17:17] <glazou> RRSAgent, make logs public
# [17:17] <RRSAgent> I have made the request, glazou
# [17:20] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [17:24] * Joins: darktears (~darktears@public.cloak)
# [17:56] * Joins: dael (~dael@public.cloak)
# [17:56] * Quits: c_palmer (~c_palmer@public.cloak) (Ping timeout: 180 seconds)
# [17:56] <glazou> Zakim, code?
# [17:56] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
# [17:57] * Joins: bcampbell (~chatzilla@public.cloak)
# [17:57] <Zakim> Style_CSS FP()12:00PM has now started
# [17:57] <Zakim> +dael
# [17:58] <Zakim> +MikeMiller
# [17:58] <Zakim> +??P19
# [17:58] <SimonSapin> Zakim, ??P19 is me
# [17:58] <Zakim> +SimonSapin; got it
# [17:58] <Zakim> -MikeMiller
# [17:58] <Zakim> +plinss
# [17:59] <Zakim> +[IPcaller]
# [17:59] * Joins: tantek (~tantek@public.cloak)
# [17:59] <Zakim> + +1.479.764.aaaa
# [17:59] <Zakim> + +33.1.39.21.aabb
# [17:59] <Florian> Zakim, I am aaaa
# [17:59] <Zakim> +Florian; got it
# [17:59] <glazou> Zakim, aaaa is me
# [17:59] <Zakim> sorry, glazou, I do not recognize a party named 'aaaa'
# [17:59] <glazou> Zakim, aabb is me
# [17:59] <Zakim> +glazou; got it
# [18:00] <Zakim> +dauwhe
# [18:00] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [18:00] <Zakim> +??P26
# [18:00] <dael> ScribeNick: dael
# [18:00] <tantek> zakim, ??p26 is me
# [18:00] <Zakim> +tantek; got it
# [18:00] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:01] <tantek> Zakim, mute me
# [18:01] <Zakim> tantek should now be muted
# [18:01] * Joins: AH_Miller (~mike@public.cloak)
# [18:01] <Zakim> -dauwhe
# [18:01] <Zakim> + +1.206.675.aacc
# [18:01] <astearns> zakim, aacc is me
# [18:01] <Zakim> +astearns; got it
# [18:01] <Zakim> + +1.907.315.aadd
# [18:01] <Zakim> +dauwhe
# [18:01] * Joins: smfr (~smfr@public.cloak)
# [18:01] * Joins: bradk (~bradk@public.cloak)
# [18:01] <Zakim> +[Microsoft]
# [18:02] <gregwhitworth> Zakim, +1.907.315.aadd is me
# [18:02] <Zakim> +gregwhitworth; got it
# [18:02] <Rossen_> zakim, microsoft has me
# [18:02] <Zakim> +Rossen_; got it
# [18:02] <Zakim> +[IPcaller.a]
# [18:02] <Zakim> + +1.281.305.aaee
# [18:02] <Zakim> +smfr
# [18:02] <jdaggett|slumber> zakim, IPcaller.a is me
# [18:02] <Zakim> +jdaggett|slumber; got it
# [18:02] * Joins: murakami (~murakami@public.cloak)
# [18:02] * jdaggett|slumber is now known as jdaggett
# [18:02] * tantek is resolving and closing CSS3-UI issues left & right. Thanks to nudges from Florian.
# [18:02] <Zakim> +BradK
# [18:03] <Zakim> +[IPcaller.a]
# [18:03] * glazou tantek : s/nudges/nukes ? ;-)
# [18:03] * tantek glazou lol!
# [18:03] * Florian Thank you Tantek. I hope you like it, there's more coming :)
# [18:03] <Zakim> +[Microsoft.a]
# [18:03] <Zakim> +MikeMiller
# [18:04] * tantek has more edits to css3-ui coming too.
# [18:04] * tantek Florian thanks for submitting your new tests to the test suite too.
# [18:04] * Joins: c_palmer (~c_palmer@public.cloak)
# [18:04] * Joins: KeshavP (~KeshavP@public.cloak)
# [18:05] <Zakim> +[Bloomberg]
# [18:05] <dael> plinss: let's get started. anything to add to the agenda.
# [18:05] * Joins: ArronEi (~ArronEi@public.cloak)
# [18:06] * Joins: ChrisL (clilley@public.cloak)
# [18:06] <dael> Florian: TabAtkins raised something about :has-focus. I'd like it added.
# [18:06] <dael> plinss: Okay. No problem.
# [18:06] <TabAtkins> Zakim, aaee is me
# [18:06] <Zakim> +TabAtkins; got it
# [18:06] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:06] <dael> Topic: Re-naming flex-basis: auto
# [18:06] <Rossen_> Tantek not on the call
# [18:06] <dael> plinss: Who wants to talk on this one.
# [18:06] * fantasai proposes rossen lead
# [18:06] <smfr> http://lists.w3.org/Archives/Public/www-style/2014Jul/0008.html
# [18:06] <tantek> Rossen_: I am here
# [18:07] <dael> TabAtkins: It's fantasai that wants to talk. I'm not ready to talk on this yet.
# [18:07] <Zakim> +dbaron
# [18:07] <Zakim> +SteveZ
# [18:07] <Zakim> +SylvaIng
# [18:07] <dael> dael: [reads fantasai IRC comment]
# [18:07] <dael> Rossen_: I wasn't ready to talk either, but since it's there let's talk.
# [18:07] <dael> plinss: We can defer.
# [18:08] <dael> Rossen_: I still haven't seen a mass responce from dev on this. I did see leaverou a week or so ago and she chatted with fan and gave her feedback.
# [18:08] <dael> Rossen_: That's just one sample.
# [18:08] <Zakim> +ChrisL
# [18:08] * Bert has phone problems. Will keep trying...
# [18:08] <dael> Rossen_: It at all possible I'll keep pushing to change to the first option rather than the second which breaks compat and I believe is more confusing. That was the issue.
# [18:08] * ChrisL took a few tries to connect today, too
# [18:08] <Zakim> +[Sophia]
# [18:09] <dael> Rossen_: Where are we, like I said, I'm still waiting on feedback on it. If someone wants to add we can disucss, otherwisee w can defer.
# [18:09] * Bert zakim, [Sophia] is me
# [18:09] * Zakim +Bert; got it
# [18:09] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0040.html
# [18:09] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0041.html
# [18:09] <dael> fantasai: I think leaverou was why not content size. I asked others and they posted these.
# [18:09] * antonp is following on IRC... stuck in meeting
# [18:09] <dael> fantasai: Someone else posted...let me find that.
# [18:10] <dael> fantasai: A little bug seems like...it seems like it doesn't charge backwards compat. The mozilla bug that was leaning toward not changing to main-size.
# [18:10] <dael> dbaron: We've had the change that's been in the spec in nightly, but we pulled from beta given the set of regressions it caused. There's a decent compat risk, we've had things show up
# [18:11] * Joins: thinkxl_ (~thinkxl@public.cloak)
# [18:11] * Quits: thinkxl_ (~thinkxl@public.cloak) (Client closed connection)
# [18:11] * Joins: thinkxl_ (~thinkxl@public.cloak)
# [18:11] <dael> dbaron: At this point my memory is a bit muddled between which changes caused what regressions.
# [18:12] <dael> fantasai: What I've heard is Microsoft and Mozilla are worried about compat. Author side liekd the other option, they don't like dealing with backcompat problems and content as a keyword makes more sense. We're used to auto computing to something. That's the feedback from dev I've pinged, I haven't heard feedback supporting the first.
# [18:12] <dael> fantasai: Given that I'd propose where auto means main-axis and adda keyword saying I was automatic sizing with content or content-sizing as the keyword
# [18:12] <fantasai> s/content-sizing/content-size/
# [18:13] <fantasai> s/main-axis/main-size/
# [18:13] <dael> plinss: So we have a proposal. Opinions?
# [18:13] * Joins: andreyr (~andreyr@public.cloak)
# [18:13] <dael> TabAtkins: I like this less, but I won't fight it. It's fine.
# [18:13] <dael> plinss: dbaron?
# [18:13] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [18:13] <alex_antennahouse> apologies for late arrival, will be on phone in a minute
# [18:13] <dael> dbaron: I'm fine with...I'm not intot he issue that much, but if people think it's less backwards compat issue, I'm in favor.
# [18:14] <dael> fantasai: It def will. It doesn't change meaning, just creates new syntax for something you previously couldn't access directly.
# [18:14] <dael> plinss: Obj?
# [18:14] <dael> Rossen_: I don't want to break backcompat
# [18:14] <Zakim> + +1.917.818.aaff
# [18:14] * tantek break backcompat? the day is still young.
# [18:14] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [18:14] <dael> RESOLVED: Accept fantasai proposal for flex-basis: auto changes
# [18:14] <fantasai> third author - http://lists.w3.org/Archives/Public/www-style/2014Nov/0055.html
# [18:14] <Zakim> + +1.631.398.aagg
# [18:15] <dael> Topic: Unicode-range syntax
# [18:15] <jdaggett> basic problem, CSS 2.1 defined UNICODE-RANGE token
# [18:15] <jdaggett> 2.1 tokenization: http://www.w3.org/TR/CSS21/syndata.html#tokenization
# [18:15] <jdaggett> UNICODE-RANGE u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
# [18:15] <jdaggett> unicode-range descriptor of @font-face rule uses this
# [18:15] <dael> jdaggett: The basic problem is in CSS2.1 the unicode-range token was defined. I put in the tokenization syntax.
# [18:15] <jdaggett> sometimes interferes with other syntax in places outside @font-face rules
# [18:15] <jdaggett> like selectors: u+a { color: green } will get tossed by the parser
# [18:15] <jdaggett> testcase: http://people.mozilla.org/~jdaggett/unicoderangetokenization.html
# [18:15] <Zakim> +[IPcaller.aa]
# [18:15] <dael> jdaggett: The descriptor exists. the prob is sometimes this interferes with other grammar like selectors.
# [18:15] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:15] * Joins: antenna (~antenna@public.cloak)
# [18:16] <Zakim> +??P62
# [18:16] <jdaggett> telcon discussion in july: http://lists.w3.org/Archives/Public/www-style/2014Jul/0051.html
# [18:16] <jdaggett> resolution was to dump UNICODE-RANGE token, replace with production "something like An+B"
# [18:16] <Zakim> -??P62
# [18:16] <dael> jdaggett: I put a test case witht he problem. It fails in Chrome and FF.
# [18:16] <Zakim> + +1.416.364.aahh
# [18:16] <antonp> Zakim, aahh is me
# [18:16] <Zakim> +antonp; got it
# [18:16] <jdaggett> quick review unicode-range descriptor syntax
# [18:16] <jdaggett> list of comma-delimited <urange> values
# [18:16] <dael> jdaggett: The basic resolution was to dump the unicode-range token and replace with something like An+B syntax.
# [18:16] * Quits: thinkxl (~thinkxl@public.cloak) (Ping timeout: 180 seconds)
# [18:16] <jdaggett> ex: unicode-range: u+f2e, u+100-1f3, u+2??
# [18:16] <jdaggett> three basic types - single codepoint, range, wildcard
# [18:16] <alex_antennahouse> im ipcaller
# [18:16] <jdaggett> defined in CSS3 Fonts: http://dev.w3.org/csswg/css-fonts/#urange-value
# [18:16] <jdaggett> tab wants to define <urange> in Syntax: dev.w3.org/csswg/css-syntax/#urange-syntax
# [18:16] <jdaggett> seems like a verbose explanation of the same thing
# [18:16] <zcorpan_> (i can attend on irc but not call in.)
# [18:16] * Parts: glazou (~glazou@public.cloak) (glazou)
# [18:17] <dael> jdaggett: Basically there's 3 types. There's single code, range, and wild-card. It's currently defined in CSS3 Fonts, but TabAtkins wants to define the urange production in sntax spec. I put in the URL to existing and proposed
# [18:17] <jdaggett> and the grammar simply lists a bunch of possible token sequences
# [18:17] * Joins: glazou (~glazou@public.cloak)
# [18:17] <jdaggett> <urange> =
# [18:17] <jdaggett> u '+' <ident-token> '?'* |
# [18:17] <jdaggett> u <dimension-token> '?'* |
# [18:17] <jdaggett> u <number-token> '?'* |
# [18:17] <jdaggett> u <number-token> <dimension-token> |
# [18:17] <jdaggett> u <number-token> <number-token> |
# [18:17] <jdaggett> u '+' '?'+
# [18:17] <jdaggett> but the algorithm is simply saying "take this jumble of tokens and reinterpret them as a sequence of..."
# [18:17] <dael> jdaggett: In the new description you have something like this (above)
# [18:17] <jdaggett> ends up being different (and incorrect) version of existing defn
# [18:17] <jdaggett> and it's totally out of context since the Fonts spec explains what these ranges represent
# [18:17] <jdaggett> and how they are used
# [18:17] <dael> jdaggett: It ends up being different and not entirely correct. I think it's out of place too since you need info from font spec too. It's also just not in where this thing is desc how it's used.
# [18:17] * plinss zakim, [IPcaller.aa] is alex_antennahouse
# [18:17] * Zakim +alex_antennahouse; got it
# [18:18] <dael> jdaggett: Resolving to remove the unicode-range token is fine, but this new syntax and algo doesn't make a lot of sense to me. It's really hard to read and impl have to look at both syntax and font to use it correctly. Since it's only used for the unicode-range descriptor, we don't need it chared across specs.
# [18:18] * fantasai thought we already removed the token?
# [18:19] <ChrisL> agree it makes sense for all the spec of urange to be in css3 fonts
# [18:19] <dael> jdaggett: I'd suggest, in the process of removing the unicode-range token, we redefine urange to link to this and avoid linking to syntax spec.
# [18:19] <dael> TabAtkins: There's several issue. The loc of the urange, I don't care where it's defined. I put it in syntax b/c it's a wierd complex things, but if you want it in fonts, fine. Don't care.
# [18:19] <dael> TabAtkins: If you want it in fonts, that's fine. Not an issue.
# [18:20] <dael> TabAtkins: You also said it's incorrect, but you haven't pointed out where. I ported the definition of the old parsing and modified in a few small places. It should be as correct and matched the old unicode-range. WE don't accept wider or narrower then the old.
# [18:20] <dael> TabAtkins: The definition itself is ugly, I agree. This is what happens when you mix syntaxes.
# [18:20] <dael> jdaggett: It's not nec.
# [18:21] <dael> TabAtkins: It is. You can't use existing font spec that def roughly how it looks because it doesn't map into a string of token propoerly. It's ugly and terrible and that why it says this isn't for authors to read and I have a note to read other bits nad that this bit is just for impl.
# [18:21] <fantasai> You could put it into an appendix
# [18:22] <dael> jdaggett: You're not giving percises mapping. If you look at the algo it just says reinterp as these other things. The grammar is so complex because the syntax is hairy and we can't capture easily. What you wrote is what an impl will get from the existing and this doesn't add clarity.
# [18:22] * Joins: Rossen__ (~Rossen@public.cloak)
# [18:23] <dael> TabAtkins: The token definitions I've pulled out are non-obvious, but they are what an impl needs to recognize. Asserting we don't need to write that is wrong. We absolutely need to write that or each impl will need to recognize those independantly.
# [18:23] <zcorpan_> i agree with TabAtkins on the above
# [18:23] <dael> jdaggett: What's obj is that the grammar is useless. The algo isn't wants used, it's saying reinterp as hex digits.
# [18:23] <dael> TabAtkins: That's what we need when we remove the old version.
# [18:24] * Joins: Rossen___ (~uid21900@public.cloak)
# [18:24] <dael> dbaron: I think we need to say how a token stream needs to be interp. I think part of the controv was TabAtkins making changs about what's valid and invalid.
# [18:24] <ChrisL> so why was the special token removed? why not have an opaque blob for that one thing?
# [18:24] <dbaron> ChrisL, because it matched things that it wasn't supposed to match, like some selectors
# [18:24] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:24] <dael> TabAtkins: Which I dropped back from. I found it easier to do explicit parsing that matches the old text. It matches everything it did before. Nothing that didn't match before matches now.
# [18:24] <ChrisL> thanks, dbaron
# [18:24] <dbaron> ChrisL, we were having trouble telling authors why u+i was a valid selector and u+a was not
# [18:25] <dael> jdaggett: dbaron why do you think the algo is necessary
# [18:25] * zcorpan_ ChrisL e.g. u+a {}
# [18:25] <ChrisL> got it
# [18:26] * Joins: dael_ (~dael@public.cloak)
# [18:26] <dael_> jdaggett: The production will be longer than it is now
# [18:26] <dael_> dbaron: It will, yes.
# [18:27] <dael_> TabAtkins: If we were doing ihis today, we wouldn't use this syntax. We would use something more compat. We're stuck with it. It's fine. It's nice and usable. However desc it in syntax now that we're removed the token, it's messy, but that's for impl.
# [18:28] <dael_> TabAtkins: Dev doesn't have to worry about the messy, they get a nice simple way.
# [18:28] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:28] <dael_> ??: One question. Even though it's hard, can you new syntax be seperate. Is this useful or redundant?
# [18:28] <jdaggett> u+2f3f? is not captured with the current syntax
# [18:28] <dael_> TabAtkins: Depends on how much work you're willing to do.
# [18:28] <dael_> dbaron: And how precise the other text is.
# [18:29] <dael_> ??: So having two definitions that say the same thing, is that useful? Maybe making one an informative note explaining the other.
# [18:29] <dbaron> I think the complexity of expressing this makes me wonder if we should instead keep the token and teach selectors how to handle unicode-range tokens as selectors.
# [18:29] <SimonSapin> s/??/Florian/
# [18:29] <dael_> TabAtkins: The pretty author text, that's the informative. The normative is the algo.
# [18:29] <dael_> fantasai: We might want it in an appendix also.
# [18:29] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:29] <dael_> TabAtkins: That's reasonable.
# [18:30] <Zakim> +[Microsoft.aa]
# [18:30] <dael_> jdaggett: It's basically useless information. I think we need to allow for variations in number of tokens, blah blah blah.
# [18:30] <dael_> TabAtkins: That's captured by dimention with optional ? clause.
# [18:30] * sgalineau it's almost time to argue over whether Florian should co-edit unicode-range
# [18:30] <dael_> jdaggett: That's 2F3. How's that caputred.
# [18:30] <dael_> TabAtkins: It's a valid dimention.
# [18:30] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:30] * Florian I wanted to reuse it in @text-transform, so I almost have a valid claim.
# [18:31] <dael_> jdaggett: This isn't helping anything. An impl is thinking the algo and what are the set of tokens I'm getting and I'll reinterp as a string. The algo caputres existing syntax.
# [18:31] * tantek is seeing serious lag with wiki.csswg.org editing :/
# [18:31] * bradk has to leave early. Sorry. Bye.
# [18:31] <SimonSapin> as an implementer: yes, making this weird messy grammar explicit is useful
# [18:31] * tantek is not sure if it is his network's fault though. :/
# [18:31] <Zakim> -BradK
# [18:31] <zcorpan_> u+2f2f? -> IDENT(u) DIMENSION(+2, f2f) DELIM(?)
# [18:31] <dael_> TabAtkins: That's the point. The point is to desc the syntax in terms of CSS language. I think you're imaging that implemetors can just imaging the undelying pieces. If unicode is defined as a higher lavel, I need to define it in terms of tokens.
# [18:31] * sgalineau tantek, are you asking for a co-editor?
# [18:32] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [18:32] * tantek slaps sgalineau with a week-old trout.
# [18:32] <dael_> TabAtkins: You're arguing for use to reintroduce the unicode-range token. That's what we don't want because it's a complex structure that's interfereing. So we're left with this messy one.
# [18:32] * sgalineau fair enough
# [18:32] * tantek now checks w3cmemes just in case.
# [18:32] <dael_> jdaggett: You're desciribing what the spec could decirbe by saying instead of unicode-range, there's this, this, and this. You're descrived it and the exttra doesn't help anyone.
# [18:32] <dael_> TabAtkins: Expect impl who want interop.
# [18:33] * tantek excruciatingdetails++
# [18:33] * tantek Florian for chair!
# [18:33] <dael_> Florian: I think at this piont TabAtkins and jdaggett positions are clear. I think we need to move on with discussion.
# [18:33] <dael_> SimonSapin: As an impl it helps to have the token explained.
# [18:33] <dael_> jdaggett: Why?
# [18:33] <fantasai> s/move on with discussion/hear from other people/
# [18:33] <dael_> SimonSapin: It's what I need to impl.
# [18:34] <dael_> dbaron: If we remove the token, we need this. HOwever, I'm having second thoughts on removing this. We need to leave it and teach selectors how to deal.
# [18:34] <dael_> ChrisL: How would you do that?
# [18:34] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [18:34] <dael_> TabAtkins: The selectors would need to intep some types of U range as a type selectors plus another type selector. not for all uranges.
# [18:34] <Zakim> -SteveZ
# [18:35] <Zakim> +SteveZ
# [18:35] <dael_> TabAtkins: If we need the ugliness somewhre, I'd rather isolte it into the one place it needs to be. Since I have to write a proper parse of Selectors, I dread having to deal with this.
# [18:35] <dael_> plinss: I agree.
# [18:35] <dael_> dbaron: One of the things that is level breaking about TabAtkins prop is it req remembering textilization of unicode tokens
# [18:35] <dael_> TabAtkins: That's already required for hex colors.
# [18:36] <dael_> dbaron: I don't remember having to do that.
# [18:36] <zcorpan_> dbaron gecko isn't interoperable with IE on hex colors in quirks mode. quirks spec sides with IE currently
# [18:36] * tantek goes back to searching bugzilla for UI related selectors
# [18:36] <dael_> TabAtkins: The quirks(?) spec has a funky thing. It needs to spec a hex color without the hex in front. So to do that you need numbers and idents so you don't drop leading zeros.
# [18:36] <dael_> SimonSapin: There's a comment saying Gecko isn't compat with IE on this.
# [18:37] * Joins: MaRakow_ (~MaRakow@public.cloak)
# [18:37] * glazou http://www.quickmeme.com/img/2e/2eb4b183efccea125df5418016a30c7e5ff3227238546fb299a74e2f78a729d5.jpg
# [18:37] <dael_> TabAtkins: I think we are compat with IE last I remember.
# [18:37] <Florian> s/SimonSapin/florian/
# [18:37] <zcorpan_> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk http://w3c-test.org/quirks-mode/hashless-hex-color.html
# [18:37] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [18:37] <dael_> plinss: So we have disagreement as to if this needs to be there, but several impl want it there. I think we hve agreement this should be in font spec as an appendix. Can folks liv with that.
# [18:37] <dael_> jdaggett: I'm fine with an appendix.
# [18:37] <dael_> plinss: Obj?
# [18:37] * sgalineau first read this URL as 'hashless sex color quirk'. Very disappointed.
# [18:37] <zcorpan_> 123 = #112233 in IE/spec, but #000123 in gecko/blink
# [18:38] <dael_> jdaggett: With the caveat where I think this can be simplied.
# [18:38] <dael_> RESOLVED: Move this definition to an appendix in the Font spec
# [18:38] <dael_> Topic: CSS3-UI
# [18:38] <tantek> Zakim, unmute me
# [18:38] <Zakim> tantek should no longer be muted
# [18:38] * Joins: jrossi (~jrossi@public.cloak)
# [18:38] * zcorpan_ dbaron i guess the quirk spec could be changed though
# [18:38] <dael_> Florian: A bunch of small, but maybe not too small. The first was discussed at TPAC, but not resolved. Drop the definitioin os syntaxes because they're better fef in selectors.
# [18:39] * TabAtkins Ah, so we're compat with Gecko. Interesting.
# [18:39] <dael_> Florian: There's pseudo-elements. I have two sep points, one is pseudo-classes are in Selectors 4 either identical or clarified.
# [18:39] * glazou loves « déjà-vouuuu »
# [18:39] * TabAtkins But I tend to suspect that quirks compat leans heavier toward the IE result.
# [18:39] <dael_> Florian: WE kind of agreed, but didn't record a resolution. Maybe it's been resolvd already
# [18:40] <dael_> plinss: Objections?
# [18:40] <dael_> tantek: No obj. I think this does need different review from normal element tree for reasons like the valid/invalid experience we had. No obj to moving them to Selectors 4, I want to figure out how we get more and earlier review to fix them.
# [18:41] <dael_> tantek: I guess that's more of a request for input instead of a proposal
# [18:41] <andreyr> no objection
# [18:41] * zcorpan_ TabAtkins possibly but clearly we can get away with not matching IE here
# [18:41] <dael_> tantek: My comment also applies for moving the pseudo-elements to the pseudo-elements spec. So that same comment/request applies.
# [18:41] <dael_> Florian: So can we resolve on psuedo-classes and move on?
# [18:42] <dael_> plinss:Obj?
# [18:42] <dael_> RESOLVED: Move psuedo-class from CSS3-UI to Selectors 4.
# [18:42] <dael_> tantek: And this is just for existing ones?
# [18:42] * TabAtkins zcorpan_ Sure. We don't *need* numeric representation if dbaron is okay with allowing U+00000000000002 being valid and equivalent to U+0002.
# [18:42] <dael_> plinss: I think in general psuedo-classes should be in some level of selectors.
# [18:42] <fantasai> http://dev.w3.org/csswg/selectors4/
# [18:42] <dael_> fantasai: New ones have been dropped into selectors 4. We just never removed those.
# [18:43] <dael_> tantek: So I'd like that recorded as well.
# [18:43] * TabAtkins Oh, well, I suppose I'd need to record some more flags from scinot numbers.
# [18:43] <dael_> Florian: I'm having a hard time, but I think I'm okay with what I've heard.
# [18:43] <dael_> RESOLVED: For clarity, all future pseudo-classes should be in a Selectors module
# [18:43] * TabAtkins Right now I translate them directly into numbers. If we drop the representation, I'll need to record that they were scinot and what power they had.
# [18:43] <Zakim> -tantek
# [18:44] <dael_> Florian: For pseudo-elements, I'd agree with tantek's suggestion, but I sugest we drop them entirely since they only apply to XFORMS.
# [18:44] <ChrisL> xforms is not really relevant anymore
# [18:44] * Florian waits for tantek to get back online
# [18:44] <dael_> Florian: Bert was tasked with...we lost tantek
# [18:44] <dael_> glazou: I don't think there's a single XFORM with a pseudo-element
# [18:44] <Bert> (I checked the most likely implementations and did not find pseudo-element support.)
# [18:44] <dael_> plinss: I'm not clear is tantek is trying to get back.
# [18:44] <Bert> (Exceprt for XSmiles, which is not maintained.)
# [18:45] <dael_> Florian: So Bert reported it hasn't been used since 2008.
# [18:45] <ChrisL> drop it
# [18:45] <dael_> Florian: I contacted the suggestion from the list and they don't use them either, they compile into HTML. So with no known impl, I suggest we drop them instead of moving them.
# [18:45] <dael_> glazou: I agree with that.
# [18:45] <dael_> plinss: Anyone want ot keep 'em?
# [18:46] * Joins: bradk (~bradk@public.cloak)
# [18:46] <Florian> Tantek?
# [18:46] * zcorpan_ TabAtkins dbaron maybe we should explore killing representation of tokens if having the representation is bad
# [18:46] <dael_> RESOLVED: Dropp XFORMS related pseudo-elements.
# [18:46] <dael_> Florian: unfortunate we lost tantek
# [18:46] <dael_> plinss: We'll revisit if he obj.
# [18:46] <dael_> Florian: Similarly the icon value and prop don't have impl and there's no interest. So I suggest we drop them
# [18:46] <TabAtkins> zcorpan_: I know that our implementor switching us to the Syntax spec wanted to avoid using representation, for memory reasons. It would be nice to avoid.
# [18:46] <dael_> plinss: Push to 4 or drop entirely?
# [18:47] <dael_> Florian: I think drop, but I can push if there's interest. So far I've found no interest.
# [18:47] <dael_> plinss: implementors? Anyone want to implement this?
# [18:47] <dael_> Florian: I asked on the list and Google and Microsoft were no if I remember correct.
# [18:47] <dael_> Florian: Yes, TabAtkins and gregwhitworth say no plan. No other comments.
# [18:47] <dael_> dauwhe: These were in Generated Content and had no interest either
# [18:47] <ChrisL> drop
# [18:48] <dael_> ??: I don't think webkit has interest.
# [18:48] <dael_> plinss: So drop entirely?
# [18:48] <plinss> s/??/smfr/
# [18:48] <dael_> Florian: We can pull back if someone becomes interested.
# [18:48] <smfr> drop
# [18:48] <dael_> dauwhe: I'd say dro
# [18:48] <andreyr> drop
# [18:48] <dael_> glazou: drop
# [18:48] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [18:48] * SimonSapin TabAtkins, +1 to dropping number representation if possible
# [18:48] <dael_> RESOLVED: Drop content: icon and the icon property
# [18:48] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [18:48] <dael_> Florian: Last drop is the nav: index.
# [18:49] * Joins: tantek (~tantek@public.cloak)
# [18:49] <glazou> s/nav: index/nav-index
# [18:49] <dael_> Florian: Directonal is fine, but the index has problems. This has a bit of interest, so I'd suggest move to 4, but I think it would hold back CSS3-UI
# [18:49] <dael_> dbaron: WE had various discussions about this. I don't know if they'd be upset about moving to 4, but we should get the results of that discussion in somewhere.
# [18:50] <dael_> ChrisL: Florian you mentioned some interest?
# [18:50] <dbaron> s/discussions/discussions with WAI/
# [18:50] <dael_> Florian: THe same people with interest in directional nav had interest, but I don't remember exactly.
# [18:50] <Zakim> -jdaggettslumber
# [18:50] * dauwhe now there will only be eighteen possible values for the content property :)
# [18:50] <ChrisL> that argues for moving to level 4 rather than dropping, then
# [18:50] <dael_> glazou: In terms of TV, people are more interested in direction than index. If it's impl it's not used and I'm not sure if it's impl everywhere.
# [18:50] * jdaggett is now known as jdaggett|sleep
# [18:51] * smfr we obviously need a nav-index stacking context
# [18:51] <dael_> fantasai: I remmeber some discussion about nav0index and the problem was it's global to the page with no hirearchy. If we can we should try and fix that. It seems that would be better in 4
# [18:51] <tantek> I've been tracking "future" / "postponed" UI related pseudo-classes and pseudo-elements here https://wiki.csswg.org/spec/css4-ui#more-selectors
# [18:51] <tantek> gah
# [18:51] <tantek> is my IRC getting through at least?
# [18:51] <tantek> ???
# [18:51] * smfr tantek yes
# [18:51] * Bert sees Tantek on IRC
# [18:51] <dbaron> tantek, just got 4 lines at once
# [18:51] <tantek> it's in the CSS3-UI issues page folks
# [18:51] <dael_> glazou: The prob is the use case. Last time I read about that it said this is useles sbecause people are using the arrow keys on the remote.
# [18:51] <tantek> could someone please check that instead of wondering where it is?
# [18:51] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0364.html
# [18:51] <tantek> search https://wiki.csswg.org/spec/css3-ui for nav-index
# [18:52] <fantasai> glazou's email that was this investigation^
# [18:52] <tantek> it links to various discussions and things
# [18:52] <tantek> since searching email fails
# [18:52] <dael_> glazou: I think we ping these people to find out if it's used. If it's unused we should drop it and it's worthless to invest time. People have implemented the direction nav, but not the others.
# [18:52] <dael_> fantasai: And we're not talking about dropping direction.
# [18:52] <dael_> glazou: I don't think anything but direction is used.
# [18:52] <fantasai> minutes from last nav-index discussion with a11y folks: http://lists.w3.org/Archives/Public/www-style/2011Nov/0712.html
# [18:53] <dael_> Florian: People still discuss it, so I don't want to drop completely, but we can push to 4 and discuss again when we try and stablize that. If it's clear no one wants it we can drop immediatly. I'm fine with either.
# [18:53] <Zakim> +??P0
# [18:53] <tantek> zakim, ??p0 is me
# [18:53] <Zakim> +tantek; got it
# [18:53] <dael_> fantasai: I'd like to push to level 4 with an issue about the things brought up at the last a11y disucssion.
# [18:53] <dael_> Florian: tantek you're back?
# [18:53] <dael_> tantek: Yes.
# [18:53] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [18:54] <dael_> Florian: So the question is for we drop nav-index now or move to level 4. No one is arguing for stablizing now.
# [18:54] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [18:54] <dael_> tantek: I haven't seem impl itnerested. The potential opp is to fix it and make it better then tab-index because it doesn't have backward compat. And the folks withing directional nav stylesheets could use it in the same stylesheet. If that's interesting enough I think we can put it in 4. If there's no itnerest, we can drop
# [18:55] <dael_> tantek: I'll move the text to a wiki and let it evalove passively
# [18:55] <ChrisL> (it seems not)
# [18:55] <dael_> tantek: So does anyone in the group, esp those witht he directional properties, have interest?
# [18:55] <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg440
# [18:55] <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg441
# [18:55] <tantek> for reference: https://wiki.csswg.org/spec/css3-ui?&#issue-25
# [18:55] <tantek> please add more URLs there
# [18:55] <dael_> glazou: The impl I did at Samsung had no interest in nav-index.
# [18:56] <dael_> Florian: I don't remember Opera. They haven't loudly expressed interest.
# [18:56] <Zakim> -[Microsoft.aa]
# [18:56] <dael_> tantek: That's important data. I'd also like to hear from TabAtkins who looked at tab-index. Is it worthwhile?
# [18:56] <dael_> TabAtkins: I don't think so. I think we should fix HTML and then CSS.
# [18:56] <fantasai> s/tab-index/tabindex/
# [18:56] * fantasai html attrs don't have hyphens ;)
# [18:56] * zcorpan_ fantasai except those that do :-)
# [18:57] * fantasai yeah, fair :p http-equiv
# [18:57] * ChrisL someone shouting in a cave?
# [18:57] <dael_> tantek: Okay, so I'd rather it move to w3c wiki with other semi-abandoned properties so if anyone else wants to get it later, it's good.
# [18:57] * astearns resolves that the wiki page title should be "island of misfit properties"
# [18:57] * dauwhe s/island of misfit properties/gcpm/
# [18:57] <Bert> q+ to suggest asking WAI PF for a joint telcon or at least advice
# [18:57] * Zakim sees Bert on the speaker queue
# [18:57] <glazou> HERE ARE MY TEN COMMANDMENTS^H^H^H… LINES OF CSS
# [18:57] <tantek> apparently zilles is the wise reverb elder ;)
# [18:57] * fantasai no, Dael, don't make that replacement ...
# [18:58] <dael_> stevez: it seems to me that at the protocol group someone talked about the nav-index so check with him to see if there's interest. The question is if they thought it would fix tabindex.
# [18:58] <dael_> fantasai: I linked the F2F discussion. They brought up a lot of problems, I'm not sure how much it was "I want this"
# [18:59] <dael_> tantek: fantasai can you add your urls to this wiki page?
# [18:59] <dael_> dbaron: I also linked to the follow-up threads.
# [18:59] * fantasai suggests Tantek/Florian review the minutes from this telecon and make notes
# [18:59] <tantek> please add your URLs about nav-index here: https://wiki.csswg.org/spec/css3-ui?&#issue-25
# [18:59] <tantek> dbaron and elika ^^^
# [18:59] <dael_> Florian: There seems to be consensus on moving this to a wiki.
# [18:59] <dael_> plinss: sounds reasonable.
# [18:59] <dael_> tantek: If you care about it, put it on the wiki
# [18:59] <dael_> RESOLVED: pull nav-index to level 3 and put it on a wiki
# [18:59] <dbaron> tantek, there's also a separate https://wiki.csswg.org/ideas/nav-index
# [19:00] <Zakim> -SteveZ
# [19:00] <dael_> Florian: One more. There is a clarification that we need ont ext-overflow. The prose is controdicting when there's a single vaue and you are scrolling the thing that's being ellipsed.
# [19:00] <dael_> Florian: The text appears to be controdicting as to if it applies to both sides or just on the end side. Impl do end side only. If you have double value it's fine.
# [19:01] <dael_> tantek: This isn't a one minute issue. I belive disucssion this with fantasai two years ago we got this to work with Gecko. If the spec has prose problems, I'm going to go with Gecko.
# [19:02] <dael_> tantek: At the time our tests showed no other impl, IE, Wekitbpr, esto were even trying to do something interesting.
# [19:02] <dael_> Rossen___: This isn't one minute. It's a good topic.
# [19:02] <dael_> Florian: I agree. WE can't do this now.
# [19:02] <dael_> tantek: Continue offline.
# [19:02] * sgalineau 1 CSS minute = 96 regular minutes
# [19:02] <zcorpan_> s/Wekitbpr, esto/WebKit, Presto/
# [19:02] <dael_> plinss: One quick topic myself. We've had some disucssions about creating a taskforse for the box-tree API. I don't think we have a resolution for it.
# [19:02] <dael_> plinss: Obj?
# [19:02] <ChrisL> +1
# [19:02] <dauwhe> +1
# [19:03] <sgalineau> +1
# [19:03] <tantek> we didn't get to :has-focus either - on that topic please review *all* the new CSS UI related selectors being considered/implemented: https://wiki.csswg.org/spec/css4-ui#more-selectors
# [19:03] <dael_> RESOLVED: Create a taskforse to work on box-tree API and extensible CSS APIs
# [19:03] * glazou needs to run, sorry
# [19:03] <glazou> bye
# [19:03] <Zakim> -glazou
# [19:03] <dael_> tantek: I want to point out we didn't get to :has-focus. There's a whole bunc of CSS Selectors being impl. I just dropped a link, give it a look.
# [19:03] <SimonSapin> Rossen___, what domain name is this?
# [19:04] * Quits: andreyr (~andreyr@public.cloak) ("Page closed")
# [19:04] <dael_> plinss: That's it for the week, thanks everyone.
# [19:04] <Zakim> -[IPcaller.a]
# [19:04] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [19:04] <Zakim> -gregwhitworth
# [19:04] <Zakim> -[IPcaller]
# [19:04] <Zakim> -[Microsoft.a]
# [19:04] <Zakim> -SylvaIng
# [19:04] <Zakim> -dauwhe
# [19:04] <Zakim> -[Microsoft]
# [19:04] <Zakim> -dbaron
# [19:04] <Zakim> -smfr
# [19:04] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [19:04] <Zakim> -tantek
# [19:04] * Florian fantasai: I have reviewed the minutes from the old discussion, and that's what is informing my reading of the spec. That's not what gecko does
# [19:04] <Zakim> -plinss
# [19:04] <Zakim> -MikeMiller
# [19:04] <Zakim> - +1.917.818.aaff
# [19:04] <Zakim> -[Bloomberg]
# [19:04] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [19:04] <Zakim> -alex_antennahouse
# [19:04] <Zakim> -Bert
# [19:04] <Zakim> -antonp
# [19:04] <Zakim> -SimonSapin
# [19:04] <Zakim> -TabAtkins
# [19:04] <Zakim> -astearns
# [19:04] * dael_ fantasai I think that tantek and Florian looking at this set of minutes is a GREAT idea.
# [19:04] * Quits: AH_Miller (~mike@public.cloak) ("")
# [19:04] <Zakim> - +1.631.398.aagg
# [19:04] <Zakim> -dael
# [19:04] * Florian fantasai: or are you talking about the current one?
# [19:04] <tantek> I have a feeling the scrolling + text-overflow discussion won't be properly resolved until we can discuss it interactively at a f2f while trying out implementations.
# [19:05] <tantek> for now if you have something to add re: scroll + text-overflow, please link to it from this CSS3-UI issue: https://wiki.csswg.org/spec/css3-ui#issue-24
# [19:05] <fantasai> Florian: mean this one, since there were lots of comments/links dropped
# [19:05] * dael_ Florian: I think fantasai meant this set so that my half-understanding doesn't muddle the discussion further :)
# [19:06] <fantasai> Dael, you're doing fine.
# [19:06] <Florian> That's quite possible, white boards help. Although implementations are quite simple: everyone but gecko and presto are terrible. gecko and presto do the same thing on the single values. gecko does "the right thing" on the 2 values.
# [19:06] * fantasai needs a whiteboard
# [19:06] <tantek> Florian - not whiteboards, but interacting with implementations *in person*
# [19:06] <Zakim> -Florian
# [19:06] <tantek> Florian - it sounds like we're on the same page on this
# [19:07] <fantasai> tantek: I actually don't remember why we do end-only on one value
# [19:07] <tantek> now to document it better for everyone else
# [19:07] <dael_> tantek, Florian: would either/both of you be willing to give these minutes a look? I'm usually done around 9pm east coast time and can send you the minutes so you can send me corrections.
# [19:07] <tantek> fantasai - I think that was the result of discussion with mats and roc and trying a few different options
# [19:07] <Florian> dael: sure, no pb.
# [19:07] <fantasai> yeah, but I don't remember *why*
# [19:07] * dbaron Zakim, who is on the phone?
# [19:07] * Zakim sees on the phone: ChrisL
# [19:07] <Florian> I've looked at old minutes, and could not find an explanation for that
# [19:07] <fantasai> might've been compat with the other (broken) implementations, who knows
# [19:07] <dael_> Thanks Florian!
# [19:08] <tantek> fantasai: definitely wasn't a compat issue
# [19:08] * Quits: dael_ (~dael@public.cloak) ("Page closed")
# [19:08] <tantek> since the other implementations were so (differently) bad there was nothing worthy of being compat with
# [19:08] <Florian> can't be compat issues, as other implementations don't scroll
# [19:08] <fantasai> tantek: heh
# [19:08] <fantasai> tantek: what does Apple do for its ellipsized form controls?
# [19:09] <tantek> it sure doesn't scroll them that's for sure ;)
# [19:09] <tantek> alright I'm going to try restarting various routers to see if my network situation improves. bbiab.
# [19:10] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [19:11] <Florian> anyway, the whole issue, if we want to discuss it from scratch, is complicated. If we take start from the fact that mozilla's implementation is spec compliant, modulo one ambiguity on which the've picked sides, and roc has said he'd rather not change, maybe this is going to be a lot faster
# [19:11] <Florian> but still, not 1 minute fast :)
# [19:11] <Zakim> disconnecting the lone participant, ChrisL, in Style_CSS FP()12:00PM
# [19:11] <Zakim> -ChrisL
# [19:11] <Zakim> Style_CSS FP()12:00PM has ended
# [19:11] <Zakim> Attendees were dael, MikeMiller, SimonSapin, plinss, [IPcaller], +1.479.764.aaaa, +33.1.39.21.aabb, Florian, glazou, dauwhe, tantek, +1.206.675.aacc, astearns, gregwhitworth,
# [19:11] <Zakim> ... Rossen_, +1.281.305.aaee, smfr, jdaggett|slumber, BradK, [Microsoft], [Bloomberg], TabAtkins, dbaron, SteveZ, SylvaIng, ChrisL, Bert, +1.917.818.aaff, +1.631.398.aagg,
# [19:11] <Zakim> ... +1.416.364.aahh, antonp, alex_antennahouse
# [19:12] * Quits: c_palmer (~c_palmer@public.cloak) (Ping timeout: 180 seconds)
# [19:15] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:16] * Quits: smfr (~smfr@public.cloak) (smfr)
# [19:16] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [19:20] * Joins: tantek (~tantek@public.cloak)
# [19:20] * Joins: Florian (~Florian@public.cloak)
# [19:21] <tantek> let's see. tap tap tap. is this network on?
# [19:21] <TabAtkins> tantek: pong
# [19:22] <tantek> :has-network !
# [19:22] <Florian> that tends to be useful
# [19:23] * tantek just rediscovers the :friend() pseudo-class LOL
# [19:23] <tantek> … proposed by Hixie: http://lists.w3.org/Archives/Public/www-style/2005Oct/0173.html
# [19:24] <Florian> There is definitely a bunch of pseudos waiting to progress, very interesting. It's a nice parking lot you have on this wiki
# [19:24] <tantek> Florian, wikis make good parking lots :)
# [19:25] <Florian> yes
# [19:25] <tantek> since *unlike some people* I don't believe in just leaving things dangling in the depths of a mailing list.
# [19:25] <tantek> (not you of course Florian :) )
# [19:26] <tantek> TabAtkins: where do you prefer to maintain a "parking lot" for various Selectors4 ideas?
# [19:26] <TabAtkins> wiki is fine
# [19:27] <Florian> speaking of mailling lists, my next hobby is to go through all mails about css-ui since CSS3-UI was published as last call, and see if we have responded to everything. I've started, and there are mails that fell between the cracks, some with valid points.
# [19:27] <Florian> I'll surface that soon
# [19:27] <tantek> Florian: hopefully the explicit listing of email URLs in the CSS3-UI issues will help with that
# [19:27] <tantek> that was how I was doing it before
# [19:27] * Quits: antenna (~antenna@public.cloak) ("Leaving")
# [19:27] <Florian> it does, but it is not complete
# [19:27] <tantek> so that if anyone came across an email from the archives, they could "simply" search for the URL in the issues page and see if it had been collected / resolved
# [19:28] <tantek> And if you find anything that *wasn't* responded to, please collect it
# [19:28] <tantek> (in the wiki)
# [19:28] <Florian> yep, that's the plan
# [19:29] <Florian> wiki + resurect on the ml
# [19:29] <tantek> If it's already been resolved, perhaps record the (link to) resolution on https://www.w3.org/wiki/CSS3-UI#Resolved_Issues
# [19:29] <tantek> definitely do not resurrect old threads please
# [19:29] <Florian> restart
# [19:29] <Florian> with proposal for solution
# [19:29] <tantek> if there's new (or unhandled) issues, please add them to https://wiki.csswg.org/spec/css3-ui#current-issues
# [19:29] <Florian> yes, add them there, then start a new thread to solve them
# [19:30] <tantek> directly, preferably *before* emailing
# [19:30] <tantek> I'd prefer to see a collection of issues on the wiki first
# [19:30] <Florian> I'm fine with that
# [19:30] <tantek> before a barage of email thread hell
# [19:30] <tantek> and then I'd prefer to simply use URLs to those issues to discuss in telcons
# [19:30] <tantek> ONLY if the issue seems non-obvious or contentious does it deserve email discussion IMO
# [19:31] <tantek> maybe just *one* email to www-style saying all past issues have been collected into https://wiki.csswg.org/spec/css3-ui#current-issues once you feel you've gone through the emails about them
# [19:31] * Quits: murakami (~murakami@public.cloak) ("Page closed")
# [19:31] <tantek> (I thought I had - but if you found things I missed, then please add them)
# [19:32] <tantek> *thought I had gone through the emails re: CSS(3)-UI
# [19:32] <Florian> will do.
# [19:33] * Florian goes prepare dinner
# [19:33] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:34] <tantek> fantasai: since you're here, and a co-editor of CSS Backgrounds … could you review my proposed text for https://wiki.csswg.org/spec/css3-ui#issue-27 (has to do with propagating "root" property value to the canvas) ?
# [19:37] * Quits: tantek (~tantek@public.cloak) (tantek)
# [19:38] * Joins: tantek (~tantek@public.cloak)
# [19:46] * Joins: adenilson (~anonymous@public.cloak)
# [19:47] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [19:48] * Joins: thinkxl (~thinkxl@public.cloak)
# [19:52] * Quits: KeshavP (~KeshavP@public.cloak) ("Page closed")
# [19:53] * Quits: thinkxl_ (~thinkxl@public.cloak) (Ping timeout: 180 seconds)
# [20:00] * Quits: MaRakow_ (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [20:00] * Joins: ArronEi (~ArronEi@public.cloak)
# [20:08] * Quits: glazou (~glazou@public.cloak) ("dinner")
# [20:12] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [20:19] <fantasai> TabAtkins: Just checked in edits for the two Flexbox resolutions we made
# [20:19] <fantasai> TabAtkins: Here's the one for main-size https://dvcs.w3.org/hg/csswg/diff/915749c414e6/css-flexbox/Overview.bs
# [20:19] <fantasai> TabAtkins: Here's the one for single-line/multi-line https://dvcs.w3.org/hg/csswg/diff/7b2e6777a464/css-flexbox/Overview.bs
# [20:19] <fantasai> TabAtkins: Look them over and let me know if I missed anything?
# [20:20] <fantasai> tantek: Looks wrong
# [20:20] * fantasai looks up wording
# [20:21] <fantasai> tantek: IIRC, you don't want to propagate from <body>, you just want to propagate from the root
# [20:22] <fantasai> tantek: The behavior for background was just for legacy
# [20:22] <fantasai> tantek: For other properties (like direction, writing-mode) we don't have propagation from <body>
# [20:23] * Joins: Florian (~Florian@public.cloak)
# [20:24] <fantasai> tantek: So, something like "In orderto allow styling of the canvas, the UA must apply the 'cursor' value of the root element to the entire canvas. However, ..."
# [20:24] <fantasai> Although honestly, in your case we might not need the However
# [20:24] <fantasai> You can calculate the cursor without needing a box
# [20:24] <fantasai> We couldn't do that for background, since you need to know how big the background sizing area is
# [20:26] <TabAtkins> fantasai: In the first, where you say "which takes the same values as the 'width' property (plus an additional "content" keyword)", we should instead specifically call out that "auto", while technically a 'width' property value, is interpreted completely differently.
# [20:28] <TabAtkins> Similarly issues in the 'flex-basis' section. Otherwise that one is fine.
# [20:29] <TabAtkins> The multi-line one seems fine.
# [20:29] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [20:30] <tantek> fantasai - perhaps body propagation needs testing?
# [20:30] <fantasai> TabAtkins: the auto value is called out there, in the next paragraph
# [20:30] <fantasai> tantek: Seems like a reasonable idea
# [20:31] <tantek> I honestly don't know if cursor is propagated from body to canvas or not.
# [20:31] <TabAtkins> I know, but it sounds misleading to say "same as 'width'" when it's not - it's width minus "auto", plus a *different* "auto" keyword.
# [20:31] <tantek> just assumed it did
# [20:31] <fantasai> TabAtkins: I prefer not cluttering that sentence further
# [20:32] <fantasai> TabAtkins: It's already a parenthetical clause in a fairly complex construction
# [20:33] <TabAtkins> Then it needs some rewriting. It's misleading as written. :/
# [20:33] <TabAtkins> Let me tweak it a bit.
# [20:36] <fantasai> TabAtkins: I don't think it's misleading.
# [20:36] <fantasai> TabAtkins: I know *you* think of it as removing 'auto' and then adding in a different 'auto'
# [20:36] * Joins: jrossi1 (~jrossi@public.cloak)
# [20:36] <fantasai> TabAtkins: But I think to most people, 'auto' is just a symbol meaning "insert magic here"
# [20:37] <fantasai> TabAtkins: and having that magic be context-dependent is totally normal, and having it explained in a sentence right after the paragraph on syntax is perfectly understandable
# [20:37] <fantasai> however, feel free to test that theory on someone else
# [20:37] <fantasai> "read this stuff, explain it back to me"
# [20:38] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:38] <TabAtkins> My point is that "same as 'width', plus the "content" keyword" implies that "width: XXX" and "flex-basis: XXX" are the same, including "width: auto" and "flex-basis: auto".
# [20:39] <TabAtkins> In every other place we define a property in terms of another property, it's because they interpret things the same way.
# [20:39] <fantasai> And any exceptions are called out
# [20:39] <fantasai> Which in this case they are
# [20:39] <fantasai> in its very own paragraph immediately below.
# [20:41] * Joins: adenilson (~anonymous@public.cloak)
# [20:41] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [20:42] <TabAtkins> I just slightly reworked it to be a less complicated parenthetical anyway, and added the clarifying text I wanted.
# [20:44] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [20:44] * Joins: Florian (~Florian@public.cloak)
# [20:45] <fantasai> TabAtkins: Shorter sentences are better anyway :)
# [20:45] <TabAtkins> Yes. ^_^
# [21:03] * Joins: plh (plehegar@public.cloak)
# [21:03] * Parts: plh (plehegar@public.cloak) (Leaving)
# [21:15] * Joins: dbaron (~dbaron@public.cloak)
# [21:23] <Florian> tantek: still around?
# [21:24] <Florian> For the text of issue 27, I think we should use "default" rather than "auto" as the fall back, since auto is supposed to be context dependent, but there's no context.
# [21:25] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [21:29] <tantek> Florian - sounds reasonable
# [21:29] <tantek> what do you think of the question of body propagating to canvas?
# [21:29] <tantek> not sure implementations actually do
# [21:29] <tantek> but they might?
# [21:29] <tantek> haven't tested it
# [21:29] <tantek> (in HTML)
# [21:29] <TabAtkins> tantek: Easy to test.
# [21:29] <Florian> I was about to write a test for that
# [21:30] <Florian> I'll report back in a couple of minutes
# [21:30] <Florian> by the way, did you see the wording I proposed for this on the ML?
# [21:30] <Florian> http://www.w3.org/mid/1904C267-E71E-481E-AE72-E7FD12D88BCF@rivoal.net
# [21:31] <Florian> it is very close to yours, but with a bit more introduction and notes, using default rather than auto, and without the body part
# [21:33] * Zakim excuses himself; his presence no longer seems to be needed
# [21:33] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [21:35] <Florian> gecko does not propagate the cursor either from root of from body
# [21:36] <Florian> blink does only from root
# [21:36] <Florian> => no compat risk in not propagating from body
# [21:40] <tantek> huh - so should we even propagate from root then since we don't have interop?
# [21:40] <tantek> I prefer less magic
# [21:41] <Florian> I think we should, it is analogous to how backgrounds work, and it lets you style the whole visible area. The use case seems valid, and there is precedent for this specific kind of magic
# [21:41] <tantek> what does IE do?
# [21:42] <Florian> give me a sec, booting the vm
# [21:42] <Florian> (presto and safari do the same as blink)
# [21:42] <tantek> that's good data
# [21:43] <Florian> ie does the same as everyone else
# [21:43] <Florian> gecko is the only one not doing it
# [21:44] <tantek> well then that makes the spec question easy
# [21:44] * Florian wonders if he'll ever quit testing presto
# [21:44] <tantek> and no one propagates from body then?
# [21:44] <Florian> no
# [21:44] <Florian> not for cursor
# [21:44] <tantek> good. nice to not have that legacy
# [21:44] <Florian> indeed
# [21:45] <tantek> perhaps even worth of an (e)rror test to test against it.
# [21:45] <tantek> *worthy
# [21:45] <Florian> Completely agree
# [21:45] <tantek> to make sure it doesn't accidentally happen in the future due to some big site compat issue or bizdev nonsense
# [21:45] <Florian> I was about to make one
# [21:45] <Florian> but how do you make a reftest for cursor?
# [21:46] <Florian> I'd rather not make it interactive if I can avoid, but I am not sure I can avoid
# [21:52] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [22:04] <Florian> ok, I have a half decent test. Unfortunately, it looks like I'm going to need to make an image in the .cur format, as that's the only one supported in all browsers (according to MDN)
# [22:04] <Florian> about about mandinting png?
# [22:08] * Joins: thinkxl_ (~thinkxl@public.cloak)
# [22:08] * Quits: thinkxl_ (~thinkxl@public.cloak) (Client closed connection)
# [22:08] * Joins: thinkxl_ (~thinkxl@public.cloak)
# [22:13] * Quits: thinkxl (~thinkxl@public.cloak) (Ping timeout: 180 seconds)
# [22:30] * Joins: antonp (~Thunderbird@public.cloak)
# [22:33] <tantek> I'm ok with mandating png if 2+ browsers support it
# [22:46] <Florian> everybody but IE support it (according to mdn, and quick tests confirm)
# [22:46] <Florian> in the meanwhile, I've made a pair of tests with the .cur format, which everybody does support
# [22:47] <Florian> http://florian.rivoal.net/csswg/root-propagate.html
# [22:47] <Florian> http://florian.rivoal.net/csswg/body-propagate.html
# [22:48] <Florian> I'll submit once the normative prose hits the spec
# [22:48] * jdaggett|sleep is now known as jdaggett
# [22:48] * Quits: Rossen___ (~uid21900@public.cloak) ("Connection closed for inactivity")
# [22:53] * Joins: adenilson (~anonymous@public.cloak)
# [22:58] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [23:01] <Florian> and if anyone's curious, the easiest way to create a .cur file is with http://www.nongnu.org/icoutils/
# [23:01] <Florian> port install icoutils && icotool -c -o foo.cur foo.png
# [23:06] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [23:11] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:14] * Joins: dael (~dael@public.cloak)
# [23:17] * Quits: jrossi1 (~jrossi@public.cloak) ("Leaving.")
# [23:19] * Joins: tantek (~tantek@public.cloak)
# [23:19] <tantek> Florian - wow the root propagate test gives a very random looking cursor in Safari 6.1.6
# [23:20] <Florian> wow, indeed
# [23:20] <tantek> and when I try to load green.cur directly in the browser - it gives me "Failed to load resource: Frame load interrupted"
# [23:20] * Joins: jrossi (~jrossi@public.cloak)
# [23:20] <tantek> !!!
# [23:20] <Florian> I guess there is no commonly supported image format then
# [23:21] <Florian> if .cur on mac isn't the same thing as .cur on windows
# [23:21] <Florian> wait, mdn suggests the .ani format as well
# [23:21] <tantek> Florian - your server is sending application/octet-stream
# [23:21] <tantek> need to fix the mime type
# [23:22] <Florian> good point
# [23:22] <tantek> for http://florian.rivoal.net/csswg/green.cur
# [23:22] <tantek> that could be screwing up both Safari and FF
# [23:23] <Florian> this one, right? http://filext.com/file-extension/CUR
# [23:25] <tantek> Florian - I thought you said you wanted to require png?
# [23:25] <Florian> I do
# [23:25] <tantek> then...
# [23:25] <Florian> just wanted to also write a test that runs in browsers today
# [23:25] <tantek> green.png?
# [23:25] <tantek> oh ok
# [23:26] <Florian> I could write the same test without green / red, and using other cursors, but it'd be harder to read
# [23:26] <Florian> and having an interoperable format sounds like a good thing anyway
# [23:27] <tantek> see http://en.wikipedia.org/wiki/ICO_%28file_format%29#PNG_format
# [23:27] <tantek> you can use PNG inside CUR :)
# [23:27] <Florian> yes, but you have to repackage
# [23:27] <tantek> now that we have APNG for animated PNG, perhaps we need CPNG for a Cursor PNG
# [23:28] <tantek> or does PNG already have the notion of a hotspot (I think it might)
# [23:30] <Florian> On a different topic, do you want a patch for the various things we decided to drop today? On top of removing the sections, some adjustments to the introduction /abstract / overview / at-risk / default style sheet is needed to go with it?
# [23:30] <tantek> where's Chris Lilley when you need him
# [23:30] <tantek> dropping stuff is easy enough - I can take care of it
# [23:30] <Florian> sure
# [23:30] <tantek> including the related updates / prose references to such features
# [23:30] <Florian> in general, I like making the patches though. It's a good way to get familiar with the details of the spec
# [23:30] <tantek> should be able to do it within a day or two
# [23:31] <tantek> hoping to also do the cursor edits too
# [23:31] <Florian> "cursor edits" = propagate to canvas?
# [23:31] <tantek> can't find anything about a cursor or hotspot in http://www.w3.org/TR/PNG/
# [23:31] <tantek> cursor property related edits yeah
# [23:31] <tantek> and then I can get started on caret
# [23:32] <Florian> sounds good.
# [23:32] <tantek> hmm I should add an issue for that immediately
# [23:33] <Florian> For the cursor edits, I have sent patches to the ml. If they suck, feel free to discard, but otherwise, you can save 15 minutes :)
# [23:33] <tantek> heh - will do and thanks :)
# [23:33] <Florian> as for mandating PNG, that probably show be listed as well, and brought to the list
# [23:33] <tantek> hmm - why is caret-color so specific?
# [23:34] <tantek> I'd expect just "caret" which could take a combination of color and a keyword
# [23:34] <Florian> what do you mean?
# [23:34] <tantek> e.g. orange segment
# [23:34] <tantek> e.g. green block
# [23:35] <Florian> where are you reading this from? I don't believe that's what we resolved to add
# [23:35] <tantek> carets have multiple shapres
# [23:35] <tantek> shapes even
# [23:35] <tantek> why only color?
# [23:35] <tantek> seems a bit odd
# [23:35] <Florian> well, I kind of wanted to discuss that, but people seemed happy to keep it simple.
# [23:36] <Florian> also, tab kind of objected to the block cursor, because it has semantics associated with it (overwrite instead of insert)
# [23:36] <tantek> simple is starting with just 'caret' that could allow for different kinds of values in the future
# [23:36] <tantek> rather than boxing ourselves into 'caret-color'
# [23:36] <tantek> it has no such semantics
# [23:36] <tantek> presence/absence of a block cursor is orthogonal to overwrite/insert
# [23:37] <Florian> well, it could work as a long hand, so we could still introduce a 'caret' short hand later
# [23:37] <tantek> on platforms that support overwrite/insert toggling - typically the cursor *stays* as a block
# [23:37] <tantek> yeah
# [23:37] <tantek> well, it's at risk anyway and likely to get cut
# [23:37] <tantek> when we go from LCCR->PR
# [23:38] <tantek> I don't expect browsers to implement it quickly
# [23:38] <tantek> so we can simply to 'caret' in CSS4-UI with both
# [23:38] <tantek> *do
# [23:38] <Florian> hmm. I thought I agreed with Tab about overwrite sematics, but I just checked the OS X terminal, and it has a block cursor with insert semantics
# [23:38] <tantek> bingo
# [23:38] <tantek> the look of the cursor does not convey the semantics
# [23:38] <tantek> it's purely … stylistic ;)
# [23:38] <Florian> by the way, in terms of process. As far as I understand, the only transition from old process to new process that we can't do is old LC -> new CR
# [23:39] <Florian> so the easiest is probably to republish as a WD once, and imediately go to new CR after that
# [23:40] <tantek> who is andreyr?
# [23:40] <Florian> multiple implemenations, I don't know. But at least one should be fast enough. I believe bloomberg has a patch for chrome that they maintain locally, and would like to upstream (after matching the spec) once it is standard
# [23:40] <Florian> anreyr is from bloomberg
# [23:40] <tantek> I'm pretty sure that since we've been in CR before we can straight to new CR
# [23:41] <Florian> s/anreyr/andreyr/
# [23:42] <tantek> anyway - it will be a good test of new process
# [23:42] <tantek> because I believe it fits within the intent
# [23:42] <tantek> Lea's original proposal was for just 'caret' http://lists.w3.org/Archives/Public/www-style/2011Nov/0772.html
# [23:44] <Florian> I don't care strongly. As long as we're keeping door open for extensions
# [23:44] <Florian> shapes as you suggested
# [23:44] <Florian> or blink speed
# [23:44] <Florian> or what have you
# [23:45] <tantek> oh hey - who is Silverwind?
# [23:46] <Florian> that I don't know
# [23:46] <tantek> already proposed caret-style line block underline http://lists.w3.org/Archives/Public/www-style/2014Sep/0172.html
# [23:46] <tantek> ok that looks good enough for CSS4-UI
# [23:46] <Florian> but I believe that's the reason that we ended up with caret-color right now, rather than just caret as Lea suggested
# [23:46] <tantek> and we'll stick with *just* caret-color for CSS3-UI at risk, and watch it likely get dropped
# [23:47] <Florian> (or something along these lines)
# [23:47] <tantek> sure
# [23:47] <tantek> we can put the 'caret' shorthand in CSS4-UI
# [23:47] <Florian> right
# [23:47] <tantek> but it's annoying that we won't be able to use the shorthand from the start
# [23:47] <tantek> that's why I'm suggesting it for 3
# [23:49] <Florian> In general, I am not entirely sure I want to settle on a syntax for the short hand before we debate exactly what goes into the long hands. long1 || long2 || long3 often works, but sometimes we do something else
# [23:49] <Florian> in this case though, I'd be surprised if we did something else
# [23:49] <tantek> sure that's reasonable. I'll likely write something up anyway
# [23:50] <tantek> so we have something to discuss
# [23:50] <Florian> thanks
# [23:50] <Florian> Also, I don't know that we actually want the 'invert' color value
# [23:51] * Quits: jrossi (~jrossi@public.cloak) ("Leaving.")
# [23:52] <Florian> invert doesn't play well with compositing
# [23:52] <tantek> I'm not including invert
# [23:52] <tantek> since there was no consensus on that
# [23:52] <tantek> in fact the only consensus was on *caret-color* in *css3-ui*
# [23:52] <tantek> so I'm going to take editor's liberty in defining the property as I interpret the group's consensus intersected with what has a chance of interoperably shipping soonish
# [23:52] <tantek> captured with plenty of URLs
# [23:52] <tantek> exactly. no invert value.
# [23:52] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-31
# [23:53] <Florian> I'd suggest auto computes to auto, and lets UAs do whatever they want
# [23:53] <Florian> currentColor is probably what they'll do, but if they have a better idea, fine by me
# [23:54] <tantek> hence a *should* for currentColor rather than a must
# [23:55] <Florian> do you want that reflected in the computed value though?
# [23:57] <Florian> not sure what the implications are in terms transitions/ animation.
# [23:58] <tantek> yes your wording may be better - feel free to update https://wiki.csswg.org/spec/css3-ui#issue-31 accordingly
# [23:58] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [23:58] <Florian> It's getting late here, I'll sleep on it.
# [23:59] <tantek> sounds good. night!
# Session Close: Thu Nov 20 00:00:00 2014

The end :)