/irc-logs / w3c / #css / 2014-01-15 / end

Options:

# Session Start: Wed Jan 15 00:00:00 2014
# Session Ident: #css
# [00:06] * Joins: zcorpan (~zcorpan@public.cloak)
# [00:09] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [00:13] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [00:14] * Joins: teoli (~teoli@public.cloak)
# [00:15] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [00:19] <TabAtkins> paul___irish: Ah, you're right, we can't use font-size as a discriminator in @font-face, at least. So yeah, doesn't really make sense.
# [00:19] <TabAtkins> I'll think on it and see if it makes sense to special-case the grammar to not force the inclusion of font-size.
# [00:20] * Joins: teoli (~teoli@public.cloak)
# [00:20] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [00:22] <TabAtkins> paul___irish: Ah, fantasai just pointed out *why* font-size is required.
# [00:22] <TabAtkins> It's a grammar disambiguator.
# [00:22] <TabAtkins> Blame the ability to have unquoted font names.
# [00:22] <TabAtkins> We can't tell whether "bold Arial" is dictating the bold variant of "Arial", or a font named "bold Arial".
# [00:23] <TabAtkins> Requiring a font-size between them disambiguates this.
# [00:23] <TabAtkins> So no, we can't remove the font-size from the grammar for .match().
# [00:23] <TabAtkins> I'll put a note in the Font Load Events spec about this, recommending just using "1em" or whatever.
# [00:27] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [00:27] <paul___irish> TabAtkins: that'd be awesome. thank you
# [00:28] <paul___irish> tried out our impl in blink this weekend. pretty fun. :)
# [00:36] * Joins: jdaggett (~jdaggett@public.cloak)
# [00:58] * Joins: dwim (~dwim@public.cloak)
# [01:06] * Joins: zcorpan (~zcorpan@public.cloak)
# [01:08] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [01:08] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [01:15] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [01:24] * Joins: teoli (~teoli@public.cloak)
# [01:38] * Joins: sgalineau (~sgalineau@public.cloak)
# [01:40] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [01:50] * Joins: adenilson (~anonymous@public.cloak)
# [01:53] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [01:53] * Quits: eliezerb (~Eliezer@public.cloak) (Client closed connection)
# [01:59] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:09] * Joins: zcorpan (~zcorpan@public.cloak)
# [02:10] * Quits: jet (~junglecode@public.cloak) (jet)
# [02:10] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [02:16] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:29] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [02:33] * Joins: teoli (~teoli@public.cloak)
# [02:33] * Joins: adenilson (~anonymous@public.cloak)
# [02:42] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [02:42] * Joins: teoli (~teoli@public.cloak)
# [02:42] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [03:00] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [03:00] * Joins: dwim (~dwim@public.cloak)
# [03:03] * Joins: eliezerb (~Eliezer@public.cloak)
# [03:03] * Quits: eliezerb_2nd (~Eliezer@public.cloak) (Client closed connection)
# [03:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:16] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [03:17] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [03:18] * Joins: teoli (~teoli@public.cloak)
# [03:26] * Quits: eliezerb (~Eliezer@public.cloak) (Client closed connection)
# [03:26] * Joins: eliezerb (~Eliezer@public.cloak)
# [03:26] * Joins: adenilson (~anonymous@public.cloak)
# [03:26] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [03:39] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [03:40] * Joins: dwim_ (~dwim@public.cloak)
# [03:42] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [03:43] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [03:46] * Quits: eliezerb (~Eliezer@public.cloak) ("Leaving")
# [04:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [04:18] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [05:11] * Joins: zcorpan (~zcorpan@public.cloak)
# [05:18] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [05:31] * Quits: dwim_ (~dwim@public.cloak) (Client closed connection)
# [05:31] * Joins: dwim_ (~dwim@public.cloak)
# [05:32] * Quits: dwim_ (~dwim@public.cloak) (Client closed connection)
# [05:32] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:32] * Joins: dwim_ (~dwim@public.cloak)
# [05:44] * Joins: jet (~junglecode@public.cloak)
# [05:47] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [06:11] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [06:11] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [06:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:19] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [06:19] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [06:24] * Joins: dbaron (~dbaron@public.cloak)
# [08:43] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:53] * plinss changes topic to '15-jan-2014 Telcon Canceled'
# [08:55] * fantasai waves to Ms2ger
# [08:55] <Ms2ger> Good morning
# [08:56] <fantasai> Good evening :)
# [08:56] <Ms2ger> How are you?
# [08:57] <fantasai> sleepy
# [08:57] * Quits: jet (~junglecode@public.cloak) (jet)
# [08:57] <fantasai> I should go to bed, but have to convince myself to move first, heh
# [08:59] <Ms2ger> Can't argue with that :)
# [08:59] * fantasai overcomes static friction
# [09:00] <Ms2ger> Good night :)
# [09:06] * Quits: dwim_ (~dwim@public.cloak) (Client closed connection)
# [09:07] * Joins: dwim_ (~dwim@public.cloak)
# [09:07] * Quits: dwim_ (~dwim@public.cloak) (Client closed connection)
# [09:07] * Joins: dwim_ (~dwim@public.cloak)
# [09:11] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:32] * Quits: dwim_ (~dwim@public.cloak) (Client closed connection)
# [09:33] * Joins: dwim_ (~dwim@public.cloak)
# [09:45] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [09:45] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:52] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [10:32] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:55] * Joins: darktears (~darktears@public.cloak)
# [12:30] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:51] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [12:51] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:58] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [13:01] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:13] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [13:13] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:45] * Joins: teoli (~teoli@public.cloak)
# [14:00] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [14:01] * Joins: plh (plehegar@public.cloak)
# [14:24] * Joins: eliezerb (~Eliezer@public.cloak)
# [14:47] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [15:00] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:07] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [15:21] * Joins: eliezerb (~Eliezer@public.cloak)
# [15:40] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [15:55] * Quits: dwim_ (~dwim@public.cloak) (Client closed connection)
# [15:55] * Joins: dwim_ (~dwim@public.cloak)
# [16:00] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:05] * Joins: eliezerb (~Eliezer@public.cloak)
# [16:07] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:28] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [16:29] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [16:34] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [17:00] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:04] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:05] * nvdbleek i'm going to a sep room to do the call
# [17:07] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:10] <SimonSapin> nvdbleek: the call is cancelled https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0032.html
# [17:29] * Joins: lmcliste_ (~lmclister@public.cloak)
# [17:33] * Joins: eliezerb (~Eliezer@public.cloak)
# [17:38] * Quits: eliezerb_2nd (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [17:48] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [17:51] * Joins: sgalineau (~sgalineau@public.cloak)
# [17:53] <krit> SimonSapin: oh, thanks
# [17:55] * Joins: MaRakow (~MaRakow@public.cloak)
# [17:56] * Joins: teoli (~teoli@public.cloak)
# [17:56] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [17:56] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:57] * Joins: glenn (~gadams@public.cloak)
# [17:59] * Joins: BradK (~bradk@public.cloak)
# [18:00] * Joins: tantek (~tantek@public.cloak)
# [18:00] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:01] * Parts: BradK (~bradk@public.cloak) (BradK)
# [18:06] * Joins: adenilson (~anonymous@public.cloak)
# [18:21] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:22] * Joins: israelh (~israelh@public.cloak)
# [18:22] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [18:32] * Joins: jet (~junglecode@public.cloak)
# [18:34] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [18:35] * Joins: teoli (~teoli@public.cloak)
# [18:37] * Joins: teoli_ (~teoli@public.cloak)
# [18:37] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [18:45] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:53] * Joins: dbaron (~dbaron@public.cloak)
# [19:02] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:09] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [19:24] <fantasai> ping astearns
# [19:24] <astearns> fantasai: heya
# [19:24] <fantasai> astearns: So...
# [19:24] <fantasai> astearns: Serialization is supposed to be defined in CSSOM
# [19:25] <fantasai> we explicitly didn't include it in css3-background
# [19:25] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [19:25] <fantasai> because of that
# [19:25] <fantasai> I can add a statement for background-position
# [19:25] <fantasai> but I don't want to go through and add serialization rules for all the properties...
# [19:25] <fantasai> because it shouldn't be in this spec
# [19:25] <astearns> I just posted an additional serialization question on background-position
# [19:25] <astearns> (in a [css-shapes] post, unfortunately)
# [19:26] <astearns> I'm mainly (only?) concerned with <position> because the computed value makes serialization tricky
# [19:26] <fantasai> Yes
# [19:26] <fantasai> but
# [19:27] <fantasai> it should be fixed in CSSOM
# [19:27] <Ms2ger> Why?
# [19:27] <fantasai> where we define the serialization of all the other types
# [19:28] <fantasai> Ms2ger: Because CSSOM is where the serialization rules are, for the most part
# [19:28] <krit> fantasai: unless we republish an updated version every couples of month, we maybe need to think how it should be done per spec and property
# [19:29] <fantasai> krit: I think that was the goal, to get there eventualy
# [19:29] <Ms2ger> The serialization rules should be there because they should be there?
# [19:29] <fantasai> krit: but CSS2.1's rules aren't in 2.1
# [19:29] <astearns> I agree that CSSOM should define serialization, but if/when modules make new things that require changes, I think it's fine to describe those changes in those modules
# [19:29] <fantasai> krit: so they have to be covered by CSSOM
# [19:29] <fantasai> krit: CSS3 Backgrounds was similarly grandfathered in
# [19:29] <fantasai> krit: adding serialization rules to it would expand the scope
# [19:30] <fantasai> krit: which I don't really want to do right now, I want to just fix the things that are wrong in it righ tnow
# [19:30] <krit> fantasai: I totally understand your point
# [19:31] <krit> fantasai: the problem is that we don’t even have a stable version of CSSOM today… how can we expect that we get an updated version in short amount of times?
# [19:31] <fantasai> The answer to that question is right in your statement.
# [19:31] <fantasai> CSSOM is unstable, so we can updated it whenever we please :P
# [19:31] <fantasai> I was looking through it actually, and I can't see that it handles serialization properly for a lot of things
# [19:31] <fantasai> any property with more than one component value
# [19:31] <fantasai> :/
# [19:32] <fantasai> or at least, more than one component value and not a defined order of them
# [19:32] <fantasai> counter-reset is an ordered list, so it's handled...
# [19:32] <fantasai> but background-position
# [19:32] <fantasai> and border-spacing
# [19:32] <fantasai> aren't
# [19:33] <fantasai> s/defined order/defined order and size/
# [19:33] <fantasai> s/size/number/
# [19:33] <fantasai> because they have optional components
# [19:33] <krit> fantasai: I guess the question is can our specs get to CR, even if a part is not specified (meaning CSSOM no in LC)
# [19:33] <astearns> what I want to avoid happening again: we go to LC on Shapes, defining things in a reasonable way for <position>, then those things about <position> change out from under us, so we have to go to LC again. Last time it was computed value. I don't want to do the same dance with serialization
# [19:33] <astearns> where it gets defined doesn't matter to me
# [19:34] <krit> astearns: agree
# [19:34] <fantasai> astearns: Where in your spec are you relying on serialization such that changing the serialization rules would break your spec?
# [19:35] <astearns> I wouldn't characterize it as a break, just a change. I define the computed value and serialization of circle() and ellipse()
# [19:36] <fantasai> OK
# [19:36] <fantasai> astearns: Are you OK for CSS3 Background to go to LC, and we work on serialization of <position> in CSSOM?
# [19:37] <fantasai> astearns: We can refile the issue against LC if it turns out to be a problem.
# [19:37] <astearns> I'd like to see the serialization rules for background-position set down somewhere before we go to LC on Backgrounds
# [19:38] * sgalineau remembers when 'put it in CSSOM' was the other 'put it in GCPM'. Thank you, Simon Pieters
# [19:38] <fantasai> sgalineau, it was never that bad. Amything we wanted to put in CSSOM was something we seriously wanted someone to work on. Except nobody did
# [19:39] * sgalineau oh yeah, I see the huge difference :)
# [19:39] * sgalineau stands corrected. There was GCPM. And there was piping work to /dev/nul.
# [19:39] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [19:40] * Joins: teoli (~teoli@public.cloak)
# [19:40] * Joins: teoli_ (~teoli@public.cloak)
# [19:40] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [19:40] <fantasai> We were piping it to the zcorpan of the future :)
# [19:40] <fantasai> We just didn't know it yet.
# [19:40] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:41] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:41] <sgalineau> Yeah, I could think of CSSWG as the Matrix crossed with Back To The Future
# [19:42] <sgalineau> side note: it feels odd to have computed values depend on serialization definitions. But for that I'll have to stop by astearns' office so he educates me
# [19:42] <fantasai> They shouldn't
# [19:43] <astearns> they do not
# [19:43] <fantasai> I think he just wants them defined somewhere, and they're not currently
# [19:43] <astearns> serializations can depend on computed values, though
# [19:43] <sgalineau> they do not. but they can. :)
# [19:44] <sgalineau> anyway. to be discussed later. (side note of side note: never understood why we want or need to define serialized values either but oh well)
# [19:47] <fantasai> they usually do, because getComputedStyle usually returns some serialization of the computed value
# [19:47] <krit> sgalineau: there is a lot you still need to learn young padawan
# [19:51] <sgalineau> fantasai, sure. I understand why an editor wants a clear definition of a computed value. Not sure why they need to worry about how it's serialized. I understand animations/transitions can be a reason but that seems brittle.
# [19:52] <astearns> sgalineau: in my case it's because I have conscientious engineers who want to implement serialization correctly :)
# [19:52] <astearns> and ideally, once
# [19:54] <sgalineau> if the result is getComputedStyle() can be used in a static stylesheet to obtain the exact same result, isn't it correct?
# [20:01] * fantasai rereads astearns' message
# [20:01] <fantasai> astearns: is the getComputedStyle result really 'right 10px' and not '100% 10px'?
# [20:02] <fantasai> or is this something that we need tests for...
# [20:02] <fantasai> to figure out what it actually is
# [20:02] <astearns> fantasai: good question
# [20:03] <fantasai> astearns: background-position has always computed to percentage/length, no keywords
# [20:03] <fantasai> http://www.w3.org/TR/CSS21/colors.html#propdef-background-position
# [20:06] <astearns> 100% 10px isn't correct - that's equivalent to right top 10px
# [20:08] <astearns> the serialization would either be 'right 10px' or 'calc(100%-10px)'
# [20:08] <astearns> with an omitted 'center' for the vertical component
# [20:14] <fantasai> oh, maybe I meant "10px 100%" :)
# [20:14] * fantasai forgets the order
# [20:14] <astearns> the 10px is the offset from the right edge in my example
# [20:14] <fantasai> ...
# [20:14] <fantasai> I don't think that's valid
# [20:14] <fantasai> if it's valid, I made a mistake somewhere
# [20:15] <fantasai> two-value positions are always interpreted per CSS2.1 rules, or should be
# [20:15] * fantasai is annoyed that the /TR copy is missing various corrections over the last 2 years
# [20:15] <fantasai> :/
# [20:16] <Ms2ger> Well, it is the TR copy
# [20:16] <Ms2ger> That's its purpose
# [20:16] <fantasai> um, no
# [20:16] <fantasai> that is what it has degenerated to
# [20:16] <astearns> ah right, I should have used a three-value example. I'll post a correction
# [20:16] <astearns> (or four)
# [20:16] <fantasai> Ms2ger: it's purpose, originally, was to be an up to date latest draft of what the WG is working on :)
# [20:17] <Ms2ger> Of course
# [20:19] <fantasai> astearns: Maybe post into the new thread on serialization? :)
# [20:19] * fantasai needs zcorpan to get involved
# [20:19] <fantasai> I'm not OM expert
# [20:22] <astearns> I think the main question is whether it's useful to have a single defined serialization where multiple possible serializations could be used
# [20:22] <sgalineau> exactly!
# [20:22] <Ms2ger> Yes it is
# [20:22] <sgalineau> you *can* define serialization. I don't get why we *must*
# [20:22] <Ms2ger> ...
# [20:23] <astearns> I agree with Ms2ger, so I think we must :)
# [20:23] <Ms2ger> Because the goal of a specification is interop?
# [20:23] <sgalineau> what interop are you specifically talking about?
# [20:23] <Ms2ger> getComputedStyle?
# [20:24] <astearns> a script that depends on manipulating the string you get from getComputedStyle
# [20:24] <astearns> if different browsers give you different strings, it's bad
# [20:24] <sgalineau> that scripts have to manipulate strings is a bug
# [20:24] <astearns> s/a bug/unfortunate reality/
# [20:24] <Ms2ger> That doesn't excuse you from defining it
# [20:25] <Ms2ger> That quirks mode exists is a bug, yet we still spec it
# [20:25] <sgalineau> browsers parse strings into concrete values. which we then serialize to strings so script can parse them back into integers and then deserialize them. it's insane.
# [20:25] <Ms2ger> Hell, most of the HTML spec is bugs
# [20:25] <Ms2ger> But if you're going to design the new cssom, go for it!
# [20:25] <sgalineau> well, here is the question I'm really asking
# [20:25] <astearns> sgalineau: I agree - I'd like to have a new CSSOM with parsed values
# [20:26] <astearns> but there's legacy to support as well
# [20:26] <sgalineau> is the work of 1) defining serialization 2) agreeing to it 3) writing all the testcases 4) achieving interop really that much cheaper than defining an OM for value types?
# [20:26] <Ms2ger> So
# [20:26] <Ms2ger> What do you want to do when someone has an old script that getComputedStyles background
# [20:27] <Ms2ger> And wants to use the new fancy b&b-4 stuff
# [20:27] <Ms2ger> Throw an exception? Return half the position?
# [20:28] <sgalineau> that's not a new problem and I don't see how defining serialization avoids that problem
# [20:28] <sgalineau> you have no control on how anyone will parse those values
# [20:28] * sgalineau recalls the number of times changing serialization in IE broke something somewhere. good luck convincing browsers to align to some new thing.
# [20:29] <Ms2ger> Right
# [20:29] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [20:29] <Ms2ger> So you're saying that pages depend on a particular serialization?
# [20:29] <sgalineau> they even depend on more than one
# [20:29] <Ms2ger> That's why you define it
# [20:30] <Ms2ger> So that there's only one
# [20:30] <Ms2ger> And so that I don't have to figure it out by myself when Servo implements it
# [20:30] <sgalineau> ok, let's fast forward to the day all browsers emit the same computed value string
# [20:31] <sgalineau> that's certainly nice for the people who write JS to parse it - no doubt - but it still gives you no control on the level of brokeness of the JS code that parses it
# [20:31] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [20:31] <sgalineau> …and how sensitive that code will be to new updates from future levels etc.
# [20:31] <sgalineau> so we're not fixing the bit that's most likely to break down
# [20:32] <astearns> so? we're fixing the bit we have some control over
# [20:32] <sgalineau> ah, so what matters is what we have control over, not whether it fixes the main problem?
# [20:32] <astearns> (and incidentally, making cross-browser animation tests slightly easier to write)
# [20:33] <astearns> just because we can't fix the whole problem doesn't mean we should throw up our hands on our portion of the problem
# [20:34] <sgalineau> that's not the point
# [20:34] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [20:34] <sgalineau> you're assuming you *can* fix this problem
# [20:34] <sgalineau> using strings
# [20:34] <Ms2ger> No
# [20:34] <Ms2ger> I'm assuming that there exists an API that spits out those strings
# [20:34] <Ms2ger> And that people use it
# [20:35] <Ms2ger> And that browsers need to implement it
# [20:35] <sgalineau> again, I spent 5 years dealing with breakage related to small changes to computed value strings. looking at other's bug databases it's not an isolated experience
# [20:35] <Ms2ger> And that pages depend on the particulars of the output
# [20:35] <Ms2ger> So that browsers that want pages to work need to get the output right
# [20:35] <Ms2ger> THAT'S WHY YOU SPEC IT NOW
# [20:35] <sgalineau> so what is the benefit browser vendors get of dealing with all the pain of convering on some common serialization format? I don't get it.
# [20:36] <Ms2ger> So that they don't need to converge *after* pages rely on different formats
# [20:36] <sgalineau> i don't give a shit about speccing it. any monkey can write the spec. WILL IT BE IMPLEMENTED and why is my question.
# [20:36] <Ms2ger> Because you need to implement something?
# [20:36] <sgalineau> er, pages already rely on different formats
# [20:37] <Ms2ger> Because it wasn't specced in the first place!
# [20:37] <sgalineau> it's already been implemented many times
# [20:37] <sgalineau> without any specs
# [20:37] <astearns> scoping my portion of the problem, I don't expect to fix background-position. I want to specify the serialization of circle() at the outset so that we don't get different implementations that people have to deal with
# [20:37] <Ms2ger> And that's why you're having this issue
# [20:37] <sgalineau> i don't' have any issues!
# [20:37] <sgalineau> jesus
# [20:37] <sgalineau> my issue is having to deal with fucking strings
# [20:38] <Ms2ger> Then fix that!
# [20:38] <Ms2ger> But in the meantime, don't complain when people spec the thing that's actually used
# [20:38] <astearns> "sgalineau> i don't' have any issues!" is a fine start for a W3C meme
# [20:38] <sgalineau> LOL
# [20:38] <sgalineau> yes
# [20:39] <sgalineau> I'm not complaining. I'm asking why this needs to be defined. I'm still not getting an answer except 'we're doing this because it can be done and specifying how things should work is a nice thing to do irrespective of whether or not this is the biggest problem for authors, and irrespective of whether or not anyone will implement the thing to begin with'
# [20:40] <Ms2ger> No, it needs to be implemented, that's the main thing
# [20:40] <astearns> my engineers are implementing circle(), and asking how they should serialize it
# [20:40] <Ms2ger> And it needs to be specced so that we can get it implemented the same way
# [20:40] <Ms2ger> I don't want all browser engines to serialize circle() differently
# [20:41] <Ms2ger> Because then you get something that apparently is not an issue, not sure what it is then, where pages need to handle different formats
# [20:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:41] <sgalineau> so that parsing is easier, something which everyone agrees is wrong
# [20:41] <Ms2ger> Because, in the real world, there is no replacement yet
# [20:42] <Ms2ger> You can't tell people "don't write any code until we've implemented the replacement in ten years"
# [20:42] <sgalineau> it's not what I'm saying at all
# [20:42] <sgalineau> so never mind
# [20:42] <Ms2ger> Parsing needs to be easier, yes
# [20:42] <Ms2ger> Because parsing is the only way to do it
# [20:42] <sgalineau> nobody should write JS to parse computed values
# [20:43] <Ms2ger> What should they do?
# [20:43] <Ms2ger> Not do any dynamic styling?
# [20:43] <Ms2ger> Use dart?
# [20:43] <sgalineau> WTF?
# [20:43] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [20:43] <sgalineau> why should anyone have to produce "100px" then "101px" then "102px" in a loop?
# [20:44] <sgalineau> instead of incrementing e.g. style.width.px ?
# [20:44] * Joins: teoli (~teoli@public.cloak)
# [20:44] <Ms2ger> Did someone implement the non-string-based cssom while I wasn't looking?
# [20:44] <Ms2ger> Because their boss says they have to support IE6?
# [20:44] <Ms2ger> Incrementing style.width.px right now is a ReferenceError
# [20:44] <sgalineau> oh, I''m sorry. I sort of thought we defined new features in the platform. I forgot IE6 defined the scope of everything we do
# [20:45] * Joins: teoli_ (~teoli@public.cloak)
# [20:45] <Ms2ger> No, we also spec legacy features
# [20:45] <sgalineau> of course it is. until we define it and then polyfill it for older versions.
# [20:45] <Ms2ger> Then go ahead and define it
# [20:45] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [20:45] <sgalineau> circle() is not a legacy feature
# [20:46] <sgalineau> and the serialization work I've seen so far is not specifying how things work today either (since it varies anyway).
# [20:46] <sgalineau> so since we're doing new work anyway, why not do new work that also moves the platform forward
# [20:46] <Ms2ger> Sure, do it
# [20:46] <sgalineau> it's called a WG
# [20:47] <sgalineau> the WG prefers to define strings. I'm asking why. If you don't like my asking that's too bad
# [20:47] <Ms2ger> I've heard people say we need a better cssom ever since I first subscribed to www-style 6 years ago
# [20:47] <Ms2ger> I've never seen it happen
# [20:47] <sgalineau> so what?
# [20:47] <sgalineau> does that prove we don't need a better cssom?
# [20:47] <Ms2ger> No
# [20:47] <Ms2ger> That suggests that it isn't going to happen soon
# [20:47] <Ms2ger> And that people will need to use strings
# [20:48] <sgalineau> doing something that doesn't fix the problem is unlikely to make it happen sooner
# [20:48] <Ms2ger> Not defining serialization won't make it happen any sooner either
# [20:48] <Ms2ger> If you want to improve the cssom, step up and do the work
# [20:48] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [20:49] * fantasai would like Animations finished, too
# [20:50] <sgalineau> I heard you irrelevant 'step up and do the work' dismissal the first 12 times.
# [20:50] <fantasai> It's not irrelevant
# [20:50] <fantasai> It's the reason it's not done yet
# [20:50] <fantasai> Nobody's stepped up to do the work
# [20:51] <sgalineau> no. that it's not done is not a reason to agonize over strings that people will keep parsing wrong in a broken way.
# [20:51] <SimonSapin> I don’t think the WG prefers strings, it’s just the only thing we have so far
# [20:51] <sgalineau> er, yeah, if we don't commit to the work what is there today is all we have :)
# [20:51] <sgalineau> that bit makes sense :)
# [20:52] <astearns> even if we commit to that work, what's there today will still be around for a long long time
# [20:52] <Ms2ger> Genuinely curious: how do you think this better cssom is going to happen if nobody starts working on it?
# [20:53] <sgalineau> asteans, sure. but I don't see anyone doing the work for what we have either. Is there any work going on to document what browsers serialize today that I missed?
# [20:54] <astearns> sgalineau: that part I don't care as much about, actually. I just want to do the new things in a consistent way
# [20:55] <sgalineau> fair enough. better make sure people pay attention to CSSOM then. because the things was neglected for so long it stopped being true some time ago for quite a few people.
# [20:56] * Joins: plh (plehegar@public.cloak)
# [20:57] <sgalineau> IE9 actually followed anne's first set of CSSOM rules years ago. first it caused all kinds of breakage. then we were told 'oh no, this was just what anne thought. the WG didn't agree to that'. needless to say, the mistake of paying attention to serialization in CSSOM was not made again.
# [20:57] * sgalineau is likely overly bias due to the amount of needless serialization shit he shoveled over the years.
# [20:58] <Ms2ger> I guess it would have been good if, at the time, there had been tests that could be run cross-browser to check what others did
# [20:59] * Joins: plh3 (plehegar@public.cloak)
# [20:59] * Ms2ger doesn't feel like "the wg agreed to it" is a relevant argument anyway
# [20:59] <sgalineau> tests are very nice. whether they will generate willingness to change code and deal with the compat fallout or impede it is another story. but i suppose that's a separate story from whether new features should define their serialization.
# [20:59] <fantasai> Ms2ger: it usually means there was more review of the thing than if there wasn't
# [21:00] <fantasai> and more review usually means fewere bugs than less review :)
# [21:00] <Ms2ger> Sure, review is good
# [21:00] <sgalineau> it was the argument used for others - mozilla, in fact - to not care about it or make any changes. so it was relevant at one time.
# [21:01] <sgalineau> anyway. this horse is beaten silly. later.
# [21:01] <Ms2ger> Bye
# [21:05] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [21:31] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [21:31] * Joins: teoli (~teoli@public.cloak)
# [21:38] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [21:42] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:48] <TabAtkins> I'm extremely confused by this entire conversation.
# [21:49] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [21:49] * TabAtkins doesn't understand how "We have a feature that we can't kill, *of course* we have to spec it." isn't a sufficient answer.
# [21:49] <Ms2ger> I was half of it and I'm confused too
# [21:51] <astearns> we've gone along for many years without specifying background-position syntax, so 'why now' could be a reasonable response
# [21:51] <astearns> but I don't mind being the forcing function
# [21:51] <astearns> s/syntax/serialization/
# [21:52] <TabAtkins> Ah, "why now" is "Because fuck us for not doing it earlier, that's why."
# [21:53] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [21:55] <Ms2ger> "Because you can't build a house without a foundation, as much as the CSSWG likes to"? :)
# [21:58] * Joins: glenn (~gadams@public.cloak)
# [21:58] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [21:58] * Joins: glenn (~gadams@public.cloak)
# [22:24] * Joins: glenn_ (~gadams@public.cloak)
# [22:30] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [22:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:48] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [22:56] * Joins: jet (~junglecode@public.cloak)
# [22:56] * Joins: teoli (~teoli@public.cloak)
# [22:59] * Joins: dbaron (~dbaron@public.cloak)
# [23:00] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:03] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [23:14] <sgalineau> that isn't a sufficient answer for perfectly pragmatic reasons I did a shit job explaining
# [23:15] <sgalineau> for instance, that the compat impact of messing with serialization was not random
# [23:15] <TabAtkins> Compat impact is what you choose to allow it to be.
# [23:16] <sgalineau> by messing with serialization, I mean messing with the serialization of exiting properties
# [23:16] <TabAtkins> Having a defined serialization, and not following it, is no worse than having no defined serialization at all.
# [23:16] <sgalineau> bear with me
# [23:16] <TabAtkins> And it's better, because new browsers can just follow the spec.
# [23:17] <sgalineau> in particular - and we're talking years ago - those sites that used widely used JS libraries to animate properties were generally unaffected by our messing with serialization. those libs learned the hard way to parse things nearly as defensively as a browser so you could move things around without troubling them
# [23:18] <sgalineau> and since then, the amount of such fiddling that goes through such hardened code has only increased i.e. the amount of new code that directly interpolates and updates an animating width is very, very, very small
# [23:18] <sgalineau> of course 'not zero' on the web can still be pretty large
# [23:21] <sgalineau> and there will still be people who, for whatever reason, roll out their own. outputting one common format is a benefit for them; it lets them use regex a lot more safely.
# [23:21] <TabAtkins> You appear to be agreeing that serialization should be defined. Are you building up to a counter-argument?
# [23:21] <sgalineau> I never said it shouldn't be. I'm questioning whether it's actually worth the effort. or how many people's lives it really helps
# [23:22] <sgalineau> If most looping dynamic updates go through hardened frameworks whose developers know how to parse and will keep parsing defensively and carefully whether there is one computed style format or 3, I'm not sure I care
# [23:22] <sgalineau> but *if* there is data showing that, to this day, a massive load of CSS properties are updated in loops by people who learned regex yesterday and use it everywhere then I see more value in it
# [23:23] <sgalineau> my experience suggests the world is far closer to the former i.e. I think it's more agonizing than it's worth
# [23:24] <sgalineau> bottom line: the perfect is not the enemy of the good. but just because it looks good doesn't make it worth your time if the world has long ago well adapted to the conspicuous absence of said perfect for years on end
# [23:25] <sgalineau> I'm afraid we're mostly doing something because it feels better than doing nothing and we feel bad about doing nothing
# [23:27] <TabAtkins> I don't think leaving everything alone because people have partially, badly adapted to it being broken is a good state of affairs.
# [23:29] <sgalineau> the point is that they haven't badly adapted to it
# [23:29] <TabAtkins> I know that I wrote fragile code some time ago to parse color values, because every single browser returned a different format.
# [23:30] <TabAtkins> I don't want to write that code again.
# [23:30] <TabAtkins> And anyway, it'll break if we ever add new color functions or keywords, because IE returned the exact value used for input.
# [23:31] * Joins: teoli (~teoli@public.cloak)
# [23:31] <TabAtkins> We of course should do a value-based API. I'm working on that right now, and it's a hard problem. But it doesn't excuse or remove the need for the string-based API.
# [23:31] <sgalineau> the point is that it isn't fragile code; if most such loops are handled by well established frameworks with very solid code that is extremely resilient to format differences, standardizing that serialization format may be of very little consequence in practice
# [23:32] <sgalineau> yes, maybe jQuery & friends can use regex to parse these new values now. great. they might use that. or they might not if it's slower.
# [23:32] <TabAtkins> Giving up on standardizing because frameworks have done the grunt work isn't a good answer.
# [23:33] <sgalineau> well, the argument for standardizing strings is that 'this is what we have'. that everyone does this through frameworks is what we have too.
# [23:33] <TabAtkins> For weird values of "everyone" that exclude a whole bunch of people.
# [23:33] <TabAtkins> jQuery is massively used, but it's far from "everyone".
# [23:33] <sgalineau> and I'm not saying 'don't standardize'. I'm saying 'the value of standardizing thing may be very small.
# [23:34] <TabAtkins> And I think you're underestimating the value, especially over the long term.
# [23:34] <sgalineau> yes; it may leave a good-size group. having one format instead of 2+ is good. it reduces the scope for mess but thousands of people each parsing strings their own way will still mess it up often.
# [23:35] <sgalineau> so the syntax convergence is nice but in aggregate it may still be marginal
# [23:35] <TabAtkins> You're welcome to not help, then.
# [23:36] <sgalineau> I sure am not :) but may I try to understand why others think it valuable? you're welcome to not answer if that bothers you, too
# [23:36] <sgalineau> when people go deep into things I don't grok based on experience I'll ask why. insistently if needed. sorry.
# [23:36] <TabAtkins> You already know why I and others find it valuable, because we've already said so in this conversation and it's the stock answer: standardization reduces divergence in implementation, saving authors work, and makes it easier for new UAs to enter the market.
# [23:37] <sgalineau> stock answers apply to a lot of things. including things we don't do. so they're not sufficient.
# [23:38] <TabAtkins> Well, stop asking if you're going to reject the answer.
# [23:38] <TabAtkins> I don't need a special unicorn snowflake of an answer.
# [23:38] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:38] <sgalineau> when I don't get enough of an answer i'll ask for a better one.
# [23:38] <sgalineau> if you can't provide one, or don't want to, then don't.
# [23:38] <TabAtkins> This shit's valuable for both present and future. Done.
# [23:39] <sgalineau> You believe it is. Your belief is not sufficient to me. Done.
# [23:39] <TabAtkins> Dude, look, you ask me why, I tell you why, you reject the answer and keep asking why. Forgive me if I'm not exactly happy about the way this conversation is going.
# [23:39] <TabAtkins> I get that *you* don't think it's worthwhile *enough* to be worth doing. I do.
# [23:39] <TabAtkins> So, hey, value judgement.
# [23:40] <sgalineau> Telling me 'this is the stock answer so shot up' is supposed to be satisfying to me? think again.
# [23:40] <TabAtkins> Stop pretending that your particular valuation is objectively true and sufficient to reject my answer and demand more.
# [23:40] <sgalineau> I'm not interested in what you think I'm 'pretending'
# [23:40] <TabAtkins> Again, I don't need to give a special snowflake answer. This isn't a special snowflake situation. There's a thing, which isn't standardized, and has divergence as a result, which causes pain. We can stop this.
# [23:40] <TabAtkins> THAT'S MY WHOLE ANSWER.
# [23:40] <TabAtkins> I'm sorry that you don't like it.
# [23:40] <sgalineau> You can call things you don't want to consider 'snowflakes' all you want.
# [23:41] <sgalineau> likewise
# [23:41] <TabAtkins> For fucks sake, I don't understand what you're going on about.
# [23:41] <TabAtkins> What is so unique about this situation, in your estimation, that it requires an extraordinary justification beyond what I gave you?
# [23:41] <sgalineau> And given your tone you're completely uninterested in even trying so let's end this here.
# [23:43] <TabAtkins> This entire conversation is exactly as confusing as the one I read from earlier.
# [23:43] <sgalineau> My justification, Tab, is based on years of working on a browser with a long tail of shit. And finding out that certain problems - like this one - did not happen for sites that depended on code that has since become a de facto standard. What is confusing about that?
# [23:44] <TabAtkins> So, boiling that down, your response is again "I don't think the value is sufficient to justify working on it". Correct?
# [23:44] <sgalineau> Does it mean it should absolutely not be fixed? of course not. but it may mean it may not matter anymore. The end.
# [23:45] <TabAtkins> THAT IS A COMPLETELY VALID AND SUFFICIENT RESPONSE, WHICH DOES NOT NEGATE MY OWN RESPONSE THAT I FIND IT SUFFICIENTLY VALUABLE.
# [23:45] <TabAtkins> We don't need to agree on precisely how valuable it is, because this isn't a topic which requires us to synchronize our beliefs.
# [23:46] <sgalineau> So WHAT? I can't ask others why *they* believe it important? Are you the oracle or something?
# [23:46] <TabAtkins> You *have* asked others. *Repeatedly*. And they, and I, have told you why we think it's important. FOR THE SAME REASONS IT ALWAYS IS.
# [23:46] <TabAtkins> There's nothing new or special about this situation that demands a unique reason.
# [23:46] <sgalineau> When?
# [23:46] <TabAtkins> Scrollback.
# [23:47] <TabAtkins> This isn't a face-to-face conversation. You can just go read what we've already discussed.
# [23:47] <sgalineau> So to figure out what a large group of people think you pop up on IRC and take the opinion of the first two or three?
# [23:47] <sgalineau> that explains a lot
# [23:48] <sgalineau> seriously man, if you don't want to talk about it, don't.
# [23:48] <TabAtkins> What large group are you polling? You just asked me, I told you, and you asked me again. And I told you again. And you asked me again.
# [23:48] <TabAtkins> You won't stop asking, for some reason, and then you get offended that I'm tired of repeating myself.
# [23:48] <sgalineau> You just aid I shouldn't ask you because others already answered the same thing.
# [23:49] <TabAtkins> You certainly shouldn't ask me a *second* time, especially when my first answer is identical to others.
# [23:49] <sgalineau> I didn't ask you a second time. you seem to misunderstand my argument. so I went for another round.
# [23:52] <TabAtkins> I did understand you, I reiterated my point which counters your own argument (at least for myself), and you continued to pretend that I'm not giving "enough of an answer".
# [23:52] <TabAtkins> And insinuated that I'm either deliberately being vague, or don't understand my own position enough to know when I'm being vague.
# [23:53] <sgalineau> Not how that went on my end. Sorry. All I heard could be summarized as 'there is no justification for arguing against this'. So I explained what I see as a reasonable justification to question the priority of this.
# [23:53] <TabAtkins> 14:43 <sgalineau> when I don't get enough of an answer i'll ask for a better one.
# [23:53] <TabAtkins> 14:43 <sgalineau> if you can't provide one, or don't want to, then don't.
# [23:53] <TabAtkins> That's how it went on both our ends.
# [23:53] <sgalineau> I'm about as interested as arguing about what you think I insinuated on IRC as you are about what I think I heard you say
# [23:53] <TabAtkins> I accepted, explicitly, that you don't find enough value in it.
# [23:54] <sgalineau> I'm pretty sure we can agree that'd be fucking boring. so let's leave it at that.
# [23:54] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:54] <TabAtkins> If you chose to read that as me dismissing your justification, I don't understand what you're doing.
# [23:54] <sgalineau> as for the quotes better, I was not saying I'd ask more answers from you. I'll ask multiple people what they think.
# [23:55] <sgalineau> when people tell you 'this is the stock answer. stop asking' it can be interpreted in different ways
# [23:55] <sgalineau> such as 'this is the stock answer so stop asking me and everyone else'
# [23:55] <sgalineau> not just 'stop asking *me*'
# [23:55] <TabAtkins> If by:
# [23:55] <TabAtkins> 14:40 <sgalineau> I sure am not :) but may I try to understand why others think it valuable? you're welcome to not answer if that bothers you, too
# [23:56] <TabAtkins> ...you meant "Okay, that's cool. I'm interested in what others might think about this too, so I'll ask them later as well." then that's fine.
# [23:56] <sgalineau> YES
# [23:56] <sgalineau> that's all there is to it
# [23:56] <TabAtkins> If that *is* what you meant, then you have quick the knack for phrasing things in relatively offensive ways when you mean innocuous things.
# [23:56] <sgalineau> dude, you did the same
# [23:57] <TabAtkins> "you're welcome to not ansdwer if that bothers you" if a blow-off phrase that implies someone's being unreasonable.
# [23:57] <sgalineau> 'this is the stock answer so stop asking' is not a blow-off answer that could be construed as 'just STFU' in this context?
# [23:57] <TabAtkins> We can go quote-mine to establish that I didn't say anything of the sort.
# [23:57] <TabAtkins> I said *my* answer was the stock answer.
# [23:57] <TabAtkins> So you can quit asking *me*.
# [23:58] <sgalineau> i doubt I have a monopoly of bad phrasing in an IRC argument
# [23:58] <sgalineau> the meaning of your communication is up to your recipient. and vice-versa.
# [23:59] <TabAtkins> Well, now that we're done with the phrasing wankfest: I think it's valuable for the stock reason. So does Alan and Ms2ger, apparently.
# [23:59] <sgalineau> Sadly, yes. Oh well.
# Session Close: Thu Jan 16 00:00:01 2014

The end :)