/irc-logs / w3c / #css / 2014-07-30 / end

Options:

# Session Start: Wed Jul 30 00:00:00 2014
# Session Ident: #css
# [00:02] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [00:02] * Joins: glenn_ (~gadams@public.cloak)
# [00:07] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [00:20] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [00:20] * Joins: antonp (~Thunderbird@public.cloak)
# [00:26] * Joins: lmcliste_ (~lmclister@public.cloak)
# [00:26] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [00:27] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [00:27] * Joins: lmclister (~lmclister@public.cloak)
# [00:31] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [00:58] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [00:59] * Joins: glenn (~gadams@public.cloak)
# [01:01] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:05] * Joins: glenn_ (~gadams@public.cloak)
# [01:07] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:11] * Joins: rhauck (~rhauck@public.cloak)
# [01:13] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:14] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [01:18] * Joins: glenn (~gadams@public.cloak)
# [01:28] * Joins: glenn_ (~gadams@public.cloak)
# [01:33] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:35] * Joins: glenn (~gadams@public.cloak)
# [01:40] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:54] * Joins: tantek (~tantek@public.cloak)
# [02:02] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [02:06] * Joins: tantek (~tantek@public.cloak)
# [02:10] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [02:15] * Quits: lmclister (~lmclister@public.cloak) ("")
# [02:31] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [02:40] * Joins: glenn_ (~gadams@public.cloak)
# [02:43] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [02:49] * Quits: rhauck (~rhauck@public.cloak) ("Leaving.")
# [02:59] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [03:19] * Joins: glenn (~gadams@public.cloak)
# [03:21] * Joins: glenn__ (~gadams@public.cloak)
# [03:23] * leaverou is now known as leaverou_away
# [03:23] * Joins: glenn___ (~gadams@public.cloak)
# [03:24] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [03:26] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [03:29] * Quits: glenn__ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [04:00] * Joins: glenn (~gadams@public.cloak)
# [04:04] * Quits: tantek (~tantek@public.cloak) (tantek)
# [04:06] * Quits: glenn___ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [04:36] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [04:56] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [05:02] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [05:02] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [05:09] * leaverou_away is now known as leaverou
# [05:26] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
# [05:26] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [05:28] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [05:33] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [05:52] * Joins: glenn_ (~gadams@public.cloak)
# [05:57] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [06:02] * Joins: glenn (~gadams@public.cloak)
# [06:07] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [06:41] * leaverou is now known as leaverou_away
# [06:50] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
# [06:51] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [06:58] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [07:04] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [07:14] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [07:59] * Joins: glenn_ (~gadams@public.cloak)
# [08:03] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [08:11] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:11] * Joins: tantek (~tantek@public.cloak)
# [08:36] * leaverou_away is now known as leaverou
# [08:37] * Joins: dbaron (~dbaron@public.cloak)
# [08:42] * Joins: glenn (~gadams@public.cloak)
# [08:47] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [08:48] * leaverou is now known as leaverou_away
# [08:58] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [08:58] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [09:03] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [09:03] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
# [09:21] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:33] * Joins: glenn_ (~gadams@public.cloak)
# [09:38] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [09:40] * Joins: glenn (~gadams@public.cloak)
# [09:44] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [09:54] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [10:02] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [10:11] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:12] * Joins: glenn_ (~gadams@public.cloak)
# [10:14] * Joins: glenn__ (~gadams@public.cloak)
# [10:17] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [10:20] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [10:41] * leaverou_away is now known as leaverou
# [10:52] * leaverou is now known as leaverou_away
# [11:06] * Joins: liam (liam@public.cloak)
# [11:07] * Quits: tantek (~tantek@public.cloak) (tantek)
# [11:22] * Joins: glenn (~gadams@public.cloak)
# [11:26] * Quits: glenn__ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [11:30] * Joins: glenn_ (~gadams@public.cloak)
# [11:34] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [11:56] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [11:56] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [12:03] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [12:05] * leaverou_away is now known as leaverou
# [12:16] * leaverou is now known as leaverou_away
# [12:45] * leaverou_away is now known as leaverou
# [13:05] * Joins: plh (plehegar@public.cloak)
# [13:10] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [13:34] * leaverou is now known as leaverou_away
# [13:35] * leaverou_away is now known as leaverou
# [13:49] * Quits: Bert (bbos@public.cloak) (Client closed connection)
# [13:54] * Joins: Bert (bbos@public.cloak)
# [13:57] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [14:41] * Joins: glenn (~gadams@public.cloak)
# [14:46] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [15:47] * leaverou is now known as leaverou_away
# [15:57] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [16:01] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [16:24] * leaverou_away is now known as leaverou
# [16:33] * Joins: dwim_home (~Dongwoo@public.cloak)
# [16:33] * Quits: dwim_home (~Dongwoo@public.cloak) ("Leaving")
# [16:36] * leaverou is now known as leaverou_away
# [16:48] * Quits: tommyjtl (~tommyjtl@public.cloak) ("brb")
# [17:06] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [17:12] * Joins: dbaron (~dbaron@public.cloak)
# [17:16] * Joins: adenilson (~anonymous@public.cloak)
# [17:18] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [17:32] * Joins: lmclister (~lmclister@public.cloak)
# [17:38] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [17:40] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [17:51] * Joins: antonp (~Thunderbird@public.cloak)
# [17:52] * Joins: dael (~dael@public.cloak)
# [17:57] * leaverou_away is now known as leaverou
# [17:58] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [18:00] * Joins: AH_Miller (~mike@public.cloak)
# [18:00] <gregwhitworth> is zcorpan not setup? I didn't see my number popup
# [18:00] <gregwhitworth> I guess it's trackbot
# [18:01] * Joins: Zakim (zakim@public.cloak)
# [18:01] * Joins: RRSAgent (rrsagent@public.cloak)
# [18:01] <RRSAgent> logging to http://www.w3.org/2014/07/30-css-irc
# [18:02] <plinss> zakim, this is style
# [18:02] <Zakim> ok, plinss; that matches Style_CSS FP()12:00PM
# [18:02] <dael> ScribeNick: dael
# [18:02] <Zakim> +??P16
# [18:02] <Zakim> +glenn
# [18:03] <adenilson> Zakim: +??P16 should be me.
# [18:03] <Zakim> +SylvaIng
# [18:03] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:04] <dael> zakim, who is here?
# [18:04] <Zakim> On the phone I see +1.907.315.aaaa, Lea, dael, +1.240.421.aabb, plinss, ??P16, glenn, SylvaIng
# [18:04] <Zakim> On IRC I see MaRakow, RRSAgent, Zakim, AH_Miller, alex_antennahouse, dael, antonp, gregwhitworth, lmclister, Ms2ger, adenilson, dbaron, glenn, Bert, fantasai, ed, mihnea___,
# [18:04] <Zakim> ... darktears, nikos_, birtles, abucur__, amtiskaw_____, dwim, kangil, renoirb, CSSWG_LogBot, shepazu, anssik_, achicu_____, paul___irish, timeless, krijnhoetmer, astearns_,
# [18:04] <Zakim> ... gsnedders, Hixie, TabAtkins, lmclister_____, jacobg______, logbot, alexmog, mvujovic____, slightlyoff, sgalineau, plinss, projector, shans, leaverou, hober, sylvaing,
# [18:04] <Zakim> ... SimonSapin, decadance
# [18:04] <Zakim> +antonp
# [18:04] * plinss changes topic to 'http://lists.w3.org/Archives/Public/www-style/2014Jul/0572.html'
# [18:04] <Zakim> +Stearns
# [18:05] * Joins: bradk (~bradk@public.cloak)
# [18:05] * Joins: bkardell_ (~uid10373@public.cloak)
# [18:05] <Zakim> +[IPcaller]
# [18:05] <Zakim> +[Microsoft]
# [18:05] <Zakim> - +1.907.315.aaaa
# [18:05] <alex_antennahouse> I'm IPCaller
# [18:05] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:05] <MaRakow> Zakim, I'm [Microsoft]
# [18:05] <Zakim> I don't understand 'I'm [Microsoft]', MaRakow
# [18:05] <bkardell_> Phone issues, unable to dial in today.. Sorry, irc only
# [18:05] <Zakim> + +1.603.821.aacc
# [18:05] * Joins: smfr (~smfr@public.cloak)
# [18:05] <Zakim> +BradK
# [18:05] <Zakim> +[IPcaller.a]
# [18:05] <astearns_> zakim, who is noisy?
# [18:05] <MaRakow> Zakim, [Microsoft] is me
# [18:05] <Zakim> +MaRakow; got it
# [18:05] <Zakim> +SteveZ
# [18:06] <Zakim> +dbaron
# [18:06] <Zakim> +??P33
# [18:06] <Zakim> astearns_, listening for 10 seconds I heard sound from the following: 14 (8%), [IPcaller.a] (38%)
# [18:06] <SimonSapin> Zakim, ??P33 is me
# [18:06] <Zakim> +SimonSapin; got it
# [18:06] <dael> zakim, [IPCaller] is alex_antennahouse
# [18:06] <Zakim> +alex_antennahouse; got it
# [18:06] <Zakim> +smfr
# [18:06] <Zakim> +[Microsoft]
# [18:06] <adenilson> Zakim, ??P16 is me.
# [18:06] <Zakim> +adenilson; got it
# [18:06] <Rossen_> zakim, microsoft is me
# [18:06] <Zakim> +Rossen_; got it
# [18:06] * fantasai is on, unsure which
# [18:06] <Zakim> + +1.631.398.aadd
# [18:07] * Joins: SteveZ (~SteveZ@public.cloak)
# [18:08] <dael> plinss: Let's get started
# [18:08] <dael> plinss: Anything to add to the agenda
# [18:08] <dael> plinss: That's a no.
# [18:09] <dael> Topic: Animations Issues
# [18:09] * fantasai had sent a few agenda+ earlier
# [18:09] <dael> sylvaing: This was an old issue about the shorthands and subproperties that aren't available. as dbaron pointed out there's a buncho f subissues that need resolution. At least 2, maybe a 3rd
# [18:10] <dael> sylvaing: The first is that in general the computed value can depend on other computed values. So if you have a font size and set an resolution of 2em, the font size effect that. Do we do that in keyframes
# [18:10] * Joins: smfr_ (~smfr@public.cloak)
# [18:10] <dael> sylvaing: Second is that in other implementations we ignore non-impl properties. So do we apply in a keyframE? If you have border-start: none and set a keyframe, does that reset to 0?
# [18:11] <dael> sylvaing: 3rd is from a resolution a while about. How do we animate non-animatable properties. There my understanding was that it would be animations and transitions, but dbaron says it's only animations.
# [18:11] <dael> sylvaing: dbaron am I missing anything?
# [18:11] <dael> dbaron: There's complications to the second issue, but we can get there at some point.
# [18:11] <Zakim> +hober
# [18:12] * dbaron now wonders if he meant first issue
# [18:12] <dael> sylvaing: So first we have a keyframe anywhere in the animation. ex we have font size of 42px and an indenet of 2em, do we resolve the keyframe as a reg rule applied to the element?
# [18:12] <dael> sylvaing: I think yes. It would be surprising if rule work one way inside a keyframe and different outside
# [18:12] <dael> dbaron: One complication here.
# [18:12] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:12] <Zakim> + +1.425.463.aaee
# [18:13] <dael> dbaron: The way anmations work is that you animate each prop sep. So if you have 0% prop that spec both prop, but a 50% that's only 2 prop, you animate the first as if it's only 50% and the second from 0% to 100%. One model to treat this is the keyframe is a style rule
# [18:13] <dael> sylvaing: I believe this is what authors think happens
# [18:14] <dael> dbaron: Maybe. It produces weird results in that case. If you're anim font size in em and you're doing something else in em units in the keyframe. You'd do the em units at 0 against 1em and 3 against 3em.
# [18:14] * Joins: tantek (~tantek@public.cloak)
# [18:14] <dael> sylvaing: I don't think it's ness. weird. If you're animating the width of something and the container is changing width, they'llin teract.
# [18:15] * Joins: smfr (~smfr@public.cloak)
# [18:15] <dael> sylvaing: I agree that if you think of animations as each prop in it's own keyframe, then I think current makes sense, but I'm not convinced that's how authors think about it. The keyframes are like a selector. It's a rule with a bunch of prop that aplly together. so it's surprising if font size is 16px and use 2em it's different if you move within a keyframe
# [18:16] <dael> dbaron: Maybe. I'm curious what others think.
# [18:16] <dael> sylvaing: Me too. If folks like leaverou are on the call that would be great.
# [18:16] <dael> smfr_: Anything about how the children of things are being animated?
# [18:16] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
# [18:16] <dael> dbaron: Animations do affect the computed value
# [18:16] <dael> smfr_: So it would make sense for em size to be affected by font size.
# [18:16] * tantek notes that children of things tend to be quite animated.
# [18:17] <dael> dbaron: That's not the question. It's em size inside the keyframe itself.
# [18:17] <dael> smfr_: I think that if inheret works I think em size would. I'm not sure I understand the implications of your example.
# [18:17] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:17] * leaverou LOL tantek
# [18:17] * tantek leaverou :)
# [18:17] <dael> smfr_: It seems when you're doing em size in a 50 keyframe, it seems you would pick half way between 0 and 100
# [18:17] <dael> dbaron: WE need an order to resolve prop dependant cycles in order to resolve animations prop in correct order
# [18:18] <dael> smfr: Isn't that true of style positions anyway?
# [18:18] <dael> dbaron: Maybe. We'd need to explicitly have code to know that in this case. We don't now.
# [18:18] * fantasai is super confused
# [18:18] * leaverou is too
# [18:18] * bkardell_ is also confused
# [18:19] * tantek apologizes for the confusion
# [18:19] <dael> dbaron: I think the model...keyframes are a bit weird because you only use the stuff out of them that was spc in them. Prop not spec in the keyframe aren't overridden by the anmatioin so they're diff from the rest of the cascade
# [18:19] <dael> smfr: So if I animate the font size and have stuff outside in em it's not effected?
# [18:20] <dael> dbaron: That's effect. Keyframes are diff from rest of cascade because it matters what's spec or not that doesn't normally matter. it effect if the animation choose to overide during that period of time
# [18:20] * leaverou Some code showng the issue we're trying to decide about would be useful, since so many here are lost.
# [18:20] * Joins: smfr_ (~smfr@public.cloak)
# [18:20] <dael> dbaron: Esp if you have mlti animations running.
# [18:20] <bkardell_> dbaron: I agree that is weird
# [18:20] <dael> plinss: It looks like there's a lot of people lost. Is there an ex we can put in IRC
# [18:20] <dael> sylvaing: WE can do the one in the thread.
# [18:20] <dael> dbaron: A simple is which.
# [18:20] <sgalineau> #a { animation: a; font-size: 16px; }
# [18:20] <sgalineau> @keyframes a { 0% { font-size: 32px; text-indent: 2em } }
# [18:21] <sgalineau> does the font-size: 32px inside the keyframe change the value of
# [18:21] <sgalineau> text-indent (and make it 64px rather than 32px)?
# [18:21] <dael> Rossen_: So if we have font which is animating at 1/3, let's say 30% from 2em to 1em
# [18:21] <Rossen_> 2 > 1 > 3
# [18:21] <dael> Rossen_: And to the 100% is to 3em. It goes 2 to 1 to 3.
# [18:21] <sgalineau> original thread http://lists.w3.org/Archives/Public/www-style/2014Jul/0297.html
# [18:21] <leaverou> if font-size in the animation supersedes the one in the rule, I'd expect it would also apply to ems. OTherwise it would be super confusing
# [18:21] <dael> Rossen_: And then we have animatable which is in em which goes the opposite and snaps on the 1/3 which is in the middle of the 2 to 1 animation of the font.
# [18:21] <sgalineau> leaverou: right.
# [18:22] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:22] <dael> Rossen_: So the q is, what would be the resolution at the 30% of the prop that's animating in em if the font is being animated from 2 to 1 in the same time
# [18:22] <dael> Rossen_: dbaron Is that the right rep of your point?
# [18:22] <sgalineau> leaverou: i think authors expect keyframe rules to apply like other rules. in practice, it's as if each prop gets its own @keyframes rule
# [18:22] <dael> dbaron: I didn't follow
# [18:22] <dael> fantasai: Can you type it in CSS code?
# [18:23] * Joins: smfr (~smfr@public.cloak)
# [18:23] <dael> plinss: Are you typing, Rossen_ ?
# [18:23] <dael> Rossen_: Yes.
# [18:23] <bkardell_> sgalineau: FWIW, that is what I would expect as an author :)
# [18:23] <dbaron> @keyframes a { 0% { font-size: 32px; width: 10em } 50% { width: 15em } 100% { font-size: 64px; width: 20em} } #elem { animation: a linear 5s; font-size: 16px }
# [18:23] <dael> dbaron: I'm typing a diff ex as well
# [18:23] * fantasai finds the agenda+ email finally: https://lists.w3.org/Archives/Member/w3c-css-wg/2014JulSep/0058.html
# [18:24] <leaverou> I think if the link between font-size and ems is broken, this is going to be very confusing
# [18:24] * smfr fantasai: agenda is in the /topic
# [18:24] * plinss fantasai: go it
# [18:24] * plinss fantasai: got it
# [18:24] <leaverou> so I'd expect em to animate as the font-size is animating, as well as animating from 2 -> 3
# [18:24] <dael> sylvaing: So in dbaron ex I would expect width to be 120. At 50% the font would be between 32 and 64, 15x48, I guess?
# [18:25] <dael> sylvaing: at 100% 20x64
# [18:25] <dael> dbaron: What about if the animation had 2 running, low afft font, upper affecting width
# [18:25] <dael> fantasai: I think yes. I think at each point in time take the combo of all rules nad interpolate as needed.
# [18:25] <dael> dbaron: That gets really complicated.
# [18:26] <leaverou> dbaron: To understand or to implement?
# [18:26] <dael> sylvaing: What's more complicated for author? Combine them or think as each being split into logical keyframe rules? It gets complicatedi n both directions. It's complex enough, but thinking of each property your animating getting a logical keyframe is a bit
# [18:27] <dbaron> @keyframes a1 { 0% { font-size: 32px } 100% { font-size: 64px } } @keyframes b { 0% { width: 10em } 50% { width: 15em } 100% { width: 20em} } #elem { animation: a linear 5s, b linear 8s; font-size: 16px }
# [18:27] <dael> sylvaing: So we're 25 minutes in. If it needs more email discussion, that's fine. Like TabAtkins I'm in favor of creating keyframe rules like @ rules to min surprizes
# [18:27] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:27] * leaverou thanks fantasai :)
# [18:27] <dael> fantasai: leaverou asked if it's complicated to understand or impl?
# [18:27] <dael> dbaron: I'm pretty sure it's complicated it implement. I think it's also hard to understand
# [18:27] <dael> fantasai: I think anything else is hard to understand, but I can't speak to impl
# [18:28] <dael> smfr: I think this is a fix for something that isn't encountered much. leaverou case witht eh border shorthand is a more common thing to talk about
# [18:28] <bkardell_> +1, I can't actually see another way that is more intuitive
# [18:28] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [18:28] * Joins: darktears (~darktears@public.cloak)
# [18:29] <dael> plinss: Let's see if we can wrap up. Back to dbaron first ex. You're animating font size in first and last, but not middle, but doing width in all. So over the whole animating your changing the font size, so I don't see why the em size isn't changing.
# [18:29] <dael> dbaron: I think current is you apply each rule and you extract values
# [18:29] <leaverou> +1 to plinss
# [18:29] <dael> plinss: So at 50% you're appling the ful the set width, but the other keyframes are still involved
# [18:29] <Rossen_> @keyframes a {0%{font-size: 20px; width: 10em} 33%{ width: 20em } 66%{font-size: 20px;} 100%{font-size: 30px; width: 30em}}
# [18:29] <dael> sylvaing: So then the animtiong, we're not animating computed values
# [18:29] <dael> dbaron: We're doing it, but where and when do computed values come from?
# [18:29] * Joins: smfr_ (~smfr@public.cloak)
# [18:30] <dael> fantasai: I understand better. We have a missing font size in the middle keyframe. One option is to compute from the other keyframes. The other is to take it from the style rule without the animation because in this keyframe we weren't given a value
# [18:31] <dael> dbaron: I don't think it's that simple. You have to decide if the base incl other animations or not. And if you try and inc things from other animations in the base value, you need to consider when and that can make animations jump in odd ways.
# [18:31] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:31] * smfr_ is now known as smfr
# [18:31] * hober http://sherri9.typepad.com/.a/6a01157142e48a970c01347fef07ac970c-pi
# [18:31] <dael> fantasai: I think the two things that make sense is you interpolate whatever is missing and do your computations from there. Or in a given animation you want to have a value for every prop mentionened and anything missing comes from the unanimated state.
# [18:31] * bkardell_ lolz
# [18:31] <leaverou> IMHO the 2nd option is sure to cause a lot of WTFs…
# [18:32] <dael> fantasai: things that don't take the value from the current state seems confusing.
# [18:32] <dael> sylvaing: So you're saying animations don't influence eachother
# [18:32] <dael> fantasai: Well, we should take all the rules, apply the cascade and do the animations like that.
# [18:33] <dael> sylvaing: So if A is doing font size and B is doing width in em, you're saysing that B is based on the width before anmation, but if width is together with font size, the width is effected during the animation
# [18:33] * dbaron didn't follow what fantasai said
# [18:33] * Joins: shorton (~shorton@public.cloak)
# [18:34] <dael> fantasai: I think that' straightforward to understand. I thinkt he first is better, but if it's not othen used, it's fine. I don't know how to have the animations rules interact in a different way from taking all the values and interpolating. I understand A and B, but you're saying there's other more complex options
# [18:34] * leaverou observes we’ve spent half the call on this item
# [18:34] * sgalineau your observation is ACCURATE
# [18:34] <dael> fantasai: A is take all the rules that apply from all animations at a given time and iterpolate. B is if you have an animation that's missing values from keyframes, grab them from non-animated state.
# [18:34] * Joins: smfr_ (~smfr@public.cloak)
# [18:34] <dael> dbaron: I think there are other options like if you do one at a time from lowest to highest.
# [18:35] <dael> sylvaing: Okay. WE go back to the ML.
# [18:35] * leaverou does not understand how anybody would support B. It's completely unexpected and confusing.
# [18:35] <dael> fantasai: It's nice to have a summary of the options.
# [18:35] * bkardell_ is pretty sure we can spend entire call on this item and still not resolve well
# [18:35] <bradk> If Width is not affected by font-size during the animation, does it jump at the end of the animation?
# [18:35] <dael> sylvaing: One more q. dbaron in your ex what would it request the animation frame to return. If I try and get the use values
# [18:35] <dael> dbaron: That just gets your callback at a certain time
# [18:35] <dael> sylvaing: So would you expect it any different?
# [18:35] <sgalineau> s/sylvaing/Rossen
# [18:36] <dael> rossen: The way you would resolve the callback vs the two animation lines? In your second example.
# [18:36] <dael> dbaron: Okay.
# [18:36] <dael> Rossen_: In it if you req animation as, say 4sec in B, which is about 50%
# [18:36] <dael> Rossen_: What would you expect the use value for width to be?
# [18:37] <dael> dbaron: That's what we're trying to decide. Basic options are if it's based on...
# [18:37] <dael> Rossen_: What would your impl do today?
# [18:37] <dael> dbaron: 15em x 16px
# [18:37] <dael> dbaron: And I think that might be interop
# [18:37] <dbaron> I think
# [18:38] <dael> Rossen_: I wouldn't expect a decision that would conteract too much something that's interop. I think there's content that depends on that.
# [18:38] <leaverou> with that logic, non-animatable properties being dropped from keyframes is also interoperable, but we resolved against it
# [18:38] <dael> plinss: I hear you, but if this is underspec, we may want to fix.
# [18:38] <dael> Rossen_: Sounds fair, but let's not ignore that.
# [18:38] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:38] <dael> plinss: If everyone is interop, maybe we have to live with it. Can someone write up a straightforward example for the ML?
# [18:39] <dael> sylvaing: I can start a new thread with the options we've discussed and dbaron can exland
# [18:39] <dael> plinss: Did we get to the border issue?
# [18:39] <dael> dbaron: I think the border issue is the same, but involves non-animatiable prop
# [18:39] <dael> dbaron: So this is the border issue simplified.
# [18:39] * Joins: smfr (~smfr@public.cloak)
# [18:39] <dael> Topic: Specifying options for scrollIntoView()
# [18:40] <dael> plinss: Who wants to talk on this one. Do we have TabAtkins?
# [18:40] <dael> fantasai: No.
# [18:40] <dael> dbaron: I might be able to talk on it, but TabAtkins recently responded. Let me see.
# [18:40] * sgalineau animation: computed-value-issue 2100s infinite;
# [18:40] <dael> dbaron: So. There's something in the CSSOM spec that doesn't make sense and we want to impl that thing so we need to have it make sense. I think. Am I changing topic here?
# [18:41] <dael> dbaron: Maybe. This is a slightly different thread. This isn't the one I asked. I'm commenting on the "and related" part, but I don't know we'll get far without TabAtkins and zcorpan
# [18:41] <dael> plinss: Want to come back to it?
# [18:41] <dael> dbaron: I guess, but we'll have something impl before than
# [18:41] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:41] <dael> plinss: So is there a concrete prop?
# [18:42] <dael> dbaron: There was, but TabAtkins said he doesn't like it, but not on the public list.
# [18:42] <dael> plinss: We'll aim for progress on the ML>
# [18:42] <dael> Topic: Flexbox and Overflow
# [18:42] <dael> plinss: Can we do this without TabAtkins ?
# [18:43] <dael> fantasai: I'm here, but I don't know if I can do it. Basically the issue is that we normally have the overflow, you can't scroll to the start direction, just the end if it overflows. If we're aligning we go to the end side.
# [18:43] <dael> fantasai: So with flex box should that be flex direction relative instead of writing more
# [18:43] <dael> dbaron: And if you use a ??keyword theyr'e the same thing
# [18:43] <dbaron> s/??/*-reverse /
# [18:44] <dael> Rossen_: And writing mode vs flex direction, fantasai hit the point. I agree with TabAtkins that if we're using flex direction as the origin os start and end for flow, what Chrome does today makes sense. If we don't IE and Firefox makes snes. For impl from our point of view it's easy one way or the other, but we have to decide on pref.
# [18:44] * Joins: smfr_ (~smfr@public.cloak)
# [18:45] <dael> fantasai: I think...I'm leaning toward writing mode relative and take into acocunt content alignmenet and scroll in alignment direction. Reverse should be ordering and page should layout as before, but I haven't thought much on it
# [18:45] <dael> Rossen_: That wouldn't help in the overflow case.
# [18:45] <fantasai> s/and take/maybe take/
# [18:45] <dael> Rossen_: So take this to the ML?
# [18:45] <dael> fantasai: I think so.
# [18:46] <dael> Topic: Ruby
# [18:46] <fantasai> There are three issues I would like the CSSWG to review and approve:
# [18:46] <fantasai> 1. Inlinizing rules http://lists.w3.org/Archives/Public/www-style/2014Jul/0028.html
# [18:46] <fantasai> 2. Floats inside ruby http://lists.w3.org/Archives/Public/www-style/2014Jul/0392.html
# [18:46] <dael> fantasai: I sent a mail earlier about 3 issues in Ruby.
# [18:46] <fantasai> 3. Bidi of ruby http://lists.w3.org/Archives/Public/www-style/2014Jul/0191.html
# [18:46] <dael> fantasai: First one is inlinizing.
# [18:46] * smfr_ fantasai we can’t hear you
# [18:46] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:46] * smfr_ is now known as smfr
# [18:46] <Zakim> -[IPcaller.a]
# [18:46] <fantasai> Issue is inlinizing rules
# [18:46] * trackbot doesn't understand that ISSUE command.
# [18:47] <fantasai> probably someoine can just read that email
# [18:47] * sgalineau confused trackbot is confused
# [18:47] * Rossen_ trackbot, what DO you understand?
# [18:47] <trackbot> Sorry, Rossen_, I don't understand 'trackbot, what DO you understand?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
# [18:47] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0028.html
# [18:47] <Zakim> +[IPcaller]
# [18:48] <dael> fantasai: So bidi is an inline time and you break between lines so it would be easy for a ruby space to contain a block element but it's bad because you can't break across lines prop. If you stil a block level thing inside a line element, you have split behaviour. But ruby structures are complicated.
# [18:48] <dael> fantasai: So to deal with this, which seems to have no use case, I added a line saying if you have block level, you add it to inline level.
# [18:49] <dael> fantasai: I wanted to check with the WG if that makes sense or if you want to do something different
# [18:49] <fantasai> s/add it/change its computed display type/
# [18:49] <dael> plinss: For Ruby that makes snese to me. Any other opinions?
# [18:49] <dael> plinss: I guess not.
# [18:50] <dael> fantasai: Related, If you have in your annotation a forced line break char. the white space automatically gets collapsed bc/ I didn't know what to do to linebreak the annotation, but not hte whitespace. I can revist that if there's a more useful behaviour
# [18:50] * Joins: smfr_ (~smfr@public.cloak)
# [18:50] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0392.html
# [18:50] <dael> fantasai: The next issue was floats inside ruby. One option is they go, pass up to the containing block. Or we ignore float.
# [18:51] <dael> fantasai: TabAtkins pref the first. The goal is to make them as much like inlines as practical.
# [18:51] <dbaron> I think it makes sense to pass them up to the containing block.
# [18:51] <dael> SteveZ: Floats as an alignment issue. it says it can't be before the first thing. Would that make s difference in this case?
# [18:51] <dael> fantasai: I'm not sure. It would be aligned to the linebox. It shouldn't be higher than top of line box, right?
# [18:51] <dael> dbaron: Yes.
# [18:51] <dael> SteveZ: Cool.
# [18:52] <dael> RESOLVED: Floats are passed up through Roby to the containing block
# [18:52] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0191.html
# [18:52] <dael> s/Roby/Ruby
# [18:52] <dael> fantasai: Next is bidi. There are two constraints from ruby. They need to be contiguous. Ruby anotations must stay with this bases.
# [18:53] * leaverou thought s/a/b substitutions don't work without final slash. Has this been fixed?
# [18:53] <dael> fantasai: Simmiplist is to force bidi isolation which means they can't be split up. The rule for ordering is use the direction prop of their container.
# [18:53] <dael> fantasai: Is there any comments? Want to think more? Does that seem fine?
# [18:53] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:53] <dael> plinss: Anyone?
# [18:53] <fantasai> http://dev.w3.org/csswg/css-ruby/#bidi
# [18:54] <dael> SteveZ: If I wanted to split I can break Ruby into chunks?
# [18:54] <dael> fantasai: Yeah.
# [18:54] <dael> dbaron: Does bidi use the direction of the prop? Is there direction associated?
# [18:54] <dael> fantasai: Yes. If you are doing odd things in Ruby with bidi and you're not tagging with correct dir attr things won't look good
# [18:55] <dael> dbaron: But only if you're mixes inside Ruby.
# [18:55] <dael> fantasai: Basically, if the Ruby element doesn't match the element, it'll go bad.
# [18:55] * Joins: smfr (~smfr@public.cloak)
# [18:55] <dael> SteveZ: So if you're annotating Latin with Arabic, I should be careful?
# [18:55] <dael> fantasai: Yeah. I think that's reasonable. I think you'd need to tag tht even if it wasn't Ruby.
# [18:55] <dael> plinss: Okay.
# [18:56] <dael> plinss: Anything else on Ruby?
# [18:56] <dael> fantasai: Re-wrote whitespace handling. No one was interested on the list. If people want time, that's fine, but I think we need a new WD
# [18:56] <dael> Rossen_: Yes, we do.
# [18:56] <dael> plinss: before a new WD?
# [18:56] <dael> Rossen_: No. You can do a new WD
# [18:56] <dael> plinss: This is just a standard pub of a new WD?
# [18:57] <dael> fantasai: Yep. No where near a LC.
# [18:57] <dael> plinss: So any obj to a WD?
# [18:57] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [18:57] <dael> RESOLVED: New WD for Ruby
# [18:57] <dael> fantasai: Can a staff contact help me with that tomorrow, or all they all off?
# [18:57] <dael> fantasai: Okay. I'll send it to Sheppard.
# [18:57] <dael> plinss: You might CC Bert.
# [18:57] <Zakim> - +1.425.463.aaee
# [18:57] <dael> fantasai: Okay. Thanks.
# [18:57] <dael> Topic: Renaiming gray()
# [18:57] * fantasai nice. Good timebox
# [18:58] * sgalineau fifty-shades()
# [18:58] * Rossen_ it is fitty-shades()
# [18:58] * fantasai is pretty sure CSS percentages allow for more than fifty shades
# [18:58] <dael> leaverou: The thing is in CSS level 4 there's gray() that goes from 0 to 100% which is black to white. I suggested it should rename to white or black since it's strange that gray(100%) is white.
# [18:58] <leaverou> http://lea.verou.me/2014/07/an-easy-notation-for-grayscale-colors/
# [18:58] <leaverou> https://docs.google.com/forms/d/1pp3RY-A4MAs7b-gmqFx6bKn52_G_WLoPFkV0vueiWP4/viewanalytics
# [18:59] * Joins: rhauck (~rhauck@public.cloak)
# [18:59] <dael> leaverou: I also posted a poll (above) with 246 responces and surprisingly mostly people wanted rgb() with 1 arg or rgba() with 2 arg.
# [18:59] <dael> leaverou: It seems that was concensus, which I find strange since the others are more understandable, but this is what authors liked.
# [18:59] <leaverou> https://docs.google.com/spreadsheets/d/1XJU1jOLb-6ifvkUqK1Y_bsHx9r09aWApce18SkWryFc/edit#gid=166170944
# [18:59] <dael> leaverou: If you want details, they'r ein the spreadsheet above
# [18:59] * Joins: smfr_ (~smfr@public.cloak)
# [19:00] <dael> leaverou: There's a lot of other because originally there was rgb() with 1 or 2 arguements, but I changed it so those votes became other. If you count the other votes, it's even larger.
# [19:00] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [19:00] * Joins: lmcliste_ (~lmclister@public.cloak)
# [19:00] <dael> plinss: It does follow our pattern of repeating missing arguements.
# [19:01] <dael> ???: I also like the rgb/rgba(). It looks more familair.
# [19:01] <MaRakow> s/???/MaRakow
# [19:01] <dael> SteveZ: There question is would they expect it for the other color fucntions? That's more difficult
# [19:01] * Parts: shorton (~shorton@public.cloak) (shorton)
# [19:01] <dael> SteveZ: If I do different colors than rgb, would they still want one element in the gray direction
# [19:01] * sgalineau on the other hand, shorter # values and shorter rgb() values will do different things? not sure if that matters.
# [19:01] <Zakim> - +1.603.821.aacc
# [19:01] * fantasai notes the spreadsheet is locked
# [19:02] <dael> leaverou: I'm not sure. Like a sort with one arguement? I saw one comment, but only that.
# [19:02] * MaRakow #7 == #777 == #777777 ?
# [19:02] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [19:02] <leaverou> s/Like a sort/Like hsl()/
# [19:02] <dael> fantasai: I think that makes sense. The rgb to get gray you write 50% three times and you're short handing. For HSL gray isn't 50% x3. I think it makes sense for RGB, but not HSL.
# [19:02] <dael> SteveZ: There's where I was coming from. I can see people asking for it.
# [19:03] <dael> leaverou: Many suggested what MaRakow suggested which is repeated single digit text values.
# [19:03] * fantasai can't remember why we rejected 2-digit hex
# [19:03] <dael> SteveZ: It certainly makes sense, I was worried we're doing a precedent.
# [19:03] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [19:03] * Joins: liam (liam@public.cloak)
# [19:03] <TabAtkins> No way to add alpha
# [19:03] * Joins: lmclister (~lmclister@public.cloak)
# [19:03] <dael> leaverou: In HSL arguements aren't repeated so it's not the same pattern. HSL 50, 50, 50 means nothing.
# [19:03] <dael> SteveZ: I understand.
# [19:03] * MaRakow #78 == #7778 == #77777788?
# [19:03] <fantasai> TabAtkins: 4-digit hex ?
# [19:04] <dael> plinss: So I'm not hearing obj to adopting rgb()/rgba()
# [19:04] <dael> ??: I think that's useful for existing authors, but for new people it's not intutive.
# [19:04] <TabAtkins> Right, no way to do gray hex with alpha.
# [19:04] * Rossen_ #78 == #7788 == #777888 :)
# [19:04] <TabAtkins> 4 digit hex is adjust rgba
# [19:04] <dael> ??: I'm wondering if we could have black with one arguement that's an alias. Are we restircted to picking one?
# [19:04] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [19:04] <fantasai> TabAtkins, ????
# [19:04] * Joins: smfr (~smfr@public.cloak)
# [19:04] <dael> leaverou: I agree. I think rgb is the least readable.
# [19:05] * hober http://www.paperlinks.org/wp-content/uploads/2014/02/maybe.gif
# [19:05] <dael> MaRakow: I think they're seeing it as an abbv of what they've been doing for gray. It's not the most readable.
# [19:05] * fantasai thinks ?? has a good point
# [19:05] * fantasai isn't sure who ?? is tho
# [19:05] <dael> leaverou: Any reason we can't have both?
# [19:05] * fantasai :)
# [19:05] <MaRakow> s/MaRakow/???
# [19:05] <dael> plinss: Black wouldn't be b/c it's the opposite, but white.
# [19:05] <dael> leaverou: Black got the second most votes.
# [19:05] * fantasai thinks we need ranked choice here, if we didn't have gray, would those ppl vote white or black?
# [19:06] <dael> ??: I think with black it's the opposite of RGB. If you're doing 255 you'd expect the opposite.
# [19:06] <dael> plinss: I wouldn't want opposite directions.
# [19:06] <dael> plinss: So I think we expect single values for rgb and 2 for rgba.
# [19:06] <dael> ??: Maybe for black and white we accept only single values.
# [19:06] * fantasai too bad choosing the right answer here wasn't black & white :)
# [19:06] <dael> leaverou: If we do black, would that be aspecial value for print?
# [19:06] * Quits: smfr_ (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [19:07] <dael> plinss: I think colors would need to be in the same space unless we're spec doing print.
# [19:07] * sgalineau if you give people enough options it turns out they might choose something weird
# [19:07] <Zakim> -hober
# [19:07] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) ("Page closed")
# [19:07] <dael> s/??/bkardell
# [19:07] <Zakim> -SylvaIng
# [19:07] <dbaron> s/bkardell/BradKemper/
# [19:07] * Joins: bradk (~bradk@public.cloak)
# [19:07] <Zakim> -SteveZ
# [19:07] <Zakim> -adenilson
# [19:07] <Zakim> -dbaron
# [19:07] <dael> RESOLVED: accept rgb() with single values and rgba() with 2 values and keep exploring other values
# [19:07] <Zakim> -smfr
# [19:07] <Zakim> -BradK
# [19:07] <Zakim> -antonp
# [19:07] <Zakim> -SimonSapin
# [19:07] <Zakim> - +1.240.421.aabb
# [19:07] <Zakim> -Lea
# [19:07] <Zakim> -Rossen_
# [19:07] <dael> plinss: Thanks everyone.
# [19:07] <Zakim> -plinss
# [19:07] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [19:07] * Quits: AH_Miller (~mike@public.cloak) ("")
# [19:08] <Zakim> -Stearns
# [19:08] <Zakim> -alex_antennahouse
# [19:08] * Joins: AH_Miller (~mike@public.cloak)
# [19:08] <Zakim> -MaRakow
# [19:08] <Zakim> - +1.631.398.aadd
# [19:08] <Zakim> -[IPcaller]
# [19:08] * leaverou sgalineau: In my brief tenure as a graphic designer, I noticed that clients always voted for the worst of the logos they were presented with :P
# [19:08] <Zakim> -dael
# [19:08] * Quits: AH_Miller (~mike@public.cloak) ("")
# [19:08] <sgalineau> leaverou: in my tenure as a US resident following primary elections, I noticed the craziest often wins
# [19:08] * Quits: dael (~dael@public.cloak) ("Page closed")
# [19:08] * Parts: bradk (~bradk@public.cloak) (bradk)
# [19:09] <MaRakow> Actually thinking more, probably #78 == #787878 would make more sense, rather than #77777788
# [19:09] <MaRakow> maybe
# [19:09] <fantasai> yes
# [19:09] <fantasai> The double digit should be a unit imo
# [19:09] <leaverou> MaRakow: the reasoning against these was that #xyz expands by digit, not by repetition
# [19:09] <leaverou> so inconsistency
# [19:10] <fantasai> it's 3 values, it kinda has to
# [19:10] <SimonSapin> leaverou, http://www.commitstrip.com/en/page/16/ ?
# [19:10] <fantasai> repeating wouldn't make any logical sense
# [19:10] <fantasai> hm
# [19:11] <MaRakow> yeah, i'm just thinking out loud. haven't really looked at this before
# [19:11] * fantasai neither, really..
# [19:11] <leaverou> since the call ended and people are still here
# [19:11] <leaverou> I was wondering…
# [19:11] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [19:12] <leaverou> is my proposal about numbers with a decimal point but no digits after it completely crazy at this point?
# [19:12] * fantasai whic?
# [19:12] <Zakim> -glenn
# [19:12] <Zakim> Style_CSS FP()12:00PM has ended
# [19:12] <Zakim> Attendees were +1.907.315.aaaa, Lea, dael, +1.240.421.aabb, plinss, glenn, SylvaIng, antonp, Stearns, +1.603.821.aacc, BradK, MaRakow, SteveZ, dbaron, SimonSapin,
# [19:12] <Zakim> ... alex_antennahouse, smfr, adenilson, Rossen_, +1.631.398.aadd, hober, +1.425.463.aaee, [IPcaller]
# [19:13] <glenn> rssagent, publish minutes
# [19:13] <leaverou> fantasai: this: http://lists.w3.org/Archives/Public/www-style/2014Jul/0568.html
# [19:13] <hober> I think we should just keep it as gray()
# [19:13] <glenn> +1
# [19:13] <antonp> grayshade
# [19:13] <hober> see e.g. Core Graphics' CGColorCreateGenericGray()
# [19:13] <antonp> or something similar
# [19:13] <hober> CGColorRef CGColorCreateGenericGray (CGFloat gray, CGFloat alpha);
# [19:14] <fantasai> gray(100%) is black?
# [19:14] <leaverou> it's white
# [19:14] <fantasai> oh
# [19:14] <fantasai> ~_~
# [19:14] <antonp> haha that's gonna confuse me a ton
# [19:14] <leaverou> gray(0%) is black
# [19:14] <fantasai> I know! Do a poll
# [19:14] <leaverou> lol
# [19:14] <fantasai> On your first instinct, gray(100%) is a) black b) white
# [19:15] <fantasai> If you get 90% answers on one answer, go with gray()
# [19:15] <fantasai> otherwise, I think it can be considered a failure
# [19:15] <fantasai> and you have to reject it and find a different name
# [19:15] <MaRakow> no strong opinion re: full stop after numbers. the author will still see a "jump" when editing the number in your example, 2.5 -> 2.0 -> 2.9, but i suppose that's probably a smoother transition than 2.5 -> invalid -> 2.9
# [19:15] <leaverou> MaRakow: See my next post
# [19:16] <leaverou> MaRakow: I got the numbers wrong in that example, exactly because of that reason
# [19:16] <fantasai> leaverou: Two comments
# [19:17] <fantasai> 1. I have no opinion of my own, but I would stand behind whatever dbaron concludes on the issue
# [19:17] <MaRakow> 2 -> 2.1 is a special case though -- this won't work so well for any other tenth edit, e.g. 2.8->2.9
# [19:17] <fantasai> 2. might be possible for the tools to work around this
# [19:17] <leaverou> MaRakow: It's basically any integer to any decimal value, not only to .1
# [19:17] <SimonSapin> fantasai: "On your first instinct, gray(100%) is a) black b) white", that could include c) "medium" gray
# [19:18] <fantasai> Also, 2.9->3.0 is going to break in any case
# [19:18] <hober> yeah, obviously gray(100%) is the grayest gray :)
# [19:18] <leaverou> fantasai: Yes, sometimes they do. E.g. dev tools usually support arrows to increment/decrement smoothly. But we can't depend on that
# [19:18] <MaRakow> i see. also agree this seems like something tools could solve
# [19:18] <liam> gray in colour is a shade rather than a tint usually, so 0% would be white
# [19:18] <fantasai> SimonSapin: an interesting point, but I think that makes it awkward to have the range 0%-200%
# [19:19] <SimonSapin> fantasai: of course. Which is why gray() doesn’t work IMO
# [19:19] <leaverou> still, it's fewer cases of breakage, for not much cost (unless I’m missing something) and I don't see how it could break existing code. In fact, it's 1 char less lookahead for the grammar
# [19:19] <astearns_> leaverou: I expect the proper place to fix your 1. issue is just in the tools
# [19:20] <astearns_> I don't see a benefit to allowing 1.px in a stylesheet
# [19:20] <leaverou> this argument be used against against ANY syntax improvement
# [19:20] <leaverou> s/be/could be
# [19:20] <astearns_> I see it more of an affordance than an improvement
# [19:21] <leaverou> it's also consistency with the other OWP technologies. JS allows it
# [19:22] * fantasai prefers black to white as well, fwiw
# [19:23] <liam> gray(200%) should be blue with pink stripes. Keep the b*stards guessing. Better is black(50%)
# [19:23] <liam> always knew you were really a goth :)
# [19:24] <leaverou> I would love black() even more if it also corresponded to device-cmyk(0,0,0,x) in print. Currently, I think printers convert RGB grays to use all the inks, which is super wasteful.
# [19:24] <liam> depends on the printer driver / RIP
# [19:25] <liam> some can do UCR too, and some not.
# [19:25] <leaverou> cheap home printers?
# [19:26] <SimonSapin> I don’t think it’s CSS’s job (in a feature not related to printing) to work around cheap printers being stupid
# [19:27] <SimonSapin> would it make sense to have both white() and black(), even though they’re technically redundant?
# [19:28] <leaverou> IIRC device-cmyk() is converted to rgb with the naïve conversion anyway, which I believe would convert grayscale colors to proper RGB grays. So we could define black() as a shortcut to device-cmyk(0,0,0,x). But then there’s no opacity… :(
# [19:29] <SimonSapin> should we have device-cmyka() too?
# [19:29] <leaverou> SimonSapin: Let’s turn all the CSS colors into functions!!!1!1 :P
# [19:29] <fantasai> device-cmyk(0,0,0,50%) is not 50% opaque?
# [19:30] <leaverou> fantasai: Not unless we implement some form of overprint
# [19:30] <leaverou> (which btw, is sorely needed)
# [19:30] * fantasai doesn't really understnad how device-cmyk() is supposed to work
# [19:31] <leaverou> it's just a different color space. 50%K is not semi-transparent, just like rgb(50%,0,0) isn't
# [19:31] <liam> k is black, not opacity
# [19:31] <SimonSapin> does alpha blending make sense in cmyk space?
# [19:32] <fantasai> I know, but if you're spilling black at 50% of its disperal, is it opaque?
# [19:32] <leaverou> SimonSapin: Why not? InDesign/Illustrator support it…
# [19:32] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [19:32] <fantasai> Like, 50% black on orange paper is somewhat orange, is it not
# [19:33] <fantasai> if you printed orange ink under it, that would be the same, no?
# [19:33] * fantasai is taking device-cmyk too literally
# [19:33] <leaverou> fantasai: If you overlay a 50% K div over an orange div, it wouldn't be affected unless you overprint
# [19:33] <leaverou> and there's no standard way of overprinting right now AFAIK
# [19:34] <leaverou> in practice, whwat would happen
# [19:34] <leaverou> is that the print formatter would create a "hole" in the orange div
# [19:34] <leaverou> and print the gray on top of it
# [19:34] <leaverou> you can see that a lot in magazines and stuff
# [19:34] <leaverou> when the designer forgot to overprint
# [19:34] <leaverou> and the letters aren't completely aligned
# [19:35] <leaverou> (because perfect alignment is rare)
# [19:35] <leaverou> and you can see the white "hole" underneath them
# [19:36] <leaverou> fantasai: ^^
# [19:36] * fantasai nods
# [19:38] <leaverou> fantasai: Does it make sense?
# [19:38] <fantasai> yes
# [19:38] <fantasai> I'm aware :)
# [19:38] <liam> 50% black on orange paper will show up as a pattern of tiny dots usually, like newsprint
# [19:38] <liam> (or on any other colour paper)
# [19:40] <leaverou> I believe print formatters implement their own proprietary overprint properties, or nothing at all (not sure about AH, but I believe Prince has a property for it)
# [19:40] <liam> printing inks used for commercial offset litho (the basis for CMYK) are opaque at around 80% depending on dot gain (how absorbent the paper is) but lower values are simulated by dots, and the lower colours show though the dots. Black is printed underneath.
# [19:40] <liam> well, you also need trapping support (avoiding sharp corners), and support for avoiding too much ink at any pixel
# [19:41] <liam> four-colour separation software may do some of that, and/or "preflight" software.
# [19:49] * Joins: glenn_ (~gadams@public.cloak)
# [19:53] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [19:55] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [19:55] * Joins: lmclister (~lmclister@public.cloak)
# [20:04] * Joins: glenn (~gadams@public.cloak)
# [20:07] * Joins: glenn__ (~gadams@public.cloak)
# [20:09] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:10] * Zakim excuses himself; his presence no longer seems to be needed
# [20:10] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [20:11] * Joins: glenn_ (~gadams@public.cloak)
# [20:11] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:13] * Joins: glenn (~gadams@public.cloak)
# [20:15] * Quits: glenn__ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:18] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:20] * Joins: glenn_ (~gadams@public.cloak)
# [20:23] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:28] <fantasai> shepazu: would you be the W3C Staff shepherd of a CSS Ruby publication for me, please?
# [20:30] * Joins: glenn (~gadams@public.cloak)
# [20:33] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:35] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [20:36] * Joins: lmclister (~lmclister@public.cloak)
# [20:45] * Quits: SteveZ (~SteveZ@public.cloak) ("Page closed")
# [20:54] * Joins: glenn_ (~gadams@public.cloak)
# [20:58] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [20:58] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [20:59] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:59] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [21:09] * leaverou is now known as leaverou_away
# [21:10] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [21:22] * Joins: glenn (~gadams@public.cloak)
# [21:24] <fantasai> krit: I'm guessing you meant text-indent rather than atext-indent?
# [21:24] <fantasai> https://dvcs.w3.org/hg/csswg/annotate/109c35c788f1/default.css#l113
# [21:24] * fantasai about to fix that
# [21:25] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [21:31] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [21:32] * Joins: lmclister (~lmclister@public.cloak)
# [21:32] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [21:32] * Joins: lmclister (~lmclister@public.cloak)
# [21:34] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [21:35] <krit> fantasai: not “a text-ident”? After linear-gradient at? :)
# [21:35] <krit> fantasai: typo :)
# [21:37] <fantasai> TabAtkins: Bikeshed seems to slurp up rather more issue than it should for <span class=issue> inside a paragraph.
# [21:37] * fantasai getting random text from the next line
# [21:38] <fantasai> into the issue index
# [21:46] * Joins: glenn_ (~gadams@public.cloak)
# [21:51] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [22:04] * Joins: rhauck1 (~rhauck@public.cloak)
# [22:05] * Joins: rhauck2 (~rhauck@public.cloak)
# [22:05] * Quits: rhauck1 (~rhauck@public.cloak) (Client closed connection)
# [22:09] * Quits: rhauck (~rhauck@public.cloak) (Ping timeout: 180 seconds)
# [22:12] * Joins: lmcliste_ (~lmclister@public.cloak)
# [22:12] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [22:20] * fantasai wonders if webreq is on vacation, too
# [22:25] <astearns_> fantasai: there's a publishing moratorium until Friday
# [22:27] * Joins: dbaron (~dbaron@public.cloak)
# [22:30] <fantasai> astearns_: Ah. Thanks :)
# [22:36] <shepazu> fantasai, I'll start it, and let Chris or Bert take over as they are available
# [22:36] <shepazu> fantasai, do you already have approval for publication tomorrow?
# [22:41] <fantasai> No, apparantly there's a moratorium, so it'd have to be Tuesday?
# [22:58] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [22:58] * Joins: rhauck (~rhauck@public.cloak)
# [22:58] * Quits: rhauck2 (~rhauck@public.cloak) (Client closed connection)
# [22:59] * Joins: lmclister (~lmclister@public.cloak)
# [22:59] * Joins: rhauck1 (~rhauck@public.cloak)
# [22:59] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [22:59] * Quits: rhauck (~rhauck@public.cloak) (Client closed connection)
# [22:59] <shepazu> fantasai, ready to go on Tuesday
# [22:59] * Joins: lmclister (~lmclister@public.cloak)
# [23:00] <shepazu> I put it in place, did a bit of cleanup (see email), and Denis will push it out on Ruby Tuesday
# [23:01] <Ms2ger> Isn't it funny how this still hasn't been automated?
# [23:05] <fantasai> shepazu: Thanks!
# [23:05] * fantasai supposes shepazu is right, Ruby should be published on Tuesdays.
# [23:06] <fantasai> Ms2ger: W3C's computer systems are antiquated.
# [23:06] <fantasai> Ms2ger: Ironic, given we're defining the bleeding edge of the web platform
# [23:06] <SimonSapin> fantasai: every Tuesday? :)
# [23:06] <fantasai> lol
# [23:06] <fantasai> No, just once in a Blue Moon
# [23:07] <Ms2ger> fantasai, that hasn't been W3C for a decade ;)
# [23:07] <fantasai> It has for CSS!
# [23:07] * fantasai wishes text justification bled less
# [23:08] <Ms2ger> Perhaps I should avoid snarky comments about the CSSWG in this channel :)
# [23:10] * fantasai not really sure what you're commenting on
# [23:10] <Ms2ger> Nothing
# [23:11] <Ms2ger> But I could be commenting on the general speed of the WG, say
# [23:11] <Ms2ger> But not tonight
# [23:12] * Ms2ger yawns
# [23:12] <fantasai> Hm, I think you misunderstand the phrase then.
# [23:12] <fantasai> It's nothing to do with speed.
# [23:12] <Ms2ger> No, I understand
# [23:12] <Ms2ger> I just like complaining :)
# [23:12] <fantasai> heh
# [23:12] <fantasai> you're in a channel of spec writers
# [23:12] <fantasai> if you're being imprecise with words, it will be noted =)
# [23:13] <Ms2ger> And hey, "antiquated" makes me think of the CSSWG, I can't help it ;)
# [23:13] * Ms2ger poofs
# [23:13] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:13] <fantasai> TabAtkins, krit: Just redid the styling for inline notes, thoughts?
# [23:14] <fantasai> http://dev.w3.org/csswg/css-flexbox/#cross-sizing
# [23:14] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [23:14] * Joins: lmclister (~lmclister@public.cloak)
# [23:14] <fantasai> TabAtkins: This one's less intrusive, so you can read the rest of the paragraph without having the note (which should be de-emphasized, if anything) jump at you
# [23:15] <fantasai> Ms2ger: Yeah, we're survivors from an older era.
# [23:15] <fantasai> The era before bug-tracking systems maybe
# [23:19] * leaverou_away is now known as leaverou
# [23:23] <TabAtkins> device-cmyk() has an optional alpha argument
# [23:23] * Joins: glenn (~gadams@public.cloak)
# [23:23] <leaverou> TabAtkins: really?!
# [23:25] <TabAtkins> Go read the spec!
# [23:25] <leaverou> lol, obviously :P It was an expression of surprise
# [23:28] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [23:29] * Joins: rhauck (~rhauck@public.cloak)
# [23:29] * Quits: rhauck1 (~rhauck@public.cloak) (Client closed connection)
# [23:34] * Joins: jcraig (~jcraig@public.cloak)
# [23:37] <TabAtkins> fantasai: No, I can't really read that. Green colorblind, yo.
# [23:37] <TabAtkins> It looks too similar to the black text.
# [23:38] <TabAtkins> fantasai: Also, example of it messing up on inline issues?
# [23:38] <TabAtkins> I bet I know what the problem is.
# [23:39] <TabAtkins> (It's lxml's stupid data model, which is dumb and I hate it.)
# Session Close: Thu Jul 31 00:00:00 2014

The end :)