/irc-logs / w3c / #css / 2015-01-21 / end

Options:

# Session Start: Wed Jan 21 00:00:00 2015
# Session Ident: #css
# [00:11] * shepazu_away is now known as shepazu
# [00:13] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [00:16] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [00:16] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [00:17] * Joins: myakura (~myakura@public.cloak)
# [00:24] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [00:27] * shepazu is now known as shepazu_away
# [00:30] * shepazu_away is now known as shepazu
# [00:35] * Joins: jdaggett (~jdaggett@public.cloak)
# [00:38] <dbaron> anybody (shane?) know what version of Chrome the rewrite of transitions based on Web Animations was enabled?
# [00:39] <shane> dbaron: 33
# [00:39] <dbaron> shane, thanks; I guess I'm a little surprised at still seeing the quirky webkit behavior for transitions running on both ancestors and descendants
# [00:39] <shane> dbaron: we maintained compatability with all the quirks
# [00:40] <shane> dbaron: but as the animations and transitions specs stabilize I want to remove them.
# [00:40] <dbaron> shane, so the rewriting transitions stuff to follow the starting prose in the new spec is separate from that, and hasn't landed?
# [00:40] <shane> dbaron: what's the specific quirk you're talking about?
# [00:41] <dbaron> shane, in http://dbaron.org/css/test/2015/transition-starting-1 the transition on the child doesn't start until the transition on the parent completes
# [00:43] <shane> dbaron: oh interesting. That looks more like a bug than a quirk :) I'll look into it.
# [00:44] <dbaron> shane, I actually wrote the testcase to find out what you did on a more detailed point of the behavior, but then I couldn't tell because the transition on the child doesn't start until the one on the parent finishes
# [00:44] <dbaron> (since I think that finer point is a bug in the current spec that I need to figure out how to fix before we can ship code based on it)
# [00:45] <dbaron> anyway, thanks for looking
# [00:56] * Joins: tantek (~tantek@public.cloak)
# [01:06] <Florian_away> tantek: The edits to the wiki requested above have now been done
# [01:06] <tantek> It's never done, it's a way of life ;)
# [01:06] <Florian_away> it is currently up to date
# [01:06] <tantek> Perhaps you mean, the wiki is up to date with complaints on www-style as of YYYY-MM-DD. ;)
# [01:06] <Florian_away> yes
# [01:07] <tantek> great
# [01:07] <Florian_away> as of now
# [01:07] <tantek> just curious (not asking you to do so) - did you reply to each new thread and say, " thank you, this has been captured as Issue NN (permalink)"
# [01:07] <tantek> I did that for a while and people seemed to appreciate it
# [01:07] <tantek> even if no actual answer was available yet
# [01:08] <Florian_away> Can't guarantee that it's been done on all threads, but I tend to do that, yes. It is a bit fuzzy sometimes when a discussion forks
# [01:10] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [01:10] <Florian_away> By the way, I noticed you changed the proposed resolution for Issue 40 (drop ime-mode). I would much appreciate if you could respond to the ongoing thread that is linked to from the wiki, instead of just changing it, especially when your proposal is different from the emerging consensus. It is difficult to respond to arguments when you don't know they're being made.
# [01:10] * Florian_away is now known as Florian
# [01:16] <tantek> that thread was nonsensical
# [01:16] <tantek> there was no emerging consensus AFAICT
# [01:17] <tantek> the "bit fuzzy sometimes when a discussion forks" is exactly one of the reasons why we use the wiki canonically for issue collection/resolution, not email
# [01:18] <Florian> if you disagree, responding to the thread is friendlier, rather than dismissing me
# [01:18] * Quits: thinkxl (~thinkxl@public.cloak) (Ping timeout: 180 seconds)
# [01:18] <tantek> not dismissing you - just noting why I made the change - happy to re-explore it
# [01:19] * tantek checks issue 40
# [01:19] * tantek is not a fan of ime-mode anyway :P
# [01:19] <tantek> Florian, I was taking the "HTML editor" approach there
# [01:20] <tantek> pretending something that is interop does not exist is NOT helpful
# [01:20] <Florian> as for no consensus, Ted, fantasai, koji and I all explicitely agree, in adition to the people how had raised the issue in the first place
# [01:20] <tantek> in fact it is HURTFUL because it legitimizes it through silence (de facto)
# [01:20] <Florian> it is not interoperable
# [01:20] <tantek> hmm - you have a URL to a test for that?
# [01:21] <tantek> that's worth capturing in https://wiki.csswg.org/spec/css3-ui#issue-40
# [01:21] <Florian> it is captured in the thread linked to from there
# [01:22] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [01:22] <Florian> and on MDN, with various comments on each value of the property such as "This value is not supported by Internet Explorer." or "Not supported on Linux."
# [01:23] <tantek> hate to say it - but there's really no such thing as "captured in the thread" - that's why we have separate issues tracking
# [01:23] <tantek> "captured in the thread and linked to from there" is almost as bad as "It's posted on the web, just google for it."
# [01:23] <tantek> I'll check MDN - that's a specific reference I can look-up - thanks.
# [01:24] <Florian> I will not duplicate everything that's said on www-style to the wiki
# [01:24] <tantek> and that's a strawman. no one said "everything that's said". in fact, please don't!
# [01:24] <tantek> the point of issues tracking is to distill out the immediately essential bits
# [01:24] <tantek> without making people "hunt" for answers
# [01:25] <tantek> (and yes, two levels deep in links is hunting)
# [01:25] <tantek> hence direct links to answers only
# [01:25] <tantek> Ok I found https://developer.mozilla.org/en-US/docs/Web/CSS/ime-mode via Yahoo search
# [01:25] <tantek> (first result)
# [01:26] <tantek> my summary reading of https://developer.mozilla.org/en-US/docs/Web/CSS/ime-mode is that we have interop between FF and IE Windows on the values auto | active | inactive | disabled.
# [01:26] <tantek> only "normal" is not interop
# [01:26] <tantek> that's the claim anyway
# [01:26] <tantek> (in the docs)
# [01:27] <tantek> also lack interop on "apply to password editing fields"
# [01:27] <tantek> note that advice such as this is important for repairing bad ime-mode on the web:
# [01:27] <tantek> "Users may correct the inappropriate behavior of sites that don't follow this recommendation by placing the following CSS into their user CSS file:"
# [01:28] <tantek> "input[type=password] { ime-mode: auto !important; } "
# [01:28] <tantek> I think I agree with you in spririt that we should "drop" ime-mode from the platform, we just disagree on how best to do that.
# [01:29] <tantek> My proposal is aboutt explicitly documenting a tombstone of sorts. Whereas your proposal is more of a "ignore it and hope it goes away".
# [01:30] <Florian> My problem is that if we document it, even as a tombstone, what we write needs to be correct.
# [01:30] <Florian> and currently there is a difference between the spec, ie and ff
# [01:30] <Florian> and there is a difference between ff on various platforms
# [01:30] <Florian> and it cannot be supported as speccified on anything but windows
# [01:31] <Florian> Documenting that it exists, and that you should not use it sounds sane and useful. Trying to document how it works sounds more perilous.
# [01:33] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [01:34] <Florian> anway, www-style would be a good place to have this discussion, lest we have to repeat it entirely
# [01:34] <tantek> I'm sure www-style has repeated most discussions 5-10x, with 20-100x the # of bytes.
# [01:35] * Joins: tantek_ (~tantek@public.cloak)
# [01:35] <Florian> Are you fine with documenting its existence without going into the behavior?
# [01:36] <Florian> with a note about why it is a bad idea
# [01:36] * shepazu is now known as shepazu_away
# [01:36] <Florian> and what to use instead (even though not all the replacements are fully stable)
# [01:38] <Florian> anyway, with a bit of luck, we'll get that on the telecon tomorrow. I need to get some sleep now.
# [01:40] * Joins: tantek__ (~tantek@public.cloak)
# [01:40] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [01:41] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [01:41] * tantek__ is now known as tantek
# [01:42] <tantek> drat another network blip
# [01:42] * tantek checks the logs for other wise things Florian said.
# [01:42] <tantek> sigh, why do our logs REQUIRE JS?
# [01:43] * Quits: tantek_ (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [01:43] * tantek changes topic to 'logs: http://krijnhoetmer.nl/irc-logs/css - 2015-01-14 telcon http://lists.w3.org/Archives/Public/www-style/2015Jan/0247.html (JS only logs: https://log.csswg.org/irc.w3.org/css/today )'
# [01:44] <tantek> Florian - yes I think that makes sense.
# [01:44] <tantek> I'm going to add what you just wrote to the proposed resolution
# [01:45] <tantek> I'll leave your own resolution line there and let you decide to remove it when you think we have a consensus resolution.
# [01:45] <tantek> I think if you and I have a consensus resolution, we can move forward with it and make it a FYI to the WG instead of spending everyone's time on it.
# [01:45] * shepazu_away is now known as shepazu
# [01:45] <tantek> I'm sure most people in the group don't care to waste telcon time on ime-mode
# [01:49] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [01:57] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:59] * Joins: tantek_ (~tantek@public.cloak)
# [02:02] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [02:02] * tantek_ is now known as tantek
# [02:04] * shepazu is now known as shepazu_away
# [02:06] * Joins: myakura (~myakura@public.cloak)
# [02:06] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [02:07] * Joins: dauwhe (~dauwhe@public.cloak)
# [02:08] * Joins: tantek_ (~tantek@public.cloak)
# [02:09] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [02:09] * tantek_ is now known as tantek
# [02:10] <tantek> Florian, https://wiki.csswg.org/spec/css3-ui#issue-40 updated
# [02:14] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [02:14] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [02:14] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [02:19] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:23] * shepazu_away is now known as shepazu
# [02:27] * Quits: dwim (~dwim@public.cloak) ("Leaving.")
# [02:27] * Joins: dwim (~dwim@public.cloak)
# [02:30] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:33] <shane> dbaron: what should happen in that case?
# [02:33] <shane> should the child be continually retransitioning?
# [02:34] <dbaron> shane, that's the thing I was hoping to avoid
# [02:34] <shane> dbaron: so do you want the two transitions to start together but the child to finish first?
# [02:34] <dbaron> shane, it seems particularly bad for that to happen as a result of unrelated style changes, but not happen if there are no unrelated style changes
# [02:34] <dbaron> shane, yes, that's what I'd like to happen
# [02:35] <dbaron> shane, I need to retest the change that I thought would fix it but didn't when I last tested it... and probably debug why it didn't
# [02:35] <shane> dbaron: that's going back to the multiple inheritance pass ide
# [02:35] <shane> a
# [02:35] <shane> dbaron: I don't think we'd want to go there
# [02:36] <dbaron> shane, I guess I see why the thing I tried before doesn't work... but this also seems like a rather bad result
# [02:36] <shane> dbaron: to be clear, I think our current behaviour is buggy too
# [02:41] <shane> dbaron: the issue is that to do your approach you'd need a transition triggering style update (to calculate the result with no transitions running); then a real style update (so that transitioned values can inherit properly). At first, it seems like the real style update could be incremental, but you need to be able to deal with different inherited values
# [02:41] <shane> which means you need to be able to do data tracking all through the tree .. or just give up and recalculate from scratch. This seems like an unreasonable expense.
# [02:42] <dbaron> yeah
# [02:43] <dbaron> I wonder if we could avoid the problem by either (a) doing something to remember that the child has already finished a transition to that value until the parent completes the transition or (b) just making the child take the longer transition in the first place. (I also wonder whether either would fully avoid the problem.)
# [02:51] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [02:52] * Joins: Florian (~Florian@public.cloak)
# [02:58] <shane> If the child is continuously retargeted you effectively get (b)
# [03:00] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [03:02] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [03:02] * Joins: Guest91 (~textual@public.cloak)
# [03:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [03:55] * Joins: myakura (~myakura@public.cloak)
# [04:02] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [04:02] * shepazu is now known as shepazu_away
# [04:11] * Joins: dauwhe (~dauwhe@public.cloak)
# [04:19] * Quits: dauwhe (~dauwhe@public.cloak) ("")
# [04:23] * Joins: jdaggett (~jdaggett@public.cloak)
# [04:35] * Quits: mvujovic_____ (~sid13458@public.cloak) (Client closed connection)
# [04:37] * Joins: tantek (~tantek@public.cloak)
# [04:39] * shepazu_away is now known as shepazu
# [04:41] * Joins: dbaron (~dbaron@public.cloak)
# [04:43] * Joins: Florian (~Florian@public.cloak)
# [04:45] * Joins: mvujovic______ (~sid13458@public.cloak)
# [04:50] * Quits: krit (~sid15081@public.cloak) (Client closed connection)
# [04:51] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [04:52] * Quits: mvujovic______ (~sid13458@public.cloak) (Ping timeout: 180 seconds)
# [04:56] * Quits: shane (~uid61558@public.cloak) (Ping timeout: 180 seconds)
# [05:07] * Joins: krit_ (~sid15081@public.cloak)
# [05:12] * Joins: mvujovic______ (~sid13458@public.cloak)
# [05:22] * Guest91 is now known as hgl
# [05:22] * Joins: shane (~uid61558@public.cloak)
# [05:22] * Quits: hgl (~textual@public.cloak) ("Quit")
# [05:23] * Joins: hgl (~hgl@public.cloak)
# [05:38] * fantasai notes that run-in is in fact defined in the Display module at this time
# [05:39] * shepazu is now known as shepazu_away
# [05:43] * Joins: tantek_ (~tantek@public.cloak)
# [05:44] * Joins: myakura (~myakura@public.cloak)
# [05:48] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [05:48] * tantek_ is now known as tantek
# [05:51] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [05:58] * shepazu_away is now known as shepazu
# [06:04] * Quits: tantek (~tantek@public.cloak) (tantek)
# [06:33] * Joins: tantek (~tantek@public.cloak)
# [06:33] * Joins: tantek_ (~tantek@public.cloak)
# [06:40] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [06:44] * Quits: tantek_ (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [06:46] * Joins: tantek (~tantek@public.cloak)
# [07:00] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [07:09] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [07:09] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [07:10] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [07:16] * shepazu is now known as shepazu_away
# [07:17] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [07:20] * shepazu_away is now known as shepazu
# [07:25] * Joins: tantek_ (~tantek@public.cloak)
# [07:30] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [07:30] * tantek_ is now known as tantek
# [07:32] * Joins: myakura (~myakura@public.cloak)
# [07:39] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [07:40] * shepazu is now known as shepazu_away
# [07:48] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [07:48] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [07:49] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [07:50] * shepazu_away is now known as shepazu
# [07:55] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [08:07] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:10] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [08:10] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [08:23] * Joins: Florian (~Florian@public.cloak)
# [08:31] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [08:33] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [08:39] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [08:43] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:55] * Joins: svillar (~sergio@public.cloak)
# [08:55] * Joins: tantek (~tantek@public.cloak)
# [09:06] * Joins: tantek_ (~tantek@public.cloak)
# [09:08] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [09:09] * Joins: antonp (~Thunderbird@public.cloak)
# [09:10] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [09:14] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:15] * Quits: tantek_ (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [09:15] * Joins: tantek (~tantek@public.cloak)
# [09:21] * Joins: myakura (~myakura@public.cloak)
# [09:22] * Quits: tantek (~tantek@public.cloak) (tantek)
# [09:24] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:26] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:29] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [09:56] * Joins: Florian (~Florian@public.cloak)
# [10:01] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [10:03] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [10:21] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:46] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [10:47] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [10:47] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [11:01] * Joins: anssik (~uid10742@public.cloak)
# [11:04] <hgl> got a question for the transform module. the spec says transformed elements are flattening by default. is it correct that what really happens is that the perspective property won't apply to a nested 3d rendering context, so such child 3d rendering context looks like flattened by default?
# [11:06] * Joins: jdaggett (~jdaggett@public.cloak)
# [11:07] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [11:07] <hgl> and by using preserve-3d, the nested 3d rendering context is prevented from being created, thus making the transformed elements which would otherwise be in the nested context appear popped out?
# [11:10] * Joins: myakura (~myakura@public.cloak)
# [11:12] * Joins: jdaggett (~jdaggett@public.cloak)
# [11:17] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [11:18] * Quits: hgl (~hgl@public.cloak) ("Sleep")
# [11:32] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [11:44] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [11:46] * Joins: Florian (~Florian@public.cloak)
# [11:50] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [11:53] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [12:15] * Joins: Florian (~Florian@public.cloak)
# [12:16] * Joins: hgl (~hgl@public.cloak)
# [12:54] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [12:56] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [12:56] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [12:58] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [12:59] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [12:59] * Joins: myakura (~myakura@public.cloak)
# [13:00] * Joins: tommyjt__ (~tommyjtl@public.cloak)
# [13:03] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [13:03] * Quits: tommyjt__ (~tommyjtl@public.cloak) (Client closed connection)
# [13:03] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [13:03] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [13:06] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [13:06] * Joins: myakura_ (~myakura@public.cloak)
# [13:06] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [13:08] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [13:12] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [13:13] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
# [13:18] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
# [13:40] * Quits: hgl (~hgl@public.cloak) ("Sleep")
# [14:02] * Joins: plh (plehegar@public.cloak)
# [14:05] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [14:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:14] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [14:21] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [14:21] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [14:26] * Joins: jdaggett (~jdaggett@public.cloak)
# [14:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:44] * Quits: nikos (~uid28403@public.cloak) ("Connection closed for inactivity")
# [15:02] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [15:07] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [15:07] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:10] * Joins: svillar (~sergio@public.cloak)
# [15:24] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [15:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:39] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [15:40] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
# [15:43] * Joins: lajava (~javi@public.cloak)
# [15:53] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:03] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:06] * Joins: Florian_ (~Florian@public.cloak)
# [16:12] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [16:16] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [16:21] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:22] * Joins: dbaron (~dbaron@public.cloak)
# [16:30] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [16:30] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [16:30] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [16:31] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:37] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [16:39] * Joins: glazou (~glazou@public.cloak)
# [16:41] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:42] * Quits: tommyjtl_ (~tommyjtl@public.cloak) ("brb")
# [16:56] * Joins: thinkxl (~thinkxl@public.cloak)
# [16:58] * dauwhe_ is now known as dauwhe
# [17:08] * Joins: Zakim (zakim@public.cloak)
# [17:08] * Joins: RRSAgent (rrsagent@public.cloak)
# [17:08] <RRSAgent> logging to http://www.w3.org/2015/01/21-css-irc
# [17:08] <glazou> Zakim, this will be STyle
# [17:08] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 52 minutes
# [17:08] <glazou> RRSAgent, make logs public
# [17:08] <RRSAgent> I have made the request, glazou
# [17:08] * glazou changes topic to 'logs: http://krijnhoetmer.nl/irc-logs/css - 2015-01-21 telcon http://lists.w3.org/Archives/Public/www-style/2015Jan/0369.html(JS only logs: https://log.csswg.org/irc.w3.org/css/today )'
# [17:09] * glazou changes topic to 'logs: http://krijnhoetmer.nl/irc-logs/css - 2015-01-21 telcon http://lists.w3.org/Archives/Public/www-style/2015Jan/0369.html (JS only logs: https://log.csswg.org/irc.w3.org/css/today )'
# [17:11] * Joins: Florian (~Florian@public.cloak)
# [17:22] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [17:25] * Florian is now known as Florian_away
# [17:27] <glazou> hmmm I pushed a editorial fix on mediaqueries-3 minutes ago and now I can’t reach dev.w3.org/csswg any more
# [17:27] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [17:28] <Florian_away> doesn't load from here either
# [17:28] <glazou> hmmm
# [17:29] <glazou> hg commit & hg push kill the server ; lovely :-p
# [17:32] <Florian_away> or a coincidence
# [17:32] <Florian_away> or a hint to start using git
# [17:32] <Florian_away> :)
# [17:32] <Florian_away> I'll be a bit late to the call today (most likely), but I'll join. Probably 20 minutes late or so
# [17:37] <glazou> yes, saw that already
# [17:38] <glazou> Florian_away: I heard someone say about a year ago « mercurial is the live proof the syntax of XSLT was not that bad » :-D
# [17:42] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:42] * dauwhe glazou: XSL > hg :)
# [17:42] <Ms2ger> Mercurial has syntax?
# [17:43] * leaverou is now known as leaverou_away
# [17:43] <glazou> that person was speaking of the command line’s syntax, Ms2ger
# [17:47] * Joins: Rossen_ (~Rossen@public.cloak)
# [17:50] * Joins: bcampbell (~chatzilla@public.cloak)
# [17:51] * leaverou_away is now known as leaverou
# [17:54] * Joins: dael (~dael@public.cloak)
# [17:55] <Zakim> Style_CSS FP()12:00PM has now started
# [17:55] <Zakim> +dael
# [17:57] * Joins: AH_Miller (~mike@public.cloak)
# [17:57] <Zakim> +??P9
# [17:57] <glazou> Zakim, ??P9 is me
# [17:57] <Zakim> +glazou; got it
# [17:58] <Zakim> +plinss
# [17:58] <Zakim> +??P17
# [17:58] <SimonSapin> Zakim, ??P17 is me
# [17:58] <Zakim> +SimonSapin; got it
# [17:59] <Zakim> +dauwhe
# [17:59] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:00] <Zakim> +[IPcaller]
# [18:00] <bcampbell> IPcaller is me
# [18:00] <glazou> Zakim, [IPcaller] has bcampbell
# [18:00] <Zakim> +bcampbell; got it
# [18:00] <Zakim> +Lea
# [18:01] * Joins: andreyr (~andreyr@public.cloak)
# [18:01] <Zakim> +MikeMiller
# [18:01] * Joins: bradk (~bradk@public.cloak)
# [18:01] * Joins: SteveZ (~SteveZ@public.cloak)
# [18:01] <glazou> Zakim, mute Lea
# [18:01] <Zakim> Lea should now be muted
# [18:01] * leaverou is on a terrible connection, might be better to just follow on IRC :(
# [18:01] * Quits: andreyr (~andreyr@public.cloak) ("Page closed")
# [18:01] <Zakim> +??P19
# [18:02] * leaverou (or at least be muted and reply in IRC)
# [18:02] <glazou> leaverou: I muted you through zakim, unmute yourself if you want to speak
# [18:02] <kwkbtr> Zakim, ??P19 is me
# [18:02] <Zakim> +kwkbtr; got it
# [18:02] <Zakim> +BradK
# [18:02] <Zakim> +[Bloomberg]
# [18:02] * leaverou glazou: I will unmute myself through zakim and mute myself on Skype, it’s easier for me, is that ok?
# [18:02] <glazou> as you wish leaverou
# [18:02] <leaverou> Zakim, unmute Lea
# [18:02] <Zakim> Lea should no longer be muted
# [18:02] <Zakim> +Stearns
# [18:02] <Zakim> +fantasai
# [18:02] <Zakim> +hober
# [18:02] * Joins: andreyr (~andreyr@public.cloak)
# [18:02] <Zakim> +SteveZ
# [18:03] * Joins: smfr (~smfr@public.cloak)
# [18:03] * dauwhe I'm not hearing noise
# [18:03] * dael only heard it briefly
# [18:03] * fantasai probably me, I have all the sucky internets and telephones these days
# [18:03] * Joins: tantek (~tantek@public.cloak)
# [18:03] <Zakim> +[Microsoft]
# [18:03] <Zakim> +smfr
# [18:04] * leaverou is isolated on the top of a greek mountain, away from civilization and fast interwebs
# [18:04] <Rossen_> zakim, microsoft has me
# [18:04] <Zakim> +Rossen_; got it
# [18:04] <glazou> leaverou: please send some food and wine
# [18:04] <Zakim> +dbaron
# [18:04] * dael leaverou I'll trade if you want :)
# [18:04] <bradk> Olympus?
# [18:04] * leaverou glazou man, you're french! You have all the good wines there!
# [18:04] * glazou remembers excellent wines from Crete
# [18:04] * leaverou glazou: not to mention the food. French food >> Greek food
# [18:05] <Zakim> +??P44
# [18:05] * Joins: ChrisL (clilley@public.cloak)
# [18:05] <Zakim> + +1.281.305.aaaa
# [18:05] <dael> glazou: Let's start
# [18:05] <dael> ScribeNick: dael
# [18:05] <TabAtkins> zakim, aaaa is me
# [18:05] <Zakim> +TabAtkins; got it
# [18:05] <dael> glazou: Anything to add to the agenda or discuss before we start to official one
# [18:05] * Joins: antenna (~antenna@public.cloak)
# [18:05] <dael> glazou: There's one from koji but I'm not sure we'll have time
# [18:05] <dael> Topic: Flexbox Accessability
# [18:05] <bcampbell> https://wiki.csswg.org/spec/css3-flexbox/accessibility
# [18:05] <dael> bcampbell: Let me paste the wiki
# [18:06] * leaverou bradk: you might be surprised to hear there are hundreds more mountains than olympus :P
# [18:06] <Zakim> +[IPcaller.a]
# [18:06] <Zakim> +ChrisL
# [18:06] * dbaron Zakim, who is on the phone?
# [18:06] * Zakim sees on the phone: dael, glazou, plinss, SimonSapin, dauwhe, [IPcaller], Lea, MikeMiller, kwkbtr, BradK, [Bloomberg], Stearns, hober, fantasai, SteveZ, [Microsoft], smfr, dbaron,
# [18:06] * Zakim ... ??P44, TabAtkins, [IPcaller.a], ChrisL
# [18:06] * Zakim [Microsoft] has Rossen_
# [18:06] * Zakim [IPcaller] has bcampbell
# [18:06] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [18:06] <Zakim> +??P55
# [18:06] * ChrisL and each one is brimming with deities
# [18:06] <dael> bcampbell: After posting some arguements and replies, it was my ex that I put in with a trivial flex box that was a diagram, I agree it was trivial and we need to address the holy grail of layout
# [18:06] <tantek> glazou: I'd like to prepare a CSS3-UI draft for publication before the f2f
# [18:06] <alex_antennahouse> i should be ipcaller that just joined
# [18:06] <tantek> zakim, ??p55 is me
# [18:06] <Zakim> +tantek; got it
# [18:07] <tantek> zakim, mute me
# [18:07] <Zakim> tantek should now be muted
# [18:07] <glazou> tantek: ok, will put that between items 2 and 3
# [18:07] <Zakim> +??P62
# [18:07] <tantek> thank you glazou
# [18:07] <dael> bcampbell: I did some research on that and realized it says the seq of the cont in this layout has no meaning and therefore rearranging visually has no consiquence. We have an arguement against that from Matt King in IMB who is a spokes person for the blind and he's said that he wants it to work for the blind
# [18:07] <Zakim> + +1.631.398.aabb
# [18:08] * bradk leaverou, no doubt. I just imagined you were up there drinking mess with the gods.
# [18:08] <dael> bcampbell: After seeing that there's reflief and a meaningful sequesnce, I talked to Richard and a dev on a high profile IBM app to understand why we have this issues and what exactly they want. Flexbox has the opp to be powerful for designers that need to move things visually and not get dev to change the code.
# [18:08] <Zakim> +koji
# [18:08] * bradk ack. S/mess/mead
# [18:08] <Zakim> +[IPcaller.aa]
# [18:09] * leaverou bradk: Heh, I wish. TabAtkins has the best mead, in Sunnyvale
# [18:09] <dael> bcampbell: There's several examples that I can site where data comes into the client and you're able to arrange the data using Flexbox. Those dev are crying out about losing the Moz "bug" because they're not going to update or use Tab and nex to go through.
# [18:09] <Zakim> -Lea
# [18:09] * glazou imagines leaverou drinking Ambrosia, on the top of a greek mountain, playing lyre :-)
# [18:09] <fantasai> s/Tab and nex/tabindex/
# [18:09] <dael> bcampbell: So we have a complex, rich application, like an e-mail app, so that's the other side of the power. TO go back, the arguement to force browsers to update tabbing order is what I'm hearing from disabled community.
# [18:10] <dael> bcampbell: From Richard and I what we need is a paramater to tell if the sequence is meaningful or not. If it's not meaningful, we can stay witht he old way. When it is meaningful, we need to be able to tell the browser that it is and switch the tab order.
# [18:10] <dael> bcampbell: The prop has changed more to allow Flexbox to have the power of doing it either way.
# [18:11] * Joins: tgraham (~user@public.cloak)
# [18:11] <dael> bcampbell: I have two questions to ask. The first one is if we have anyone that knows today how the backlog is for complaints about the way Mozilla reorders for Flexbox. The bug has been around for a long time and I'd love to know if it's a huge point of contention
# [18:11] <Zakim> +Lea
# [18:11] <dael> bcampbell: I'd also like to understand better, and everyone has been good at explaining and helping, but I'm wondering in this holy grail layout, starting tab order in the middle of the content and page, what situation does a user need to do that?
# [18:12] <dael> bcampbell: I'm from a standpoint of just peole using a webpage, not people with a disability. In general I'm going to assume this isn't a huge deal.
# [18:12] <dbaron> Is this discussion supposed to be primarily about tab-order, or also (which I thought was more important) about reading order?
# [18:12] <tantek> q+
# [18:12] * Zakim sees tantek on the speaker queue
# [18:12] <dael> bcampbell: I'll open it there.
# [18:12] * fantasai q+ dbaron
# [18:12] * Zakim sees tantek, dbaron on the speaker queue
# [18:12] <dael> glazou: tantek?
# [18:12] <tantek> ack tan
# [18:12] * Zakim unmutes tantek
# [18:12] * Zakim sees dbaron on the speaker queue
# [18:12] <dael> glazou: dbaron go ahead.
# [18:12] * fantasai can't hear a word
# [18:13] <Zakim> -fantasai
# [18:13] <dael> tantek: Sorry, I'm hoping this is one of the areas where directional nav can help such as when there's a scenario when the author...
# [18:13] <dbaron> Tab was very faint when he was trying to talk.
# [18:13] <Zakim> +fantasai
# [18:13] * dbaron Zakim, mute fantasai
# [18:13] * Zakim fantasai should now be muted
# [18:13] <dael> tantek: uses Flexbox to move things and the tab order is non-obvious and not fixable by the browsers, but the author can say I know where things belong
# [18:13] <dael> bcampbell: I'm unfamiliar witht he spec lang that you mean.
# [18:13] * dbaron fantasai, there was a bunch of background noise when you rejoined
# [18:14] * fantasai better?
# [18:14] <dael> tantek: Directional-nav prop in CSS3 UI. Let me get a ling.
# [18:14] <tantek> http://dev.w3.org/csswg/css-ui-3/#nav-dir
# [18:14] <astearns> http://dev.w3.org/csswg/css-ui/#nav-dir
# [18:14] * dbaron Zakim, unmute fantasai
# [18:14] <Zakim> -BradK
# [18:14] * Zakim fantasai should no longer be muted
# [18:14] <dael> s/ling/link
# [18:14] <dael> tantek: Take a look at that and see if it could help from authing side
# [18:14] <dael> bcampbell: Interesting.
# [18:14] <tantek> zakim, mute me
# [18:14] <Zakim> tantek should now be muted
# [18:14] <Zakim> +BradK
# [18:14] <fantasai> I think creating an 'order' property was a mistake, it should have been 'visual-order' if only affects the visual order.
# [18:14] <astearns> directional navigation is separate from tabbing, yes?
# [18:15] <fantasai> astearns, yes
# [18:15] <dael> dbaron: One thing about this discussion was that there was...a lot of the discussion seemed to be about tabbing order, but we've been talking about what is the logical order in which to read the content or do anything other than how yo put it on the screen along the x and y axis
# [18:16] <dael> bcampbell: I think what you're referring to is visual order may be diff than logical. The answer I got on that was mainly from Matt King. He was adimant that all screens should follow the pattern, left ot right, top to bottom. That is not necc the visual flow on a screen, but it's the flow screen reader users understand. That's where it starts to get subjective
# [18:16] <Zakim> -Lea
# [18:16] <dael> bcampbell: You can manipulte that, but I think that arguement when you get to those who want it, they want it the way its always been.
# [18:16] <fantasai> s/manipulate that/manipulate that via visual hierarchy/
# [18:17] <dael> dbaron: At some point what you said is you want a switch that says if you want things in the order as reorded by order or in the original order? I think order is that switch.
# [18:17] <dael> dbaron: The idea of order is the dom should be in the logical order. If you want the visual different you use order to manipulate that.
# [18:17] <ChrisL> q+
# [18:17] * Zakim sees dbaron, ChrisL on the speaker queue
# [18:17] <leaverou> Not having tabbing order follow that order that reduces its usefulness. For example, if you pin posts in a forum with order: -1; wouldn't you expect tabbing to respect that? I can't think of any case where you would want tabbing to follow the source order
# [18:17] * leaverou (but I can only get part of the discussion, so feel free to ignore of the above doesn't make sense)
# [18:17] <fantasai> leaverou, the argument we're making is that you shouldn't be using 'order' for semantic reordering
# [18:18] <dael> bcampbell: But if you use order to manipulate the visual orde,r this is the basis of what we're talking about, then you have a tabbing order that jumps everywhere. If the visual is meaningful to the viewer, you need the seq of the tabs to flow in a meaningful direction.
# [18:18] <fantasai> leaverou, which is very clearly stated in the spec, but hasn't been reflected in e.g. your favorite tutorial
# [18:18] <dael> dbaron: If it's meaningful, tey shouldn't be using order, tey should do the dom in that order.
# [18:18] <Zakim> +Lea
# [18:18] <glazou> ChrisL next
# [18:18] <dael> bcampbell: In principal I agree, but that isn't how it's being used and it's sort of unreasonable in a larger, agile team enviroment.
# [18:18] * ChrisL fantasai just made the point I wanted to
# [18:19] * fantasai but only in IRC :)
# [18:19] * fantasai suggests you speak up anyway
# [18:19] <ChrisL> you shouldn't be using 'order' for semantic reordering
# [18:19] <fantasai> s/principal/principle/
# [18:19] * ChrisL ok
# [18:19] <astearns> q+
# [18:19] * Zakim sees dbaron, ChrisL, astearns on the speaker queue
# [18:19] * dbaron Zakim, ack dbaron
# [18:19] * Zakim sees ChrisL, astearns on the speaker queue
# [18:19] <dael> bcampbell: The other part is dev is finding that the speed of CSS to move things is faster. Inside of IBM on high profile apps is that they're using flexbox in any way they can. That has tons of implications and breaks things for those with a disability. Without a siwtch to say we want to change the order and say that we want this to flow in a meaningful way, they need that to get the benifits.
# [18:20] <dael> bcampbell: If the idea is to not have those benefits for Flexbox, how do you get people not to mess things up for those with disbailities.
# [18:20] <tantek> bcampbell: can you provide a URL to one of these high profile app examples that we can look at ?
# [18:20] <dael> bcampbell: Can I understand the arguements against adding a switch other than dev should be doing good coding? I think we're stretching CSS and if it's moving in this way with Flex ans Psuedo Elements I think we'll have to change the stance of updating the DOM backwards.
# [18:21] <glazou> Zakim, ack ChrisL
# [18:21] <Zakim> I see astearns on the speaker queue
# [18:21] * bradk doesn't think CSS should be an excuse for bad HTML
# [18:21] <dael> ChrisL: fantasai made the point in IRC, you shouldn't use order to mod the semantic order, it's designed for visual. There are things used for alt reading orders. It's all very well to say the content and DOM should be in natural reading order.
# [18:21] <tantek> bradk I agree and you should say that on the record
# [18:22] * fantasai agrees with tantek's point about speaking up :)
# [18:22] <dael> ChrisL: Say you have a map and the reading order depends. If you want heights you can tab through that, or shops and tab through that. There isn't only one right order. Reording the DOM all the time also isn't a good answer.
# [18:22] <dael> bcampbell: I think what I pinpoint is when you say stuff like should, I get that. I agree that you should do it the right way. I'd like to look at the directional-nav properties
# [18:23] * glazou thinks we should speed up a bit, already 18 mins on this
# [18:23] <tantek> q+ to ask for examples the group can see where 'order' is being apparently misused
# [18:23] * Zakim sees astearns, tantek on the speaker queue
# [18:23] * fantasai it's a complex topic, I don't think there's much speed to be had
# [18:23] <dael> bcampbell: What I'm seeing from all sides is that this flexbox tool could be a great poss for what designers do. To go back to all these teams and say no, I guess that is an option, but I'm hearing loud voices that say flexbox is awesome for these things, but a11y says flexbox is killing us.
# [18:23] * glazou fantasai if it needs more, it’s a good ftf item…
# [18:24] * fantasai it's def a good f2f item, I think
# [18:24] * tantek agrees with fantasai, and notes that this is perhaps one of the very important aspects of flexbox. also +1 to f2f discussion to see the problematic layouts in person.
# [18:24] * fantasai would like bcampbell to finish explaining his perspective, tho
# [18:24] * fantasai thinks he's explaining better by voice than by email :)
# [18:24] <dael> bcampbell: The simple solution for everyone is to allow people to use flexbox. I'm sort of beating a dead horse. The arguement to add a paramitere, if that's on the table, the arguement is that you shouldn't be adding things in that order.
# [18:24] <dael> ??: I have an arguement about adding a switch
# [18:24] * TabAtkins has no idea if people can hear him.
# [18:24] * Rossen_ agree to spend longer time on this during f2f
# [18:24] * fantasai nope, can't hear you
# [18:24] <glazou> s/??/astearns
# [18:25] * ChrisL tab, no we can't
# [18:25] * TabAtkins But I was about to make astearn's point, basically.
# [18:25] * ChrisL but we sure hear whoever keeps beeping loudly!
# [18:25] <dael> astearns: Having a flexbox specific switch is a little too narrow. We considered a switch that changes the way pointer properties go in display order rather than dom. We should consider a switch that alows us to change all the order.
# [18:25] <astearns> s/change all the order/change tab for all the ways we can manipulate display/
# [18:25] <leaverou> fantasai: no matter what we evangelize, authors *will* use it that way, just like they're using :before and :after for semantic content too. proper accessibility > semantical purity IMO. Also, what *is* non-semantic reordering? Is there any example of that? (sorry if it has been mentioned, I keep dropping)
# [18:26] <dael> TabAtkins: Caring about order is a narrow view that doesn't address the problem. There's lots in flexbox that causes problems. We need to address visual order rather than DOM order directly. Maybe that's a CSS prop or maybe it's something for a11y.
# [18:26] <glazou> q?
# [18:26] * Zakim sees astearns, tantek on the speaker queue
# [18:26] <astearns> ack me
# [18:26] * Zakim sees tantek on the speaker queue
# [18:26] <fantasai> leaverou, consider main vs navigation sidebars. Putting sidebar on left or right is a visual decision that shouldn't affect navigation/speech order
# [18:26] <dael> bcampbell: That was part of the problem. If you're changing the visual order it needs to be accessed by the a11y tree. That sounds like a hge undertaking that can take a long time.
# [18:26] * dbaron Zakim, who is noisy?
# [18:26] * Zakim dbaron, listening for 11 seconds I heard sound from the following: glazou (4%)
# [18:27] * glazou dbaron so TabAtkins is not even speaking :-)
# [18:27] * tantek odd
# [18:27] <dael> TabAtkins: Not nec. That's the answer, there's no way around it. Ign order, you can force direction in upwards or rightwards direction, that reverses your normal flow. The assumption that dom table order will match visual order isn't really valid with advanced layout.
# [18:27] * dbaron Zakim, who is noisy?
# [18:27] * ChrisL will miss these zakim features when zakim goes away
# [18:27] * tantek fantasai is garbling - can't understand
# [18:27] * Zakim dbaron, listening for 10 seconds I heard sound from the following: [IPcaller] (49%), fantasai (64%), +1.631.398.aabb (15%)
# [18:28] * tantek who is +1.631.398.aabb ?
# [18:28] * glazou ChrisL zakim going away ?
# [18:28] * dbaron Zakim, mute [IPcaller]
# [18:28] * Zakim [IPcaller] should now be muted
# [18:28] * dbaron Zakim, unmute [IPcaller]
# [18:28] * Zakim [IPcaller] should no longer be muted
# [18:28] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:28] <dael> fantasai: I'd worht noting with MQ...If you want to insist that you want it to go in this way in this size for this divice, but if I change device I want a differenet way, that should be a screen reader feature that handles all the different properties. Any way you can get things out of order, if you want that visual order you should have a feature that does that
# [18:28] <dael> glazou: bcampbell will you be in Sydney.
# [18:29] <dael> bcampbell: Not unless I can make a good arguement for it.
# [18:29] * dauwhe is NYC in May too late?
# [18:29] <dael> glazou: It seems to me this is an excellent topic for a F2F
# [18:29] <tantek> zakim, unmute me
# [18:29] <Zakim> tantek should no longer be muted
# [18:29] <fantasai> s/with MQ/with MQ, the visual order can change depending on the device or as I change the width of the browser window/
# [18:29] <dael> bcampbell: I agree. I can work on it, but I doubt it. That's a good question. NYC if we don't have a resolution before.
# [18:30] <fantasai> s/insist that you want it to go in this way/insist that you want it to go strictly left to right top to bottom/
# [18:30] <Zakim> -fantasai
# [18:30] <ChrisL> yes, floats have provided reordering since forever
# [18:30] * TabAtkins No, more examples aren't needed. We get what the issues are.
# [18:30] <dael> tantek: We've been able to rearange content in CSS for a long time. This isn't Flexbox in particular, it sounds like you're finding new examples. Links would help us see if it's a new problem or the same old one. Presentation vs DOM problem has been around since CSS1
# [18:30] <Zakim> +fantasai
# [18:30] <dael> bcampbell: The question is if Flexbox doesn't give you more flexability, why have it?
# [18:31] <dael> tantek: It gives you more flexability. The problem case we've had floats doing this since forever, positioning, tons of ways before flexbox. If we want this semantic order we shouldn't monkey-patch, we should solve.
# [18:31] * glazou suggest to move to item 2 on agenda
# [18:31] <plinss> zakim, who is noisy?
# [18:31] <dael> bcampbell: I completely agree.
# [18:31] <Zakim> plinss, listening for 10 seconds I heard sound from the following: [IPcaller] (31%), tantek (50%)
# [18:31] <astearns> all the other ways we've been able to reorder display have been hacks - using features not meant for layout. Flexbox is the first feature meant for layout, so keeping tab order consistent with the intended layout is a bit more important than before
# [18:31] <dael> tantek: I think that's why people are asking for it at a F2F
# [18:31] <fantasai> s/change device I want a differnet way/change device or screen width I want to change the reading order to match that different order/
# [18:31] <dael> glazou: I'm sorry we don't have a conclusion, but I suggest we move on
# [18:31] <fantasai> s/that should be/then that should be/
# [18:31] <dael> bcampbell: This move more forward another step. I'll see about the F2F. Thank you.
# [18:32] <bradk> Is there any reason why nav-index can't solve this?
# [18:32] <dael> glazou: If you can't make Sydeny, lets do it in NYC.
# [18:32] <dael> Topic: CSS Grid Layout Issues
# [18:32] * leaverou is very happy that there will be a F2F in NYC :)
# [18:32] <bradk> Nav-index: visual-order
# [18:32] <dael> glazou: Rossen_ you requested a week on this
# [18:32] <tantek> bradk nav-index was a poor design, and only addresses the tabbing problem
# [18:32] <tantek> or only *tries* to
# [18:32] <dael> Rossen_: I'm okay with it
# [18:32] <astearns> bradk: using nav-index along with order is a maintenance nightmare
# [18:32] <fantasai> s/that handles all the different properties/that reads the page in strictly visual left to right top to bottom order, and handles all the different ways of repositioning items (including flexbox, grid positioning, floats, abspos, etc.)
# [18:32] <tantek> er, *tried*. sigh.
# [18:32] <dael> glazou: So, who raised the issue? Was it you fantasai ?
# [18:33] * dauwhe leaverou: So am I. My first meeting in my own time zone :)
# [18:33] <bradk> Expand nav-index to affect screen readers too then
# [18:33] <dael> fantasai: Let me try and remember it.
# [18:33] <tantek> bradk, astearns: if anything I'd prefer to brainstorm a 'nav-next' property similar syntax as 'nav-up' etc.
# [18:33] * leaverou dauwhe not just my own timezone, but only a 1 hour flight or a 5 hour bus ride away! :)
# [18:33] <Rossen_> we did re-review it one more time internally and are OK with the proposed change
# [18:33] * dbaron leaverou or 3-4 (??) hour train ride
# [18:34] <dael> fantasai: The issue was we wanted to updae the spec so space-around and space-between creates space between the grid tracks. That gives us some real functionality and is consistant with how items are thought abou
# [18:34] <tantek> bradk - now that's crazy nav-index spooky side-effect from a distance stuff! :/
# [18:34] <fantasai> s/real/useful/
# [18:34] * Rossen_ sry too loud around me to talk
# [18:34] * leaverou dbaron trains are overpriced, not worth it over a flight
# [18:34] <dael> glazou: So Rossen_ says he agrees.
# [18:34] <dael> glazou: objections?
# [18:34] <andreyr> no obj
# [18:35] <fantasai> RESOLVED: align-content and justify-content on grid containers operate on the grid tracks (allows distributing extra space between grid tracks)
# [18:35] <dael> glazou: Okay for everyone?
# [18:35] <dael> [silence]
# [18:35] <dael> Topic: CSS3 UI
# [18:36] <Florian_away> I am joining now
# [18:36] <Florian_away> give me 1 minute
# [18:36] <dael> tantek: Thanks to Florian_away help we've made good progress with resolutions. I would like to pub a draft before the F2F.
# [18:36] * fantasai in favor of publishing
# [18:36] <fantasai> Publish early, publish often
# [18:36] <dael> tantek: I'd like to both continnue to resolve the issues and anything we can't resolve in time I'll incorporate inline to the spec. I wanted to see if that plan is ammenable to the group and, if so, I'll follow that plan and have something for next Wed
# [18:37] <dael> ChrisL: Sounds good. Can I have it by Tuesday for the pub queue.
# [18:37] <Zakim> + +1.479.764.aacc
# [18:37] <Florian_away> Zakim, I am aacc
# [18:37] <Zakim> +Florian_away; got it
# [18:37] * dauwhe start the presses!
# [18:37] <dael> tantek: I can dot hat, but I wanted to let the group review. If people are okay with what's there and the continued progress, that's fine with me too.
# [18:37] * Florian_away is now known as Florian
# [18:37] <dael> ChrisL: If you have it for Tuesday, I can put it in the queue and if we don't resolve on Wednesday I can pullit out.
# [18:37] <dael> tantek: Okay.
# [18:37] <dael> glazou: Anyone obj to the publication?
# [18:38] <dael> fantasai: I'm in favor
# [18:38] <dael> TabAtkins: I think it's reasonable for Florian to be a co-editor with everything he's put into the draft
# [18:38] * astearns anyone object? (several voices murmur in favor to drown anyone else out) :)
# [18:38] <dael> tantek: I'll make sure Florian is acknowledged
# [18:38] <dael> tantek: Florian has put a lot in, but there's been a lot before. I'll give Florian proper acknowledgement.
# [18:39] * SimonSapin fantasai, why can’t we have 'max-width: 50em' on /TR, again?
# [18:39] * dauwhe agree wtih TabAtkins
# [18:39] <dael> glazou: To add to what TabAtkins said, I think he should be a co-editor, but we won't spend the rest of the call on it. He's doing major work. Lets go back to the main subject
# [18:39] * fantasai agrees with TabAtkins and glazou
# [18:39] <dael> RESOLVED: New WD of CSS3 UI
# [18:39] <ChrisL> I agree it makes sense for Florian to become co-editor. And +1 to publish
# [18:39] * fantasai SimonSapin because rules
# [18:39] <dael> Topic: Color & Background Serialization
# [18:39] * fantasai consistency of making all /TR publications look equally ugly
# [18:39] <glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html
# [18:39] <dael> glazou: That was from Sebastian Zartner.
# [18:40] * ChrisL simon because the webmaster refuses to publish it otherwise. same for non-blue links and for line spacing that is wider than 1.2
# [18:40] <leaverou> I think it makes much more sense at the end, because it’s *underneath* the background image, so it follows the order of the rest of the bg layers
# [18:40] * glazou will add a topic about Florian as co-editor of CSS3 UI for ftf : it makes no sense to keep him outside like this, it’s against our usual practices in this WG
# [18:40] <dael> TabAtkins: I can do this. Apperently, currently the grammar for BG puts the bg-color at the end of the last layer. The serialization matches the grammar. Apperently Firebug users prefer it at the front. Are we okay with switching the serialization around? Is that a compat thing?
# [18:41] <dael> dbaron: You're putting the color at the beginning of the last ident instead of the end of the last
# [18:41] <leaverou> is there any reason to put it in the beginning besides people asking for it? Did they provide any rationale?
# [18:41] <dael> TabAtkins: Yeah. That's what he's asking for.
# [18:41] <dael> TabAtkins: I'm reading dbaron comment on it. It sounds like it's to make the code simplier
# [18:41] <dael> TabAtkins: I don't care either way. It's a tiny change. fantasai should be the one worrying about accept or reject.
# [18:42] <dael> smfr: Any feelings on the compat risk of this?
# [18:42] <dael> TabAtkins: No feelings.
# [18:42] <dael> dbaron: Are browsers interop now?
# [18:42] <dael> TabAtkins: I'm testing Chrome.
# [18:42] * tantek TabAtkins glazou fantasai ChrisL I will definitely your suggestion under strong advisement. I'll discuss with Florian also.
# [18:42] <Florian> Zakim, who is in the call?
# [18:42] <Zakim> I don't understand your question, Florian.
# [18:43] <dael> TabAtkins: It's only asking to rearrange the serialization of the last layer. It's not a meaning change.
# [18:43] * ChrisL @t thanks
# [18:43] <dael> glazou: The main q isn't how the browsers are serializing. Are there frameworks that parse it and expect the color at the end?
# [18:43] <dael> TabAtkins: No idea. Chrome puts the color at the beginning.
# [18:44] <dael> smfr: Same with webkit
# [18:44] <dael> dbaron: Which implies it's fine the change.
# [18:44] <Rossen_> can you share the tc
# [18:44] <dael> fantasai: The reason for end is that it's painted at the bottom of the bg layers and the bottom layer is the last with multiple layers. That's the org rational.
# [18:44] * ChrisL hears lots of breakup
# [18:44] <dael> TabAtkins: I'm either insane or Chrome has a completely broken serialization of the BG shorthand. It looks like w'ere 100% broken.
# [18:44] <Rossen_> TabAtkins: can you share your test case pls?
# [18:45] * dael too
# [18:45] <dael> TabAtkins: This is what I get...I don't know how we completely broke that, but it's crazy times.
# [18:45] * TabAtkins rgb(255, 0, 0) url(http://software.hixie.ch/utilities/js/live-dom-viewer/foo), url(http://software.hixie.ch/utilities/js/live-dom-viewer/bar) repeat, repeat scroll, scroll 0% 0%, 0% 0% / auto, auto padding-box, padding-box border-box, border-box
# [18:45] <dael> dbaron: We didn't get the this.
# [18:45] * TabAtkins background: url(foo), red url(bar);
# [18:45] <dael> TabAtkins: So ours is an error.
# [18:46] <dael> TabAtkins: It does look like color is first.
# [18:46] * bradk is on another call now, on a different phone, so I'll hang up and glance at irc now and then.
# [18:46] <Zakim> -BradK
# [18:46] <dael> ??: So there's not that strong dependanies on how this is presented.
# [18:46] <dael> glazou: So are there obj to the change?
# [18:46] <dael> [silence]
# [18:46] <dael> RESOLVED: accept the proposed change for the serialization order
# [18:46] <glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0166.html
# [18:47] * TabAtkins has to drop off, so he can do an interview at the top of the hour
# [18:47] <dael> Topic: Floats & Initial Letters
# [18:47] <Zakim> -TabAtkins
# [18:47] * tantek perks up
# [18:47] <dael> fantasai: When dauwhe and I worked on initial letters, we discussed a lot of things already, but not how to deal with if there's a float on the first or second line of a paragraph with a two line drop cap
# [18:47] <dael> fantasai: We went witht he float clears the initial letter as if the initial letter was a float.
# [18:48] <ChrisL> initial letter I18n examples from richard ishida https://www.flickr.com/photos/ishida/sets/72157650248400402/
# [18:48] <dael> fantasai: Other options were float is betweent he initial letter and the rest of the text. Or it fits between initial letter and the rest of the text.
# [18:48] * ChrisL hears little, will drop and rejoin
# [18:48] <Zakim> -ChrisL
# [18:48] <dael> fantasai: I think there's a reasonable arguement for at least two options. If the float is on the first line and not the second, it's awk no matter what.
# [18:49] <dael> fantasai: If you want an image at the beginning you can put it before the para with the initial letter.
# [18:49] <tantek> aren't such floats usually FOR the initial letter
# [18:49] <dael> fantasai: Generally an image is an item on it's own.
# [18:49] <dael> fantasai: I wanted to see if there's other feedback
# [18:49] <Zakim> +ChrisL
# [18:50] <dael> SteveZ: I sent you another interp on the ML which is to say we should treat the initial letter as defining what the first line or current line is which means the float in the second line would move to the front and up because it's aprt of the initial letter seq
# [18:50] <dael> SteveZ: The arguement is the initial letter has moved the line it's shortening so it's part of the same seq. It would give you a fairly reasonable handling of most cases, even with shorter lines
# [18:50] <fantasai> SteveZ: http://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html
# [18:51] <dael> SimonSapin: I was with you until the last thing.
# [18:51] <dael> SteveZ: That would be okay because it would float beneath the initial letter.
# [18:51] <SimonSapin> s/SimonSapin/???/
# [18:51] * tantek reads the floats and initial letters thread
# [18:51] <Florian> s/SimonSapin/Florian/
# [18:51] <dael> Florian: I thought it would get to float below.
# [18:51] <dael> SteveZ: not perfect, but I think better.
# [18:52] <dael> fantasai: I think it's an interesting interp. YOu can get yourself into interesting floats because the float might be on the second line, it fits on the second line, so it should shift left and it fits, but then when you move it up it doesn't fit anymore.
# [18:52] <dael> SteveZ: You migth need logic like that in Regions, so you make your decisions and if the layout changes, you ignore that.
# [18:52] <dael> fantasai: I'd like dbaron opinion.
# [18:52] <fantasai> s/anymore/anymore because the first line is now also shortened/
# [18:52] * dbaron wasn't following the whole thing
# [18:53] <Florian> floats are hard enough already
# [18:53] <dael> Rossen_: Sounds like a lot for doubtful benefits. The layout logic is quite complicated for something that's complex enough.
# [18:53] <dael> SteveZ: It's no worse than two floats on one line.
# [18:53] * tantek has finished reading the thread as of now.
# [18:53] <dael> Rossen_: If ther initial letter is a float, yeah.
# [18:53] <dael> fantasai: no
# [18:53] <dbaron> we should be moving away from treating the initial letter like a float
# [18:53] <dael> SteveZ: The alignmenet is different, but it's basically a float
# [18:54] <tantek> dbaron meaning ::first-letter ?
# [18:54] <dbaron> tantek, yes
# [18:54] <dael> fantasai: Floats depend...you never move a float p. YOu can decide if it fits, as you layout the text you see if it fits on the line and if it does, great, and you shift the position. If it doesn't fit you push to the end of the line and coniue layout.
# [18:55] <leaverou> s/float p/float up/
# [18:55] <dael> fantasai: If you move it up, you can't do that. Here's my line #2, it fits, great, but we have an initial letter so ou have to push it up and then you have to relayout and the float may no longer fit. So if you're not moving up you can layout, but in this case you have a cyclic dependancy.
# [18:55] * fantasai dbaron issue is floats within the drop-cap lines
# [18:55] <fantasai> s/drop-cap/drop-cap-affected/
# [18:55] <dbaron> yeah
# [18:55] <dael> SteveZ: It's no worse than you have to take the length of the lines being shortened byt he drop cap
# [18:55] <dael> s/byt he/by the
# [18:56] <fantasai> s/push it up/push it up, shorten the first line/
# [18:56] <dael> tantek: I think we should capture this as an outstanding issue. I think it would also benefit from F2F visual discussion
# [18:56] <dael> Florian: Use cases would be good
# [18:56] <fantasai> tantek, we already published
# [18:56] <dael> dauwhe: I haven't seen an example where there's this possible interaction so I want to do a search for that.
# [18:56] <fantasai> I want to note that if you want to put a float in the top left corner, you can already do that
# [18:56] <dael> Florian: I think the proposal is sane, but there might be better.
# [18:56] <fantasai> Just put the float before the paragraph
# [18:56] <dael> dauwhe: I also think initial letter is different than a float.
# [18:57] <dael> tantek: I also see Rossen_ concerns about adding complexity without real world examples.
# [18:57] <dael> dbaron: What we need to solve is lets not have cases where the spec says there should be a result that's unachieable, but elsewise I agree.
# [18:57] <dael> tantek: I think with an addition that we find that out from impl experience.
# [18:57] <dael> dbaron: We already know that it is.
# [18:57] <Florian> s/I think the proposal is sane, but there might be better./I think Steve's proposal is sane, but it's harder, and to see if it is worth solving, I'd like to see use cases. Otherwise, Fantasai's solution is simpler, and also sane./
# [18:58] <SteveZ> My proposal is documented in: http://lists.w3.org/Archives/Public/www-style/2014Dec/0277.html
# [18:58] <dael> fantasai: To summerize. I think your idea is interesting, but it intro a compexity in float that deosn't already exist. It also can create a loop. I think this is a bit of an edge case. Lastly I agree with Rossen_ that this doesn't seem like a really important thing to solve. That complexity doesn't seem to be worth dealing with for such an edge case that is rare in practice.
# [18:59] * dauwhe SteveZ: thanks for the link. Missed the email due to holiday chaos :)
# [18:59] <dbaron> I think the simple solution is saying that a float that's not in the first line and intersects (i.e., on the same side as) a drop cap clears below the drop cap
# [18:59] <dael> fantasai: That's why I think you have an interesting idea, but not a good idea for us to go with.
# [18:59] <dael> tantek: I don't know which is better because there's a lack of examples
# [18:59] <fantasai> dbaron, that's exactly the proposal dauwhe and I have
# [18:59] <dael> SteveZ: I thought we were waiting to the F2F to solve
# [18:59] <dael> dauwhe: I can make diagrams. Cool.
# [18:59] <ChrisL> diagrams++
# [18:59] <dael> fantasai: Anyone want to presue SteveZ case?
# [19:00] <astearns> let's wait until the ftf to decide, including steve's proposal
# [19:00] <dael> Florian: Without exmples, no, but if he has examples maybe
# [19:00] <dael> tantek: I can't answer w/o examples
# [19:00] <ChrisL> s/presue/pursue/
# [19:00] <dael> SteveZ: I also have to understand putting the float before the dropcap a bit better.
# [19:00] <fantasai> <img> <p>Drop cap paragraph/p>
# [19:00] <fantasai> img { float: left;
# [19:00] <fantasai> Done. Puts it in top left corner of paragraph
# [19:00] <dael> glazou: We're at the top of the hour
# [19:00] <Bert> (Also seems asymmetric to me: you might to move up when floating left, but probably not when flowtimnmg right...)
# [19:00] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [19:01] <dael> Florian: Quest question on CSS3 UI. There was one resolution that we made that was objected to. If we pub without changes that's fine, but I don't want to make edits and change them.
# [19:01] <Zakim> -[Bloomberg]
# [19:01] <dael> tantek: Issue 40?
# [19:01] <dael> Florian: No. If we publish, publish as is and don't roll in the edits.
# [19:02] <Florian> I cannot hear you
# [19:02] <dael> tantek: I can capture the obj. I'd rather have the edits in and caputure the concesus and the objection
# [19:02] <tantek> this is about Issue 47 resize (I think)
# [19:02] <Florian> it is about issue 47
# [19:02] <tantek> need URL to the objection
# [19:02] <Florian> it's in the wiki
# [19:02] <tantek> great. thanks.
# [19:02] <dael> glazou: I'm lost. What are you waiting for tantek
# [19:02] <dael> tantek: Nothing.
# [19:02] <dael> glazou: Okay.
# [19:02] * dauwhe I'm waiting for lunch
# [19:02] <Zakim> -dbaron
# [19:02] <Zakim> -ChrisL
# [19:03] <Zakim> -hober
# [19:03] <Zakim> -Stearns
# [19:03] <Zakim> -glazou
# [19:03] <Zakim> -SteveZ
# [19:03] <Zakim> -dauwhe
# [19:03] * Quits: AH_Miller (~mike@public.cloak) ("")
# [19:03] <dael> glazou: That's it for today. Talk to you next week and thank you very much.
# [19:03] <Zakim> -Florian_away
# [19:03] <Zakim> -[IPcaller]
# [19:03] <Zakim> -tantek
# [19:03] <Zakim> -smfr
# [19:03] <Zakim> -??P62
# [19:03] <Zakim> -fantasai
# [19:03] <Zakim> -plinss
# [19:03] <Zakim> -??P44
# [19:03] <Zakim> -[IPcaller.a]
# [19:03] <Zakim> -kwkbtr
# [19:03] <Zakim> -SimonSapin
# [19:03] * Parts: smfr (~smfr@public.cloak) (smfr)
# [19:03] <Zakim> -koji
# [19:03] <Zakim> -[Microsoft]
# [19:03] <Zakim> -Lea
# [19:03] <Zakim> -[IPcaller.aa]
# [19:03] <Zakim> -dael
# [19:03] <alex_antennahouse> bye
# [19:03] <Zakim> -MikeMiller
# [19:03] * Quits: bcampbell (~chatzilla@public.cloak) ("ChatZilla 0.9.91.1 [Firefox 31.4.0/20150105205548]")
# [19:03] <Florian> Objection was from Tab and smfr.
# [19:03] <Zakim> - +1.631.398.aabb
# [19:03] <Zakim> Style_CSS FP()12:00PM has ended
# [19:03] <Zakim> Attendees were dael, glazou, plinss, SimonSapin, dauwhe, bcampbell, Lea, MikeMiller, kwkbtr, BradK, [Bloomberg], Stearns, fantasai, hober, SteveZ, smfr, Rossen_, dbaron,
# [19:03] <Zakim> ... +1.281.305.aaaa, TabAtkins, [IPcaller], ChrisL, tantek, +1.631.398.aabb, koji, +1.479.764.aacc, Florian_away
# [19:03] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [19:03] * Quits: dael (~dael@public.cloak) ("Page closed")
# [19:03] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [19:03] * Parts: tgraham (~user@public.cloak) (ERC Version 5.3 (IRC client for Emacs))
# [19:04] * Quits: antenna (~antenna@public.cloak) ("Leaving")
# [19:05] * Quits: andreyr (~andreyr@public.cloak) ("Page closed")
# [19:05] * Quits: glazou (~glazou@public.cloak) (glazou)
# [19:05] * Parts: kwkbtr (~kwkbtr@public.cloak) (kwkbtr)
# [19:14] * Joins: mib_xmxjd8 (~5da91408@public.cloak)
# [19:16] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:16] * Joins: Florian (~Florian@public.cloak)
# [19:16] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:17] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:36] * Joins: svillar (~sergio@public.cloak)
# [19:38] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:40] * Quits: mib_xmxjd8 (~5da91408@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [19:42] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:46] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [19:53] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [20:01] * Joins: bradk (~bradk@public.cloak)
# [20:04] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [20:11] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [20:16] * Joins: bradk (~bradk@public.cloak)
# [20:17] * Joins: Florian (~Florian@public.cloak)
# [20:20] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:20] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [20:21] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [20:26] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [20:26] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [20:27] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [20:28] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:29] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [20:35] * Joins: bradk (~bradk@public.cloak)
# [20:35] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [20:38] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [20:43] * Joins: bradk (~bradk@public.cloak)
# [20:44] * Zakim excuses himself; his presence no longer seems to be needed
# [20:44] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [20:50] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [20:50] * Joins: Florian (~Florian@public.cloak)
# [21:02] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [21:57] <SimonSapin> TabAtkins: Values & Units says "UAs should support reasonably useful ranges and precisions" about numeric data types, but what to do on overflow is apparently undefined
# [21:57] <SimonSapin> I think it’d be useful to specify something like "clamp, do not wrap"
# [21:57] <SimonSapin> "… if the supported range is finite"
# [21:59] <Florian> SimonSapin: spoken like a true rust developer, always with safety in mind. I'm a C++ guy, and I'm fine with undefined behavior :P
# [22:01] <SimonSapin> Florian: integer overflow does not affect memory safety :) I’m rather thinking that `z-index: 3000000000` should not wrap to -1294967296
# [22:02] <Florian> jokes aside, as long as the browser does not crash, I don't mind if wrapping happens instead of clamping. If the values used are so large the browser can't handle them, the intended layout will be messed up anyway. I don't know if clamp messes up less badly than wrap, but I am not convinced I am intersted in the performance trade off needed to make sure you can one fallback over the other
# [22:03] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:07] <Florian> Integer overflow does not affect memory safety, but strange values might crash the layout system. That must be avoided but I don't mind if the layout is messed up
# [22:13] * Joins: nikos (~uid28403@public.cloak)
# [22:17] * Joins: bradk (~bradk@public.cloak)
# [22:22] <SimonSapin> If your layout code crashes with large input values, the correct fix is not to make sure input values are small :)
# [22:26] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [22:26] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:28] <Ms2ger> "Doctor, it hurts when I do this"
# [22:29] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:39] * gsnedders votes for clamping, given the amount of breakage had with 16-bit z-indexes
# [22:40] <SimonSapin> gsnedders: clamping z-index also means that different values can end up at the same max clamped value, and so stack differently than if the max was higher
# [22:41] <SimonSapin> (it’s still better than wrapping)
# [22:41] <gsnedders> SimonSapin: yeah, but it's probably a better experience in general
# [22:41] <gsnedders> idk, I mean wrapping could end up with 98, 99, 100 instead of crazy_value, crazy_value + 1, etc.
# [22:41] <gsnedders> which might work better
# [22:41] <gsnedders> but only in the cases where they're thus stacked
# [22:42] <gsnedders> data for crazy value usage, plz
# [22:42] <SimonSapin> except it’s apparently more often crazy_value^2 than crazy_value + 1
# [22:42] <SimonSapin> http://adspecs.aol.com/technical-guidelines/z-index-guidelines
# [22:42] <SimonSapin> (I’m only slightly exaggerating)
# [22:43] <gsnedders> still seems like wrapping may actually give the better advice then, bleh. why's there no solution that always works best? :)
# [22:43] <gsnedders> (well, there is, arbitrarily-sized ints, but…)
# [22:43] <SimonSapin> bignum all the things!
# [22:47] <gsnedders> If I wanted to be evil I'd suggest scaling down from max_seen_in_AST to MAX_INT.
# [22:47] <gsnedders> But I'm not that evil.
# [22:47] <gsnedders> Mostly.
# [22:48] <SimonSapin> dynamic updates would be fun
# [22:48] <gsnedders> SimonSapin: This is what makes it truly evil instead of "kinda evil".
# [22:48] * Joins: bradk (~bradk@public.cloak)
# [22:53] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [22:56] * Quits: tantek (~tantek@public.cloak) (tantek)
# [22:57] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:58] <TabAtkins> Florian: No, wrapping is terribad, and there's no excuse for it. Clamping is also bad, but when you can't avoid it, it at least comes close to the author's intent, and is thus more likely to be less broken.
# [23:05] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [23:19] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [23:24] * Joins: dauwhe (~dauwhe@public.cloak)
# [23:27] * Joins: thinkxl_ (~thinkxl@public.cloak)
# [23:27] * Quits: thinkxl (~thinkxl@public.cloak) (Client closed connection)
# [23:43] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [23:58] * leaverou is now known as leaverou_away
# [23:59] * leaverou_away is now known as leaverou
# Session Close: Thu Jan 22 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn