/irc-logs / w3c / #css / 2012-10-30 / end

Options:

# Session Start: Tue Oct 30 00:00:00 2012
# Session Ident: #css
# [00:03] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 60 seconds)
# [00:03] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [00:03] * Quits: tomoyuki (~tshimizu3@public.cloak) (Ping timeout: 60 seconds)
# [00:08] * Joins: cabanier (~cabanier@public.cloak)
# [00:19] * Quits: isherman1 (~Adium@public.cloak) ("Leaving.")
# [00:29] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [00:37] * Joins: cabanier (~cabanier@public.cloak)
# [00:46] * Joins: SimonSapin (~simon@public.cloak)
# [01:09] * Joins: SimonSapin1 (~simon@public.cloak)
# [01:09] * Quits: SimonSapin (~simon@public.cloak) (Client closed connection)
# [01:11] * Quits: Kid (~Kid@public.cloak) (Client closed connection)
# [01:13] * Quits: SimonSapin1 (~simon@public.cloak) (Ping timeout: 60 seconds)
# [01:18] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [01:22] * Joins: yaso (~yaso@public.cloak)
# [01:22] * Quits: yaso (~yaso@public.cloak) (yaso)
# [01:25] * Joins: cabanier (~cabanier@public.cloak)
# [01:38] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [01:39] * Joins: cabanier (~cabanier@public.cloak)
# [01:39] * Joins: shepazu (schepers@public.cloak)
# [02:07] * Joins: isherman (~Adium@public.cloak)
# [02:38] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 60 seconds)
# [02:42] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [03:07] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [03:34] * Joins: glenn (~gadams@public.cloak)
# [03:54] * Joins: kensaku (~kensaku@public.cloak)
# [04:12] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [04:13] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [04:45] * Joins: Norbert (~standards@public.cloak)
# [04:54] * Quits: paul___irish (~paul___irish@public.irc.w3.org) ("ZNC - http://znc.sourceforge.net")
# [05:02] * Joins: paul___irish (~paul___irish@public.cloak)
# [05:31] * Quits: Norbert (~standards@public.cloak) (Ping timeout: 60 seconds)
# [05:37] * Joins: rotsuya (~rotsuya@public.cloak)
# [05:46] * Joins: Norbert (~standards@public.cloak)
# [06:19] * sylvaing_away is now known as sylvaing
# [06:27] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [06:30] * Quits: vhardy_ (~uid7483@public.cloak) (Client closed connection)
# [06:31] * Quits: boblet (~uid1921@public.cloak) (Client closed connection)
# [06:31] * Quits: isherman (~Adium@public.cloak) (Client closed connection)
# [06:31] * Quits: CSSWG_LogBot (~PircBot@public.irc.w3.org) (Ping timeout: 60 seconds)
# [06:31] * Quits: shans (~shans@public.irc.w3.org) (Ping timeout: 60 seconds)
# [06:32] * Joins: vhardy__ (~uid7483@public.cloak)
# [06:32] * Joins: isherman (~Adium@public.cloak)
# [06:32] * Joins: CSSWG_LogBot (~PircBot@public.cloak)
# [06:32] * Quits: leaverou_away (~leaverou@public.irc.w3.org) (Ping timeout: 60 seconds)
# [06:32] * Joins: boblet (~uid1921@public.cloak)
# [06:33] * Joins: shans_away (~shans@public.cloak)
# [06:33] * shans_away is now known as shans
# [06:33] * Quits: plinss (~plinss@public.irc.w3.org) (Ping timeout: 60 seconds)
# [06:33] * Quits: sylvaing (~sylvaing@public.irc.w3.org) (Ping timeout: 60 seconds)
# [06:34] * Joins: leaverou_away (~leaverou@public.cloak)
# [06:34] * leaverou_away is now known as leaverou
# [06:34] * Joins: plinss (~plinss@public.cloak)
# [06:34] * Joins: sylvaing (~sylvaing@public.cloak)
# [06:39] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [06:45] * Joins: yamaday (~yamaday@public.cloak)
# [06:45] * Quits: rotsuya (~rotsuya@public.cloak) (Ping timeout: 60 seconds)
# [06:49] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 60 seconds)
# [06:52] * Quits: Norbert (~standards@public.cloak) (Norbert)
# [06:55] * Joins: rotsuya (~rotsuya@public.cloak)
# [06:58] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
# [07:00] * Joins: glenn (~gadams@public.cloak)
# [07:06] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
# [07:19] * Joins: plh (plehegar@public.cloak)
# [07:20] * Joins: Norbert (~standards@public.cloak)
# [07:24] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
# [07:27] * Quits: Norbert (~standards@public.cloak) (Norbert)
# [07:27] * Joins: kensaku (~kensaku@public.cloak)
# [07:30] * Joins: plh (plehegar@public.cloak)
# [07:32] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [07:48] * Joins: SimonSapin (~simon@public.cloak)
# [07:55] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
# [07:59] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [08:00] * Joins: plh (plehegar@public.cloak)
# [08:08] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [08:14] * Joins: glenn (~gadams@public.cloak)
# [08:16] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
# [08:27] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [08:28] * Zakim excuses himself; his presence no longer seems to be needed
# [08:28] * Parts: Zakim (zakim@public.irc.w3.org) (Zakim)
# [08:30] * leaverou is now known as leaverou_away
# [08:30] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:30] * sylvaing is now known as sylvaing_away
# [08:31] * Joins: nsakai (~nsakai@public.cloak)
# [08:32] * sylvaing_away is now known as sylvaing
# [08:32] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [08:40] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [08:42] * Joins: nsakai (~nsakai@public.cloak)
# [08:43] * Joins: kensaku (~kensaku@public.cloak)
# [08:47] * Joins: stearns (~anonymous@public.cloak)
# [08:47] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [08:47] * Quits: kensaku (~kensaku@public.cloak) (Ping timeout: 60 seconds)
# [08:48] * Joins: stearns (~anonymous@public.cloak)
# [08:48] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [08:49] * Joins: dbaron (~dbaron@public.cloak)
# [08:49] * Joins: stearns (~anonymous@public.cloak)
# [08:50] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [08:51] * Joins: nsakai (~nsakai@public.cloak)
# [08:55] * Joins: SimonSapin (~simon@public.cloak)
# [08:55] * Joins: glenn (~gadams@public.cloak)
# [08:56] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [08:57] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [08:58] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [08:58] * Joins: SimonSapin (~simon@public.cloak)
# [08:59] * Joins: tokamoto (~tokamoto@public.cloak)
# [08:59] * Joins: kensaku (~kensaku@public.cloak)
# [08:59] * Joins: plh (plehegar@public.cloak)
# [09:00] * Joins: nsakai (~nsakai@public.cloak)
# [09:00] * Joins: kotakagi (~koichi_takagi@public.cloak)
# [09:00] * Quits: kotakagi (~koichi_takagi@public.cloak) ("Yaaic - Yet another Android IRC client - http://www.yaaic.org")
# [09:01] * Joins: kotakagi (~koichi_takagi@public.cloak)
# [09:01] * Quits: SimonSapin (~simon@public.cloak) (Client closed connection)
# [09:01] * Joins: dino (~dino@public.cloak)
# [09:01] * Joins: sakkuru (~sakih@public.cloak)
# [09:01] * Joins: Yune (~Yune@public.irc.w3.org)
# [09:01] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:02] * Joins: SimonSapin (~simon@public.cloak)
# [09:03] * Joins: Norbert (~standards@public.cloak)
# [09:03] * leaverou_away is now known as leaverou
# [09:03] * Joins: nsakai (~nsakai@public.cloak)
# [09:04] * Joins: rotsuya (~rotsuya@public.cloak)
# [09:04] * Joins: glazou (~glazou@public.cloak)
# [09:05] * Joins: mihara (~mihara@public.cloak)
# [09:05] * Joins: cabanier (~cabanier@public.cloak)
# [09:06] * Joins: drublic (~drublic@public.cloak)
# [09:06] * Joins: lmclister (~lmclister@public.irc.w3.org)
# [09:06] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:07] * Quits: sakkuru (~sakih@public.cloak) ("Leaving...")
# [09:07] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
# [09:07] * Joins: kazutaka (~yamamoto_kazutaka@public.cloak)
# [09:07] * Joins: sakih (~sakih@public.cloak)
# [09:08] * Joins: nsakai (~nsakai@public.cloak)
# [09:08] * Joins: antonp (~Thunderbird@public.cloak)
# [09:08] <Bert> ScribeNick: Bert
# [09:09] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:09] * Joins: yamaday (~yamaday@public.cloak)
# [09:10] * Quits: sakih (~sakih@public.cloak) ("Leaving...")
# [09:11] * Joins: nsakai (~nsakai@public.cloak)
# [09:12] * Joins: Rossen (~Rossen@public.cloak)
# [09:12] * Joins: Zakim (zakim@public.irc.w3.org)
# [09:12] * Joins: sakkuru (~sakkuru@public.cloak)
# [09:12] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:12] * Joins: mishida (~mishida@public.cloak)
# [09:13] * Joins: JohnJansen (~JohnJansen@public.cloak)
# [09:14] * Joins: nsakai (~nsakai@public.cloak)
# [09:14] * glazou (general discussion about agenda and I18N people unpingable)
# [09:14] <Bert> Topic: Before/after/head/foot/tail/start/end terminology
# [09:14] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:15] * Joins: arronei (~arronei@public.cloak)
# [09:15] * Joins: rhauck (~rhauck@public.irc.w3.org)
# [09:15] <Bert> fantasai: We have issue in writing mode spec about terminology.
# [09:16] <dbaron> http://dev.w3.org/csswg/css3-writing-modes/
# [09:16] * Joins: SteveZ (~chatzilla@public.cloak)
# [09:16] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [09:16] * Joins: jet (~jet@public.cloak)
# [09:16] * Joins: Rossen (~Rossen@public.cloak)
# [09:16] <dbaron> http://dev.w3.org/csswg/css3-writing-modes/#abstract-box
# [09:16] * Joins: nsakai (~nsakai@public.cloak)
# [09:17] <Bert> ... Two sets of terms, physical (top, left...) and flow-relative terms.
# [09:17] <Bert> ... Block axis and inline axis.
# [09:17] <Bert> ... Start/end is in inline axis
# [09:17] * Joins: knobuta2 (~knobuta2@public.irc.w3.org)
# [09:18] <Bert> ... line relative (line-left, line-over...)
# [09:18] <dbaron> s/line-over/over/
# [09:19] * Joins: evanli (~androirc@public.cloak)
# [09:19] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:19] <Bert> ... Old :before and :after are in document order.
# [09:19] <Bert> ... Flex can be in any axis.
# [09:20] <Bert> ... Speech have before/after. too.
# [09:20] * Joins: Shinji (shinji@public.cloak)
# [09:20] <dbaron> fantasai: longstanding issue about confusion figuring out which of start/before end/after were which. Sylvain also raised issue about confusion with :before and :after.
# [09:20] <Bert> howcome: We also need inside/outside for paged media.
# [09:20] <Bert> SteveZ: relative to spine of 2-page spread.
# [09:21] <Bert> fantasai: thead/tfoot similar to head/foot terms.
# [09:21] <Bert> ... But feedback on list was that it was confusing.
# [09:21] * Joins: nsakai (~nsakai@public.cloak)
# [09:22] <Bert> ... E.g., Japanese uses "line head" for start of line.
# [09:22] <Bert> howcome: N E S W ?
# [09:22] <Bert> fantasai: IN bidi, E/W would swicth. even more confusing.
# [09:23] <Bert> Rossen: prefix with box-?
# [09:23] <Bert> fantasai: Avoid too long words.
# [09:23] <Bert> ... Some places where these terms could be used:
# [09:24] * Joins: lstorset (~leif@public.cloak)
# [09:24] <Bert> ... grid start, margin start, start border radius...
# [09:25] <Bert> ... My latest idea: [lists many pairs]
# [09:25] * Joins: koji (~koji@public.cloak)
# [09:25] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:25] <Bert> SteveZ: When I first asked if Head/foot fit Japanese, I was told yes. Now it turns out it doesn't
# [09:25] <Bert> fantasai: It is somewhat inconsistent.
# [09:26] <Bert> SteveZ: That is the audience we target. has to be logical for them.
# [09:26] <arronei> before/after, pervious/next, lead/tral, ahead/behind, head/foot, above/below, fore/aft, ante/post, prior/next, front/rear, pre/post, early/late
# [09:26] * Joins: massimo_ (~chatzilla@public.cloak)
# [09:26] <arronei> s/tral/trail
# [09:26] * Joins: nsakai (~nsakai@public.cloak)
# [09:26] <Bert> fantasai: Grid is logical.
# [09:26] <Bert> bert: No, for me grid is physical.
# [09:27] <Bert> SteveZ: [something about DOM order]
# [09:27] <Bert> ... People learn the terms after a while.
# [09:27] * Joins: tantek (~tantek@public.cloak)
# [09:27] * Quits: lmclister (~lmclister@public.irc.w3.org) ("Page closed")
# [09:27] <Bert> ... Unless the termss are significantly better, there is not much reason to change.
# [09:28] * Joins: lmclister1 (~Adium@public.cloak)
# [09:28] <Bert> ... Head&foot seem not optimal for the intended audience.
# [09:28] <Bert> howcome: I keep mixing htem up.
# [09:28] <glazou> TabAtkins, glazou: no grid is logical
# [09:28] <Bert> ... Just arbitrary.
# [09:28] <Bert> SteveZ: It *is* arbtrary.
# [09:29] * Quits: rhauck (~rhauck@public.irc.w3.org) (Ping timeout: 60 seconds)
# [09:29] <Bert> howcome: Pre/post?
# [09:29] <Bert> SteveZ: : Still unclear it is blovk or line.
# [09:29] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:29] <Bert> TabAtkins_: I was convinced by before/after at first.
# [09:29] <Bert> glazou: It is not confusing for avg web designer
# [09:29] * Quits: evanli (~androirc@public.cloak) ("AndroIRC - Android IRC Client ( http://www.androirc.com )")
# [09:29] <Bert> howcome: I think it is.
# [09:30] <Bert> glazou: Pre/post means nothing.
# [09:30] <Bert> peter: :before coul be in line *or* block diretcion.
# [09:30] <Bert> glenn: I had to memorize, but then had no more pbs.
# [09:30] * Quits: tantek (~tantek@public.cloak) (tantek)
# [09:31] <Bert> howcome: 'block-start'/'block-end'
# [09:31] <Bert> sylvaing: Gets long for border radius
# [09:31] * Joins: nsakai (~nsakai@public.cloak)
# [09:31] <Bert> howcome: don't need it there
# [09:31] * sylvaing that was not me...
# [09:31] <stearns> s/sylvaing/arron/
# [09:31] * Joins: rhauck (~rhauck@public.irc.w3.org)
# [09:32] <Bert> SteveZ: I'm not convinced. All neutral words have the pb that they don't say block/line.
# [09:32] <Bert> ... It probably doesn't matter. As Glenn said. you memorize it.
# [09:32] <Bert> ... Add exra words is not wordth it.
# [09:33] <Bert> Bert: In the Box model I proposed using A, B, C, and D sides.
# [09:34] <Bert> fantasai: That doens't work well witht he grid.
# [09:34] <Bert> SteveZ: I'd just reverse to with before/after
# [09:35] <Bert> TabAtkins_: I'd prefer head/foot.
# [09:35] * Quits: massimo_ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [09:35] <Bert> SteveZ: All uses of before/after are in DOM order.
# [09:35] <Bert> glazou: We do this for 18n
# [09:36] <Ms2ger> s/18n/i18n/
# [09:36] <Bert> ... No consensus.
# [09:36] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
# [09:36] <Bert> ... So stick with before (for top) and after for (bottom), is that it?
# [09:37] * Joins: evanli (~androirc@public.cloak)
# [09:37] <Bert> SteveZ: Go back to before/after.
# [09:37] <Bert> koji: Proposal last May.
# [09:37] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:37] <dbaron> http://lists.w3.org/Archives/Public/www-style/2012May/1149.html has a resolution to change to head/foot
# [09:37] <Bert> ... It was resolved and raised again.
# [09:38] <Bert> sylvaing: webkit uses before/after
# [09:38] <Bert> TabAtkins_: (with prefixes)
# [09:38] <Bert> ... There is next to no usage of it, in our surveys.
# [09:39] <Bert> peter: No real user feedback
# [09:39] <JohnJansen> s/sylvaing/arronei
# [09:40] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [09:40] <Bert> koji: Talked to r12a and he said like stevez, if terms improved over before/after then OK, but head/foot didn't seem to improve.
# [09:40] * Joins: nsakai (~nsakai@public.cloak)
# [09:40] <Bert> TabAtkins_: If before/after are half acceptable, then why nor pre/post
# [09:40] <Bert> fantasai: Confuses with DOM order.
# [09:41] <fantasai> s/Confuses/before and after confuses/
# [09:41] <Bert> TabAtkins_: I think it is reasonable, in my attempts.
# [09:41] <Bert> glenn: If you use both XSL and CSS,
# [09:41] <Bert> ... new terms will be confusing.
# [09:41] <fantasai> [Tab and fantasai were talking about ease of wording spec prose]
# [09:42] <Bert> TabAtkins_: On the web almost no uses of the terms.
# [09:42] <Bert> SteveZ: Audience is not just web authors.
# [09:42] <Bert> peter: That argument isn't solving any pb.
# [09:42] * Joins: massimo (~chatzilla@public.cloak)
# [09:42] <Bert> SteveZ: I propose we agree to drop head/foot and leave open what the terms are going to be.
# [09:43] <glazou> dbaron: XSL FO won't be in Mozilla...
# [09:43] <dbaron> (in response to glenn)
# [09:44] <Bert> glazou: Steve's seems acceptable for now.
# [09:44] * Quits: evanli (~androirc@public.cloak) (evanli)
# [09:44] * Joins: tantek (~tantek@public.cloak)
# [09:44] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:44] * Joins: evanli (~androirc@public.cloak)
# [09:45] <Bert> REASOLVED head/foot are not the terms (revert earlier decision), that doens't say anything about other terms.
# [09:45] <Bert> s/REASOLVED/RESOLVED/
# [09:46] <Bert> fantasai: Some properties use line-relative direction.
# [09:46] <Bert> ... Text decoration, ruby should also.
# [09:47] <Bert> ... Should I use over/under there?
# [09:47] <fantasai> ... currently useing above/below
# [09:47] <Bert> SteveZ: In vertical, those terms don't make much sense.
# [09:47] * Joins: nsakai (~nsakai@public.cloak)
# [09:47] <JohnJansen> I think trackbot requires that the 'resolved' syntax be correct. so I'm re-resolving our non-resolution to be resolved...
# [09:48] <glenn> dbaron: never say never
# [09:48] <JohnJansen> RESOLVED: head/foot are not the terms (revert earlier decision), that doesn't say anything about other terms.
# [09:48] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:48] <Bert> Tab: over/under seems fine to me.
# [09:48] * Joins: rotsuya_ (~rotsuya@public.cloak)
# [09:48] <Bert> Peter: We alrady have over/under in text-deco, good to not add more terms.
# [09:49] <Bert> RESOLVED: Use over/under terms instead of above/below
# [09:50] <Bert> SteveZ: ascender/descender go "up" and "down"
# [09:50] * Joins: nsakai (~nsakai@public.cloak)
# [09:50] <Bert> ... rotated fonts
# [09:50] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:50] <Bert> Peter: Text rotation, what is over/udnder?
# [09:50] <Bert> fantasai: Stays on same side
# [09:51] * Joins: nsakai (~nsakai@public.cloak)
# [09:51] <Bert> Topic: CSS Transforms (continued from yesterday)
# [09:52] * Quits: rotsuya_ (~rotsuya@public.cloak) (Client closed connection)
# [09:53] * Joins: krit (~krit@public.cloak)
# [09:53] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17433
# [09:53] <Bert> Dirk: Issue about how do 3D transf in 2D context.
# [09:53] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [09:53] * Joins: cabanier (~cabanier@public.cloak)
# [09:53] <Bert> ... Do we need to specify it or is it obviousl, mathematically?
# [09:54] <Bert> s/obviousl/obvious/
# [09:54] <Bert> ... Can we ask the implementers?
# [09:54] * Quits: kazutaka (~yamamoto_kazutaka@public.cloak) ("CHOCOA")
# [09:54] <Bert> dino: Loking at last comment in the bug.
# [09:55] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:55] <Bert> ... Youre asking if we need to define what flatten means?
# [09:55] <Bert> dirk: Yes, is it not obvious enough?
# [09:56] <Bert> dino: No, I think it is not.
# [09:56] * Joins: nsakai (~nsakai@public.cloak)
# [09:56] <Bert> ... Rendering into 2D texture and that is composited.
# [09:56] <Bert> ... Perspective proeprty sets up te coord system.
# [09:57] <Bert> ... I think you should take an action to define it.
# [09:57] * Quits: Rossen (~Rossen@public.cloak) (Client closed connection)
# [09:57] <Bert> dbaron: Roc or somebody would know, I'm not the best person.
# [09:57] <dbaron> s/somebody/mattwoodrow/
# [09:57] <Bert> dino: Probably we all do the same thing, but still worth defining.
# [09:57] * Quits: glenn (~gadams@public.cloak) ("Leaving...")
# [09:58] <glazou> RRSAgent, this is Style
# [09:58] <RRSAgent> I'm logging. I don't understand 'this is Style', glazou. Try /msg RRSAgent help
# [09:58] <Bert> Dirk: It seems an implementation detail, but I'd like some doc that describes how it works.
# [09:58] <dbaron> trackbot, this is style
# [09:58] <trackbot> Sorry, dbaron, I don't understand 'trackbot, this is style'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
# [09:58] <Bert> dino: I can also take an action to try and write it up.
# [09:58] * dbaron Zakim, remind us in 8 hours to go home
# [09:58] * Zakim ok, dbaron
# [09:59] <Bert> ACTION dino: propose wording how you flatteen 3d subtree into normal CSS 2s rendering.
# [09:59] * trackbot noticed an ACTION. Trying to create it.
# [09:59] * RRSAgent records action 5
# [09:59] <trackbot> Created ACTION-515 - Propose wording how you flatteen 3d subtree into normal CSS 2s rendering. [on Dean Jackson - due 2012-11-06].
# [09:59] * Joins: Rossen (~Rossen@public.cloak)
# [09:59] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [09:59] <Bert> s/2s/2D/
# [09:59] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [09:59] * Quits: massimo (~chatzilla@public.cloak) (Client closed connection)
# [09:59] * Quits: Norbert (~standards@public.cloak) (Norbert)
# [10:00] <Bert> dirk: Other issues are editorial and we already have actions.
# [10:00] <Bert> ... Remaining is unmatrix stuff.
# [10:00] <Bert> dino: We can do it offline.
# [10:00] <Bert> ... We all want it to look correct and the same.
# [10:01] <Bert> dino: We just need to know why Mozilla did it differently.
# [10:01] * Joins: nsakai (~nsakai@public.cloak)
# [10:01] <Bert> dirk: I'd like to ask for LC in about 4 weeks, depending on whether these last issues are solved.
# [10:01] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
# [10:02] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [10:02] <Bert> Dong-yong lee: we're looking in to stereo display.
# [10:02] * Joins: tokamoto (~tokamoto@public.cloak)
# [10:03] <Bert> ... Has anybody in the group thought about that?
# [10:03] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [10:03] <Bert> dino: Would you make 2D objects appear in 3D, or only the existing 3D objects.
# [10:03] <Bert> Dong-yong: The latter.
# [10:03] <Bert> dino: Should be possible for most content, just slightly different transform for the two views.
# [10:04] <Bert> ... the 3D isn't a realistic 3D, strange perspective distances, etc.
# [10:04] * Joins: tokamoto (~tokamoto@public.cloak)
# [10:04] <Bert> Dong-yong: We tried, and we can render many interesting 3D transforms quite nicely.
# [10:04] <Bert> ... E.g., on 3D TV.
# [10:04] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [10:05] <Bert> ... But we want some correct or nive way or some specification for doing it.
# [10:05] <stearns> s/nive/nice/
# [10:05] <Bert> ... We are not sure if it is a good idea how/whether to display in 3D.
# [10:05] <Bert> dino: Some extra properties in CSS?
# [10:05] <Bert> dong-yong: Maybe
# [10:06] <Bert> dirk: I'd like to read the propsalon the m-list. Don't want ot add complexity right now.
# [10:06] <Bert> ... Maybe next version.
# [10:06] * Joins: nsakai (~nsakai@public.cloak)
# [10:06] <Bert> glazou: We need to publishe this version as soon as possible.
# [10:06] * Joins: glenn_ (~gadams@public.cloak)
# [10:06] <Bert> ... But interesting for next version.
# [10:07] <Bert> dino: Can Dong-Yong send a proposal/idea to m-list?
# [10:07] * Joins: florianr (~yaaic@public.cloak)
# [10:07] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [10:07] <Bert> Dong-yong: Yes, I can write it. We don't necessarily propose a solution.
# [10:07] <Bert> glazou: We need you input, with or without proposal.
# [10:07] <Bert> dino: Yes, the backgtound info is as important as the proposal.
# [10:08] <Bert> dong-yong: The extension should be minimal. And all 3D content should also display on a 2D display.
# [10:09] * Joins: glenn_ (~gadams@public.cloak)
# [10:09] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [10:09] <Bert> glazou: So a few edits base don today/yesterday, and then ask for LC?
# [10:09] * Quits: glenn_ (~gadams@public.cloak) ("Leaving...")
# [10:09] <Bert> dino: Dirk said within 4 weeks we'll ask.
# [10:10] <Bert> [Discussion about agenda]
# [10:11] * Joins: glenn (~gadams@public.cloak)
# [10:11] * Joins: nsakai (~nsakai@public.cloak)
# [10:13] * Joins: liam (liam@public.cloak)
# [10:13] <Bert> Topic: Reversing transitions
# [10:13] <Bert> dbaron: Does IE implement something for that?
# [10:13] <stearns> s/reversing transitions/reversing interrupted transitions/
# [10:14] <Bert> ... E.g., on hover, and then the hover ends, do you moves back at same speed or in same duration?
# [10:14] <Bert> ... Therwe were 2 proposals.
# [10:14] <Bert> ... Dino's proposal and my impl in Gecko.
# [10:14] <Bert> ... I prefer mine.
# [10:15] <Bert> ... Is it a good idea to discuss it now? Or just figure out a way to move forward on the issue?
# [10:16] <Bert> Tab: I wanted to write up examples, but I never did.
# [10:16] <Bert> dbaron: Wait for tab's stuff?
# [10:16] <Bert> .. The issue was knowing what it looks like in practice.
# [10:16] <Bert> ... Other issue:
# [10:17] <Bert> ... We don't allow inherit and initial to be keywords in list in some properties.
# [10:17] <Bert> ... Also none
# [10:17] * Quits: lmclister1 (~Adium@public.cloak) ("Leaving.")
# [10:17] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [10:17] * krit No comments from sylvaing today?
# [10:17] <Bert> ... Transition proeprty list should never allow those keywords in a list, only isolated.
# [10:18] * Joins: massimo (~chatzilla@public.cloak)
# [10:18] * Quits: glenn (~gadams@public.cloak) (glenn)
# [10:18] * Joins: glenn (~gadams@public.cloak)
# [10:18] <dbaron> RESOLUTION: none, inherit, and initial are not allowed at any position within the list for 'transition-property'; such a declaration is syntactically invalid
# [10:18] <florianr> On transition reversal, I believe that we had concluded in a previous f2f (paris or hamburg) that next level could introduce a new property to switch between the various possible alternatives, and that it made the choice less critical one. Whatever we pick has to be reasonable, but doesn't have to solve all usecases
# [10:19] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [10:19] <dbaron> http://dev.w3.org/csswg/css3-transitions/#animatable-types
# [10:19] <Bert> dbaron: In section on animation of property types:
# [10:19] <Bert> ... colors in pre-multiplied space?
# [10:19] <Bert> tab: I think we watned to use pre-multipled in all cases.
# [10:19] <Bert> ... Need to be consistent with gradients, etc.
# [10:20] <Bert> dirk: And with SVG
# [10:20] <Bert> dbaron: But SVG 1.1 had opactity and color on separate proeprties.
# [10:20] <Bert> dino: Still has the same problem of interpolating in 4 channels.
# [10:21] <Bert> dbaron: Gradient says pre-multiplied.
# [10:21] <glazou> s/watned/wanted
# [10:21] <Bert> ... Some OS's don't give you that.
# [10:21] * Joins: rubylin (~rubylin@public.cloak)
# [10:21] <Bert> ... I'd be happy with pre-multiplied.
# [10:21] <Bert> Rik: Prefer non-pre-multiplied.
# [10:21] <Bert> ... Better for SVG and Canvas.
# [10:22] <Bert> Tab: (How did Canvas end up different, I wonder...)
# [10:22] * Quits: glenn (~gadams@public.cloak) (glenn)
# [10:22] * Joins: glenn (~gadams@public.cloak)
# [10:22] <Bert> ... Because CSS gradient has been pre-multuiplied for a while.
# [10:23] <Bert> Dino: benefit of pre-mul is you don't gray when anamating to transparent. And can solbe it by going to rgb(...)
# [10:23] <oyvind> I believe we encountered issues on the web when we did non-premultiplied transitions
# [10:23] <Bert> Tab: Can add some color stops.
# [10:23] * Joins: kazutaka (~yamamoto_kazutaka@public.cloak)
# [10:23] <oyvind> hovering comments on youtube looked weird, for instance
# [10:23] <Bert> ... But SVG is adding mesh gradients and you cannot do the same trick.
# [10:24] <Bert> dbaron: I feel more strongly about animations being pre-mul than about gradients.
# [10:24] <Bert> ... If an animation from/to transparent is ugly, thta is a pb.
# [10:25] <Bert> Rik: Transparent is black, that is the pb.
# [10:25] <Bert> sylvaing: That's why we ended up with pre-mul, isn't it?
# [10:26] <Bert> dbaron: If you anim from green 20% opaque to 100% opaque red.
# [10:26] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
# [10:26] <Bert> .. not the same issue as going through gray, but in non-mul space, the green will first get deeper before fading.
# [10:27] <leaverou> dbaron’s example http://dabblet.com/gist/3979232
# [10:27] <Bert> ... Our MSIL anim code is using pre-mul, I'm pretty sure.
# [10:27] <Bert> dino: One old proposal was to transition in hsl.
# [10:27] <dbaron> http://dbaron.org/css/test/2009/transitions/transitions-alpha
# [10:27] <Bert> dbaron: I have a test case:
# [10:28] * sylvaing doesn't think author expect transparent in a transition to always imply going through black shades, whatever the normative definition of the keyword says. Makes the keyword somewhat useless in this context.
# [10:28] <Bert> tab: webkit is non-pre-multiplied.
# [10:28] <Bert> dbaron: FF is pre-mul.
# [10:28] * Joins: divya (~Adium@public.cloak)
# [10:29] <Bert> ... So actually everybody is doing pre-mul after all.
# [10:29] * Joins: plh (plehegar@public.cloak)
# [10:29] <Bert> tab: [checking]
# [10:29] * Quits: massimo (~chatzilla@public.cloak) (Client closed connection)
# [10:29] <Bert> lea: Did FF change?
# [10:29] <Bert> dbaron: No, we always did.
# [10:30] <Bert> dino: So we all do the same. Let's specify it.
# [10:30] <Bert> tab: Yes, chrome does pre-mul, too.
# [10:31] <Bert> [dbaron adding a test]
# [10:31] * Quits: Shinji (shinji@public.cloak)
# [10:31] <Bert> RESOLVED: Animations of colors are in pre-multiplied space.
# [10:31] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [10:31] * Quits: glazou (~glazou@public.cloak) (glazou)
# [10:32] * Quits: jet (~jet@public.cloak) (jet)
# [10:33] * Quits: rhauck (~rhauck@public.irc.w3.org) (Ping timeout: 60 seconds)
# [10:34] * Quits: knobuta2 (~knobuta2@public.irc.w3.org) (Ping timeout: 60 seconds)
# [10:34] * Quits: florianr (~yaaic@public.cloak) (Client closed connection)
# [10:34] * Joins: shepazu (schepers@public.cloak)
# [10:35] * Quits: yamaday (~yamaday@public.cloak) (Ping timeout: 60 seconds)
# [10:35] * Quits: mishida (~mishida@public.irc.w3.org) (Ping timeout: 60 seconds)
# [10:35] * Joins: glazou (~glazou@public.cloak)
# [10:36] * Quits: glazou (~glazou@public.cloak) (glazou)
# [10:37] * Joins: florianr (~yaaic@public.cloak)
# [10:37] * Joins: tokamoto (~tokamoto@public.cloak)
# [10:38] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
# [10:40] * Quits: rubylin (~rubylin@public.cloak) (Ping timeout: 60 seconds)
# [10:41] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [10:41] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [10:43] * Joins: tokamoto (~tokamoto@public.cloak)
# [10:45] * Quits: kazutaka (~yamamoto_kazutaka@public.cloak) ("CHOCOA")
# [10:45] * Quits: mihara (~mihara@public.cloak) (Client closed connection)
# [10:49] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [10:50] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [10:53] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [10:54] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [10:55] * Quits: Yune (~Yune@public.irc.w3.org) (Ping timeout: 60 seconds)
# [10:55] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [10:55] * Quits: florianr (~yaaic@public.cloak) ("")
# [10:55] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [10:57] * Quits: divya (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [10:57] * Joins: yamaday (~yamaday@public.cloak)
# [10:57] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [10:58] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [10:58] * Joins: Shinji (shinji@public.cloak)
# [10:58] * Joins: mishida (~mishida@public.irc.w3.org)
# [10:58] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [10:58] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [10:59] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [11:00] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [11:01] * Joins: glazou (~glazou@public.cloak)
# [11:05] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [11:05] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [11:06] * Joins: mihara__ (~mihara@public.cloak)
# [11:07] * Joins: rotsuya_ (~rotsuya@public.cloak)
# [11:07] <fantasai> ScribeNick: fantasai
# [11:07] * Joins: lmclister (~Adium@public.cloak)
# [11:07] <fantasai> Topic: text-overflow
# [11:09] * Joins: jet (~jet@public.cloak)
# [11:10] <fantasai> tantek: First sub-item is wrt selection behavior of ellipsed content
# [11:10] <fantasai> tantek: Second issue is what should we do about ellipsing block overflow content
# [11:11] * Joins: yune (~yune@public.irc.w3.org)
# [11:11] <glazou> http://www.w3.org/Style/CSS/Tracker/issues/279
# [11:11] <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html
# [11:11] <fantasai> fantasai: I think we have a resolution from previous F2F as being out-of-scope for this feature
# [11:11] <fantasai> tantek: captured on css4-ui wiki
# [11:11] <fantasai> tantek: so should be resolved wrt this meeting
# [11:12] <fantasai> tantek: first issue wrt selection behavior is unspecified in spec
# [11:12] <fantasai> tantek: issue is, should it be specified, and if so... how
# [11:12] * Joins: Rossen (~Rossen@public.cloak)
# [11:13] <fantasai> tantek: One is wrt copy/paste, another is what hapens when you select
# [11:13] <fantasai> tantek: in Safari, you can see that the copy-pasted text is the complete text
# [11:13] * Joins: kensaku (~kensaku@public.cloak)
# [11:13] <fantasai> tantek: I think this is what is expected by users, implemented by other browsers, should put it in the spec
# [11:14] <fantasai> arronei: There's a problem in this case is that the ellipsis doesn't look highlighted
# [11:15] * Quits: lmclister (~Adium@public.cloak) ("Leaving.")
# [11:15] <fantasai> [some discussion of DOM ranges]
# [11:15] <fantasai> Bert: Is this the first time we talk about selection in CSS?
# [11:16] <fantasai> tantek: I thought we had something in the Selectors spec
# [11:16] <fantasai> fantasai: Doesn't say what is selected, or selection behavior, just what the selection looks like
# [11:16] <fantasai> Bert: If you use text-transform: uppercase; in selection, you may get uppercase or not
# [11:16] <fantasai> Bert: Not opposed, but do we think we're strong enough to say what happens?
# [11:16] <fantasai> tantek: In this case I think we are
# [11:16] <fantasai> tantek: have strong interop
# [11:17] <fantasai> tantek: Another issue is list markers -- what gets copied?
# [11:17] <fantasai> sylvaing: We put this on the agenda because we have an issue wrt css3-ui definition
# [11:18] * Joins: krit (~krit@public.cloak)
# [11:18] * Joins: krit1 (~krit@public.cloak)
# [11:18] * Quits: krit (~krit@public.cloak) (Client closed connection)
# [11:18] <fantasai> RESOLVED: Selecting the ellipsis selects the ellipsed text.
# [11:18] <fantasai> plinss: I think the ellipsis should look selected, though
# [11:19] <fantasai> Rossen: We're now talking about selection which is happening with something not in the content
# [11:19] <fantasai> glazou: Could select a list item by clicking list marker
# [11:19] <fantasai> tantek: label selects an input
# [11:19] <fantasai> arronei: It's weird and misleading if you don't highlight the ellipsis
# [11:20] <fantasai> tantek: No implementation as far as I know will actually let you select the ellipsis itself
# [11:20] <fantasai> tantek: I can't click on it and highlight it
# [11:20] * Quits: kotakagi (~koichi_takagi@public.cloak) ("Yaaic - Yet another Android IRC client - http://www.yaaic.org")
# [11:21] <fantasai> antonp: It's a problem with generated content in general
# [11:21] <fantasai> tantek: It's bad behavior, but also interoperable
# [11:21] <fantasai> tantek: There are some ppl that want to specify bad behavior that's interoperable
# [11:21] <fantasai> tantek: Some ppl take approach of leaving things vague, allowing for improvement
# [11:22] <fantasai> tantek: I'm of the opinion that we should be vague in L3, and put normative should in L4
# [11:22] <fantasai> Bert: Add some kind of note of what we intend
# [11:22] <fantasai> plinss: We don't require test passes on shoulds
# [11:22] <fantasai> plinss: So let's just put a should.
# [11:23] * Joins: kotakagi (~koichi_takagi@public.cloak)
# [11:23] <fantasai> dbaron: What do you think UAs should do if part of the ellipsed text is selected?
# [11:23] * Joins: massimo (~chatzilla@public.cloak)
# [11:23] <fantasai> dbaron: e.g. via DOM manipulation
# [11:23] <dbaron> ... or text selected prior to the resize that makes the ellipsis
# [11:24] <dbaron> ... or selection of text with the keyboard
# [11:24] <dbaron> (maybe)
# [11:24] <glazou> show ellipsis in a tooltip and allow seleciton in the tooltip
# [11:24] <fantasai> tantek: Looks like selection with keyboard goes one character at a time
# [11:24] <fantasai> TabAtkins_: For highighting the ellipsis, think should only do so once contain the entire ellipsed text
# [11:24] <fantasai> fantasai: And otherwise don't select any of it?
# [11:25] <fantasai> dbaron: Don't know I'd require that; could do better
# [11:25] <fantasai> dbaron: e.g. selecting part of ellipsis proportional to selected text
# [11:25] <fantasai> tantek: That makes me lean towards a note, since we don't know exactly the right behavior
# [11:26] <fantasai> plinss: I don't think we need to specify in excruciating detail, but give them some broad strokes
# [11:26] <fantasai> plinss: If everything is selected, must select the whole ellipssis
# [11:26] <fantasai> plinss: if partial selection, may indicate that some other way
# [11:27] * Joins: tokamoto (~tokamoto@public.cloak)
# [11:27] <fantasai> s/must/should/
# [11:27] <fantasai> RESOLVED: If all of ellipsed text is selected, show selection of ellipsis
# [11:28] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [11:28] * Joins: tokamoto (~tokamoto@public.cloak)
# [11:28] <fantasai> RESOLVED: put a note that behavior wrt partially-selected text is up to UA
# [11:28] * Joins: divya (~u1924@public.cloak)
# [11:29] <fantasai> Rossen: Have a minor issue wrt the example in the testcases
# [11:29] * fantasai wants a link to that testcase here
# [11:29] <fantasai> Rossen: You only have an ellipsis on the last line of text, and they are confused
# [11:30] <fantasai> Rossen: They think it's defining multiline ellipsis because the example only shows the ellipsis on the last line
# [11:30] <fantasai> Rossen: This example sets the expectations
# [11:30] <fantasai> fantasai: Change it to "CSS AWESOME IS"
# [11:31] * divya starts a zazzle store
# [11:31] * Joins: rubylin (~rubylin@public.cloak)
# [11:31] <fantasai> ACTION tantek: fix text-overflow example in the spec to not ellipse the last line, but an earlier line
# [11:31] * trackbot noticed an ACTION. Trying to create it.
# [11:31] * RRSAgent records action 6
# [11:31] <trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)) - please contact sysreq with the details of what happened.
# [11:31] <fantasai> o_O?
# [11:31] <glazou> ROFL
# [11:32] * sylvaing trackbot lost the plot.
# [11:32] <fantasai> plinss asks for clarifications on what this property does
# [11:33] <fantasai> various explain
# [11:33] <fantasai> Rossen: Other issue is wrt scrolling, and expectation to keep the ellipsis, recalc on every scroll
# [11:34] <fantasai> Rossen: Currently I believe no implementation does tha
# [11:34] <fantasai> Rossen: No one has actually asked for this behavior
# [11:34] <fantasai> Rossen: Depending on the underlying implementation, whether or not we need to reformat line of text when you render it, that behavior ties display with layout, which is not a good idea
# [11:34] <fantasai> tantek: You're saying you don't want to scroll content into view?
# [11:35] <fantasai> Rossen: If you have a horizontal scroller, no implementation does what you're saying
# [11:35] <fantasai> tantek: Not true, FF does it.
# [11:36] <fantasai> JohnJansen: Tantek, are your tests online somewhere?
# [11:36] <fantasai> plinss: Secondary question: can you turn these into real tests in the test suite
# [11:37] <fantasai> Topic: Case-insensitivity of Identifiers
# [11:37] <tantek> the tests were emailed to the list a while ago
# [11:37] <tantek> I can resend
# [11:37] <JohnJansen> ACTION: Tantek send the test cases to the list
# [11:37] * trackbot noticed an ACTION. Trying to create it.
# [11:37] * RRSAgent records action 7
# [11:37] <trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)) - please contact sysreq with the details of what happened.
# [11:37] <tantek> and yes, we have an outstanding need for css3-ui test cases.
# [11:37] * Quits: jet (~jet@public.cloak) (Ping timeout: 60 seconds)
# [11:37] <tantek> (unactioned)
# [11:37] <fantasai> ishida: We may need to punt on a decision from i18n
# [11:37] * Joins: jet (~jet@public.cloak)
# [11:37] <stearns> tantek's testcase: https://bug690187.bugzilla.mozilla.org/attachment.cgi?id=583694
# [11:37] <fantasai> dbaron: Speaking of i18n, seems we can no longer assign actions to Tantek
# [11:38] <tantek> thanks stearns!
# [11:38] * Joins: r12a (rishida@public.cloak)
# [11:38] <JohnJansen> ACTION: tantek send the test cases to the list
# [11:38] * trackbot noticed an ACTION. Trying to create it.
# [11:38] * RRSAgent records action 8
# [11:38] <trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)) - please contact sysreq with the details of what happened.
# [11:38] <tantek> :D
# [11:38] <fantasai> http://wiki.csswg.org/topics/custom-ident-case-sensitivity
# [11:39] * hober dbaron: LATIN CAPITAL LETTER C WITH CEDILLA is 0xC7, not 0xC3
# [11:39] * dbaron hober, but in utf8, it's 0xc3 0x87
# [11:39] * hober ahh, indeed
# [11:39] <glazou> right, that's the issue, the python script on the server side has a problem with utf-8
# [11:40] <fantasai> fantasai summarizes the issue
# [11:40] <fantasai> (see above)
# [11:40] <hober> ACTION: dbaron to make tantek send the test cases to the list
# [11:40] * trackbot noticed an ACTION. Trying to create it.
# [11:40] * RRSAgent records action 9
# [11:40] <trackbot> Created ACTION-519 - Make tantek send the test cases to the list [on David Baron - due 2012-11-06].
# [11:40] <fantasai> ishida: For extending out to full Unicode, recommendation would be to use default case-folding
# [11:41] <fantasai> ishida: Would work for most people, except Turkish and Lithuanian
# [11:41] <fantasai> ishida: because of dotted is
# [11:41] <fantasai> ishida: Keeping case-insensitivity with default Unicode case-folding would create a problem for these users
# [11:41] <fantasai> ishida: Don't know what more we can say oday
# [11:41] * fantasai thinks eszet is also a problem
# [11:41] * Quits: paul___irish (~paul___irish@public.cloak) (Ping timeout: 60 seconds)
# [11:41] <fantasai> ishida: We don't have a conclusion in i18n
# [11:42] <fantasai> TabAtkins_: I think case-insensitivity in CSS was a mistake, but given we have this problem already, I would say keep it to ASCII
# [11:42] <fantasai> TabAtkins_: HTML already does htis
# [11:42] <JohnJansen> ACTION: fantasai make tantek fix text-overflow example in the spec to not ellipse the last line, but an earlier time
# [11:42] * trackbot noticed an ACTION. Trying to create it.
# [11:42] * RRSAgent records action 10
# [11:42] <trackbot> Created ACTION-520 - Make tantek fix text-overflow example in the spec to not ellipse the last line, but an earlier time [on Elika Etemad - due 2012-11-06].
# [11:42] <leaverou> s/htis/this
# [11:42] * glazou sysreq knows about the issue, trackbot will be restarted later today
# [11:42] <fantasai> ishida: Problem with that is writing French, would assume you have case-insensitivity, but one character in your word happens to have an accent, would not be
# [11:44] * Quits: JohnJansen (~JohnJansen@public.cloak) ("")
# [11:44] <fantasai> TabAtkins_: Could recommend to authors to just use lowercase all the time
# [11:44] * Joins: JohnJansen (~JohnJansen@public.cloak)
# [11:44] <fantasai> fantasai: Or just recommend not relying on case-insensitivity, and always using consistent casing
# [11:44] <fantasai> TabAtkins asks for ishida's opinion
# [11:45] <fantasai> ishida: I personally feel that this seems a good way forward, but would have to discuss with i18n
# [11:45] <fantasai> TabAtkins asks for a resolution by end of TPAC
# [11:45] <fantasai> ishida: Not sure, but could have an answer by next Thursday, would that be ok?
# [11:45] <fantasai> norbert: What extent do you actually need case-insensitivity
# [11:46] <fantasai> TabAtkins: There's a significant fraction of people who use capital letters for CSS keywords
# [11:46] * glazou we can assign an action to someone AND reassign to tantek after creation
# [11:46] <fantasai> TabAtkins: We can't change that.
# [11:47] * Joins: rhauck (~rhauck@public.irc.w3.org)
# [11:47] <fantasai> fantasai: So can we come to a conclusion on what we're doing here, pending i18n approval?
# [11:48] <fantasai> [explosion]
# [11:49] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html
# [11:49] <fantasai> [argument over what was resolved; see minutes above for actual resolution]
# [11:50] <fantasai> Bert is not happy with ASCII case-insensitivity
# [11:50] <jet> http://w3cmemes.tumblr.com/image/29509229758
# [11:50] * Joins: knobuta2 (~knobuta2@public.irc.w3.org)
# [11:50] <fantasai> SteveZ: My understanding is we asked i18n to come back with a recommendation
# [11:51] * Joins: mgylling (~mgylling@public.cloak)
# [11:51] <fantasai> TabAtkins: And we want to tentatively resolve on something
# [11:51] <fantasai> but there is no consensus, so we are waiting for i18n
# [11:52] <fantasai> Topic: Grid Layout
# [11:52] <fantasai> SteveZ: my issue is how to make progress on Peter's concerns. But not sure her eis the right place to do that
# [11:53] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0828.html
# [11:53] <fantasai> plinss: Takeaway from meeting with MSFT was tha where there were differences between proposals, capture as issues
# [11:53] <fantasai> plinss: and publish the spec
# [11:53] <fantasai> plinss: And then modify the spec to bring in significant aspects of my proposal
# [11:53] <fantasai> plinss: I was trying to go towards a general-purpose design grid
# [11:54] <fantasai> plinss: Don't need all those features in this level, but want to take in a direction that's compatible
# [11:54] <fantasai> plinss: I believe as the syntax stands now, it is incompatible
# [11:54] * Joins: paul___irish (~paul___irish@public.cloak)
# [11:54] <fantasai> TabAtkins: From my understanding of discussion with fantasai, it's mostly just syntax changes that are needed
# [11:54] <fantasai> TabAtkins: basically changing -position/-span to -start/-end
# [11:55] <fantasai> TabAtkins: and then other aspects slot in
# [11:55] <fantasai> SteveZ: Want to see next steps happen
# [11:55] <fantasai> fantasai: I think it's mainly a syntax brainstorming problem
# [11:55] <fantasai> fantasai: There are various constraints we want to solve here
# [11:56] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 60 seconds)
# [11:56] <dbaron> Peter: I don't require major architectural changes to the proposal; just want minor changes to allow future changes
# [11:57] <dbaron> Rossen: So do think at this point that everything will actually overlap?
# [11:57] * glazou note for all : TPAC feedback form available at https://www.w3.org/2002/09/wbs/35125/tpac2012-feedback/
# [11:57] <dbaron> Peter: I think room for moderate tweaks in syntax and terminology, to keep existing model with terminology and syntax that will be compatible with the more expanded model.
# [11:57] <dbaron> Peter: I don't see reason we should decide we can't do it and give up.
# [11:58] <dbaron> fantasai: I tried mocking up on a whiteboard; main area I got stuck on is that Peter wants a model where you say which lines you're between, whereas MS model allows for an auto-placement model, which requires ability to express with start or end positions plus a span.
# [11:58] <dbaron> fantasai: I had trouble figuring out a sane syntax that could represent both.
# [11:58] <dbaron> Peter: I had notions of a functional notation.
# [11:58] <dbaron> Peter: ... opposite side wants to be nth version of that line?
# [11:58] <dbaron> Peter: We should ... and brainstorm.
# [11:59] <dbaron> fantasai: Yep, brainstorming.
# [11:59] <dbaron> Peter: My proposal can be broken into discrete levels.
# [11:59] <dbaron> Peter: First order is agreeing to express grid model in terms of lines and fields instead of rows and columns.
# [11:59] <dbaron> Peter: So expose it that way and present it to authors in that mindset.
# [11:59] <dbaron> Peter: fields instead of cells, roles instead of names
# [12:00] <dbaron> Peter: I don't know if we decide to adopt those as principles or wait for real syntax.
# [12:00] <dbaron> fantasai: I think if we figure out the syntax it will be easier to write the prose; but I'm not the editor.
# [12:00] <dbaron> Peter: I think ??? is an important direction; based on lines and fields instead of rows and columns.
# [12:00] <dbaron> Peter: That distinction influences syntax.
# [12:00] <dbaron> Peter: Syntax now is rows, columns, and spans.
# [12:01] <dbaron> Bert: There's a danger using terms like fields, which have a meaning in some traditions.
# [12:01] <dbaron> Bert: Our fields aren't exactly what they're used for in those traditions.
# [12:01] <dbaron> Peter: I don't care about the exact words; don't want to be hung up on terms; but opposed to rows, columns, spans.
# [12:01] <dbaron> SteveZ: We need to set up a call to discuss this.
# [12:01] <dbaron> Tab: ... . I contacted Phil about being a coeditor on this spec.
# [12:02] <dbaron> SteveZ: Can we have a 15 minute update following the next CSS call?
# [12:02] * Quits: SimonSapin (~simon@public.cloak) (Client closed connection)
# [12:02] <dbaron> SteveZ: Status check of where we are on that.
# [12:02] * Joins: SimonSapin (~simon@public.cloak)
# [12:02] * Quits: SimonSapin (~simon@public.cloak) (Client closed connection)
# [12:02] * Joins: SimonSapin (~simon@public.cloak)
# [12:02] <dbaron> SteveZ: Outside of the telecon time.
# [12:03] <dbaron> JohnJansen: Why not part of the agenda on the next call?
# [12:03] <dbaron> ?: Not having the brainstorming on the call.
# [12:03] <dbaron> Peter: Have a deadline for brainstorming to be done and report back to the group.
# [12:03] <dbaron> SteveZ: Want it less than a month.
# [12:03] <dbaron> Rossen: Reasonable to dedicate some time before the next conf call.
# [12:04] <dbaron> Rossen: Minimal overlap that needs to go in the level 1 spec.
# [12:04] <dbaron> Rossen: Two things we need to guarantee: (1) that there's no features of current grid that will contradict further devel. of overlap grid
# [12:04] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [12:05] <dbaron> Rossen: ... (2) minimal set of syntax rewrite we'll need to do for current grid to verify (1)
# [12:05] <dbaron> Rossen: If we come to the conclusion they're not overlappable, because of significant differences, then we each go our separate ways.
# [12:05] <dbaron> SteveZ: ... and agree to disagree
# [12:05] <dbaron> Rossen: So I guess we have an action to get together and talk about this.
# [12:05] <dbaron> Bert: My next 3 weeks are very busy.
# [12:05] <dbaron> Rossen: Who needs to be on call?
# [12:06] <dbaron> Rossen: Peter, Elika, Bert, Tab, Steve, Rossen, Phil
# [12:06] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
# [12:06] <dbaron> Rossen: Let's schedule offline.
# [12:06] <dbaron> ACTION Rossen to organise brainstorming call about grid
# [12:06] * trackbot noticed an ACTION. Trying to create it.
# [12:06] <trackbot> Created ACTION-521 - Organise brainstorming call about grid [on Rossen Atanassov - due 2012-11-06].
# [12:07] <dbaron> Topic: Alternate style sheets
# [12:07] <dbaron> Peter: This came out of discussion about alternate style sheets, people asking what ever happened to them.
# [12:07] * Quits: massimo (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [12:07] <dbaron> Peter: I accept there are reasons they haven't caught on.
# [12:07] <dbaron> Peter: I wanted to ask if there was something we could do to fix this.
# [12:07] <dbaron> fantasai: I think Alternate SS mechanism in HTML is sufficiently powerful.
# [12:07] <dbaron> fantasai: Problem is implementations aren't.
# [12:08] <dbaron> fantasai: Mozilla has UI to switch, but doesn't remember.
# [12:08] <dbaron> dbaron: I think it does remember now.
# [12:08] <dbaron> Peter: If I go to homepage of site and switch site, it should persist.
# [12:08] <dbaron> Glenn: Intersects with OM, Anne spec'd some functionality.
# [12:08] <dbaron> dbaron: I thought that spec was sort of stable.
# [12:09] <fantasai> fantasai^: That was all worked out as an implementation plan for Mozilla, but never happened
# [12:09] <dbaron> Tantek: I think this is just one instance with the problem with prescriptive UI in specs.
# [12:09] <dbaron> Tantek: I think such things are doomed to fail.
# [12:09] <dbaron> Tantek: I think they're the form of a wishlist.
# [12:09] <dbaron> Håkon: But the spec didn't say what to do.
# [12:09] <dbaron> Tantek: The specs put in prescriptive UI, and that UI failed.
# [12:10] <dbaron> Tab: I find it unlikely we'll want to do anywhere near the same UI other browsers.
# [12:10] <dbaron> Tantek: I think prescriptive UI is going to fail.
# [12:10] <dbaron> Peter: I don't think the problem is that the UI is underspecified.
# [12:10] <dbaron> Peter: I'm questioning if there isn't something missing in the fundamental model to make this work.
# [12:10] <dbaron> q+
# [12:10] * Zakim sees dbaron on the speaker queue
# [12:10] <dbaron> Peter: We don't know where to preserve the choices for a given site.
# [12:10] <dbaron> fantasai: There are detailed proposals for that in the Mozilla bugs.
# [12:11] <dbaron> Tantek: I think that's an area where implementations need to innovate.
# [12:11] <dbaron> Tantek: We have the same problem with text zooming.
# [12:11] <dbaron> fantasai: I don't there's anything this working group needs to work on for that.
# [12:11] <dbaron> fantasai: But there's one thing on this topic I'd like to get a resolution on.
# [12:12] <dbaron> fantasai: There's a proposal for syntax for alternate style sheets proposed in the cascade module for @import rules. I'd like to drop that, at least until it's requested.
# [12:12] <dbaron> ?: or at least at risk
# [12:12] <dbaron> fantasai: If we want Cascade module to be up-to-date, we shouldn't take on functionality that nobody wants to work on.
# [12:12] <stearns> s/?/Peter/
# [12:12] * Quits: kotakagi (~koichi_takagi@public.cloak) (Ping timeout: 60 seconds)
# [12:12] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [12:13] <dbaron> RESOLVED: Drop alternate style sheet syntax from @import in css3-cascade.
# [12:14] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [12:14] * Quits: Shinji (shinji@public.cloak)
# [12:14] <dbaron> break-duration: calc(60 * 60s)
# [12:14] * Quits: jet (~jet@public.cloak) (jet)
# [12:14] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [12:14] * Quits: glazou (~glazou@public.cloak) (glazou)
# [12:14] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
# [12:14] * Quits: dino (~dino@public.cloak) (dino)
# [12:14] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [12:14] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [12:15] * Joins: Shinji (shinji@public.cloak)
# [12:15] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [12:15] * Quits: rhauck (~rhauck@public.irc.w3.org) (Ping timeout: 60 seconds)
# [12:15] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 60 seconds)
# [12:15] * leaverou is now known as leaverou_away
# [12:15] * Quits: rotsuya_ (~rotsuya@public.cloak) (Client closed connection)
# [12:16] * Quits: Shinji (shinji@public.cloak)
# [12:16] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [12:17] * Quits: tantek (~tantek@public.cloak) (tantek)
# [12:17] * Quits: r12a (rishida@public.cloak)
# [12:17] * Quits: rubylin (~rubylin@public.cloak) (Ping timeout: 60 seconds)
# [12:17] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
# [12:18] * Quits: mishida (~mishida@public.irc.w3.org) (Ping timeout: 60 seconds)
# [12:18] * Quits: knobuta2 (~knobuta2@public.irc.w3.org) (Ping timeout: 60 seconds)
# [12:18] * Quits: yune (~yune@public.irc.w3.org) (Ping timeout: 60 seconds)
# [12:18] * Joins: jet (~jet@public.cloak)
# [12:18] * Quits: sakkuru (~sakkuru@public.cloak) (Ping timeout: 60 seconds)
# [12:18] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [12:19] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [12:20] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [12:20] * Joins: rubylin (~rubylin@public.cloak)
# [12:21] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 60 seconds)
# [12:22] * sylvaing is now known as sylvaing_away
# [12:24] * Quits: mihara__ (~mihara@public.cloak) (Client closed connection)
# [12:31] * Joins: plh (plehegar@public.cloak)
# [12:32] * Quits: jet (~jet@public.cloak) (jet)
# [12:33] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [12:36] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
# [12:44] * Joins: arronei (~arronei@public.cloak)
# [12:45] * Joins: arroneiTPAC (~arronei@public.cloak)
# [12:45] * Joins: leehomlin (~rubylin@public.cloak)
# [12:46] * Quits: rubylin (~rubylin@public.cloak) (Ping timeout: 60 seconds)
# [12:48] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 60 seconds)
# [12:53] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [13:02] * Joins: stearns (~anonymous@public.cloak)
# [13:03] * Joins: tantek (~tantek@public.cloak)
# [13:03] * Quits: arroneiTPAC (~arronei@public.cloak) (Ping timeout: 60 seconds)
# [13:05] * Joins: SimonSapin (~simon@public.cloak)
# [13:09] * Joins: evanlee (~androirc@public.cloak)
# [13:09] * Quits: evanli (~androirc@public.cloak) (Client closed connection)
# [13:10] * Joins: mollydotcom (~mholzsch@public.cloak)
# [13:14] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [13:15] * Joins: kensaku (~kensaku@public.cloak)
# [13:15] * Joins: tokamoto (~tokamoto@public.cloak)
# [13:19] * Quits: kensaku (~kensaku@public.cloak) (Ping timeout: 60 seconds)
# [13:21] * Quits: evanlee (~androirc@public.cloak) (Client closed connection)
# [13:21] * Quits: leehomlin (~rubylin@public.cloak) (Ping timeout: 60 seconds)
# [13:22] * Joins: florianr (~yaaic@public.cloak)
# [13:25] * Quits: tantek (~tantek@public.cloak) (tantek)
# [13:27] * Quits: florianr (~yaaic@public.cloak) ("")
# [13:27] * Joins: florian (~florian@public.cloak)
# [13:33] * Joins: glazou (~glazou@public.cloak)
# [13:33] * Joins: arronei (~arronei@public.cloak)
# [13:36] * Joins: antonp (~Thunderbird@public.cloak)
# [13:36] * Joins: Rossen (~Rossen@public.cloak)
# [13:39] * Joins: dino_ (~dino@public.cloak)
# [13:40] * Joins: dbaron (~dbaron@public.cloak)
# [13:40] * Joins: cabanier (~cabanier@public.cloak)
# [13:41] * Joins: cabanier1 (~cabanier@public.cloak)
# [13:41] * Quits: cabanier (~cabanier@public.cloak) (Client closed connection)
# [13:42] * mollydotcom wonders what was for lunch
# [13:42] * Joins: Norbert (~standards@public.cloak)
# [13:42] * leaverou_away is now known as leaverou
# [13:43] * stearns excellent cheese
# [13:44] * Quits: vhardy (~vhardy@public.irc.w3.org) ("ZNC - http://znc.in")
# [13:44] * sylvaing_away is now known as sylvaing
# [13:44] <dbaron> Topic: Editorship of Cascade module
# [13:45] <dbaron> Tab: Elika and I would like to take editorship of cascade from Håkon
# [13:45] <dbaron> Håkon: What needs to be done?
# [13:45] <dbaron> Elika: 1) remove alternate style sheets syntax
# [13:45] * Joins: lstorset (~leif@public.cloak)
# [13:45] <dbaron> Elika: 2) synchronize text with CSS 2.1 and make sure corrections all copied over
# [13:45] <dbaron> Elika: 3) editorial reorganization of spec to make sure it still makes sense
# [13:45] <dbaron> Elika: 4) Add cascading rules for scoped styles, the 'all' shorthand, and the 'default' keyword
# [13:46] <dbaron> Håkon: Are we doing scoped style?
# [13:46] <dbaron> Tab: Yes!
# [13:46] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [13:46] <dbaron> Elika: The proposal for scoped styles, as I mentioned in the meeting yesterday. Boris Zbarsky has a proposal for the cascading part that we want to edit into the spec.
# [13:46] <dbaron> Håkon: I'm happy for you to edit; I still think we need to discuss that feature.
# [13:46] * Joins: krit (~krit@public.cloak)
# [13:47] * Joins: mgylling (~mgylling@public.cloak)
# [13:47] <dbaron> Tab: I'd like to start doing those edits and then bringing it to discuss in the group.
# [13:47] <dbaron> Bert: What is the 'all' shorthand?
# [13:47] * Joins: mgylling_ (~mgylling@public.cloak)
# [13:47] <dbaron> Tab: We'd like to make 'all' a real property that's a shorthand for all properties, that only accepts initial | inherit | default (once we add default).
# [13:47] <dbaron> Tab: Reason for this is that authors sometimes want to shut off inheritance.
# [13:47] <dbaron> Tab: Authors don't want outer page's styles to leak into a widget.
# [13:47] <dbaron> Tab: Right now authors code very defensively.
# [13:48] <dbaron> Tab: The all property makes it very easy.
# [13:48] <dbaron> Bert: Shouldn't they mark it as a scope in the HTML?
# [13:48] <dbaron> Tab: Yes, in many cases, you want to do this properly.
# [13:48] <dbaron> Tab: But the shadow dom would like to have a non-magical mechanism to reset inheritance.
# [13:48] <dbaron> q+
# [13:48] * Zakim sees dbaron on the speaker queue
# [13:48] <dbaron> Tab: When you don't need the full weight of shadow DOM, it can still be useful to reset inheritance entirely.
# [13:48] <dbaron> Bert: Seems a bit frivolous.
# [13:48] <dbaron> Tab: It's a minor improvement that reduces a bit of magic in a few parts of the platforms.
# [13:49] <dbaron> Aaron: And it solves a problem that it's a pain to ...
# [13:49] <dbaron> ack dbaron
# [13:49] * Zakim sees no one on the speaker queue
# [13:49] <fantasai> dbaron: What about things that are in the UA style sheet where the UA has an inherited property on the root, on the assumption that we want that to be the default but let authors override it
# [13:50] <fantasai> TabAtkins: Discussed with bzbarsky of having 'default' roll back one level of the cascade, resetting all author styles
# [13:51] * Quits: mgylling (~mgylling@public.cloak) (Ping timeout: 60 seconds)
# [13:51] * mgylling_ is now known as mgylling
# [13:51] <fantasai> dbaron: That assumes user prefs are expressed e.g. by changing the definition of 'medium' rather than ways that put a style rule in place on the root element
# [13:51] <fantasai> dbaron: font-size is ok, but other properties might not be
# [13:51] * Joins: shepazu (schepers@public.cloak)
# [13:51] * Parts: glazou (~glazou@public.cloak) (glazou)
# [13:51] <fantasai> dbaron: suppose we didn't have a 'medium' font size keyword, handled default by setting 'font-size: 20px' on the root
# [13:52] * Quits: florian (~florian@public.cloak) (Ping timeout: 60 seconds)
# [13:52] * Joins: nsakai (~nsakai@public.irc.w3.org)
# [13:52] <dbaron> dbaron: so default does something magic with inheriting rules on ancestors that are ua and user rules?
# [13:52] <fantasai> TabAtkins: [...]
# [13:53] <fantasai> [basically, this is an issue that needs to be considered]
# [13:53] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [13:53] * Joins: florianr (~yaaic@public.cloak)
# [13:53] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [13:53] <fantasai> RESOLVED: Tab and fantasai to take over css3-cascade
# [13:54] * Joins: Yune (~Yune@public.irc.w3.org)
# [13:54] * Quits: florianr (~yaaic@public.cloak) (Client closed connection)
# [13:55] <fantasai> Topic: HTML5 Challenges (presented by Bert)
# [13:55] * Joins: florianr (~yaaic@public.cloak)
# [13:55] <fantasai> ScribeNick: fantasai
# [13:55] <fantasai> Bert: Overall question is how much magic
# [13:55] * Quits: florianr (~yaaic@public.cloak) (Client closed connection)
# [13:56] <fantasai> Bert: we have some, for example: a link is a link, and we don't define that
# [13:56] <fantasai> Bert: CSS doesn't say when an element matches :link or :visited
# [13:56] <fantasai> Bert: So some magic we want to keep
# [13:56] <fantasai> Bert: But overall, think we should minimize magic
# [13:56] * Joins: florianr (~yaaic@public.cloak)
# [13:56] <fantasai> Bert: to be able to use as many features as possible in more environments
# [13:56] * Quits: krit (~krit@public.cloak) (Ping timeout: 60 seconds)
# [13:57] <fantasai> Bert: Here's a question -- do we need to say in CSS that you switch from CSS to SVG model? To math model?
# [13:57] <fantasai> Bert: How does this interact with the box model
# [13:57] <fantasai> Bert: Do we define what it means
# [13:57] <fantasai> Bert: SVG and Math might have different answers
# [13:57] <fantasai> Bert: Do we want some way in CSS saying that you switch rendering models?
# [13:57] <fantasai> Bert: And in the case of math, do we want to define exactly how that works?
# [13:57] * Joins: lmclister (~Adium@public.cloak)
# [13:58] <fantasai> TabAtkins: I would like to see 'display: svg' and 'display: math'
# [13:58] <fantasai> TabAtkins: with SVG switching into a kind of abspos model
# [13:58] <fantasai> TabAtkins: And math for now just being handwavy as math, but work on it more later
# [13:58] <fantasai> TabAtkins: Have had some discussions on integrating SVG and CSS models better, think it's a good idea
# [13:58] <fantasai> Bert: Do we expect to support other types of rendering models?
# [13:59] <fantasai> TabAtkins: I think others should use existing layout model, or if using something completely different, use this extension model
# [13:59] <fantasai> TabAtkins: Dont' want to overly-generalize right now
# [13:59] <fantasai> TabAtkins: If in future have a 3rd language with its own display, give it its own display value
# [13:59] * Quits: florianr (~yaaic@public.cloak) ("")
# [13:59] <fantasai> plinss: Sounds reasonable. For consistency, do we go back and do <img> and <iframe> ?
# [14:00] <fantasai> Bert, Tab: no that's replaced content b/c external file
# [14:00] <fantasai> arronei: once you're inside SVG element, CSS doesn't care anymore
# [14:00] <fantasai> TabAtkins: But would be better if integrate better
# [14:00] * Joins: r12a (rishida@public.cloak)
# [14:00] <fantasai> TabAtkins: e.g. not have to use <foreignObject> in SVG to include HTML bits
# [14:01] <fantasai> TabAtkins: But wrt CSS box model, would still behave as they do now
# [14:01] <fantasai> arronei: Do we then need inline-svg and svg?
# [14:01] <fantasai> TabAtkins: No, we need display-inside/display-outside :)
# [14:01] * Joins: tokamoto (~tokamoto@public.cloak)
# [14:01] * Joins: yamaday (~yamaday@public.cloak)
# [14:02] <fantasai> [side discussion on whether to split display]
# [14:02] <fantasai> Bert: An alternative is not to have a keyword per model, but just have one keyword, 'foreign', and let it be determined by the namespace
# [14:02] <fantasai> hober: Single keyword doesn't tell you anything useful about what's inside
# [14:02] <fantasai> or how to process it
# [14:03] <fantasai> TabAtkins: I would like to go and define an SVG layout model at some point, add it at that point
# [14:03] * Joins: SimonSapin (~simon@public.cloak)
# [14:03] <fantasai> TabAtkins: Maybe go ahead and say we'll define math value now?
# [14:03] * Joins: dbaron (~dbaron@public.cloak)
# [14:03] * Joins: glazou (~glazou@public.cloak)
# [14:04] <fantasai> fantasai: What if I set 'display: block' on an embedded <svg> element?
# [14:04] <vhardy__> For reference http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
# [14:04] <fantasai> fantasai: Right now that just makes the SVG a block-level replaced element
# [14:04] <fantasai> fantasai: just like external SVG
# [14:04] <fantasai> fantasai: but if we go with your proposal, this will cause the SVG to break
# [14:04] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
# [14:05] <vhardy__> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
# [14:05] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
# [14:05] * Joins: Daisuke (~Daisuke@public.cloak)
# [14:06] <fantasai> vhardy: Might want to talk more with HTML guys of mixing svg andhtml
# [14:06] <fantasai> Bert: Next issue is math, do we define that layout model. There are useful behaviors there, useful outside of math
# [14:06] <fantasai> Bert: Don't know how to get that done
# [14:07] <fantasai> TabAtkins suggests kidnapping David Carlisle
# [14:07] <fantasai> Bert: Have to work out details, but do people think math boxes in principle is a good idea?
# [14:07] <fantasai> plinss: I think it's reasonable
# [14:07] <fantasai> plinss: I remember we looked at how to render math with existing CSS
# [14:08] <fantasai> Bert: There's a MathML profile for that. Doesn't quite look right, but you can get quite far
# [14:08] <fantasai> ChrisL: If you redid that profile with Flexbox, would that help?
# [14:08] <fantasai> Bert: Maybe. Have to see what baselines are use
# [14:08] <fantasai> d
# [14:09] <fantasai> TabAtkins: Proposed resolution - Add 'display: svg' and 'display: math' or something similar at some point
# [14:10] <fantasai> TabAtkins: Can solve the stylesheet overriding problem by having display-inside: svg !important to UA stylesheet
# [14:10] <fantasai> ChrisL: display-inside/display-outside sets up a proper handoff mechanism
# [14:12] <TabAtkins_> RESOLVED: Add 'display: svg' and 'display: math' or something similar at some point
# [14:12] <fantasai> Bert: So, <details> element has an open attribute
# [14:12] <fantasai> Bert: So you can style differently the two different states
# [14:12] <fantasai> Bert: This is an example of a wider problem
# [14:12] <fantasai> Bert: Wider problem is, we should have a way to give every element two states
# [14:12] <TabAtkins_> I agree: http://www.xanthir.com/b4Kn0
# [14:13] <fantasai> Bert: Even a <section> or <div> should be able to be open/close
# [14:13] <fantasai> TabAtkins: I agree, and tried to write something up on this
# [14:13] <fantasai> fantasai: But you ran into a problem
# [14:13] <fantasai> TabAtkins: Yeah, ran into a fundamental problem.
# [14:13] <fantasai> TabAtkins: Circular dependencies
# [14:13] <fantasai> Bert: Did you look at the pseudo-class solution instead?
# [14:14] * Quits: Norbert (~standards@public.cloak) (Norbert)
# [14:14] <fantasai> TabAtkins: This keys directly into :checked pseudo-class, except generalizes so you can have more than 2 states
# [14:14] <fantasai> TabAtkins: Also does what HTML label element does, transferring checkedness between elements. E.g. clicking on <summary> affects <details>
# [14:14] <fantasai> TabAtkins: But fundamental problem with this, whatever property turns on ability to be checked
# [14:14] <fantasai> TabAtkins: If whie it's there, you turn off that property, then it's a problem
# [14:15] <fantasai> Bert: Do you actually need the property? Couldn't it just be implicit?
# [14:15] * Joins: Norbert (~standards@public.cloak)
# [14:15] <fantasai> TabAtkins: Could imply checked / unchecked states for all elements, just use pseudo-classes
# [14:15] <fantasai> TabAtkins: But doesn't let you do radio buttons
# [14:15] <fantasai> TabAtkins: which I've found to be super useful
# [14:16] * Joins: ChrisL (clilley@public.cloak)
# [14:16] <fantasai> TabAtkins: My suggestion is to go with this, but restrict the toggleable property to not be set in pseudo-classes that read the toggled state
# [14:17] * Joins: liam (liam@public.cloak)
# [14:17] <fantasai> Bert: You say you can have more than 2 states. I investigated that too, but it seemed too complicated for authors
# [14:17] <fantasai> TabAtkins: Not sure it's necessary, though can come up with cases where it would be useful
# [14:17] <fantasai> TabAtkins: But most cases I came up with were two states, but able to make second state sticky so that clicking it doesn't toggle the stae away from the second state
# [14:17] <fantasai> divya: Maybe solve this through shadow dom?
# [14:18] <fantasai> TabAtkins: You'd be using shadow dom to put radio buttons into the shadow dom
# [14:19] <fantasai> TabAtkins: I think shadow dom brings in additional complexity that a tailored CSS solution wouldn't
# [14:19] <ChrisL> if the labels are in the shadow dom then accessibility helpers have more trouble discovering them
# [14:19] <fantasai> TabAtkins: It still doesn't give you the label functionality, necessary even for simple case of <details>
# [14:19] <fantasai> Bert: So Tab thinks it's a good idea, anyone else?
# [14:19] * Quits: Daisuke (~Daisuke@public.cloak) (Ping timeout: 60 seconds)
# [14:20] <fantasai> fantasai: I think it's good problem to solve
# [14:20] <fantasai> divya asks for a prototype
# [14:20] <fantasai> TabAtkins asks for objections
# [14:21] <fantasai> hober: Object to what? Thinking about the problem?
# [14:21] <fantasai> Bert: Question is, do we put this in some working draft
# [14:21] <fantasai> sylvaing: Adding another module?
# [14:21] <fantasai> hober: I'm pretty sure this falls into the bottom half of our prioritization list
# [14:21] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [14:21] * Joins: Cyril (~chatzilla@public.cloak)
# [14:22] <fantasai> Bert: So, a new working draft, it would be ok at some point
# [14:22] <fantasai> arronei: I don't think we need more than 2 states initially
# [14:22] <fantasai> TabAtkins: Does anyone think this is a bad idea, should not pursue?
# [14:23] <fantasai> hober: In generic case of multiple states, adding the complexity of essentially of a state machine to all elements of all languages, so maybe we should have reason to do this?
# [14:23] <fantasai> TabAtkins: I do this so often
# [14:23] <fantasai> arronei: It's such a common pattern on the Web, it's done everywhere
# [14:23] <fantasai> fantasai: I think this is a very common use case, to have collapsible elements etc.
# [14:24] <fantasai> fantasai: Think it's good to have a declarative solution
# [14:24] <fantasai> fantasai^: Done with JS etc. all the time
# [14:24] <fantasai> fantasai: whether purely CSS or integrating somehow with DOM
# [14:24] <divya> https://github.com/louisremi/Activable
# [14:24] * Joins: lstorset (~leif@public.cloak)
# [14:24] <divya> is one solution to do a declarative markup way to do UI components
# [14:25] <fantasai> fantasai: Might be useful for DOM to be able to reflect the states, or screen reader to react to the states
# [14:25] <ChrisL> http://www.w3.org/TR/scxml/
# [14:25] <divya> (which includes interactions such as what tab discussed)
# [14:25] <ChrisL> State Chart XML (SCXML): State Machine Notation for Control Abstraction
# [14:25] <ChrisL> W3C Working Draft 16 February 2012
# [14:25] <fantasai> plinss: Bottom line is, no objections to further investigation
# [14:25] <fantasai> Bert: <details> has another issue -- when I tried to model it, problem was that there's a part you want to show, and part you want to hide
# [14:26] <fantasai> Bert: want to hide most of it, except the summary
# [14:26] <TabAtkins_> Easy: details:not([open]) > :not(summary) { display: none; }
# [14:27] <fantasai> Bert: Hmm, let me go back and see if that solves it.
# [14:27] <TabAtkins_> Easy: details:not([open]) > :not(summary:first-of-type) { display: none; }
# [14:27] * hober doesn't think we need a resolution for tab to write more blog posts :)
# [14:27] <fantasai> leaverou: It doesn't work for direct text content of the <details>
# [14:28] * divya thinks there is a meme here
# [14:28] * divya also thinks tab should write less blog posts and more code that shows what he is thinking
# [14:28] * divya also dislikes reading text
# [14:29] <fantasai> RESOLVED: Toggleable states is a cool idea and work on it at some undetermined but not high priority
# [14:29] * ChrisL TS;WR too stupid; won't read
# [14:29] <fantasai> Bert: Lst item is a replaced item whose height depends on width, but not as an aspect ratio
# [14:29] * divya resolves to use TS;WR; going forward
# [14:29] <fantasai> Bert: e.g. <iframe seamless>
# [14:30] <fantasai> TabAtkins: I don't think there's anythign to do here
# [14:30] <fantasai> Bert: Need to update object negotiation rules for it
# [14:31] * Joins: Daisuke (~Daisuke@public.cloak)
# [14:31] <fantasai> TabAtkins: [..]
# [14:31] <fantasai> fantasai: I agree with Tab that I don't think we need to add any features to CSS for this
# [14:31] <fantasai> fantasai: But I also agree with Bert that the object negotiation algorithm to handle this
# [14:32] <fantasai> s/that the/that we need to update the/
# [14:32] <fantasai> ACTION TabAtkins and fantasai to update object negotiation algorithm in css4-images to handle <iframe seamless>
# [14:32] * trackbot noticed an ACTION. Trying to create it.
# [14:32] <trackbot> Sorry, couldn't find TabAtkins. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [14:32] * Joins: krit (~krit@public.cloak)
# [14:32] <ChrisL> trackbot, status
# [14:32] * Quits: trackbot (trackbot@public.cloak) (Request too long)
# [14:33] <fantasai> Bert: So the style sheet author doens't need to set anything?
# [14:33] <fantasai> fantasai: No, the object itself returns different information in this case
# [14:33] * Joins: trackbot (trackbot@public.cloak)
# [14:33] * Joins: shige (~shige@public.irc.w3.org)
# [14:34] <fantasai> fantasai explains why this is the case
# [14:34] <fantasai> Bert: Ok, I guess it's good enough
# [14:35] <fantasai> [you always try to get the best intrisic size that you can get, and in the case of non-seamless iframes this is nothing, whereas seamless iframes can return a sizing functio]
# [14:35] <TabAtkins_> ACTION Tab and fantasai to update object negotiation algorithm in css4-images to handle <iframe seamless>
# [14:35] * trackbot noticed an ACTION. Trying to create it.
# [14:35] <trackbot> Created ACTION-522 - And fantasai to update object negotiation algorithm in css4-images to handle <iframe seamless> [on Tab Atkins Jr. - due 2012-11-06].
# [14:37] <fantasai> Topic: Conditional Rules
# [14:37] <fantasai> TabAtkins: Only one remaining issue oncss3-conditional
# [14:37] <fantasai> TabAtkins: Decided to loosen parsing things, treating unknown constructs as false
# [14:37] <fantasai> TabAtkins: rather than making rule invalid
# [14:37] <fantasai> TabAtkins: The only real change is...
# [14:37] <fantasai> TabAtkins: This bit, supports_condition, now uses 'any' token from grammar
# [14:37] <fantasai> TabAtkins: As long as you match pretty much anything at all in there
# [14:38] <fantasai> TabAtkins: If you don't see one of the grammar constructs listed, it drops out as false
# [14:38] <fantasai> TabAtkins: Should be all we need.
# [14:38] <fantasai> TabAtkins: As far as I can tell, it's right
# [14:38] <fantasai> TabAtkins: It's just details to tweak to make it clearer
# [14:39] <fantasai> TabAtkins: So, because of this change, we should now have all issues resolved, and should be able to resolve to go to LC
# [14:39] <fantasai> TabAtkins: Anyone object to publish LC?
# [14:39] <fantasai> fantasai: I'd like dbaron to have a chance to review this, but otherwise looks good
# [14:40] <fantasai> RESOLVED: Publish css3-conditional on Tuesday unless dbaron objects within next few days
# [14:40] <fantasai> Bert: You're limiting what you can do in the future, but why make things false when you don't understand them?
# [14:40] <fantasai> TabAtkins: This is to make ti easier to extend in the future
# [14:41] <fantasai> TabAtkins: We don't want the presence of new things to wipe out the entire @supports rule in older UAs
# [14:41] <fantasai> TabAtkins explains why this makes sense
# [14:42] <fantasai> plinss: but sometimes will get wrong answer
# [14:42] <fantasai> TabAtkins: Will sometimes fail, but gives better forward-compat overall
# [14:42] <fantasai> plinss: Any other items on agenda?
# [14:42] <fantasai> TabAtkins: display model?
# [14:43] <fantasai> fantasai: or paged-media
# [14:43] <fantasai> [discussion of what's left to discuss]
# [14:44] * Quits: trackbot (trackbot@public.cloak) (Ping timeout: 60 seconds)
# [14:46] * Joins: massimo (~chatzilla@public.cloak)
# [14:47] <fantasai> Topic: display models
# [14:47] * fantasai is too tired to be smart today
# [14:47] <leaverou> http://dev.w3.org/csswg/css-display-3/
# [14:48] <fantasai> Tab reviews the draft with the WG
# [14:48] <fantasai> currently showing off display-inside/display-outside
# [14:49] * Joins: knobuta2 (~knobuta2@public.irc.w3.org)
# [14:50] * Joins: trackbot (trackbot@public.cloak)
# [14:51] <fantasai> showing off display-box (noneness switch)
# [14:51] <fantasai> stearns: Do you expect authors to use independnt properties, or just shorthand
# [14:51] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [14:51] <fantasai> TabAtkins: mostly shorthand, but in some cases would want separation
# [14:51] <fantasai> TabAtkins: e.g. the SVG case discussed earlier
# [14:51] <fantasai> stearns: imo the first two properties are too much noise for benefit, but third property -- certainly something we should do
# [14:52] <fantasai> TabAtkins: The first two are mostly a matter of simplifying the spec's model of things
# [14:52] <fantasai> TabAtkins: Our complexity ends up leaking into the [...[
# [14:52] <fantasai> TabAtkins: e.g. keep having to add inline- versions of everything
# [14:52] <fantasai> TabAtkins: But also adds some additional functionality
# [14:52] <fantasai> TabAtkins: e.g. table-caption with flex layout inside
# [14:53] * Quits: shige (~shige@public.irc.w3.org) (Ping timeout: 60 seconds)
# [14:53] <fantasai> TabAtkins: or table cells, which can only be blocks right now
# [14:53] * Quits: lmclister (~Adium@public.cloak) ("Leaving.")
# [14:53] * Quits: Norbert (~standards@public.cloak) (Norbert)
# [14:54] * Quits: r12a (rishida@public.cloak)
# [14:54] <fantasai> howcome: sympathsize with Tab's attempt to make this coherent, but also Alan's concern about whether we need to expose this to authors
# [14:54] <fantasai> fantasai: If splitting out display-none part, then the other part needs to go into some property
# [14:55] <fantasai> Bert: Why is splitting out display-none useful?
# [14:55] <fantasai> TabAtkins: So you don't clobber the previously-set display value -- need an on/off switch
# [14:55] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [14:57] <fantasai> fantasai: Going back, if we're going to split out 'display' type, and at any point going to split it further into -outside/-inside, should make that split now
# [14:57] <fantasai> fantasai: otherwise will need two levels of shorthanding if we ever split it into -outside/-inside
# [14:58] <fantasai> [Tab explains why splitting out is beneficial for layout models]
# [14:58] <fantasai> antonp: Good example is flex items
# [14:58] <fantasai> antonp: Didn't want to have anonymous box tree generation in order to have flex-item display type
# [14:58] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [14:59] * fantasai missed what Tab said
# [15:00] <fantasai> plinss: What if I say table-header-group, and inside is block?
# [15:00] <fantasai> TabAtkins: Think there needs to be an edit that such things compute -inside to auto
# [15:00] <fantasai> antonp: I think key thing here is not this conceptual level, but what Bert was trying to tell me the other night
# [15:01] <fantasai> antonp: what does it really mean, for something to be an inline-block
# [15:01] <fantasai> antonp: If inline-level, participates in an inlin formatting context
# [15:01] <fantasai> antonp: but not the same as a string of text; can't split across lines
# [15:01] <fantasai> antonp: What's causing
# [15:01] * Quits: cabanier1 (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [15:02] <fantasai> antonp: that special behavior?
# [15:02] <fantasai> TabAtkins: The combination of inline-level and auto does special behavior
# [15:03] <fantasai> howcome: if we just have the display, then we name things that make sense and don't give names that don't make sense
# [15:03] <fantasai> TabAtkins: things that don't make sense to combine, you force inside to auto
# [15:03] <fantasai> howcome: it's a lot
# [15:03] <fantasai> TabAtkins: It's not a lot
# [15:03] <fantasai> TabAtkins: ...
# [15:04] <stearns> http://hyperboleandahalf.blogspot.fr/2010/04/alot-is-better-than-you-at-everything.html
# [15:04] <fantasai> howcome: Cascading things separately could be a problem
# [15:04] <fantasai> TabAtkins: Forcing is at computed value time
# [15:04] <fantasai> TabAtkins: There's 3 display-outside values: inline, block, and tabley things
# [15:05] <fantasai> ...
# [15:05] <fantasai> plinss: There are cases where you might want to toggle just the outside, e.g. just switch inline to block or vice versa, without affecting insides
# [15:05] <fantasai> Bert: I had 2 reasons for dropping it
# [15:05] <fantasai> Bert: Found out all combinations, that I was defining more, not less, with the split
# [15:05] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [15:06] <fantasai> Bert: Other thing was, even found myself only using the 'display' property
# [15:07] <fantasai> Bert: regardless of naming, kept thinking in terms of display types as a whole
# [15:08] <fantasai> Bert: Other issue wrt display...
# [15:08] <fantasai> Bert: For flex, let it be a display type, mainly didn' tthink anyone would use inline-flex
# [15:08] <fantasai> Bert: But grid, not convinced
# [15:09] <fantasai> Bert: Grid element should just have a grid property
# [15:09] <fantasai> Bert: it's a block, just like any other block
# [15:09] <fantasai> hober: it's a block on the outside, it's a grid on the inside...
# [15:09] <fantasai> plinss: when I went through grid proposal, felt the same way -- everything should be able to have a grid
# [15:10] * Joins: cabanier (~cabanier@public.cloak)
# [15:10] <fantasai> plinss: The difference here is, that MSFT model has ability for contents to push around the lines and size arond the contents
# [15:10] <fantasai> plinss: Can't do that
# [15:10] <fantasai> otherwise
# [15:10] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [15:10] <fantasai> plinss: while I think grids should be able to go anywhere
# [15:10] <fantasai> plinss: think there also needs to be a way to have a grid that auto-size around things
# [15:10] <fantasai> plinss: they're different
# [15:11] <fantasai> antonp: Another problem.. multi-col properties apply to block containers
# [15:11] <fantasai> antonp: but once you turn it into multi-col by applying those properties, it's no longer a block container
# [15:11] <fantasai> antonp: weird editorial cycle
# [15:11] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [15:11] <fantasai> ...
# [15:12] <fantasai> ChrisL: In SVG, ppl pick a random value when they're switching display on/off.
# [15:12] <fantasai> ChrisL: It doesn't matter whether choose inline or block, for the SVG, nless you inheriting down into something else
# [15:12] <fantasai> ...
# [15:12] <fantasai> TabAtkins: when we were talking about flexbox, you wanted ability to say an item is a flex-item, so that can wrap around it
# [15:13] <fantasai> TabAtkins: What model is used inside the flex item?
# [15:13] <fantasai> TabAtkins: table? flex? block?
# [15:13] <fantasai> TabAtkins explains cases where you want to mix models
# [15:13] <fantasai> TabAtkins: Only reason display works ok right now is b/c outside values are just block and inline
# [15:14] <fantasai> TabAtkins: Once we add another outside value, then the combinations will explode
# [15:14] * stearns heard "all y'all" somewhere in there
# [15:14] <fantasai> TabAtkins: Right now it's sane only because we have only two columns
# [15:15] * divya thinks we need demos
# [15:15] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 60 seconds)
# [15:15] * divya less talk more usecases
# [15:15] <fantasai> TabAtkins gives an example of <h1>, <table>, <p> put into a flexbox
# [15:16] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [15:16] * Quits: glazou (~glazou@public.cloak) (glazou)
# [15:17] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [15:17] <fantasai> <br>
# [15:17] <fantasai> return at 5pm
# [15:17] <fantasai> er
# [15:17] <fantasai> 4pm
# [15:17] * Joins: JohnJansen (~JohnJansen@public.cloak)
# [15:19] * leaverou is now known as leaverou_away
# [15:20] * Quits: Yune (~Yune@public.irc.w3.org) (Ping timeout: 60 seconds)
# [15:20] * Quits: nsakai (~nsakai@public.irc.w3.org) (Ping timeout: 60 seconds)
# [15:21] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [15:21] * Quits: mollydotcom (~mholzsch@public.cloak) (mollydotcom)
# [15:22] * Quits: yamaday (~yamaday@public.cloak) (Ping timeout: 60 seconds)
# [15:22] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) (Ping timeout: 60 seconds)
# [15:23] * sylvaing is now known as sylvaing_away
# [15:27] * Joins: Norbert (~standards@public.cloak)
# [15:32] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [15:33] * Joins: cabanier (~cabanier@public.cloak)
# [15:33] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [15:38] * sylvaing_away is now known as sylvaing
# [15:40] * Joins: Rossen (~Rossen@public.cloak)
# [15:43] * Joins: mihara (~mihara@public.cloak)
# [15:46] * Joins: Shinji (shinji@public.cloak)
# [15:47] * Joins: krit (~krit@public.cloak)
# [15:48] * Joins: glazou (~glazou@public.cloak)
# [15:49] * Joins: mgylling (~mgylling@public.cloak)
# [15:49] * Joins: mgylling_ (~mgylling@public.cloak)
# [15:50] * Joins: yune (~yune@public.irc.w3.org)
# [15:50] * Joins: yamaday (~yamaday@public.cloak)
# [15:51] * Joins: dbaron (~dbaron@public.cloak)
# [15:53] * Quits: mgylling (~mgylling@public.cloak) (Ping timeout: 60 seconds)
# [15:53] * mgylling_ is now known as mgylling
# [15:53] * Quits: mihara (~mihara@public.cloak) (Client closed connection)
# [15:54] * Joins: nsakai (~nsakai@public.irc.w3.org)
# [15:55] * Joins: lmclister (~Adium@public.cloak)
# [15:57] * Joins: lstorset (~leif@public.cloak)
# [15:58] * Joins: shepazu (schepers@public.cloak)
# [15:59] * leaverou_away is now known as leaverou
# [16:01] * Joins: rubylin (~rubylin@public.cloak)
# [16:01] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [16:01] * Joins: r12a (rishida@public.cloak)
# [16:02] * Joins: SteveZ (~chatzilla@public.cloak)
# [16:04] * Joins: kotakagi (~Koichi_Takagi_KDDI@public.cloak)
# [16:04] * Joins: lstorset (~leif@public.cloak)
# [16:06] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [16:07] * Joins: tantek (~tantek@public.cloak)
# [16:08] * Quits: Shinji (shinji@public.cloak)
# [16:08] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [16:11] * Joins: Shinji (shinji@public.cloak)
# [16:12] * Quits: Shinji (shinji@public.cloak)
# [16:13] <sylvaing> scribenick:sylvaing
# [16:14] * Quits: yune (~yune@public.irc.w3.org) ("Page closed")
# [16:14] * Joins: Yune (~Yune@public.irc.w3.org)
# [16:15] <sylvaing> howcome: I think the list of odd cases is not long enough to justify the split
# [16:15] <sylvaing> tantek: I think the list is long
# [16:15] <sylvaing> tabatkins: today we have inline versions of a number of displays
# [16:16] <sylvaing> tabatkins: we may want a flex-item display value in the future
# [16:16] <sylvaing> tabatkins: but then we'd add 4 versions of flex item
# [16:16] <sylvaing> tabatkins: every new display outside type multiplies the combinations
# [16:17] <sylvaing> howcome: but not all these combinations make sense
# [16:17] * Joins: rotsuya (~rotsuya@public.cloak)
# [16:17] <sylvaing> tabatkins: all these combinations exist today
# [16:17] <sylvaing> tabatkins: and it will keep growing as we add new layout modes
# [16:18] * Quits: shepazu (schepers@public.cloak) ("has better things to do...")
# [16:18] <sylvaing> tantek: does it make sense for these properties to cascade these properties separately?
# [16:18] * Joins: shepazu (schepers@public.cloak)
# [16:18] <sylvaing> plinss: yes
# [16:19] * Joins: kensaku (~kensaku@public.cloak)
# [16:19] <sylvaing> tabatkins: also we have some display-outside values that only take blocks inside right now but we could argue that they should support more e.g. table-caption
# [16:20] <sylvaing> howcome: but you still have to describe the combinations that don't work
# [16:20] <sylvaing> tabatkins: there are not that many
# [16:20] <sylvaing> antonp: ruby?
# [16:20] <sylvaing> tabatkins: that works similarly to table
# [16:20] <sylvaing> antonp: yes
# [16:20] * Joins: mgylling (~mgylling@public.cloak)
# [16:20] * Parts: mgylling (~mgylling@public.cloak) (mgylling)
# [16:21] <sylvaing> howcome: what's the issue with ruby?
# [16:21] <sylvaing> tabatkins: this is not in yet. everything except table-cell and table-caption force the inside to auto
# [16:21] <sylvaing> tabatkins: they only make sense in the context of tables; they're not fully independent i.e. they're not just display-outsides
# [16:22] <sylvaing> tabatkins: any new display mode we add would work the same; they would combine with everything
# [16:23] <sylvaing> antonp describes his proposal re: ruby
# [16:23] * Joins: koji (~koji@public.cloak)
# [16:23] <antonp> http://lists.w3.org/Archives/Public/www-style/2012Oct/0554.html
# [16:23] <sylvaing> tabatkins: we'd have display-outside: ruby-* then inside would be auto
# [16:24] <sylvaing> howcome: so will we say new outside values force auto?
# [16:24] <sylvaing> tabatkins: we would do it as needed
# [16:25] * Quits: massimo (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [16:25] <sylvaing> antonp: you could argue all the display values for table were overkill; were 7-8 values for table necessary? would we do this again?
# [16:26] * Joins: sakkuru (~sakkuru@public.cloak)
# [16:26] <sylvaing> bert: we also have run-in, this should be inline inside
# [16:26] <sylvaing> tabatkins: yes
# [16:26] <sylvaing> antonp: we're not trying to get rid of awkward cases; we're trying to enable independent toggling for many of the cases that make sense
# [16:26] <sylvaing> antonp: the purpose of this is not to remove the inherent complexity we already have
# [16:27] <sylvaing> antonp: just adding power to express things in a more flexible and powerful way
# [16:27] <sylvaing> bert: why add complexity ?
# [16:27] <sylvaing> tabatkins: because we are currently avoiding situations that are painful in the current model
# [16:28] <sylvaing> tabatkins: e.g. any new feature that requires adding a ton of display keywords is a turn-off
# [16:28] <sylvaing> ChrisL: an inside and outside is not that complex, is it?
# [16:28] <sylvaing> plinss: the common use-case is that someone is going to use the shorthand then override one aspect of it somewhere else.
# [16:28] * Joins: leehomlin (~rubylin@public.cloak)
# [16:29] <sylvaing> plinss: so the common use-case is not authors specifying both inside and outside everywhere
# [16:29] * Quits: rubylin (~rubylin@public.cloak) (Ping timeout: 60 seconds)
# [16:29] <sylvaing> tabatkins: we make it easier to add new values but at a lower cost
# [16:30] <sylvaing> tantek: I have run into cases where I wanted to only change the outside because someone already defined the inside
# [16:31] <sylvaing> tantek: I wanted to lay it out along other things e.g. using MQ turn some inline thing into block level for responsive design
# [16:32] <sylvaing> tantek: I just want to style the outside, not the inside
# [16:32] <sylvaing> tantek: this is a use-case
# [16:33] <sylvaing> antonp, bert: it's not just a matter of flipping the switch; you may also want to adjust widths and other measures and that will interact with the inside
# [16:33] <sylvaing> antonp: but there may be a way to do this negotiation using some of the new keywords in the sizing spec
# [16:33] <sylvaing> antonp: so I'm not sure outside/inside are fully independent
# [16:34] <sylvaing> tantek: for many inline blocks it would work with minimal work.
# [16:34] <sylvaing> antonp: tables, on the other hand, would be more complicated.
# [16:34] * Joins: massimo (~chatzilla@public.cloak)
# [16:35] <sylvaing> tantek: yes, and we'll have more questions once people use this with real content. but in terms of utility and use-cases I think we have it.
# [16:36] <sylvaing> tantek: the hack I'm using right now is float; it's my display-outside:block. it's workable but not elegant or intuitive.
# [16:36] <sylvaing> Bert: but that doesn't give you the right alignment
# [16:36] <sylvaing> tantek: exactly!
# [16:37] * Quits: nsakai (~nsakai@public.irc.w3.org) (Ping timeout: 60 seconds)
# [16:37] <sylvaing> Bert: I still think you may need to adjust margins, padding etc.
# [16:37] <sylvaing> antonp: yes, but we can handle that
# [16:38] <sylvaing> plinss: and the author can change that but that's better than having to handle all the side-effects of switching to floats
# [16:38] <sylvaing> plinss: or you may have to change the markup, which is worse
# [16:38] <sylvaing> tantek: i'd like to get this to a stage where we can get some implementation experience and iterate from there
# [16:38] <sylvaing> tantek: and yes, there will be things we do not expect
# [16:38] <sylvaing> tantek: but we should try to get there
# [16:39] <sylvaing> plinss: we'll also find new things that are really cool and would not be able to do in any other way
# [16:39] <sylvaing> howcome: I agree but I fear that some of the complexities that will appear will be implementation-specific hacks
# [16:39] <sylvaing> howcome: achieving interop will take time
# [16:40] <sylvaing> howcome: but I can see tantek's use-case
# [16:40] <sylvaing> plinss: do we proceed with this or not?
# [16:40] <sylvaing> Bert: I think we have more important things to do...
# [16:40] <sylvaing> plinss: we're not deciding priorities
# [16:41] <tantek> here's an actual use-case where I had to hack floats to get the display effects I wanted where I think it would have been easier with display-outside and display-inside
# [16:41] <sylvaing> tabatkins: is it OK to make it an ED?
# [16:41] <tantek> http://tantek.com/xoxo-2012-directory
# [16:41] <sylvaing> fantasai: display:none discards the element from the rendering tree; some of the values you have - contents - don't quite do that
# [16:42] <sylvaing> tabatkins: no it's not there, only its children
# [16:42] <sylvaing> fantasai: I'm not sure that is what authors actually want
# [16:43] <sylvaing> fantasai: is it the right place to have this control? maybe we need to rethink display-none; one meaning discard from the rendering tree, the other means that it's not in the rendering tree but it is preserved for things like counters
# [16:43] <sylvaing> fantasai: so you could hide a list item without renumbering your list
# [16:44] <sylvaing> tabatkins: I have issues in the spec for this
# [16:44] <sylvaing> plinss: objections to ED?
# [16:44] <sylvaing> RESOLVED: start css-display-3 as a new ED
# [16:45] <fantasai> ScribeNick: fantasai
# [16:46] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15242
# [16:46] <fantasai> sylvaing: I believe it was the last F2F or theone before, we discussed the way animations affect the cascade
# [16:46] <fantasai> sylvaing: an interesting issue came out of this bug is the interaction of animations with concurrent positions
# [16:46] <fantasai> sylvaing: animations trigger during a transition
# [16:46] <fantasai> sylvaing: do we treat the transition as if it runs in the background? pause it?
# [16:46] <fantasai> sylvaing: not defined at all
# [16:46] <fantasai> sylvaing: Not sure there's interop anyway
# [16:47] * Joins: jeff (jeff@public.cloak)
# [16:47] <fantasai> sylvaing: essentially, you hover over an element, it transitions, halfway through an animation starts -- what happens?
# [16:47] <fantasai> dbaron, ping
# [16:47] <dbaron> fantasai, pong
# [16:48] <fantasai> dbaron, see sylvain's issue?
# [16:48] <fantasai> dean: we've implemented that the transition is still running in the background
# [16:49] <fantasai> dean: if the transition is still running, it picks up from where it would have been in the transition
# [16:49] <fantasai> plinss: does the animation pick up from where the transition was?
# [16:50] <fantasai> fantasai: This all seems kindof wrong to me. I don't understand why transitions don't win.
# [16:50] <fantasai> plinss: Either way, still have same problem of one taking over from other one
# [16:50] * Quits: leehomlin (~rubylin@public.cloak) (Ping timeout: 60 seconds)
# [16:51] <fantasai> fantasai: [...]
# [16:51] <fantasai> dean: Transitions aren't more important than animations b/c they operate on property changes
# [16:51] <fantasai> dean: would be kindof weird for animation that's running, then a transition triggers.. does a thing, and then jumps back to the animation frame
# [16:52] <fantasai> dean: My proposal is to follow what Webkit's done, which is transition is still running, events still fire
# [16:52] <fantasai> dean: and I'm not sure what the spec says, wrt what to do with 0 or 100% keyframes, if they're missing
# [16:53] <fantasai> plinss: if they're missing, would make sense to pick up from where the transition was, and if the 100% is missing pick up where the animation's at
# [16:54] <fantasai> plinss: If the transition's running, and during the transition an animation fires, runs to completion, and leaves the property in a different state than what the transition would have done, had it not been interrupted, and the transition still has time left, where does the property go?
# [16:54] <fantasai> plinss: does it go to where the property would have been if there was no animation?
# [16:55] <fantasai> dean: ...
# [16:55] <fantasai> dean: you should act as if animations could exist in a world where there are no transitions
# [16:55] <fantasai> dean: in that case, we would always override and never pause that zero-length instantaneous transition effect
# [16:55] <fantasai> dean: I'm not sure if we actually have any issues here, if people agree
# [16:55] <fantasai> dean: I think maybe the spec has enoughwording, provided we add this description of what happens
# [16:56] <fantasai> dean: for zero and 100% case
# [16:56] <fantasai> dean: interesting question of whether missing from keyword should result in starting from transition point, or from transition start point
# [16:56] <fantasai> dean: seems like it makes sense to start from transition point
# [16:56] <fantasai> plinss: Suppose I'm animating a box's height trhough a transition over 5s
# [16:57] <fantasai> plinss: halfway through an animation runs that wiggles it, and then leaves it where started
# [16:57] <fantasai> plinss: transition continues
# [16:57] <fantasai> plinss: would that jump from start point to where transition would have been?
# [16:57] <fantasai> plinss: or transition resumes from where animation left it?
# [16:57] * Joins: Wonsuk (~wonsuk73@public.cloak)
# [16:57] <fantasai> plinss: The whole point of a transition is you don't want things do jump
# [16:57] <fantasai> plinss: do you really want to introduce these jumps
# [16:58] <fantasai> sylvaing: You have no discontinuity at the beginning
# [16:58] * Quits: lmclister (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [16:58] <fantasai> ChrisL: would it make a difference if you freeze the animation?
# [16:58] <fantasai> sylvaing: repeats when transition is stil running...
# [16:58] <fantasai> dean: Think the spec should say, calculate 0 or 100% and keep that forver
# [16:59] * Quits: massimo (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [16:59] <fantasai> dean: That saves us having to do 2 computations to figure out the style
# [16:59] <fantasai> plinss: Agree it makes implementation crazy, but wrt author ...
# [16:59] <fantasai> arronei: Maybe put a warning to authors, that if you animate and transiton same property values, it will not be smooth
# [16:59] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [17:00] <fantasai> plinss: If doing the right thing was reasonably simple and cheap, do the right thing
# [17:00] <fantasai> plinss: but better to do something lame consistently on all browsers
# [17:00] <fantasai> plinss: than to have inconsistency across browsers
# [17:00] <fantasai> plinss: want the author to see right away exactly what ways things are messed up
# [17:00] <fantasai> dean: what if you have CSS and SMIL animation on the same thing?
# [17:01] <fantasai> dean: in webkit righ now it pingpongs
# [17:01] <fantasai> tantek: Is there an effort to unify CSS and SMIl animations?
# [17:01] <fantasai> ChrisL: yes, it's caled web Animations
# [17:01] <fantasai> krit: ...
# [17:01] <fantasai> krit: We came up with proposal that the attribute style, in svg, has the lowest priority of both style sheets
# [17:02] <fantasai> krit: Then when we animate CSS property, describes before transition and animation
# [17:02] <fantasai> krit: Therefore overrides SMIL animation
# [17:02] <fantasai> krit: Already implemented in webkit and Gecko this way
# [17:02] <fantasai> krit: can't tell about Opera
# [17:02] <fantasai> ...
# [17:02] <fantasai> dean: I think our resolution is that transitions continue to run and still is overridden by animations wanted
# [17:03] <fantasai> dean: Even if you're overriding the property
# [17:03] <ChrisL> s/.../leif: we have them now in Opera
# [17:03] <fantasai> sylvaing: If 2 completely different sets of properties, happen simultaneously
# [17:03] <fantasai> sylvaing: Talked about ...
# [17:03] <fantasai> sylvaing: We may want to have smooth transition back to ...
# [17:04] <fantasai> fantasai interrupts:
# [17:04] <fantasai> fantasai: San Diego we have a resolution that transitions happen last in the cascade
# [17:04] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0900.html
# [17:04] * Joins: lstorset (~leif@public.cloak)
# [17:06] <fantasai> [..]
# [17:06] * Joins: massimo (~chatzilla@public.cloak)
# [17:06] <fantasai> plinss: It's not the transition rule that's causing it to transition now, it's because some other rule got applied, which is not overridden by the animation rule
# [17:07] <fantasai> fantasai: This resolution says that if you transition and animate the same property at the same time, you don't see the animation, just the transition
# [17:08] <fantasai> fantasai: The properties that are in transition are last in the cascade
# [17:08] <fantasai> dean: you can't do that
# [17:09] <fantasai> fantasai: I believe Gecko does
# [17:09] <fantasai> sylvaing reads/interprets the minutes
# [17:09] <fantasai> dean: Suppose I'm moving this box over 1s
# [17:10] <fantasai> dean: At the same time I have an animation that moves the top value from here to here
# [17:11] <TabAtkins_> fantasai, dino: [discussion of example]
# [17:11] * Joins: shige_ (~shige@public.cloak)
# [17:12] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [17:12] <cabanier> jsfiddle example: http://jsfiddle.net/FALtu/
# [17:12] * Joins: Shinji (shinji@public.cloak)
# [17:14] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
# [17:14] * Joins: odinho_ (~Velmont@public.cloak)
# [17:18] * Joins: koji (~koji@public.cloak)
# [17:18] * Quits: shige_ (~shige@public.irc.w3.org) ("Page closed")
# [17:19] <TabAtkins_> dino_: If the user wants to stop a transition, they put !important in their stylesheet. But that won't stop an animations.
# [17:19] <TabAtkins_> dino_: To stop animation, they put "animation: none !important;" in their user stylesheet to kill it.
# [17:20] <TabAtkins_> fantasai: No, if you have a property that is set to some value in the user!important stylesheet, that property cant' animate. The user!important rule overrides the animation rule. Per the resolution that animatinos are below user!important, nota bove.
# [17:21] <TabAtkins_> sylvaing: It doesn't stop animations...
# [17:21] <TabAtkins_> fantasai: yes, the animation still *happens*, but that property doesn't change.
# [17:21] <TabAtkins_> plinss: Now how does that realte to transitions?
# [17:21] * Quits: massimo (~chatzilla@public.cloak) (Client closed connection)
# [17:21] <TabAtkins_> plinss: If the user has a !importatn color, how can that possibly transition?
# [17:22] <TabAtkins_> Bert: They have two user!important rules.
# [17:22] <TabAtkins_> plinss: So the transition will still happen. But that has no effect on an animation from the author.
# [17:23] <TabAtkins_> plinss: What does transitions in the cascade mean? Transitions aren't cascading.
# [17:23] <TabAtkins_> fantasai: the "virtual declaration" that's in effect (dictating the value of the property at that moment from the transition)...
# [17:23] <TabAtkins_> fantasai: That declaration is the last thing in the cascade. It wins over everything else.
# [17:23] * Joins: florianr (~yaaic@public.cloak)
# [17:24] * dbaron is going to come back to the CSS room now
# [17:24] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [17:25] <TabAtkins_> plinss: So now we're flipping the case - transitions override animations, not the other way around?
# [17:25] <TabAtkins_> fantasai: Yes.
# [17:25] <TabAtkins_> plinss: Now the case is - there's an animation running, and something else happens that causes a transition.
# [17:26] <TabAtkins_> plinss: My color is pulsing from an animation, but then I hover, which changes it to black.
# [17:26] * Quits: Daisuke (~Daisuke@public.cloak) (Ping timeout: 60 seconds)
# [17:26] <TabAtkins_> plinss: So the answer seems to be that I transition *from the current animated value* (because that's the current computed value) to black.
# [17:27] <cabanier> example of a transition during an animation: http://jsfiddle.net/FALtu/
# [17:27] <TabAtkins_> plinss: Then, if I stop hovering, I think that it should transition over to the current animated value, since the animation has continued to run this whole time.
# [17:28] <TabAtkins_> krit: Transitioning from the current animated value is very hard in SMIL. It will be similarly hard to implement in CSS Transitions.
# [17:29] <TabAtkins_> [we all update David on the discussion]
# [17:30] <TabAtkins_> dbaron: My pref is that if we want the animation to win when it's running with a transition, we should do that with something other than the cascade.
# [17:30] <TabAtkins_> dbaron: Just say that the transition disappears.
# [17:31] <TabAtkins_> dbaron: If it's the other way around, I don't think we need anything special.
# [17:32] <TabAtkins_> dino_: I think animations should always trump transitions, with the exception of !important.
# [17:32] <TabAtkins_> dbaron: The thing is, it's very hard to make that happen.
# [17:32] <TabAtkins_> dbaron: It's hard to make a transition run when an animation is running too.
# [17:33] <TabAtkins_> dbaron: It's hard to make a transition start when an animation is running.
# [17:33] * fantasai totally disagrees with dean
# [17:33] <TabAtkins_> plinss: [gives his pulsing color example]
# [17:33] <TabAtkins_> plinss: So should the transition even happen? If it does, should it transition from the currently animated value, or the base value (ignoring animations).
# [17:34] <TabAtkins_> dino: The reason comes back to transitions being just property changes spread out a bit.
# [17:34] <TabAtkins_> dbaron: So do you think transitions should happen if the 'to' or 'from' is a user!important rule?
# [17:35] <TabAtkins_> dbaron: Like something that says "a:hover { color: pink; }"
# [17:35] <TabAtkins_> dbaron: If there's also a transition request for that property, does that transition happen?
# [17:35] * tantek makes an aside query, do we have a media query selector for *actual* desktop displays/interfaces? E.g. http://lh6.ggpht.com/_XOET0984s-4/TQ_R56FrmrI/AAAAAAAAAZQ/-0wkG53dr2Y/17-12-2010%2015-02-15.png.jpg and http://alpinegarrison.com/images/movies/tron_legacy_unix_os.jpg
# [17:36] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [17:36] <TabAtkins_> dbaron: In order to transition, the transition's "virtual rule" has to be higher in the cascade than the user!important rule.
# [17:37] * Joins: mjs (~mjs@public.cloak)
# [17:37] <TabAtkins_> dbaron: So you have an author stylesheet with "a:link { color: green; transition: color .25s; }" and a user!important sheet with "a:hover { color: black !important; }"
# [17:37] <TabAtkins_> dbaron: What happens?
# [17:37] <TabAtkins_> dino_: It transitions to black.
# [17:38] <TabAtkins_> dbaron: Okay, so it either immediately changes or it transitions.
# [17:38] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [17:38] <TabAtkins_> dbaron: So with your answer, the transition overrides it.
# [17:38] * fantasai thinks we should just accept that dbaron wins
# [17:38] * stearns thinks that what you always think
# [17:39] <TabAtkins_> TabAtkins_: If you go the other way (no transition from green to black, but a transition from black back to green), then that implies that you can *never* transition between two user!important values, because they *always* beat the transition. Hopefully you see that's not very good.
# [17:39] * Joins: kensaku (~kensaku@public.cloak)
# [17:40] <TabAtkins_> plinss: So I see no reason for it to not transition to/from black.
# [17:40] <TabAtkins_> plinss: And if there's another user!important rule that sets the color to something different in non-hover, it should transition those two colors as well.
# [17:40] <TabAtkins_> plinss: (author added the transition, but we're still respecting the user's colors)
# [17:40] <TabAtkins_> plinss: If the user didn't want transitions at all, they can add "* { transition: none !important; }"
# [17:42] * Quits: florianr (~yaaic@public.cloak) ("")
# [17:42] * Joins: Cyril (~chatzilla@public.cloak)
# [17:42] <TabAtkins_> fantasai: Clarification. If I have at the author level, two color rules, one on hover one on non-hover. That'll trigger a transition when I hover.
# [17:42] * Joins: plh (plehegar@public.cloak)
# [17:42] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
# [17:42] * Quits: yamaday (~yamaday@public.cloak) ("TakIRC")
# [17:42] * Quits: Shinji (shinji@public.cloak)
# [17:42] * Quits: glazou (~glazou@public.cloak) (glazou)
# [17:43] * Quits: jeff (jeff@public.cloak) ("Leaving")
# [17:43] <TabAtkins_> fantasai: If I have an animation on the element as well, then the color rules of the animation, because they're at a higher cascade level, at every point in time override those previous two rules, and therefore no transition is triggered.
# [17:43] * Quits: kotakagi (~Koichi_Takagi_KDDI@public.cloak) ("TakIRC")
# [17:43] <TabAtkins_> dbaron: That's not actually how it works in Gecko, but I dont' like Gecko's implementation.
# [17:43] <plh> q+ to bring up a web perf issue
# [17:43] * Zakim sees plh on the speaker queue
# [17:44] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [17:44] <fantasai> TabAtkins paraphrases fantasai
# [17:45] * Quits: sakkuru (~sakkuru@public.cloak) (Ping timeout: 60 seconds)
# [17:45] <TabAtkins_> plinss: So you have an animation running. Magical animation rules overriding all other cascade levels (besides transition).
# [17:45] * stearns oh no! more magic!
# [17:45] <TabAtkins_> plinss: Now if I hover over it, the hover rule's declaration loses the cascade, so no transition happens.
# [17:45] * Joins: jarek (~jarek@public.cloak)
# [17:45] * sylvaing The magic will continue until morale improves
# [17:45] <TabAtkins_> plinss: Now say the animation isn't running. I have a long transition - a 5s one on hover.
# [17:46] * fantasai loves CSS
# [17:46] * sylvaing pixie-dust: avoid;
# [17:46] <TabAtkins_> plinss: while I'm hovering, the transition is doing it's magical style rule.
# [17:46] <TabAtkins_> plinss: Now I trigger some other rule that starts an animation over the property. What happens? What wins?
# [17:47] * sylvaing this Back to the Future, CSS edition
# [17:47] <TabAtkins_> plinss: What I think elika's model is saying implies that the animation happens, it runs, everything goes normally. But the transition-created rule is still running at a higher cascade level, and so it overrides the animation's *effects* as long as it runs.
# [17:47] <ChrisL> q?
# [17:47] * Zakim sees plh on the speaker queue
# [17:47] * Quits: SteveZ (~chatzilla@public.cloak) (Client closed connection)
# [17:47] <TabAtkins_> plinss: To the implementation, transitions win, and everything works more or less statelessly.
# [17:48] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 60 seconds)
# [17:48] * Joins: SteveZ (~chatzilla@public.cloak)
# [17:48] * Joins: tokamoto (~tokamoto@public.cloak)
# [17:48] <TabAtkins_> plinss: To the author, it kinda looks like the first-set wins, just becasue whether the transition starts or not depends on whether the animation is running.
# [17:49] <Bert> q+ to ask if state change triggers transition or property value change. If the latter, does the end of an animation trigger a transition back to the normal value?
# [17:49] * Zakim sees plh, Bert on the speaker queue
# [17:49] * fantasai wants to question one of plinss's assumptions here
# [17:49] * sylvaing http://w3cmemes.tumblr.com/post/34634329920/csswg-resolves-to-use-less-magic
# [17:50] <TabAtkins_> [dbaron is drawing out the cascade levels]
# [17:50] <divya> :'(
# [17:50] <divya> that meme outmemed itself
# [17:50] * ChrisL to ansewr bert transitions trigger on state changes in computed values; animations happen on top of that and do not trigger transitions or they would trigger hundreds of them
# [17:51] * sylvaing ChrisL: we already resolved that updates from animations or transitions do not trigger transitions
# [17:51] * Joins: glenn (~gadams@public.cloak)
# [17:51] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [17:52] <TabAtkins_> dbaron: UA < user < author < magic-animation < author!important < user!important < UA!important < magic-transition
# [17:52] <TabAtkins_> dbaron: This is what Gecko does.
# [17:52] <TabAtkins_> dino_: WebKit does something else.
# [17:52] * Joins: rotsuya (~rotsuya@public.cloak)
# [17:53] <ChrisL> .@sylaing yes I know I was just explaining to @Bert
# [17:53] * Joins: sakkuru (~sakkuru@public.cloak)
# [17:54] <TabAtkins_> dino: In WebKit, magic-transition is higher than UA!important, and magic-animation is higher than that.
# [17:55] <TabAtkins_> TabAtkins_: If you set a user!important property to something static, does that override the animation or not?
# [17:55] <TabAtkins_> dino_: It does.
# [17:55] <TabAtkins_> TabAtkins_: Then you have a contradiction. Your behavior cannot be explained in terms of cascade.
# [17:56] <TabAtkins_> s/in terms/solely in terms/
# [17:56] <TabAtkins_> plinss: Can we action you to come back with examples of behaviors, and demonstrate why that makes sense from the user perspective?
# [17:56] <TabAtkins_> dbaron: I also definitely want to see what the behavior actually is.
# [17:56] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [17:57] <TabAtkins_> plinss: I think we all agree that transitions belong where they are (higher than all non-magic rules).
# [17:57] <TabAtkins_> plinss: We're disagreeing on what animations do.
# [17:57] * Zakim dbaron, you asked to be reminded at this time to go home
# [17:57] * Quits: Yune (~Yune@public.irc.w3.org) ("Page closed")
# [17:58] <TabAtkins_> ACTION Dean to come back with an explanation of WebKit's animation model, and why it makes more sense for users.
# [17:58] * trackbot noticed an ACTION. Trying to create it.
# [17:58] <trackbot> Created ACTION-523 - Come back with an explanation of WebKit's animation model, and why it makes more sense for users. [on Dean Jackson - due 2012-11-06].
# [17:58] <TabAtkins_> plh: Speaking on behalf of WebPerf, I'm here to make your life more complex.
# [17:58] <TabAtkins_> plh: We're working on animation too - requestAnimationFrame.
# [17:58] <TabAtkins_> plh: [explains rAF]
# [17:59] <ChrisL> http://www.w3.org/TR/animation-timing/#requestAnimationFrame
# [18:00] * Joins: kensaku_ (~kensaku@public.cloak)
# [18:00] <TabAtkins_> dino_: I think rAF is signif. flawed becasue you can't use it for situations where you want a callback but not at the display rate.
# [18:01] <TabAtkins_> TabAtkins_: You use setTimeout for that. rAF is just for things that want to key into the frame rate.
# [18:01] <TabAtkins_> plh: [more explanation of rAF behavior]
# [18:01] * leaverou is now known as leaverou_away
# [18:02] <plh> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0040.html
# [18:02] <TabAtkins_> plh: FF runs rAF even on inactive tabs, despite it violating the spec. The reason is that they run it on the CSS Animations loop, and don't want to run things twice.
# [18:02] <TabAtkins_> s/run things twice/run them on two separate animation loops/
# [18:02] <plh> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0043.html
# [18:03] * Quits: kensaku (~kensaku@public.cloak) (Ping timeout: 60 seconds)
# [18:04] * leaverou_away is now known as leaverou
# [18:04] <TabAtkins_> TabAtkins_: Based on what we already agreed to write yesterday (regarding animation scrubbing and how the events get fired in various cases), once that's finished, this behavior will be easy to specify.
# [18:04] <TabAtkins_> TabAtkins_: Just say that CSS animations pause whent he tab is inactive, and then scrub forward once it come sactive again.
# [18:04] <TabAtkins_> dbaron: I think right now, for background tabs we do exponential backoff on the animation timer.
# [18:05] <plh> http://w3c-test.org/webperf/specs/RequestAnimationFrame/#processingmodel
# [18:06] <TabAtkins_> TabAtkins_: I think that the spec actually doesn't *quite* forbid FF's behavior.
# [18:07] <TabAtkins_> TabAtkins_: The first paragraph of that linked section says to queue rAF stuff whenever the tab isn't hidden. it doesn't say *not* to queue rAF stuff when the tab is hidden.
# [18:07] <Bert> q?
# [18:07] * Zakim sees plh, Bert on the speaker queue
# [18:07] <Bert> ack plh
# [18:07] <Zakim> plh, you wanted to bring up a web perf issue
# [18:07] * Zakim sees Bert on the speaker queue
# [18:08] <TabAtkins_> Bert: I had an idea of what triggers the transition? A state change or a property value?
# [18:09] <TabAtkins_> TabAtkins_: It's the computed property value
# [18:09] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
# [18:09] <TabAtkins_> Bert: So then if you have an animation that ends, and the property then reverts to its normal value, you should trigger a transition, yes?
# [18:10] <TabAtkins_> TabAtkins: Depends on our exact cascade model. The one I favor would indeed do that.
# [18:10] <TabAtkins_> plinss: [explains a few other possibilities, given other models]
# [18:10] * Quits: dino_ (~dino@public.cloak) (dino_)
# [18:10] * Parts: Wonsuk (~wonsuk73@public.cloak) (Wonsuk)
# [18:10] <TabAtkins_> Bert: I was just wanting to see if this was thought of.
# [18:10] <TabAtkins_> TabAtkins: Yeah, it was definitely brought up during the discussion today at some points.
# [18:11] * Quits: mjs (~mjs@public.cloak) (mjs)
# [18:12] * Joins: Shinji (shinji@public.cloak)
# [18:12] <TabAtkins_> dbaron: The basic idea in Gecko is that we have a style with animation, and a style without animation. Transitions are triggered by the style without animation.
# [18:12] <TabAtkins_> dbaron: I took an impl shortcut that turns out to not be fully valid to that model.
# [18:13] <TabAtkins_> plinss: Okay, I just want to note for the minutes that we need to make sure that the behavior of transitions when an animations begins/ends is what we want, when we decide on the cascade model.
# [18:14] <TabAtkins_> ADJOURNED
# [18:14] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [18:14] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [18:14] * leaverou is now known as leaverou_away
# [18:15] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [18:15] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [18:16] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 60 seconds)
# [18:16] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [18:17] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
# [18:17] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [18:17] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [18:18] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 60 seconds)
# [18:19] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
# [18:20] * sylvaing is now known as sylvaing_away
# [18:21] * Joins: SteveZ (~chatzilla@public.cloak)
# [18:23] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:24] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [18:24] * Quits: rotsuya (~rotsuya@public.cloak) (Client closed connection)
# [18:24] * Quits: Shinji (shinji@public.cloak)
# [18:28] * sylvaing_away is now known as sylvaing
# [18:29] * Quits: sakkuru (~sakkuru@public.cloak) (Ping timeout: 60 seconds)
# [18:34] * Quits: kensaku_ (~kensaku@public.cloak) (Ping timeout: 60 seconds)
# [18:34] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:34] * Joins: glenn (~gadams@public.cloak)
# [18:35] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [18:35] * sylvaing is now known as sylvaing_away
# [18:47] * Joins: cabanier (~cabanier@public.cloak)
# [18:48] * Joins: tokamoto (~tokamoto@public.cloak)
# [18:53] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [18:58] * Quits: r12a (rishida@public.cloak)
# [19:36] * Quits: knobuta2 (~knobuta2@public.irc.w3.org) (Ping timeout: 60 seconds)
# [19:43] * Quits: Norbert (~standards@public.cloak) (Norbert)
# [20:00] * Quits: jarek (~jarek@public.cloak) (jarek)
# [20:19] * Joins: SimonSapin (~simon@public.cloak)
# [20:33] * Joins: antonp (~Thunderbird@public.cloak)
# [21:07] * Joins: koji (~koji@public.cloak)
# [21:08] * Quits: koji (~koji@public.cloak) ("Leaving...")
# [21:13] * Quits: SamB_Mac_ (~SamB_MacG5@public.cloak) (Client closed connection)
# [21:14] * Joins: brett (brett@public.cloak)
# [21:14] * brett Don't mind me folks, doing some sysadminning.
# [21:14] <brett> trackbot, bye
# [21:14] * Parts: trackbot (trackbot@public.cloak) (trackbot)
# [21:14] * Joins: trackbot-test (trackbot-test@public.cloak)
# [21:15] <brett> trackbot, status?
# [21:15] * Quits: trackbot-test (trackbot-test@public.cloak) (Request too long)
# [21:15] * brett Urgh.
# [21:15] <Ms2ger> That didn't work out well :)
# [21:17] <SimonSapin> brett: about today’s UTF-8 fail? One .decode('utf8') somewhere should be enough, but where :]
# [21:17] <brett> SimonSapin, That one I know I've fixed, this is about trackbot trying to flood the channel with names of CSS WG participants.
# [21:18] * Joins: trackbot-test (trackbot-test@public.cloak)
# [21:18] <brett> trackbot, status?
# [21:18] * Quits: trackbot-test (trackbot-test@public.cloak) (Request too long)
# [21:21] <brett> Okay, think I got it this time.
# [21:21] * Joins: trackbot-test (trackbot-test@public.cloak)
# [21:21] <brett> trackbot, status?
# [21:21] * trackbot-test knows about the following 87 users: Alexis, John, Taichi, Rebecca, Junichi, Zhixing, Steve, Arno, Tantek, Yong, Yehuda, Leif Arne, Katie, Giorgi, John, Tab, Geoffrey, Aryeh, Lea, Jorge Fernando, Craig, Robinet, Eric, Rune, Peter, Zheng, César, Ren, Beth, Glenn, Gilles, Chingteng, Simon, Jet,
# [21:21] * trackbot-test ... Arron, Markus, Chris, Yaso, Håkon Wium, Simon, Masayuki, Edward, Alex, Daniel, Liam, Alex, Sriram, Øyvind, Koji, Divya, Alan, Daniel, Ryan, Cheng-Hung, David, Reinaldo, Molly, Jan-Ming, Kenneth, David, Vincent, Somnath, Dean, JK, Dirk, Koji, Elika, Anton, Richard, Phil, Bert, Yujie, David,
# [21:21] * trackbot-test ... Rossen, Alexandru, Hanrui, Luke, Masayuki, Shane, Sylvain, Masataka, Hiroyuki, Kazutaka, Brad, Florian, Dragos, David
# [21:23] * Quits: trackbot-test (trackbot-test@public.cloak) (Client closed connection)
# [21:26] * Joins: trackbot (trackbot@public.cloak)
# [21:27] <brett> trackbot, status?
# [21:27] * trackbot knows about the following 87 users: Alexis, John, Taichi, Rebecca, Junichi, Zhixing, Steve, Arno, Tantek, Yong, Yehuda, Leif Arne, Katie, Giorgi, John, Tab, Geoffrey, Aryeh, Lea, Jorge Fernando, Craig, Robinet, Eric, Rune, Peter, Zheng, César, Ren, Beth, Glenn, Gilles, Chingteng, Simon, Jet, Arron, Markus, Chris, Yaso, Håkon Wium, Simon, Masayuki, Edward, Alex, Daniel, Liam, Alex, Sriram, Øyvind, Koji, Divya, Alan,
# [21:27] * trackbot ... Daniel, Ryan, Cheng-Hung, David, Reinaldo, Molly, Jan-Ming, Kenneth, David, Vincent, Somnath, Dean, JK, Dirk, Koji, Elika, Anton, Richard, Phil, Bert, Yujie, David, Rossen, Alexandru, Hanrui, Luke, Masayuki, Shane, Sylvain, Masataka, Hiroyuki, Kazutaka, Brad, Florian, Dragos, David
# [21:27] * Zakim excuses himself; his presence no longer seems to be needed
# [21:27] * Parts: Zakim (zakim@public.irc.w3.org) (Zakim)
# [21:27] <brett> All right then. If you all notice any other issues, please let us know at <sysreq@w3.org>. Thanks for your patience with this.
# [21:28] * Parts: brett (brett@public.cloak) (brett)
# [21:28] * Joins: Rossen (~Rossen@public.cloak)
# [21:40] * Joins: SamB_MacG5 (~SamB_MacG5@public.cloak)
# [21:46] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
# [21:46] * Joins: trackbot (trackbot@public.cloak)
# [21:56] * Joins: antonp1 (~Thunderbird@public.cloak)
# [21:58] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
# [21:59] * Joins: shepazu (schepers@public.cloak)
# [22:01] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:09] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [22:09] * Joins: antonp (~Thunderbird@public.cloak)
# [22:10] * Joins: antonp2 (~Thunderbird@public.cloak)
# [22:12] * Quits: antonp1 (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
# [22:13] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
# [22:14] * Quits: antonp2 (~Thunderbird@public.cloak) (Ping timeout: 60 seconds)
# [22:18] * Joins: tantek (~tantek@public.cloak)
# [22:19] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [22:30] * Joins: divya1 (~Adium@public.cloak)
# [22:30] * Parts: divya1 (~Adium@public.cloak) (divya1)
# [22:42] * Joins: liam (liam@public.cloak)
# [22:45] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [22:47] * Joins: kensaku (~kensaku@public.cloak)
# [22:49] * Joins: glenn (~gadams@public.cloak)
# [22:51] * Joins: tokamoto (~tokamoto@public.cloak)
# [22:51] * Joins: tomoyuki (~tshimizu3@public.cloak)
# [22:52] * Quits: tantek (~tantek@public.cloak) (tantek)
# [22:53] * Quits: drublic (~drublic@public.cloak) (Client closed connection)
# [22:53] * Joins: lstorset (~leif@public.cloak)
# [23:15] * Quits: kensaku (~kensaku@public.cloak) (Client closed connection)
# [23:22] * Joins: drublic (~drublic@public.cloak)
# [23:23] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [23:24] * Quits: tomoyuki (~tshimizu3@public.cloak) (tomoyuki)
# [23:30] * Joins: r12a (rishida@public.cloak)
# [23:38] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [23:40] * Joins: tokamoto (~tokamoto@public.cloak)
# [23:41] * Quits: tokamoto (~tokamoto@public.cloak) (tokamoto)
# [23:45] * Quits: lstorset (~leif@public.cloak) (Ping timeout: 60 seconds)
# [23:49] * Joins: krit (~krit@public.cloak)
# [23:50] * Quits: r12a (rishida@public.cloak)
# Session Close: Wed Oct 31 00:00:00 2012

The end :)