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

Options:

# Session Start: Tue Jan 28 00:00:00 2014
# Session Ident: #css
# [00:00] <TabAtkins>
# [00:00] <dbaron> #now { coffee-break-after: always }
# [00:13] <fantasai> s/type=break/type=coffee/
# [00:13] <fantasai> break, type of break is kinda redundant, really
# [00:13] <fantasai> s/, type of/ of type/
# [00:20] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [00:21] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [00:21] * Joins: dwim (~dwim@public.cloak)
# [00:21] <smfr> glenn: we are in a break
# [00:21] * Joins: florian (~Adium@public.cloak)
# [00:24] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [00:24] * Joins: dwim (~dwim@public.cloak)
# [00:25] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [00:29] <TabAtkins> fantasai: Versus
# [00:30] * sgalineau agreed to edit css-animations again, if that needs recording….
# [00:30] <dbaron> Rossen_, Gecko actually does have a special behavior for tables next to BFCs in quirks mode...
# [00:30] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [00:30] * Joins: dwim (~dwim@public.cloak)
# [00:31] <TabAtkins> glazou: Agenda+ this afternoon, about Counter Styles.
# [00:32] <fantasai> Topic: Animations
# [00:32] <fantasai> ScribeNick: fantasai
# [00:32] <fantasai> krit: Currently, animations spec states that animations start time is easier if the document load event is firing
# [00:32] <fantasai> krit: or when property is resolved for current element
# [00:32] <fantasai> krit: whatever happens later is actually start time
# [00:32] <fantasai> krit: I don't think this is what impl do
# [00:33] <fantasai> krit: implementations start animations once style is resolved
# [00:33] <fantasai> krit: maybe we should remove sentence about document load
# [00:33] <fantasai> dbaron: I agree with the change. Thought we already had
# [00:33] * glazou TabAtkins how much time?
# [00:33] <fantasai> RESOLVED: Remove bit about waiting for document load event before starting animations
# [00:34] <fantasai> Topic: Backgrounds and Borders
# [00:34] <fantasai> fantasai: Anyone have issues on css3-background?
# [00:34] <fantasai> krit: putting values between <box> values in background shorthand?
# [00:34] <fantasai> fantasai: should be fixed
# [00:35] <fantasai> fantasai: nope, not fixed, I'll fix it...
# [00:37] <TabAtkins> glazou: 5m if people don't argue, 20m if they do.
# [00:37] <fantasai> RESOLVED: Publish css3-background as LC with above edit, 3-week LC period
# [00:39] * astearns la5t call
# [00:39] * Quits: kawabata2 (~kawabata@public.cloak) (Client closed connection)
# [00:39] <dbaron> previous last calls: http://www.w3.org/TR/2009/WD-css3-background-20091015/ http://www.w3.org/TR/2010/WD-css3-background-20100612/ http://www.w3.org/TR/2012/WD-css3-background-20120214/ http://www.w3.org/TR/2014/WD-css3-background-20140116/
# [00:40] * sgalineau it's last calls all the way down
# [00:41] <dbaron> ok, strike the last one
# [00:41] <dbaron> (though it is actually currently on the TR page, but /TR/css3-background/ doesn't point to it)
# [00:41] * ChrisL csswg last call drinking game
# [00:41] <plh> s|http://www.w3.org/TR/2014/WD-css3-background-20140116/||
# [00:42] <fantasai> Topic: CSS2.2
# [00:42] <fantasai> Bert: Discussing updating CSS2.1
# [00:42] <fantasai> Bert: The main thing keeping us from that was some tests
# [00:42] <fantasai> Bert: I wrote some tests
# [00:42] <fantasai> Bert: Found that things were not implemented
# [00:42] <fantasai> Bert: specifically, the scinot parsing is not implemented
# [00:43] * sgalineau http://w3cmemes.tumblr.com/post/48718009851/if-you-name-it-last-call-to-get-it-done-youre
# [00:43] <fantasai> Bert: I haven't checked other errata
# [00:43] <fantasai> Bert: Wondering if they also have no implementations
# [00:43] <fantasai> SimonSapin: I have 2 implementations, but they are not independent
# [00:44] <fantasai> SimonSapin: WeasyPrint and Servo
# [00:44] <fantasai> dbaron: Should take about 5m to implement in Gecko
# [00:44] <fantasai> dbaron: need to remove an SVG check
# [00:45] <fantasai> ChrisL: SciNot was added to SVG everywhere, asked CSS to add it, and they said no. And then was recently added
# [00:45] <fantasai> ...
# [00:46] <ChrisL> ... so the implementations need to remove their special checks that disallow scinot in properties
# [00:47] <fantasai> discussion of going to LC
# [00:47] <fantasai> ChrisL: There's a bunch of tests someone posted as well
# [00:48] <fantasai> [discussion of where to find tests, etc.]
# [00:48] <dbaron> I really want to reopen some ancient RESOLVED-INVALID bug to put this patch on... but I can't find one.
# [00:49] <fantasai> plinss: Is the document ready to publish as LC?
# [00:49] <fantasai> Bert: yes, just have to change the status
# [00:49] <fantasai> fantasai: Did you kill the entire changes section, other than the most recent set?
# [00:50] <fantasai> ACTION Bert Cut down changes section to just the changes from CSS2.1REC2011
# [00:50] * trackbot is creating a new ACTION.
# [00:50] <trackbot> Created ACTION-606 - Cut down changes section to just the changes from css2.1rec2011 [on Bert Bos - due 2014-02-03].
# [00:50] <Bert> -> http://wiki.csswg.org/spec/css2.2 volunteers for CSS2 errata tests
# [00:51] <fantasai> ChrisL: What about undetectable changes?
# [00:51] <fantasai> fantasai: Just say they're undetectable in the impl report?
# [00:52] <fantasai> ChrisL: Also, how do we find existing tests that might need changes?
# [00:52] <fantasai> ChrisL: Will need a new edition of the test suite
# [00:52] <fantasai> plinss: I can build one
# [00:52] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [00:54] <fantasai> plinss: So, publish LC?
# [00:54] <fantasai> fantasai: Concerned some people will freak out, if we stay in LC for 6months+.
# [00:56] <fantasai> fantasai: Maybe put everything together and then go to LC very shortly since it's all set to move forward
# [00:56] <fantasai> dbaron: What if we put it at shortname CSS22, then nobody will everyone look at it
# [00:56] <fantasai> Tantek proposes waiting for the Process change
# [00:57] <fantasai> florian: Once we have the tests, then we can rush.
# [00:57] <fantasai> ChrisL: Once we have the tests we know where we are
# [00:57] <fantasai> tantek: excellent, we've rationalized procrastination
# [00:58] <fantasai> Topic: Counter Styles
# [00:58] <fantasai> TabAtkins: Only one issue open
# [00:58] <fantasai> TabAtkins: Nobody can give me consistent answers on the extended cjk numbering styles
# [00:59] <fantasai> TabAtkins: Already have one that goes to 10^5. One that goes to 10^16, optional
# [00:59] <glenn> +1 to drop
# [00:59] <fantasai> TabAtkins: I think it's sufficient, what we have already
# [00:59] * plh makes a 20k list in CJK
# [00:59] <fantasai> TabAtkins: Can address ina future level if someone can give me a real answer
# [01:00] <fantasai> TabAtkins: Are people ok with that?
# [01:00] <fantasai> Kawabata-san nods
# [01:01] <fantasai> fantasai: I'm ok, if it's undefined above 10k. mozilla implements beyond that, don't want to make them incompliant
# [01:01] <fantasai> dbaron: Were there disagreements on informal or formal?
# [01:02] * ChrisL does html still have a list start attribute?
# [01:02] <glazou> wait, shepazu just officially joined the CSS WG !!!
# [01:02] <fantasai> plh: Maybe ask i18n?
# [01:02] <fantasai> TabAtkins: Haven't, no. Asked some native speakers
# [01:04] <fantasai> fantasai: Say beyond 10K could either switch to cjk-decimal, or extend beyond (you figure out how)
# [01:04] * plh hopes the answer to David isn't 42
# [01:04] <fantasai> TabAtkins: The main issues are around when you drop ones and zeroes
# [01:04] <fantasai> TabAtkins: Everyone agrees on the first 4 digits
# [01:04] <fantasai> TabAtkins: beyond 10K becomes a problem
# [01:06] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:06] <fantasai> plinss proposes scientific notation
# [01:06] <fantasai> fantasai proposes engineering notation
# [01:06] * Joins: dwim (~dwim@public.cloak)
# [01:06] <fantasai> RESOLVED: Drop extended algorithm for CJK (10K+)
# [01:07] <dbaron> 八e九？
# [01:10] <fantasai> plh: should i18n review this?
# [01:10] <fantasai> fantasai: it's optional anyway
# [01:10] <fantasai> RESOLVED: Counter Styles to CR, once Tab finish off the DoC
# [01:11] <fantasai> Topic: -webkit-print-color-adjust
# [01:11] <fantasai> florian: We discussed this awhile ago
# [01:11] <florian> http://wiki.csswg.org/ideas/print-backgrounds
# [01:12] <fantasai> fantasai: we concluded 2-6 doesn't work
# [01:12] <fantasai> s/fantasai/florian/
# [01:12] <fantasai> florian: 7 is what webkit does
# [01:12] <fantasai> florian: 8 I don't remember
# [01:12] <fantasai> florian: Suggest we go with what webkit does, with a non-silly name
# [01:13] <fantasai> florian: By default browsers will adjust colors to have white background, to save ink
# [01:13] <fantasai> florian: This property can switch that behavior off, print what's specified
# [01:14] <fantasai> florian: gives author ability to say when things are important
# [01:15] <fantasai> TabAtkins, florian: Doesn't affect user's ability to control things; handle that via user stylesheet mechanism
# [01:15] <fantasai> florian: We need a name, a spec, and a description
# [01:15] <fantasai> fantasai: Colors 4
# [01:15] <fantasai> florian: So, inherits, applies anywhere, and mode where browser does whatever it wants
# [01:15] <fantasai> ChrisL: i.e. initial value is auto
# [01:15] <fantasai> florian: suggest 'economy', to be a little more explicit than auto...
# [01:16] <fantasai> plh: how about a 'never' value
# [01:16] <plh> s/plh: how about a 'never' value//
# [01:16] * plh was kidding
# [01:16] <fantasai> ChrisL: Need on, off, and auto
# [01:17] <fantasai> TabAtkins: Default behavior is whatever user wants, which happens to be save-ink by default
# [01:17] <fantasai> ChrisL: Right so, that's auto
# [01:18] <fantasai> fantasai: No, just two. 'economy' is initial value, but user can set to 'true-colors' in user style sheet
# [01:18] * plh wonders if we'll have the value "print-10000-random-pages-instead-of-the-one-I-requested"
# [01:19] <fantasai> discussion of how the user-stylesheet cascade works
# [01:19] <fantasai> Bert: Aren't you now giving the user 3 choices rather than 2?
# [01:19] <fantasai> TabAtkins: ...
# [01:19] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:19] * Joins: dwim (~dwim@public.cloak)
# [01:19] <fantasai> Bert: User has options Save, Don't Save, Do what author said
# [01:20] * ChrisL force-printhead-flushing: always | sometimes | on-low-ink-level
# [01:20] <fantasai> Bert: Property only has 2 values, but user has 3 options
# [01:20] <fantasai> TabAtkins: Blink doesn't give user any options. Depends on what the browser wants to expose
# [01:21] <fantasai> florian: We don't mandate what the UA puts in its prefs.
# [01:21] <fantasai> florian: we just give them more info to work with, if they want to
# [01:21] <fantasai> Bert: Wonder what the user thinks, seeing these options
# [01:21] <fantasai> TabAtkins: That's not our job, that's the UX designers' job.
# [01:22] <dbaron> filed https://bugzilla.mozilla.org/show_bug.cgi?id=964529 (with patch) for supporting scientific notation in Gecko
# [01:22] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:22] * Joins: dwim (~dwim@public.cloak)
# [01:22] <fantasai> [discussion of what customization options are appropriate for a browser to expose]
# [01:23] * fantasai is not minuting this
# [01:24] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:24] * Joins: dwim (~dwim@public.cloak)
# [01:26] <fantasai> Bert: How do I say, I really want to save ink?
# [01:26] <fantasai> ..
# [01:26] <fantasai> dbaron: I don't think we'd expose a 3-way toggle
# [01:26] <fantasai> dbaron: The reason we have this magic initial behavior is because authors generally don't think about printing
# [01:26] <fantasai> dbaron: This property is only used if an author *is* thinking about printing.
# [01:26] <fantasai> dbaron: If an author uses it, we trust them to have thought about printing
# [01:27] <fantasai> plinss: We thought of other heuristics to see whether author thought about printing. They weren't good enough heuristics. But this could be
# [01:28] <fantasai> plinss: Does anyone object to adding this property?
# [01:28] <fantasai> Bert: I disagree with this. Why aren't print style sheet enough?
# [01:28] <fantasai> Tab rants about "future legacy"
# [01:29] <fantasai> tantek, TabAtkins: Authors right now use borders as backgrounds, to force the printing of "backgrounds"
# [01:29] <fantasai> Basically lots of hacks. This would allow a clean way to solve the problem
# [01:29] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:30] * Joins: dwim (~dwim@public.cloak)
# [01:30] <fantasai> RESOLVED: Add this property with names TBD
# [01:31] <dbaron> print-economy: auto | as-specified ?
# [01:31] <ChrisL> economy | premium
# [01:32] <dbaron> economy | premium | super94 ??
# [01:32] <fantasai> Topic: Selectors 4
# [01:33] <fantasai> TabAtkins: Simon brought up issue of how exactly do we write the ancestor selector
# [01:33] <fantasai> TabAtkins: If I want to select containing <img>
# [01:33] <fantasai> TabAtkins: currently written as !p > img
# [01:33] <fantasai> TabAtkins: jquery writes it as p:has(img)
# [01:33] <fantasai> TabAtkins: I understand the arguments for the first one
# [01:33] <fantasai> TabAtkins: on the other hand, difficult to do multiple branches
# [01:34] <fantasai> glazou: How do you do !p ~ img
# [01:34] <Rossen__> p:can-haz(img)
# [01:34] <fantasai> SimonSapin: p:has(~img)
# [01:35] <fantasai> TabAtkins: Any arguments about this being intuitive are nil, because jquery people use it all the time
# [01:35] <fantasai> fantasai: That proves it's useful, doesn't prove it's intuitive
# [01:35] <fantasai> glazou: Seems to me we are inserting more and more ugliness in Selectors. No, don't think we shoudl do :has
# [01:35] <fantasai> SimonSapin: We only have this syntax with :matches() and :not()
# [01:36] <fantasai> SimonSapin: for same reason as shadow dom combinators, I think it's better to have a name than random meaning for ascii characters
# [01:36] <fantasai> glazou: At some point in the past we also had p:subject
# [01:36] <fantasai> glazou: The history of that proposal. Initially I submitted to WG as !p
# [01:36] <fantasai> glazou: Then ! was rejected due to negation
# [01:36] <fantasai> glazou: we went to :subject
# [01:36] <tantek> IMO the whole use of "!" in CSS has been a disaster.
# [01:36] <fantasai> glazou: now back to !p
# [01:36] * Rossen__ p:cannot-haz(img)
# [01:36] <tantek> !p is terrible
# [01:36] <astearns> +1 tantek
# [01:36] <plh> +1
# [01:37] <tantek> (nearly) every documentation about "! important" makes some joke about it being unintuitive.
# [01:37] <fantasai> glazou: I think opening a parentheses and starting with a combinator is awkward
# [01:37] * astearns p:+1(img)
# [01:38] <fantasai> plinss: This preserves the fact that the rightmost thing is the one you're selecting
# [01:38] <fantasai> TabAtkins: Also, ! it's very confusing where exactly it can go
# [01:39] <fantasai> TabAtkins: e.g. :matches() and :any() can take !, but :ancestor() can't.
# [01:39] * plh wants to write !!p~img
# [01:39] <tantek> I agree they are not equivalent
# [01:39] <fantasai> fantasai: If :has() is equivalent to !, then why different?
# [01:39] * Rossen__ p:can-haz(^^div > ^ p:cannot-has(img))
# [01:39] * fantasai actually suggested !! earlier
# [01:39] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [01:39] * liam wants :hasn't()
# [01:40] * dauwhe ^^:has(~cheezburger)
# [01:41] * MaRakow .yin:has(^.yang)
# [01:41] <fantasai> fantasai: ! on the rightmost compounds selector doesn't change the meaning of the selector
# [01:42] <fantasai> various examples thrown around
# [01:42] <fantasai> shepazu: As a non-CSS person, I'd be able to guess what :has() means, whereas for ! can't do that
# [01:43] <fantasai> ...
# [01:43] <fantasai> shepazu: Any problems with jQuery?
# [01:43] <dbaron> one of the examples was "div:ancestor(!.light-theme) > foo", where fantasai and glazou say the ! doesn't change anything since the ! is only moving the subject of what's inside the ()
# [01:44] <fantasai> tantek: No, the meanings are identical
# [01:44] * gsnedders agrees with shepazu here for all nothing it is worth
# [01:44] <fantasai> s/tantek/TabAtkins/
# [01:44] * dbaron wonders if we should take a straw poll at some point
# [01:45] * liam assuming !x implies not(x)
# [01:45] <fantasai> TabAtkins: It takes a relative selector, which is a selector that starts with a combinator (possibly an implied descendant combinator)
# [01:45] * Rossen__ liam, you're !right
# [01:46] <dbaron> for the record, I'm for :has()
# [01:46] <smfr> http://dev.w3.org/csswg/selectors4/
# [01:46] * Quits: eliezerb_2nd (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [01:47] * fantasai thinks !! is better than !
# [01:47] <fantasai> TabAtkins goes through the Selectors spec to see what needs to be cut
# [01:48] * liam ‽
# [01:48] <fantasai> :matches() and :not()
# [01:48] <fantasai> dbaron considers :matches()
# [01:48] * glazou fantasai I could live with !! :-)
# [01:48] <fantasai> dbaron: Don't know why we restrict :matches() to compound selectors in the fast profile
# [01:49] * astearns fantasai: it could be 2+ bangs, with each additional ! adding some amount of specificity
# [01:49] * fantasai :(
# [01:50] <fantasai> TabAtkins: c:matches(a c, b c) hits more combinatorial cases
# [01:50] * Parts: leif (~lastorset@public.cloak) (leif)
# [01:50] * Joins: leif (~lastorset@public.cloak)
# [01:50] <fantasai> SimonSapin: bz points out that with some new things, like parent selector, would need to do hard things
# [01:50] <fantasai> dbaron: I think if the syntax makes sense to allow combinators, then allow it
# [01:50] * glazou we're adding so many parenthesis to selectors this will soon look like Lisp :-)
# [01:51] <fantasai> TabAtkins writes out example
# [01:51] <fantasai> q c:matches(a c,b c) expands to
# [01:51] <fantasai> q a c,
# [01:51] <fantasai> q b c,
# [01:51] <fantasai> a q c,
# [01:52] <fantasai> a.q c,
# [01:52] <fantasai> b q c
# [01:52] <fantasai> b.q c
# [01:52] * fantasai forgot lots of dots. just put them in front of all the letters
# [01:53] <fantasai> TabAtkins explains that people often do just the common combinations, this would allow them to exactly express what they want
# [01:53] <fantasai> dbaron asks about :nth-last-match(), and what exactly it means
# [01:53] <fantasai> dbaron: OK, think that's alright
# [01:54] <fantasai> [brief discussion of :not()]
# [01:55] <fantasai> RESOLVED: complex selectors in :matches/:not to move to fast profile, assuming bz agrees
# [01:55] <fantasai> TabAtkins: Case-sensitivity, the 'i' flag of attribute selectors.
# [01:55] <fantasai> TabAtkins: I think we're planning to implement this
# [01:56] <fantasai> glazou: Is that implemented in gecko
# [01:56] <fantasai> dbaron: no
# [01:56] <fantasai> glazou: I have a patch for that
# [01:56] <fantasai> TabAtkins: Linguistic pseudos are new
# [01:56] <fantasai> fantasai: :dir() has implementation in mozilla
# [01:57] <fantasai> fantasai: :lang() was expanded to do lists, that's implemented in MS
# [01:57] <fantasai> SimonSapin: Also does full BCP47 matching, a bit more complex
# [01:57] <fantasai> keeping that
# [01:58] <fantasai> TabAtkins: Location pseudos
# [01:58] <fantasai> TabAtkins: :any-link is shortcut for :matches(:link,:visited)
# [01:58] <fantasai> dbaron: Gecko has it for over a decade
# [01:58] <fantasai> TabAtkins: :local-link()
# [01:58] <fantasai> fantasai: I think that one we will need to defer
# [01:59] <fantasai> TabAtkins: :target already done
# [01:59] <fantasai> TabAtkins: :scope has been around for awhile
# [01:59] <fantasai> dbaron: When does :scope apply in normal style sheets?
# [01:59] <fantasai> TabAtkins quotes from spec -- equivalent to :root
# [01:59] <fantasai> dbaron: OK
# [02:00] <fantasai> TabAtkins: Drag and drop pseudos. Do we have any implementations of the functionality?
# [02:00] <fantasai> fantasai: There's an implementation of some kind of drag and drop thing, don't remember which one
# [02:01] <fantasai> fantasai: Suggest we add an action to find out what, exactly, is implemented. Otherwise keep it
# [02:01] <fantasai> fantasai: Seems like we hashed over this enough that the definition is relatively stabel
# [02:01] * Joins: rhauck (~Adium@public.cloak)
# [02:01] <fantasai> fantasai: Does anyone have any concerns or feel like this might need more work?
# [02:02] <fantasai> TabAtkins: We have time-dimensional pseudos, defined for WebVTT.
# [02:02] <fantasai> TabAtkins: Anyone know if they're implemented anywhere?
# [02:03] <fantasai> ACTION fantasai: make sure timeline is defined for Speech
# [02:03] * trackbot is creating a new ACTION.
# [02:03] * RRSAgent records action 2
# [02:03] <trackbot> Created ACTION-607 - Make sure timeline is defined for speech [on Elika Etemad - due 2014-02-04].
# [02:03] <fantasai> TabAtkins: New input pseudos, mainly :placeholder-shown
# [02:03] <fantasai> dbaron: We used to implement it under a different name, then removed it
# [02:03] <fantasai> dbaron: Does WebKit do pseudo-class or pseudo-element
# [02:04] <fantasai> TabAtkins: There was an issue raised by hixie wrt dropping :read-only and :read-write, because no known ues
# [02:05] <fantasai> tantek: I have mixed feelings on that. Would prefer more data
# [02:05] <fantasai> ACTION TabAtkins Run a search on use of :read-only and :read-write
# [02:05] * trackbot is creating a new ACTION.
# [02:05] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [02:06] <fantasai> fantasai: For :placeholder-shown, do we have implementations?
# [02:06] <fantasai> dbaron: We have implementations for the functionality, might not match spec
# [02:07] <fantasai> TabAtkins: :user-error implemented by Moz under a different name
# [02:07] <fantasai> dbaron: :moz-ui-invalid
# [02:07] <tantek> FYI http://wiki.csswg.org/spec/css4-ui
# [02:07] <tantek> has collected a bunch of these
# [02:08] <tantek> as well as http://wiki.csswg.org/spec/selectors4#ideas-to-consider
# [02:08] <fantasai> dbaron: We also have the opposite, :moz-ui-valid
# [02:08] <fantasai> TabAtkins: That's just :not(:user-error)
# [02:08] <fantasai> fantasai: Not necessarily. Could be triggering only over time period that :user-error could trigger
# [02:08] <fantasai> fantasai: e.g. turning something green instead of red
# [02:10] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:10] <fantasai> ACTION: fantasai and Tab to investigate :moz-ui-valid
# [02:10] * trackbot is creating a new ACTION.
# [02:10] * RRSAgent records action 3
# [02:10] <trackbot> Created ACTION-608 - And tab to investigate :moz-ui-valid [on Elika Etemad - due 2014-02-04].
# [02:10] <fantasai> glazou: :blank's definition is really confusingly worded, fix it
# [02:10] * Joins: emalasky1 (~Adium@public.cloak)
# [02:11] <fantasai> ACTION fantasai fix :blank's definition to make sense
# [02:11] * trackbot is creating a new ACTION.
# [02:11] <trackbot> Created ACTION-609 - Fix :blank's definition to make sense [on Elika Etemad - due 2014-02-04].
# [02:11] <fantasai> TabAtkins: Are we keeping :blank?
# [02:11] <dbaron> glazou: change "excludes" to "allows"
# [02:11] <fantasai> fantasai: A bit concerned about the name, makes me think of form elements
# [02:12] <fantasai> dave: Also have a :blank page selector
# [02:12] <dbaron> Gecko has :blank under the name :-moz-only-whitespace
# [02:13] <fantasai> SimonSapin: Does it depend on computed value of white-space?
# [02:13] <fantasai> fantasai: No, that also needs clarification
# [02:13] <fantasai> TabAtkins: OK, naming issue , but keeping it
# [02:14] <fantasai> TabAtkins: An+B.. probably need to kill this section in favor of Syntax
# [02:14] <fantasai> fantasai: might leave some informative notes
# [02:15] <fantasai> TabAtkins: :nth-match(), keep or punt?
# [02:15] <fantasai> dbaron: Keep. This is one of the most wanted features
# [02:15] <fantasai> fantasai: One problem with this. Imagine a table
# [02:15] <fantasai> fantasai: I want to color every other row silver, that is shown and not collapsed
# [02:16] <fantasai> fantasai: So instead of :nth-child, I use :nth-match
# [02:16] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:16] <fantasai> (this is also a problem with :nth-child)
# [02:16] <fantasai> fantasai: The data is complex, and I split the data into sections using multiple <tbody>
# [02:17] <fantasai> fantasai: Now there might be 2 white rows adjacent to each other
# [02:18] <fantasai> dbaron: One possibility, might be weird, might be to keep the restriction of not having combinators inside :nth-match() and :nth-last-match()
# [02:18] <fantasai> dbaron: and use that to change what scope you're matching
# [02:18] <fantasai> dbaron: So for this example, you'd use ...
# [02:19] <fantasai> dbaron: note, this wouldn't make the fast profile
# [02:19] * Joins: eliezerb (~Eliezer@public.cloak)
# [02:21] <fantasai> fantasai: We do have some space to play around before the 'of' (anything after that keyword will be consumed as a selector, including idents and commas)
# [02:21] <fantasai> ...
# [02:21] <dbaron> (I'm proposing putting relative selectors inside :nth-match, essentially, but with a default of child rather than descendant.)
# [02:21] <fantasai> fantasai: or, we could expand :nth-child() to take the syntax of :nth-match()
# [02:21] <fantasai> TabAtkins: thoughts?
# [02:22] <fantasai> fantasai: I think it's more clear. :nth-match() could be interpreted as matching against the tree, not just against children
# [02:23] <fantasai> RESOLVED: Drop :nth-match(), move functionality to :nth-child()
# [02:23] <fantasai> TabAtkins: Next one is the refernece combinator
# [02:23] <fantasai> glazou: This is based as an ID attribute
# [02:24] <fantasai> glazou: What if we have a reference between elements, but there's no DTD declaring IDREF relationship?
# [02:24] <fantasai> TabAtkins: There's no relationship other than structure in XML
# [02:24] * Quits: smfr (~smfr@public.cloak) (smfr)
# [02:24] <fantasai> TabAtkins: You can never have a reference combinator of any kind for XML
# [02:25] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [02:25] <fantasai> fantasai: OK, so there's two things here
# [02:26] <fantasai> fantasai: You need to know which is the ID attribute. You need that for ID selectors anyway
# [02:26] <fantasai> fantasai: whether that's via DTD, or HTML spec, or xml:id
# [02:26] <tantek> clilley: no one uses xml:id any more
# [02:27] <fantasai> glazou: It's easier just to look for the first occurance, don't worry about if it's an ID attribute or not
# [02:27] * liam not clear why you can't have a reference combinator for XML - it'd require either DTD markup support or xml:id support though
# [02:27] <fantasai> fantasai: I think we should drop this feature. no implementations, not a high request
# [02:27] <fantasai> dbaron: I'm a bit queasy about this being a combinator, rather than a pseudo-class like :matches()
# [02:28] <fantasai> dbaron: Also don't even want to see the term IDREF
# [02:28] * liam - or relaxing the ID/IRREF-ness requirement
# [02:28] <fantasai> dbaron: Say language-specific knowledge if you need to, but don't say IDREF
# [02:28] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [02:28] <dbaron> dbaron: But also happy to punt to next level.
# [02:28] <fantasai> TabAtkins: OK, so put for now, fix later
# [02:28] <fantasai> Bert: Been wanting it for labels and inputs
# [02:29] <fantasai> Bert: Maybe with !! etc. could handle those cases
# [02:29] <liam> [the equivalent in XPath is a frequently-asked question, people want it all the time, even without id/idref]
# [02:30] <fantasai> plinss: in simple cases, can do that, but some cases might be in e.g. different table cells, harder
# [02:30] <fantasai> TabAtkins: Column combinator, which is ||
# [02:31] <dbaron> dbaron: I'd prefer a :column pseudo-class
# [02:31] <dbaron> :column()
# [02:31] <fantasai> fantasai: It's a combinator because it describes the relationship between two elements, which is what a combinator *is*
# [02:31] <fantasai> TabAtkins: Do we want to keep here, or punt to next level?
# [02:32] <fantasai> Bert: How do you know what's part of the column?
# [02:32] * Joins: smfr (~smfr@public.cloak)
# [02:32] <fantasai> Tab, fantasai: Markup magic.
# [02:32] <fantasai> ChrisL: CSS display
# [02:33] <fantasai> fantasai: no, only based on markup
# [02:33] <fantasai> [discussion of whether to keep or punt]
# [02:35] <dbaron> dbaron: we could add :column-hover and :column-active // fantasai: or change definition of :hover and :active so it works on columns
# [02:35] <fantasai> fantasai: Main issue seems to be whether this is a pseudo-class or a combinator
# [02:35] <fantasai> glazou: I can live either way
# [02:36] <fantasai> fantasai: Oh! You (dbaron) wanted to have an = combinator. We could use that for rows.
# [02:36] * dbaron notes fantasai and ChrisL have arrived at the = and # combinators
# [02:36] <fantasai> fantasai: If you have a spanning cell, you can't tell it belongs to the third row by child selector.
# [02:36] <fantasai> fantasai: So use || for column relationship, and = for row relationship
# [02:37] <fantasai> TabAtkins: I hate column combinator now...
# [02:37] <fantasai> ...
# [02:38] <fantasai> dbaron: Tab is proposing that td:column(.foo) matches td that is in a column either with a class of foo, or that contains a cell with class of foo
# [02:38] <fantasai> TabAtkins: This works equivalently for pseudo-class and combinator syntax. This is the column relationship selector.
# [02:38] <fantasai> dbaron: I might prefer 2 separate selectors, but ok with it...
# [02:40] <fantasai> TabAtkins: So, are we keeping in 4 or punting to 5 and what do we agree on?
# [02:40] <fantasai> dbaron: I think it might be worth getting some author feedback.
# [02:40] <fantasai> dbaron: I would like to see it stay in 4
# [02:40] <fantasai> dbaron: I would like to hear author feedback on syntaxes and whether td matching is wanted
# [02:41] <fantasai> dbaron: I suspect pseudo-class will be more preferred, but not sure. Would prefer to ask authors
# [02:41] * dauwhe U+1D11E
# [02:41] <fantasai> glazou: td selection is really useful
# [02:42] <fantasai> dbaron: Not arguing that, wondering if should be same feature or different ones
# [02:42] <fantasai> ...
# [02:42] <fantasai> glazou brings up issue of hidden rows, selecting every other row
# [02:43] <fantasai> ACTION TabAtkins Add this as an example for :nth-child()
# [02:43] * trackbot is creating a new ACTION.
# [02:43] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [02:43] * fantasai grumbles
# [02:43] <dbaron> tr:nth-child(even of :not(.hidden)) ?
# [02:44] <fantasai> glazou: Specificity, question wrt reference combinator. Think it should be counted somewhere.
# [02:44] <fantasai> TabAtkins: We're punting to L5
# [02:45] * dbaron wonders if tab is *specifically* opposed to making specificity more complicated :-)
# [02:45] <fantasai> glazou: Keep track of it
# [02:45] <fantasai> TabAtkins: OK, topic's done!
# [02:47] <dbaron> Topic: Pseudo-elements
# [02:47] <dbaron> Tab: need somebody to edit the spec
# [02:47] <dbaron> tantek?: Authors are asking why ::selection isn't specified
# [02:47] <dbaron> Tab: dbaron had a proposal to address issues
# [02:47] <dbaron> dbaron: need to see if it's web-compatible
# [02:48] <tantek> tantek was just pointing out the recent thread where author(s) asked about status of ::selection in specs since it appears to be implemented cross-browser.
# [02:49] <dbaron> Topic: bikeshedding display
# [02:49] <dbaron> fantasai: I propose renaming 'box' to 'display-box'
# [02:49] <dbaron> SimonSapin: So still violating naming convention of shorthands, since it's not part of the shorthand.
# [02:49] * dbaron is unsure
# [02:49] <fantasai> reasons being:
# [02:50] <fantasai> a) display-box connects authors with display, so that will help them transition from display: none
# [02:50] <fantasai> b) display properties are all about box generation. This is about box generation
# [02:50] <fantasai> c) We have in some cases properties which look like longhands of a shorthand, but are actually independent because we have a specific reason for them to be independent, even though they are closely related
# [02:51] <fantasai> TabAtkins: Ok, that makes sense to me.
# [02:51] <dbaron> Tab: What about naming of what I currently have as display-extras, for list-item value?
# [02:52] <dbaron> dbaron: Isn't there an association with display-outside, when marker is outside?
# [02:52] <dbaron> dbaron: what happens when you give a display:table-cell an outside marker?
# [02:58] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [02:59] * Quits: glazou (~glazou@public.cloak) (glazou)
# [03:00] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [03:01] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [03:01] <fantasai> ...
# [03:01] <fantasai> SteveZ_: display-decoration?
# [03:01] <fantasai> TabAtkins: better than display-extras
# [03:01] <fantasai> [various discussion of list bullets, unminuted]
# [03:01] <fantasai> Meeting closed.
# [03:02] * Quits: AdobeSeattle (~AdobeSeattle@public.cloak) ("Page closed")
# [03:02] * Quits: smfr (~smfr@public.cloak) (smfr)
# [03:02] <fantasai> action to all to read MQ4
# [03:02] * trackbot is creating a new ACTION.
# [03:02] <trackbot> Error finding 'to'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [03:02] <glenn> signing off for the day
# [03:02] * Quits: glenn (~gadams@public.cloak) ("Leaving...")
# [03:02] <liam> meeting :hasn't(participants)
# [03:02] * Joins: leif1 (~lastorset@public.cloak)
# [03:02] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [03:03] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [03:03] * Joins: lmcliste_ (~lmclister@public.cloak)
# [03:03] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [03:04] * Quits: leif1 (~lastorset@public.cloak) (Client closed connection)
# [03:04] * Joins: leif (~lastorset@public.cloak)
# [03:04] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [03:04] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [03:04] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [03:05] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [03:05] * Joins: koji (~koji@public.cloak)
# [03:06] * Quits: emalasky1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [03:11] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [03:12] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [03:12] * Quits: SteveZ_ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [03:13] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:15] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [03:20] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [03:21] * Quits: eliezerb_2nd (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [03:28] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [03:33] * Quits: eliezerb_2nd (~Eliezer@public.cloak) ("Leaving")
# [03:34] * Joins: eliezerb (~Eliezer@public.cloak)
# [03:35] * Quits: eliezerb (~Eliezer@public.cloak) ("Leaving")
# [03:36] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [03:40] * Joins: eliezerb (~Eliezer@public.cloak)
# [03:41] <Zakim> plinss, you asked to be reminded at this time to go home
# [03:55] * Joins: nikos (~Thunderbird@public.cloak)
# [04:32] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [04:42] * Zakim excuses himself; his presence no longer seems to be needed
# [04:42] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [04:57] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [05:03] * Joins: emalasky (~Adium@public.cloak)
# [05:11] * Joins: florian (~Adium@public.cloak)
# [05:11] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:13] * Joins: lmcliste_ (~lmclister@public.cloak)
# [05:27] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [05:27] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [05:27] * Quits: nikos (~Thunderbird@public.cloak) (nikos)
# [05:30] * TabAtkins is in the downstairs hot tub, if anyone wants to join.
# [05:32] <liam> 1°F / -17C here so it sounds like a wonderful idea but it'd take a while I'm afraid
# [05:32] <liam> hope your laptop is hot-tub proof :D
# [05:34] <TabAtkins> liam: It's not, but I'm careful, and it's sitting on a towel.
# [05:35] <liam> :D
# [05:36] <liam> supposedly my laptop has a waterproof keyboard, there's videos of people pouring glasses of water onto them... but the vents are underneath & can suck up water, which kinda defeats the advantage
# [05:36] * Joins: koji (~koji@public.cloak)
# [05:37] <TabAtkins> Uh, yeah.
# [05:38] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [05:41] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [05:48] * Joins: leif (~lastorset@public.cloak)
# [05:49] * Parts: leif (~lastorset@public.cloak) (leif)
# [05:57] * Joins: Rossen__ (~Rossen@public.cloak)
# [05:57] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [06:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:09] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [06:10] * Joins: koji (~koji@public.cloak)
# [06:13] * Joins: nikos (~Thunderbird@public.cloak)
# [06:17] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [06:39] * Joins: tantek (~tantek@public.cloak)
# [06:39] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [06:47] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [06:51] <SimonSapin> proposed definition for :blank
# [06:51] <SimonSapin> The :blank pseudo-class is like to the :empty pseudo-class, except that it additionally matches elements that only contain characters affected by whitespace processing. [CSS3TEXT]
# [06:51] <SimonSapin> looks good?
# [06:54] <liam> all characters are _affected_ by whitespace, maybe you mean that are classed as whitespace in [reference]?
# [06:54] <liam> well, maybe it's clear enough
# [07:00] * Joins: florian (~Adium@public.cloak)
# [07:01] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [07:01] <SimonSapin> well, Text doesn’t really classify characters
# [07:03] <liam> then how is the reference to CSS 3 text helping? maybe it's the HTML spec that's needed? dunno
# [07:03] <liam> (I don't mean, it's not helping, I mean, I don't understand how it's helping)
# [07:13] <SimonSapin> TabAtkins: https://dvcs.w3.org/hg/csswg/rev/e3a564cf9e04
# [07:13] * Joins: florian (~Adium@public.cloak)
# [07:17] * Joins: jet (~junglecode@public.cloak)
# [07:18] * Parts: jet (~junglecode@public.cloak) (jet)
# [07:21] * Joins: dbaron (~dbaron@public.cloak)
# [07:21] <dbaron> 𐑤. 𐑛𐑱𐑝𐑦𐑛 𐑚𐑨𐑮𐑩𐑯 is my name in Shavian.
# [07:22] <liam> hah I didn't know it was inUnicode
# [07:22] <tantek> looks like some scruff in need of a shave
# [07:22] * Quits: florian (~Adium@public.cloak) (Client closed connection)
# [07:22] * Joins: florian (~Adium@public.cloak)
# [07:23] <dbaron> it's in Plane 1.
# [07:23] <dbaron> (near the beginning of Plane 1)
# [07:24] * liam sees it in gucharmap
# [07:25] * fantasai waves
# [07:27] <liam> :)
# [07:27] * liam sorry not to be in Seattle, I bet they actually have liquid ice over there
# [07:28] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [07:44] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [07:45] * Joins: tantek (~tantek@public.cloak)
# [07:53] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [08:00] * Joins: emalasky (~Adium@public.cloak)
# [08:10] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [08:25] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:32] * Joins: stakagi (~stakagi@public.cloak)
# [08:39] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:54] * Quits: stakagi (~stakagi@public.cloak) (Client closed connection)
# [08:59] * Joins: tantek (~tantek@public.cloak)
# [09:00] <tantek> TabAtkins: http://wiki.csswg.org/tools/bikeshed
# [09:11] * Joins: koji (~koji@public.cloak)
# [09:12] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [09:12] * Joins: tantek (~tantek@public.cloak)
# [09:18] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [09:24] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [09:24] * Joins: emalasky (~Adium@public.cloak)
# [09:32] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [09:36] * Quits: Henke37 (~Henrik@public.cloak) (Client closed connection)
# [09:49] * Joins: emalasky (~Adium@public.cloak)
# [09:54] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
# [09:55] * Joins: logbot (~logbot@public.cloak)
# [09:55] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
# [09:56] * Joins: logbot (~logbot@public.cloak)
# [09:58] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [10:12] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
# [10:12] * Joins: logbot (~logbot@public.cloak)
# [10:42] * Quits: tantek (~tantek@public.cloak) (tantek)
# [11:36] * Joins: darktears (~darktears@public.cloak)
# [12:05] * leaverou_away is now known as leaverou
# [12:11] * leaverou is now known as leaverou_away
# [14:02] * Joins: florian (~Adium@public.cloak)
# [14:03] * Joins: eliezerb (~Eliezer@public.cloak)
# [14:14] * Joins: mihnea (~sid16310@public.cloak)
# [15:08] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [15:24] * Joins: florian (~Adium@public.cloak)
# [16:15] * Joins: koji (~koji@public.cloak)
# [16:23] * Joins: emalasky (~Adium@public.cloak)
# [16:33] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [16:33] * Quits: eliezerb (~Eliezer@public.cloak) (Client closed connection)
# [16:37] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:39] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [16:44] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:48] * Joins: jet (~junglecode@public.cloak)
# [16:50] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [16:54] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [16:59] * Joins: emalasky (~Adium@public.cloak)
# [17:01] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [17:05] * Joins: SteveZ (~SteveZ@public.cloak)
# [17:25] * Joins: koji (~koji@public.cloak)
# [17:37] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [17:39] * Joins: lmcliste_ (~lmclister@public.cloak)
# [17:39] * Joins: koji (~koji@public.cloak)
# [17:41] * Joins: rhauck (~Adium@public.cloak)
# [17:41] * Joins: Rossen__ (~Rossen@public.cloak)
# [17:42] * Joins: glazou (~glazou@public.cloak)
# [17:47] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [17:54] * Joins: dbaron (~dbaron@public.cloak)
# [17:57] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:57] * Joins: tantek (~tantek@public.cloak)
# [17:58] * Joins: smfr (~smfr@public.cloak)
# [18:00] * Joins: AdobeSeattle (~AdobeSeattle@public.cloak)
# [18:00] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:03] * Joins: florian (~Adium@public.cloak)
# [18:06] * Joins: plh (plehegar@public.cloak)
# [18:07] <tantek> good morning
# [18:07] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [18:07] * Joins: leif (~lastorset@public.cloak)
# [18:07] * Joins: koji (~koji@public.cloak)
# [18:08] <glazou> ScribeNick: tantek
# [18:08] <tantek> Agenda item 60 minutes Media Queries
# [18:09] <florian> http://lists.w3.org/Archives/Public/www-style/2013Nov/0122.html
# [18:09] <TabAtkins> Topic: Media Queries
# [18:09] <tantek> florian: MQ3
# [18:09] <tantek> … errata
# [18:09] <tantek> … need to fix example in a REC
# [18:09] <tantek> … we have an errata for MQ3 but that typo is not in it
# [18:10] <tantek> plh: updating errata is easy
# [18:10] <tantek> plh: but a new REC is harder
# [18:10] <tantek> florian: updating errata is good enough
# [18:10] <tantek> fantasai: you can fix the typo in place
# [18:11] <tantek> florian: whoever can touch these documents please fix
# [18:11] <tantek> bert: I can fix the errata
# [18:11] <florian> http://lists.w3.org/Archives/Public/www-style/2013Nov/0125.html
# [18:11] <tantek> florian: the other MQ3 topic
# [18:12] <tantek> … it says something about never having to evaluate a style sheet
# [18:12] <tantek> … I have proposed wording
# [18:12] <tantek> … do we want to change this in level 3?
# [18:12] <tantek> … or we can just do it in 4
# [18:12] <tantek> … in level 4 it is already fixed.
# [18:12] <tantek> glazou: fix it in both
# [18:12] <tantek> glazou: no objections, resolved.
# [18:12] <tantek> dbaron: does it make it clear that it is unless explicitly specified
# [18:13] <tantek> florian: yes
# [18:13] <tantek> dbaron: it might be good if it was "… that it overrides this rule"
# [18:13] <tantek> tab: ok
# [18:13] <SimonSapin> +1 dbaron
# [18:13] <dbaron> explicitly specified that it overrides this rule
# [18:13] <tantek> tab: MQ4 changes
# [18:13] * Joins: yamamoto (~yamamoto@public.cloak)
# [18:13] <tantek> tab: I am going to ask for first public WD
# [18:14] <tantek> tab: we are deprecating a bunch of media types, replacing them with media features
# [18:14] <dbaron> (This is based on an interesting idea I read about... I think it was from Canadian law ... there are a set of legal rights that the government can't override unless the law overriding the right explicitly says that it violates that right... so that it can't happen by accident or be hidden.)
# [18:14] <tantek> tab: TV never succeeded because your screen style sheets were not allowed
# [18:14] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [18:15] * Joins: kawabata3 (~kawabata3@public.cloak)
# [18:15] <tantek> tab: MQ4 proposes saying: media types are a legacy feature
# [18:16] <tantek> explicitly supporting: all, screen, print, speech
# [18:16] <tantek> tab: no one is publishing tv style sheets
# [18:16] <tantek> tab: beyond epsilon
# [18:17] <tantek> florian: what we did with projection was fairly strange
# [18:17] * fantasai thought it was rpetty useful, though
# [18:17] * Joins: shepazu (schepers@public.cloak)
# [18:17] <tantek> (we meaning "Opera" here)
# [18:17] <tantek> glazou: what about number of screens and resolutions of screens?
# [18:17] <tantek> glazou: we are concerned about the second screen experience
# [18:18] <tantek> tab: yes. please bring it up in an email thread.
# [18:18] <tantek> tab: also, new range context syntax
# [18:18] <tantek> tab: authors seems excited about this
# [18:18] <glazou> +1
# [18:19] <tantek> tab: old min/max features still supported, but they just map to the inequalities versions
# [18:19] <tantek> tab: could be convinced to add !=
# [18:19] * plh in css, not equals is written ^^=
# [18:19] <tantek> tab: single equal or double qual?
# [18:19] * fantasai not =^^= ?
# [18:19] <tantek> ^.%
# [18:20] <dbaron> smfr: what about != ?
# [18:20] <dbaron> dbaron: what about = ?
# [18:20] <tantek> (too many talkings)
# [18:20] <dbaron> dbaron: also want value < feature, given that they have value < feature < value
# [18:20] <dbaron> tab: yes
# [18:21] <tantek> bert: we have avoided < > in CSS to allow it better in HTML
# [18:21] <tantek> tab: it works now
# [18:21] <tantek> bert: HTML hasn't changed
# [18:21] <tantek> tab/bert: CDATA arguments
# [18:21] <tantek> shepazu: HTML5 has parser than handles it
# [18:22] <tantek> bert: not just browser, talking about HTML, XML etc.
# [18:22] <tantek> bert: you have to escape it in some cases
# [18:22] <tantek> tab: if no one escapes it they won't have a problem
# [18:22] <tantek> bert: if you use SGML you're going to have a bad day
# [18:23] <tantek> tab: we should add = sign
# [18:23] <glazou> (laughter)
# [18:23] <tantek> resolution: add "="
# [18:23] * dauwhe I have styled docbook with CSS, but I'd be fine with escaping < if needed in that situation.
# [18:23] <glazou> RESOLVED: add =
# [18:23] <tantek> tab: we need a use case for not equals
# [18:23] <tantek> RESOLVED: add =
# [18:23] <dbaron> RESOLUTION: add value < feature syntax
# [18:23] * Joins: sgalineau (~sgalineau@public.cloak)
# [18:23] <tantek> RESOLVED: add value op name form
# [18:24] <tantek> tab: in addition to name op value form
# [18:24] <tantek> tab: we are looking for use cases for the != form
# [18:24] <tantek> tab: MQ4 syntax has been rewritten but should be functionally equivalent
# [18:25] <dbaron> Tab: We agreed to add full and/or/not logic like @supports, but I haven't done that yet; plan to.
# [18:25] <tantek> glazou: if we're using media features instead of media types we're going to replicate that list of features many times in many @-rules and I don't want to see that
# [18:25] <tantek> florian: not in the spec now but we should talk about it
# [18:26] <glazou> we need a way to declare a user-defined media type based on a list of features
# [18:26] <tantek> florian: another minor change, when you just evaluate a media feature inside a parantheses we used to special case it
# [18:26] <tantek> tab: none is now falsy as well as 0
# [18:26] <tantek> tab: it prevents us from going down the route of having a boolean that takes 0 and 1
# [18:26] <tantek> tab: new media features
# [18:27] <tantek> tab: "updates" feature (name pending) - how quickly the screen updates
# [18:27] <tantek> … updates: none is like printing
# [18:27] <tantek> … updates: slow is saying not good enough for animations, like e-ink
# [18:27] <tantek> … updates:normal can handle animations
# [18:27] <tantek> … open to input on names and frequencies
# [18:28] <tantek> florian: rate sounds like a number
# [18:28] <dbaron> dauwhe: Call this refresh-rate rather than updates?
# [18:28] <dbaron> (before florian)
# [18:28] <tantek> florian: and we don't want that
# [18:28] * sgalineau update-frequency high/low?
# [18:28] <tantek> tab: next two is how you deal with overflow
# [18:28] <fantasai> Also, mention animations in the description of 'normal'
# [18:28] <tantek> … "overflow-block"
# [18:28] <tantek> … none or scroll
# [18:29] <tantek> fantasai: opera had a mode where it could do forced page breaks or otherwise it would scroll which was cool for presentations
# [18:29] <tantek> tab: is that addressed by paged?
# [18:29] <tantek> fantasai: I think it is a new one
# [18:30] <tantek> dbaron: it is can-you-make-page-breaks, not does-overflow-go-into-new-pages
# [18:30] <tantek> tab: it only applies if you are paged already
# [18:30] <tantek> tab: better to have two variants of pages?
# [18:30] <tantek> fantasai: it would devolve into the same feature
# [18:30] <tantek> florian: would have to name it something else
# [18:30] <tantek> smfr: terminology is very confusing
# [18:30] <tantek> … overflow block and scrolling is already used in CSS
# [18:30] <tantek> tab: we tried to use parallel naming but that might be confusing
# [18:31] <tantek> tab: better names are requested!
# [18:31] <tantek> smfr: content doesn't overflow the screen, it overflows the viewport
# [18:31] <tantek> tab: you're right that should be viewport
# [18:31] <tantek> tab: can we split paged into two values that better capture it
# [18:31] <tantek> tab: and we'll solicit better names for the properties themselves.
# [18:31] <tantek> tab: sound good?
# [18:32] <tantek> (no objections voiced)
# [18:32] <tantek> tab: (more new features)(
# [18:32] <tantek> tab: "pointer"
# [18:32] <tantek> tab: "none"
# [18:32] <tantek> florian: like paper, TV without a cursor
# [18:32] <tantek> tab: … other value, like a mouse
# [18:33] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [18:33] <tantek> … pointer: coarse | fine vs. hover: none | hover
# [18:34] * Joins: florian (~Adium@public.cloak)
# [18:34] <tantek> (markup discussion of spec example)
# [18:34] <tantek> tab: "hover" is a new media feature
# [18:34] * Joins: koji (~koji@public.cloak)
# [18:35] <tantek> … whether hover is supported or not
# [18:35] <tantek> florian: we are not addressing the keyboard
# [18:35] <tantek> (disappointed in minute taker for not capturing an overflow joke)
# [18:36] <tantek> tab: some devices can match multiple values
# [18:36] <tantek> tab: e.g. chrome pixel is both touch and pointing device
# [18:36] <tantek> tab: e.g. both coarse and fine
# [18:36] <tantek> tab: in general we say match according to primary input devices
# [18:37] * Joins: rhauck (~Adium@public.cloak)
# [18:37] <tantek> tab: if it's just a possible input, don't match
# [18:37] <tantek> florian: connecting a mouse to a tv does not turn it into a desktop
# [18:37] <tantek> tab: next, "lumosity"
# [18:37] <tantek> s/lumosity/luminosity
# [18:37] <tantek> smfr: this is the wrong term
# [18:37] <tantek> glazou: we should use device API terms
# [18:38] <fantasai> glazou: This is called light-level
# [18:38] <tantek> glazou: there are a lot of device APIs we could add as media queries
# [18:38] <tantek> glazou: e.g. new samsung phones have capability of detecting to see if someone is looking at the phone
# [18:38] <tantek> plinss: so you can restyle the page to look different when you're not looking at it
# [18:38] <tantek> (laughter)
# [18:39] <tantek> tab: should be careful with things useful declaratively or just in script
# [18:39] * sgalineau 'we have 5m page non-views'
# [18:39] <tantek> tab: but there's a goldmine of things we should add
# [18:39] <tantek> shepazu: have to be careful with pointer events
# [18:40] <tantek> tab: we should capture that luminosity should be named light-level
# [18:40] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [18:40] * glazou ahem do we need a 'css' media feature ?-)
# [18:40] <tantek> tab: script
# [18:40] <tantek> tab: whether or not ecmascript is supported on the current document
# [18:40] <tantek> shepazu: "script" in the CSS context might be confused with i18n script
# [18:41] * Joins: sgalineau (~sgalineau@public.cloak)
# [18:41] <tantek> shepazue: how about procedural scripting? something other than "script"
# [18:41] <tantek> fantasai: should be something about languages
# [18:41] <tantek> shepazu: scripting would be less confusing
# [18:41] <tantek> fantasai: none | js | dart
# [18:42] <tantek> tab: switch "enabled" to be actual scripting language names
# [18:42] * plh -webkit-js ?
# [18:42] <tantek> tab: a third value might be useful (in addition to none | enabled)
# [18:42] <tantek> tab: UAs like opera mini run scripts on page load and then never again
# [18:43] <tantek> tab: is that useful ?
# [18:43] <tantek> plinss: similar to printting
# [18:43] <tantek> … so yes it is useful
# [18:43] <tantek> tab: then I want two different features
# [18:43] <tantek> tab: whether scripting is allowed at all
# [18:43] <tantek> tab: and then another feature for supported language(s)
# [18:43] <tantek> florian: I don't think there is a pressing need for detecting which language
# [18:43] <tantek> fantasai: what about user pref'd off?
# [18:43] <tantek> tab: those are just "none"
# [18:44] <tantek> plinss: there are many sites that say, "your scripting is turned off, please turn it on" - horrible thing to say if you can't turn it on
# [18:44] <tantek> dbaron: there are plenty of sites that do that via a div in markup and set it to display none in script
# [18:44] <tantek> plinss: … (couldnt' hear)
# [18:45] <tantek> tab: the way the syntax is defined, both such values should be falsy
# [18:45] <tantek> tab: we could make the set of falsy values extensible
# [18:45] <tantek> florian: ?
# [18:45] <tantek> tab: if it gets fine grained enough you need a JS API
# [18:46] <tantek> florian: (something) might eventually be needed
# [18:46] <tantek> tab: will leave it as an open issue - do we want two flavors of none?
# [18:46] <tantek> tab: will add a feature for can-only-run-script-on-load
# [18:47] <tantek> ???: fingerprinting concerns?
# [18:47] <tantek> tab: a lot of them are already exposed in other ways
# [18:47] <tantek> … if there are new exposures, open to ways to deal with that
# [18:47] <SimonSapin> s/???/SimonSapin/
# [18:47] * sgalineau heard Tab say 'axes' and not 'axises'
# [18:47] <tantek> glazou: devices, keyboards
# [18:47] <tantek> glazou: some devices have keyboard that slides out
# [18:48] <tantek> tab: captured by "work properly" vs "horrible"
# [18:48] <tantek> tab: lots of open questions about keyboards
# [18:49] <tantek> tab: many sets of devices these days
# [18:49] <tantek> tab: yesterday we discussed print economy
# [18:49] <tantek> tab: some things that are static will want full backgrounds
# [18:49] <tantek> tab: some things like printers may want to do economy mode
# [18:49] <tantek> simon: ...
# [18:50] <tantek> florian: is that what media queries are for?
# [18:50] <tantek> florian: e.g. if black everywhere is expensive...
# [18:50] <tantek> tab: yes, that's my basic thought
# [18:50] <tantek> tab: the property allows you to opt into the browser's blunt hammer - e.g. economize ink usage
# [18:50] <SimonSapin> s/.../If ink-economy is a CSS property, it may be problematic to query it with MQ
# [18:50] <tantek> tab: it might be valuable to allow more fine grain user / author input
# [18:51] <tantek> tab: microsoft has a high-contrast media query
# [18:51] <tantek> tab: how does it work?
# [18:51] <tantek> rossen: the latter (that you've been put into high contrast mode and you should adapt)
# [18:51] <tantek> tab: also, inverted
# [18:51] <tantek> tab: is it forced or requested?
# [18:51] <tantek> rossen: same way
# [18:52] <tantek> plh: we looked into that related to the canvas API
# [18:52] <tantek> plh: re: custom focus ring
# [18:52] <tantek> plh: only supposed to draw focus ring if special request from user
# [18:52] <tantek> plh: it is not clear if browser has access to the information
# [18:52] <tantek> plh: e.g. on Windows it is controlled by the OS
# [18:52] <tantek> plh: but did not tell the browser
# [18:52] <tantek> plh: you may want to be careful
# [18:52] <tantek> plh: maybe some privacy implication
# [18:53] <tantek> plh: people using high contrast may have some disability and may not want to give that information
# [18:53] <tantek> tab: there was a discussion in Shenzen about this
# [18:53] <tantek> tab: all that indieUI mediaqueries, do we want them in MQ4 or leave them in an extension?
# [18:53] <tantek> plh: maybe wait a while before you do that
# [18:53] <tantek> plh: to see how successful they are
# [18:54] <tantek> bert: otherwise people will have hard time finding them
# [18:54] <tantek> fantasai: best to pull them all into one spec
# [18:54] <tantek> tab: they don't have that many
# [18:54] <tantek> tab: but a bunch of them should be pulled in
# [18:54] <tantek> fantasai: concerns e.g. with inversion is there are various ways of inverting
# [18:54] <tantek> tab: we need a way to say this is an image, don't invert it
# [18:54] <tantek> tab: but still want a mq for inversion to turn off shadows
# [18:55] <tantek> tab: being able to actually alter your styling in response, beyond just un-inverting images, is still useful
# [18:55] <tantek> tab: I will look into pulling in indieUI things we've discussed
# [18:55] <tantek> fantasai: another one ...
# [18:55] <tantek> tab: kina
# [18:55] <tantek> kinda
# [18:55] <tantek> fantasai: e.g. opera with dark theme
# [18:55] <tantek> tab: that's interesting
# [18:55] <tantek> tab: might be a good direction to go in, preferred theming
# [18:56] <tantek> tab: final issue - view-mode
# [18:56] <tantek> tab: seems half reasonable
# [18:57] <tantek> tab: should properly pull it in and get it properly tested in real browsers
# [18:57] <tantek> smfr: generally deprecating media types, bunch of other specs refer to them
# [18:58] <tantek> smfr: e.g. animations says if you're media type print you should not animate
# [18:58] <tantek> smfr: things they can be converted to?
# [18:58] <tantek> tab: animations should just refer to the "updates" media feature
# [18:58] <tantek> simonsapin: media line?
# [18:58] <tantek> (in property definitions)
# [18:58] <tantek> tab: we should fix that
# [18:58] * Quits: kawabata3 (~kawabata3@public.cloak) ("Page closed")
# [18:58] * Joins: kawabata (~kawabata@public.cloak)
# [18:59] <tantek> bert: I use some of these media types!
# [18:59] <tantek> bert: they should keep working
# [18:59] <tantek> bert: they work in opera
# [18:59] <tantek> bert: projection, handheldd
# [19:00] <tantek> florian: not since 2007
# [19:00] <tantek> bert: also in openwave
# [19:00] <tantek> bert: deprecating is fine, but don't change their meaning
# [19:00] <tantek> tab: old browsers can do what they want
# [19:00] * Joins: MaRakow (~MaRakow@public.cloak)
# [19:00] <tantek> florian: new browsers won't match them
# [19:00] <tantek> bert: that's a problem
# [19:00] <tantek> tab: won't work on my phone
# [19:00] <tantek> bert: they have bad browsers
# [19:00] <tantek> tab: these media types are not used in practice
# [19:00] <tantek> bert: no
# [19:01] <tantek> plh: perhaps deprecate but still support instead of drop?
# [19:01] <tantek> shepazu: we're talking about for browsers made today and in the future
# [19:01] <tantek> bert: ok to add new functionality
# [19:01] <tantek> bert: but not ok to break existing documents
# [19:02] <tantek> tab: but those don't work in 99.99% of devices
# [19:02] <tantek> bert: but that's a bug in those browsers
# [19:02] <tantek> bert: so how do I get my projection?
# [19:02] <tantek> glazou: projection is completely undefined
# [19:03] <tantek> bert: but it works
# [19:04] <tantek> tantek: projection only worked in one implementation. claiming we should support those documents is like saying all browsers should support -webkit- prefix features.
# [19:04] <dbaron> dbaron: The thing Opera did with projection is nothing like what the spec said.
# [19:04] <tantek> bert: but projection was in a standard
# [19:04] <tantek> (lots of talking)
# [19:05] <tantek> florian: this document at an editorial level was a major rewrite
# [19:05] <tantek> florian: please review to make sure we didn't change meaning of existing features (unintentionally)
# [19:05] <tantek> glazou: next step
# [19:05] <tantek> tab: request FPWD
# [19:05] <tantek> glazou: who agrees on FPWD
# [19:05] <tantek> glazou: who objects
# [19:05] <tantek> glazou: consensus FPWD MQ4
# [19:06] <tantek> tab: also I need to be an editor
# [19:06] <dbaron> (probably about 2/3 or more of the room in favor, and no objections)
# [19:06] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [19:06] <tantek> glazou: who will publish it? staff contact?
# [19:07] <tantek> shepazu: had a long conversation Sunday about projection
# [19:07] <tantek> shepazu: use cases
# [19:07] <tantek> shepazue: 1 notes on screen but not visible on projector (second screen thing)
# [19:07] <tantek> shepazu: 2 change contrast when it is being projected, higher contrast
# [19:07] <tantek> 3 full screen on the projection and not necessarily on your main screen
# [19:08] <tantek> florian: e.g. if you try to replicate Powerpoint in a browser
# [19:08] <tantek> shepazu: if you mirror screens, is that OS level and you can't effect? we aren't sure how we're going to address all this
# [19:08] <tantek> smfr: two of those things sounded like you wanted two views of the same document
# [19:08] <tantek> clilley: there are other contexts we've discussed that
# [19:08] <glazou> RESOLVED: FPWD of MQ4, editor and ChrisL ; Tab added as editor
# [19:08] <tantek> glazou: time
# [19:09] * Joins: florian (~Adium@public.cloak)
# [19:09] * fantasai did not understand that resolution, please rewrite what was meant?
# [19:09] <fantasai> RESOLVED: FPWD of MQ4
# [19:09] <tantek> RESOLVED: publish FWPD of MQR, add Tab as editor
# [19:09] <fantasai> ok, thanks :)
# [19:09] <tantek> RESOLVED: publish FWPD of MQ4, add Tab as editor
# [19:09] <tantek> new topic
# [19:09] <tantek> Topic: baseline grids
# [19:09] <tantek> astearns speaking/ presenting
# [19:10] <tantek> … had a problem, and with CSS in general
# [19:10] <tantek> … (sets up projector)
# [19:10] <tantek> … have been using this as an example of baseline grids
# [19:10] <tantek> … they have side by side content, and none of the baselines align across columns
# [19:11] <tantek> … it would be great to have a way to share a baseline grid
# [19:11] * plh can't stop thinking "Alan Is Watching You" when looking at the image
# [19:11] <tantek> … so that the columns could share baselines in body text
# [19:11] <tantek> … it would be great if CSS could address this problem
# [19:11] <tantek> … having line boxes align to a grid is a first step
# [19:11] <tantek> … you want a way to say I want these lines to participate in a grid and others not
# [19:12] <tantek> … e.g. body text stays on the grid
# [19:12] <tantek> … or giving blocks a way to align to the grid in interesting ways
# [19:12] <tantek> … e.g. having the first baseline of the element align to the grid
# [19:12] <tantek> … or having the entire block center on the grid
# [19:12] <tantek> … in either case you get a much better layout
# [19:13] <tantek> fantasai: I have a proposal but it depends on the Line Box Module
# [19:13] <tantek> simonsapin: line-grid module?
# [19:13] <tantek> astearns: yes
# [19:13] <fantasai> fantasai: I wrote a proposal, but the WG decided it wanted to put in the line Box module, which is not in a publishable state
# [19:13] <tantek> szilles: critical part, what gets aligned, and how big is it
# [19:13] <fantasai> fantasai: So I'm not allowed to publish it
# [19:14] <tantek> astearns: does fantasai's proposal handle it?
# [19:14] <dauwhe> http://dev.w3.org/csswg/css-line-grid/
# [19:14] <tantek> szilles: not clear
# [19:14] * hober IIRC we based -webkit-line-clamp on fantasai's proposal
# [19:14] <tantek> szilles: the way CSS does line boxes, not clear if you can determine the baselines
# [19:15] <tantek> astearns: there has to be because flexbox does some first baseline based alignment
# [19:15] <SimonSapin> fantasai, Line Box, is it Line Layout / css-inline ?
# [19:15] <tantek> clilley: would be nice to see more alignment
# [19:15] <tantek> clilley: second comment, also drop caps, n lines below the baseline
# [19:16] <tantek> clilley: 3 other alphabets align to top line etc.
# [19:16] <fantasai> clilley^: e.g. align by-lines to each other at the bottom
# [19:16] <tantek> astearns: sometimes it's not the baseline, sometimes it's some other typographic measure
# [19:16] <tantek> astearns: CJK
# [19:17] <tantek> fantasai: center baseline
# [19:17] <tantek> szilles: e.g. don't want to take ruby into account when doing the alignment
# [19:17] <fantasai> s/CJK/e.g. CJK centers the content/
# [19:17] <fantasai> s/center baseline/actually, it aligns to a baseline as well -- happens to be the central baseline rather than alphabetic baseline/
# [19:17] <tantek> astearns: ...
# [19:18] <tantek> astearns: (other problems)
# [19:18] <tantek> szilles: also widows and orphans
# [19:18] <fantasai> s/.../problem of aligning lines to baseline grid while bottom-aligning the content
# [19:18] <tantek> bert: ...
# [19:19] <Bert> (Like leader(), but vertical.)
# [19:19] <tantek> astearns: the main relationship depends on the order in the block direction
# [19:19] <tantek> astearns: how tall it is when you are bottom aligning it, then relates to grid, then loop
# [19:19] <tantek> astearns: I would like to work on this
# [19:19] <tantek> astearns: perhaps I can help co-edit Line Box Module
# [19:20] <tantek> szilles: ...
# [19:20] <tantek> fantasai: let's publish both of them, and continue working on both
# [19:20] <tantek> clilley: ?
# [19:20] <tantek> fantasai: I proposed line-grid module
# [19:20] <tantek> fantasai: but WG asked me to make it work with line box module
# [19:21] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [19:21] <tantek> florian: how can we depend on baselines without defining them?
# [19:21] <tantek> tantek: because baselines are shipping
# [19:21] <tantek> fantasai: once they both exist, cross referencing would be better
# [19:21] <tantek> clilley: if they both reference 2.1, just publish
# [19:21] <tantek> fantasai: that would be better
# [19:21] <TabAtkins> Tantek, *something* is shipping, which vaguely resembles what we typically call "baselines". That doesn't mean it's something we can write further features on top of.
# [19:21] <tantek> clilley much more eyes on it by publishing it
# [19:22] <tantek> TabAtkins, flexbox would seem to be an existence disproof of that statement. ;)
# [19:22] <tantek> (as a further feature on top of "baselines")
# [19:22] <fantasai> http://dev.w3.org/csswg/css-line-grid/
# [19:22] <fantasai> http://dev.w3.org/csswg/css-inline/
# [19:22] <TabAtkins> Flexbox is a minor violation of that statement. It only barely touches baselines. ^_^
# [19:22] <tantek> fantasai: these are the two modules we are talking about
# [19:23] <tantek> glazou: are we done?
# [19:23] <tantek> astearns: I would like to start with fantasai's proposal
# [19:23] <tantek> shepazu: I second that
# [19:24] <tantek> glazou: but where?
# [19:24] <tantek> fantasai: ok to publish as its own module
# [19:24] <tantek> fantasai: and merge later
# [19:25] * Joins: florian (~Adium@public.cloak)
# [19:25] <tantek> glazou: summarize?
# [19:25] <tantek> dbaron: so I don't entirely understand what the line grid spec is saying
# [19:25] <tantek> dbaron: should we - if we're going to publish this can discuss it a few minutes
# [19:25] <tantek> florian: we reviewed it in Kyota
# [19:26] <tantek> s/Kyota/Kyoto
# [19:26] <tantek> dbaron: the line-grid property seems global rather than an ancestor chain which seems weird
# [19:26] <tantek> dbaron: seems to imply a temporal things
# [19:26] <tantek> dbaron: would be better if it said ancestor
# [19:26] <tantek> dbaron: that should be clarified
# [19:26] <tantek> bert: seems overkill. should be ok to say this element defines a grid or not.
# [19:27] <tantek> bert: you don't need an identifier for that
# [19:27] <tantek> szilles: the reason you need identifier is you may have two grids going at the same time. one for figures and one for text
# [19:27] <tantek> bert: seems a bit far fetched
# [19:27] <tantek> bert: would like to see it based on ancestors first
# [19:28] <tantek> szilles: would prefer some discussion first
# [19:28] <tantek> clilley: we discussed at hamburg
# [19:29] <tantek> szilles: issues raised in Hamburg were not handled
# [19:29] <tantek> clilley: it is ready for FPWD
# [19:29] <tantek> clilley: if there are outstanding issues, then put them into the draft and publish
# [19:29] <tantek> tantek: agree with chris
# [19:31] <tantek> fantsai: it wasn't discussed in Hamburg, it was discussed in Kyoto 2.5 years ago
# [19:31] <tantek> s/fantsai/fantasai
# [19:31] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [19:31] <tantek> glazou: we agree that we add known issue to the document?
# [19:31] <smfr> i assume we're talking about http://dev.w3.org/csswg/css-line-grid/
# [19:31] <tantek> smfr, yes
# [19:31] <tantek> fantasai: only known issue: wanting to simplify to only use ancestors, not identifiers
# [19:31] <tantek> szilles: my issue, does it consider ruby?
# [19:31] <tantek> fantasai: ?
# [19:32] <tantek> glazou: why are we blocking this?
# [19:33] <tantek> RESOLVED add astearns, fantasai as editors to line-grid module, published FPWD css-line-grid
# [19:33] <tantek> dbaron: I'd like to see that wording thing fixed.
# [19:33] <tantek> fantasai: ok I'll fix it
# [19:33] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [19:33] <tantek> BREAK 15 minutes
# [19:33] * Joins: koji (~koji@public.cloak)
# [19:34] * Joins: lmcliste_ (~lmclister@public.cloak)
# [19:40] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [19:44] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [19:50] * Joins: florian (~Adium@public.cloak)
# [19:50] * Joins: koji (~koji@public.cloak)
# [19:51] <sgalineau> scribenick: sgalineau
# [19:51] <sgalineau> topic: css3-color
# [19:52] <sgalineau> chris: to discuss the state of implementation and test suite
# [19:52] <sgalineau> fantasai: any testcases from anyone on currentColor?
# [19:52] <sgalineau> dbaron: I think I added one for the new behavior...
# [19:53] <dbaron> I added contributors/mozilla/submitted/css3-transitions/currentcolor-animation-001.html
# [19:53] <sgalineau> fantasai: currentColor used to compute to the value of color
# [19:53] <sgalineau> fantasai: instead it now inherits
# [19:53] <sgalineau> dbaron: the test I added for another behavior derived from this change, namely animation implication
# [19:54] <sgalineau> dbaron: you'd need to use currentColor on background and test its inheritance
# [19:54] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22color%3A%20red%3B%20border-color%3A%20currentColor%22%3E%0A%3Cdiv%20style%3D%22border-style%3A%20solid%3B%20border-color%3A%20inherit%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
# [19:54] <dbaron> contributors/mozilla/submitted/css3-color/t44-currentcolor-inherited-c.xht
# [19:55] <dbaron> is a direct test for the erratum
# [19:55] <fantasai> http://test.csswg.org/shepherd/testcase/t44-currentcolor-inherited-c/name/t44-currentcolor-inherited-c/
# [19:55] <sgalineau> chrisl: is this test waiting for review? I am happy to review
# [19:56] * Joins: ChrisL (clilley@public.cloak)
# [19:56] <fantasai> r=fantasai
# [19:56] <SimonSapin> SimonSapin: Servo should implement the new behavior, but I haven’t tested it explicitly
# [19:56] <sgalineau> ACTION chris Review dbaron's test
# [19:56] * trackbot is creating a new ACTION.
# [19:56] <trackbot> Created ACTION-610 - Review dbaron's test [on Chris Lilley - due 2014-02-04].
# [19:56] * Joins: adenilson (~anonymous@public.cloak)
# [19:56] * sgalineau David discovers that it's tests all the way down
# [19:56] <dbaron> http://test.csswg.org/shepherd/search/name/t44-currentColor/
# [19:56] <dbaron> the two plinss tests are for the old behavior
# [19:57] <sgalineau> fantasai: does anyone implement it?
# [19:57] <sgalineau> simonsapin: Servo...maybe?
# [19:57] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [19:57] <sgalineau> fantasai: does any impl pass David's test?
# [19:57] <dbaron> http://test.csswg.org/shepherd/repository/5af75de6ab2b85d4233bd429e9897820c28180b4/contributors/mozilla/submitted/css3-color/t44-currentcolor-inherited-c.xht
# [19:57] <sgalineau> chris: Firefox does not.
# [19:58] <sgalineau> Rossen: no pass in IE either
# [19:58] <smfr> no pass in WebKit
# [19:59] <sgalineau> fantasai: we needed current color for an inheritable property: text-emphasis
# [19:59] <sgalineau> fantasai: we wanted the initial value to be something that said use the current color
# [19:59] <SimonSapin> After changing the test to not use CDATA (we don’t support XML), Servo passes the test
# [20:00] <sgalineau> fantasai: so it was a matter of adding a new keyword or redefining currentColor
# [20:00] <sgalineau> fantasai: the change made no difference for current use of the keyword
# [20:00] <sgalineau> fantasai: so we were able to make the change even though it was incompatible
# [20:00] <SimonSapin> WeasyPrint passes too
# [20:01] <sgalineau> dirk: I don't think the SVG WG reached consensus
# [20:01] <sgalineau> fantasai: if we don't want to make this change we need a different keyword
# [20:01] * ChrisL new-current-color
# [20:01] * fantasai current-color would work. currentColor is not current-color ;)
# [20:01] <sgalineau> dbaron: in Gecko we have a second implementation of currentColor because we can't use the old currentColor
# [20:03] <sgalineau> SimonSapin: Servo and WeasyPrint pass this test
# [20:03] <sgalineau> fantasai: anyone implement text-emphasis?
# [20:03] <sgalineau> <crickets>
# [20:03] <tantek> I am ok with this change to currentColor
# [20:03] <fantasai> SimonSapin, do Servo and WeasyPrint both pass the entire CSS3 Color test suite?
# [20:03] <tantek> this seems like a good improvement to currentColor
# [20:04] * fantasai would like to improve it by adding a hyphen, but that ship may have sailed
# [20:04] <SimonSapin> fantasai, I don’t know, since that suite is not automated
# [20:04] * Joins: stakagi (~stakagi@public.cloak)
# [20:05] * krit fantasai wasn't currentColor coming from SVG anyway?
# [20:05] * sgalineau notes minuting is much easier when people in the room use IRC instead
# [20:05] * krit SVG has had it for 14 years now :P
# [20:05] <SimonSapin> fantasai, they do pass color3*.json in https://github.com/SimonSapin/css-parsing-tests , but that’s only parsing
# [20:05] * astearns also, a mostly-silent room is soothing
# [20:06] <sgalineau> Topic: reverse lists
# [20:06] <sgalineau> tab: the lists module correctly handles HTML list rendering
# [20:06] <sgalineau> tab: except for the reverse attribute which counts backwards
# [20:06] <sgalineau> tab: if you look at the list module right now the style sheet resets the counter to some magic thing so we can't express this
# [20:06] * krit didn't we resolve that CSS has less magic?
# [20:07] <sgalineau> tab: so do we keep it magic or do we have a way to represent the number of children of an element
# [20:07] <TabAtkins> http://dev.w3.org/csswg/css-lists/#ua-stylesheet
# [20:07] <sgalineau> simonsapin: right now this is a non-normative stylesheet so we could consider this magic for now
# [20:07] <sgalineau> dbaron: i think we should address this eventually but this is not a priority right now. and the way we do address it should not just be some hack like counting the number of children
# [20:08] <sgalineau> dbaron: though it's possible html defines it as...
# [20:08] * Joins: MaRakow_ (~MaRakow@public.cloak)
# [20:08] <sgalineau> simonsapin: html suggests to count the number of <li>
# [20:08] <sgalineau> plinss: and does the display value impact the count?....
# [20:09] <SimonSapin> s/suggests/specifies/
# [20:09] <dbaron> it sounds like <ol reversed><li><li value="20"><li></ol> gives 3, 20, 19, which isn't quite expected...
# [20:09] <sgalineau> fantasai: so at the present level counter-reset is set to a magic value at the current level
# [20:09] <dbaron> I'd rather have had a mechanism that gave 21, 20, 1
# [20:09] <fantasai> fantasai: So, the HTML has a preshint-level rule that sets counter-reset on the list element to the number of <li> in the list
# [20:10] <fantasai> dbaron, that doesn't make any sense to me
# [20:10] <SimonSapin> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#attr-ol-reversed
# [20:10] <dbaron> reversed means "works the normal way but counts in the other direction"
# [20:10] <glazou> it is expected because reversing a list is only setting start a counter-increment: -1
# [20:10] <sgalineau> RESOLVED: keep counter-reset magic for reverse lists in level 3
# [20:10] <sgalineau> Topic: Transforms
# [20:10] <fantasai> dbaron: hm, fair enough. I interpreted it as "count downwards", which I suppose matches the attr name less
# [20:10] <SimonSapin> s/reverse/<ol reversed>/
# [20:11] <fantasai> dbaron, I think counting downwards is easier to conceptualize as counters, though
# [20:11] <SimonSapin> dbaron, I don’t think any behavior makes sense in that example
# [20:11] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [20:12] <sgalineau> smfr: previously i tried to clarify a couple of areas
# [20:12] <sgalineau> smfr: i would like to revise the current text slightly
# [20:13] <sgalineau> smfr: there would be a small behavior change but current interop is good
# [20:13] <sgalineau> smfr: 1) how preserve-3d works 2) what elements in the document cause flattening to happen are the two topics
# [20:13] <sgalineau> <shows testcase>
# [20:13] <sgalineau> two elements with 3d transforms applied to them
# [20:13] <sgalineau> no preserve-3d
# [20:13] <sgalineau> two siblings
# [20:14] * Quits: smfr (~smfr@public.cloak) (Client closed connection)
# [20:14] <sgalineau> these elements intersect with each other but not their parent
# [20:14] <sgalineau> today the spec says this is just a painting effect
# [20:15] <sgalineau> in webkit we do support intersection. i would like this to be the right behavior because it simplifies the explanation of preserve-3d
# [20:15] * TabAtkins fantasai, I strongly object to having both currentcolor and current-color. ^_^
# [20:15] <sgalineau> …<next test>
# [20:16] <sgalineau> …in this new model, if you wanted to prevent intersection you would need the parent to force flattening with transform-style:flat
# [20:16] * Ms2ger wants currentColour
# [20:16] <sgalineau> …the next question is when does a transformed element intersect with its parent?
# [20:17] <sgalineau> …<shows test where preserve-3d is applied to the parent>
# [20:17] <sgalineau> …intersection is where there is little interop
# [20:17] <sgalineau> ACTION smfr Share transform testcases with the group
# [20:17] * trackbot is creating a new ACTION.
# [20:17] <trackbot> Created ACTION-611 - Share transform testcases with the group [on Simon Fraser - due 2014-02-04].
# [20:18] <sgalineau> tab: so webkit make the siblings intersect in their own space then flatten
# [20:18] <sgalineau> smfr: the spec currently explains it using '3d rendering context' established by preserve-3d
# [20:19] <sgalineau> smfr: it says such elements can intersect with each other based on z-depth (not document z-index)
# [20:19] <sgalineau> smfr: so sometimes elements are a 3d rendering context, otherwise they're not
# [20:19] <sgalineau> smfr: instead I'd like to say that every element is in a 3d rendering context but sometimes it's only one element deep
# [20:19] <sgalineau> smfr: similar to stacking contexts
# [20:20] <sgalineau> dbaron: I thought i understood until we compared to stacking contexts...
# [20:20] <sgalineau> smfr: today you're sometimes in a 3d rendering context, sometimes you're not
# [20:20] <sgalineau> smfr: whereas with css contexts, all elements belong to a stacking context
# [20:21] <sgalineau> dbaron: the default with stacking contexts is to not make a new one; it sounds like with 3d rendering contexts the default would be to make a new one?
# [20:21] <sgalineau> smfr: I think I'm proposing to change that also
# [20:21] <sgalineau> smfr: now I'm considering that transform-style:flat creates a 3d rendering context
# [20:22] <sgalineau> smfr: preserve-3d extends this context through the element
# [20:22] <sgalineau> smfr: I'm proposing to transform-style: auto as an initial value instead of the current 'flat'
# [20:23] <sgalineau> smfr: if you have two elements with 3d transforms; parent has preserve-3d. its ancestor is flat
# [20:23] <sgalineau> smfr: the spec is ambiguous as to how/whether elements inserted above those child elements can cause flattening
# [20:24] <sgalineau> dbaron: the spec says this is containing-block based
# [20:24] <sgalineau> smfr: right. so it wasn't clear whether stacking contexts or containing blocks were involved
# [20:24] <sgalineau> smfr: the reason for 'auto' makes the determination of 3d rendering context unambiguous
# [20:26] <sgalineau> smfr: some things cause flattening like opacity, filters….if an element has a 2d or 3d transforms and transform-style:auto then it should be flattened
# [20:27] <sgalineau> dbaron: I'm trying to understand how this works with the various z-ordering rules that require various things to interleave
# [20:28] <sgalineau> dbaron: before this only things that established a stacking context could be preserve-3d
# [20:28] <sgalineau> dbaron: if you don't establish a stacking context things can interleave
# [20:28] <sgalineau> dbaron: I'm not sure what this means in this new model
# [20:28] <sgalineau> smfr: the spec would have to say that the root has transform-style:flat
# [20:28] <sgalineau> smfr: in the new model, the root creates a 3d rendering context
# [20:29] <sgalineau> smfr:...
# [20:30] <sgalineau> smfr: transform--style:flat establishes a 3d rendering context; you render the 3d transform descendants, including intersections...
# [20:30] <sgalineau> smfr: then you composite those above the untransformed parents...
# [20:30] <sgalineau> dbaron: suppose the root has another child with a z-index
# [20:31] <sgalineau> dbaron: so you flatten all the 3d stuff and render it with infinite z-index in that stacking context?
# [20:31] <sgalineau> smfr: I think so
# [20:32] * Joins: adenilson (~anonymous@public.cloak)
# [20:32] <sgalineau> smfr: when you have neg z-index, it renders behind…in this model, 3d descendants don't intersect with the plane of what creates the 3d rendering context....
# [20:32] <sgalineau> smfr: I don't think there is a way that z-index can trump the 3d rendering contexts
# [20:32] <sgalineau> dbaron: I agree
# [20:32] <sgalineau> dbaron: it would be great to have a write-up of this
# [20:32] <sgalineau> smfr: I have one in draft form, with test cases
# [20:33] <sgalineau> dirk: this fixes a lot of issues we currently have in the spec
# [20:33] <sgalineau> dbaron: I think the intersection of this with stacking contexts sounds OK
# [20:34] <sgalineau> dbaron: what this means is that in the default case, if you specify a 3d transform on one thing in the doc and nothing else, then this thing is above everything in the document
# [20:34] <sgalineau> smfr: yes
# [20:34] <sgalineau> dbaron: it seems kind of reasonable. but is it web compatible?
# [20:35] <sgalineau> dbaron: I'd like to hear from our transform experts...
# [20:35] <sgalineau> dbaron: i'm worried about compat but compat is also messy right now in this area
# [20:35] <sgalineau> smfr: i think this model helps explain perspective as well i.e. it doesn't cross 3d rendering context boundaries
# [20:36] <sgalineau> dirk: i agree we want more people to check out the proposal
# [20:36] <sgalineau> dirk: over email
# [20:36] <sgalineau> dbaron: yes
# [20:36] <sgalineau> smfr: I will send the proposal to www-style
# [20:37] <sgalineau> plinss: I'm a bit about the interaction with z-index...
# [20:37] <sgalineau> plinss: could we rationalize the two models?
# [20:39] <sgalineau> Bert wonders whether flattening is necessary
# [20:39] <sgalineau> dbaron, smfr, dirk: a bunch of things require it
# [20:39] <sgalineau> Bert: it is hard to explain transform-style
# [20:39] <sgalineau> smfr: this will help explain it.
# [20:39] <sgalineau> chris: you'll be able to say it's like stacking contexts!
# [20:40] * Joins: smfr (~smfr@public.cloak)
# [20:41] <sgalineau> ACTION smfr to send update to mailing list
# [20:41] * trackbot is creating a new ACTION.
# [20:41] <trackbot> Created ACTION-612 - Send update to mailing list [on Simon Fraser - due 2014-02-04].
# [20:41] <sgalineau> smfr: based on feedback I'll update the ED
# [20:41] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [20:41] <sgalineau> smfr, dirk: no other issues to discuss
# [20:41] <krit> http://dev.w3.org/csswg/css-transforms/#issues-index
# [20:43] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
# [20:43] <fantasai> ScribeNick: fantasai
# [20:43] <fantasai> Topic: Display Module Revisited
# [20:44] <fantasai> TabAtkins: Wanted to discuss fantasai's run-in model, and whether to integrate it into Display module
# [20:44] <fantasai> TabAtkins summarizes the model
# [20:44] <fantasai> (see mail above)
# [20:44] <fantasai> foo <runin>bar</runin>
# [20:44] <fantasai> creates a block boundary between foo and bar
# [20:45] <fantasai> TabAtkins: It's a remarkably simple model, and solves every problem we've had with run-ins, I believe.
# [20:45] * liam thinks the mail looks sane and helpful
# [20:45] <fantasai> fantasai: bz did raise some issues, but solveable by defining things more precisely
# [20:46] <fantasai> dbaron: Any interesting things wrt placeholders inside run-in?
# [20:46] <fantasai> dbaron: The whether things run in is purely computable at box-tree generation time? No layout effect at all?
# [20:46] <fantasai> TabAtkins: Yes
# [20:46] <fantasai> TabAtkins: Some box-tree mangling, but no layout
# [20:46] <fantasai> SteveZ: So inline, but create a new block if needed
# [20:47] <fantasai> TabAtkins: or merge into next block if needed
# [20:47] <fantasai> RESOLVED: Add fantasai's run-in model to Display Model, with clarifications / fixes needed to solve bzbarsky's issues
# [20:47] <fantasai> TabAtkins: Also, I would like to publish FPWD
# [20:47] <fantasai> http://dev.w3.org/csswg/css-display-3/
# [20:48] <fantasai> SimonSapin: Where does run-in fit into this module?
# [20:48] <fantasai> TabAtkins: It's a display-outside value, like inline-level
# [20:48] <fantasai> SimonSapin: Doesn't affect display-inside?
# [20:48] <fantasai> TabAtkins: Not at all
# [20:49] <fantasai> dbaron asks for clarification on how the shorthand handles omitted values
# [20:50] <fantasai> ACTION TabAtkins clarify how omitted values are handled for display shorthand (and other shorthands he might've forgotten to handle)
# [20:50] * trackbot is creating a new ACTION.
# [20:50] <trackbot> Created ACTION-613 - Clarify how omitted values are handled for display shorthand (and other shorthands he might've forgotten to handle) [on Tab Atkins Jr. - due 2014-02-04].
# [20:50] <fantasai> SimonSapin: What are longhands for 'display'?
# [20:51] <fantasai> fantasai: display-inside, display-outside, display-decoration
# [20:51] <fantasai> TabAtkins: Yes, need to specify that they get reset
# [20:51] <fantasai> dbaron: display shorthand should be more clear about what happens with values listed twice
# [20:51] <fantasai> dbaron: e.g. flex is both a value for 'display' and also 'display-inside', how is it interpreted
# [20:52] <fantasai> TabAtkins: Yes, I can be much clearer about that
# [20:52] <fantasai> florian: Does this model make sense for authors and others who don't have a deep mental model of how this all works?
# [20:52] <fantasai> TabAtkins: The main motivation is to separate out display: none, the rest is just making things easier
# [20:54] <fantasai> dbaron: I'm ok with publishing
# [20:54] <fantasai> RESOLVED: FPWD Display Module
# [20:54] <fantasai> SimonSapin: display-inside: auto;, says some cases element acts as normal. Should also specify what is the computed value
# [20:55] <TabAtkins> (the computed value is still "auto")
# [20:55] <fantasai>
# [20:58] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [20:59] * Joins: koji (~koji@public.cloak)
# [20:59] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [21:01] * Joins: koji_ (~koji@public.cloak)
# [21:01] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [21:13] * Quits: koji_ (~koji@public.cloak) (Client closed connection)
# [21:13] * Joins: koji (~koji@public.cloak)
# [21:20] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [21:23] * Joins: florian (~Adium@public.cloak)
# [21:28] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [21:28] * leaverou_away is now known as leaverou
# [21:29] * Joins: stakagi (~stakagi@public.cloak)
# [21:35] * Joins: glenn (~gadams@public.cloak)
# [21:38] * leaverou is now known as leaverou_away
# [21:42] * leaverou_away is now known as leaverou
# [21:46] * Joins: koji (~koji@public.cloak)
# [21:57] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [22:05] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [22:06] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [22:06] * Joins: emalasky (~Adium@public.cloak)
# [22:10] * Joins: emalasky1 (~Adium@public.cloak)
# [22:10] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [22:10] * leaverou is now known as leaverou_away
# [22:10] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [22:11] * leaverou_away is now known as leaverou
# [22:14] <smfr> hi leaverou!
# [22:15] <leaverou> hi smfr !!
# [22:15] <ChrisL> hi lea, how was sunny africa?
# [22:15] <leaverou> I'm still in Africa :)
# [22:15] <ChrisL> s/was/is
# [22:15] <leaverou> going back on Sunday
# [22:15] <leaverou> it's great!! Different than anywhere else I've ever been to
# [22:16] <smfr> leaverou: we were talking about a 9-piece image function yday
# [22:16] <ChrisL> life's a beach and then you code
# [22:16] <smfr> leaverou: not much support, and a call for use cases
# [22:16] <smfr> leaverou: so if you have use cases, could you share them somehow?
# [22:16] <leaverou> smfr: you mean for 9 slice scaling?
# [22:16] <ChrisL> call for use cases that aren't borders
# [22:16] <smfr> leaverou: right
# [22:16] <leaverou> hmm I think I've come across some, but can't remember them off the top of my head right now :/
# [22:17] <smfr> main comment on things like button backgrounds was "why can't you use user border image?"
# [22:18] <leaverou> what about masking?
# [22:18] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [22:18] <leaverou> like, if you were able to 9-slice-scale any image, you could use it for masking too
# [22:19] <leaverou> which you can't flexibly do with border-image
# [22:19] <smfr> this came up in the context of masking
# [22:19] <smfr> do we remove mask-box in favor of some mythical future image slicing function
# [22:20] * Joins: Rossen__ (~Rossen@public.cloak)
# [22:21] * Rossen__ is now known as Rossen_f2f
# [22:21] <leaverou> that doesn't seem very wise when we already have implementations of mask-box
# [22:21] <leaverou> we can always have the image slicing function in addition
# [22:22] <TabAtkins> leaverou: Main issue with usign it for masking is that you need the "outset" ability that border-image has, but that's nonsense for normal images.
# [22:22] <TabAtkins> Because normal images dont' extend outside of their bounds.
# [22:22] <TabAtkins> ScribeNick: TabAtkins
# [22:22] * Joins: florian (~Adium@public.cloak)
# [22:23] <TabAtkins> Topic: Fragmentation
# [22:23] <TabAtkins> fantasai: Main issue is element vs box vs fragment.
# [22:23] <smfr> http://dev.w3.org/csswg/css-break/
# [22:23] <TabAtkins> fantasai: Dirk posted some issues about hwo the spec is confusing.
# [22:23] <TabAtkins> fantasai: We have three things that need names right now.
# [22:24] <TabAtkins> fantasai: 1) thing in source document that has a tagname/etc
# [22:24] <TabAtkins> fantasai: 2) abstract layout object that is maybe associated with (1). Often 1 per (1), sometimes 2+ or 0 per.
# [22:24] <TabAtkins> fantasai: So far in CSS, never more than 2 per.
# [22:25] <TabAtkins> fantasai: And it has properties, like 'width'.
# [22:25] <TabAtkins> fantasai: 3) pieces of (2) that are rectangular after fragmentation.
# [22:26] <TabAtkins> dbaron: If you're display:none, you have (1) but no (2).
# [22:26] <TabAtkins> dbaron: If you're display:table, you have a single (1) but two (2)s - table box and table container box.
# [22:27] * Joins: stakagi (~stakagi@public.cloak)
# [22:27] <TabAtkins> dbaron: Depending on how you interpret block-in-inline-splitting-the-inlines, there might be more than 2 (2)s per (1).
# [22:28] <TabAtkins> fantasai: Currently we call (1) an element, (2) a box, and (3) a fragment, or box fragment.
# [22:28] <TabAtkins> fantasai: If anyone wants something else, propose it.
# [22:28] <TabAtkins> SimonSapin: I don't think we have an issue for (1). It's called an "element" in DOM and Selectors too.
# [22:28] <TabAtkins> SimonSapin: The issue is with "box" - we sometimes use it when we mean (3).
# [22:31] <TabAtkins> fantasai: [goes through another element/box/fragment example]
# [22:34] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [22:34] <TabAtkins> fantasai: CSS 2.1 uses "element" and "box" interchangeably to refer to all of these.
# [22:34] <TabAtkins> fantasai: Or at least, "element" for (1) and (2), and "box" for (2) and (3) (and sometimes (1)).
# [22:34] * Joins: sgalineau (~sgalineau@public.cloak)
# [22:35] * Quits: sgalineau (~sgalineau@public.cloak) (sgalineau)
# [22:35] * Joins: sgalinea_ (~sgalineau@public.cloak)
# [22:35] <TabAtkins> fantasai: We're trying to replace all of this by writing CSS3 specs.
# [22:36] * glazou we need "fragmented pseudo-elemental boxes" I think...
# [22:37] * Ms2ger except tables, and stuff
# [22:38] * astearns fragmepseudelemtainers
# [22:38] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:39] <TabAtkins> dbaron: One thing that confused people is that "box" may not be rectangular.
# [22:40] <dbaron> (SteveZ proposes "unresolved formatting object"; ChrisL proposes "universal formatting object")
# [22:41] <dbaron> Bert: Can "box has property" be a shorthand for "element has property"?
# [22:41] <TabAtkins> Bert: In 2.1, we want to say that boxes have properties. Is this true?
# [22:41] <dbaron> Tab, fantasai: yes! Also anonymous boxes need that.
# [22:41] <TabAtkins> fantasai: Yes, we agreed on that a while ago. Anonymous boxes definitely have properties.
# [22:41] <TabAtkins> Bert: Is the box structure always a tree?
# [22:41] <TabAtkins> fantasai: Yes.
# [22:41] <dbaron> 林
# [22:42] <ChrisL> grove
# [22:42] <TabAtkins> Bert: What about margin boxes? They're not in the same tree as the elements.
# [22:42] <smfr> box -> package
# [22:42] <TabAtkins> fantasai: They're in a separate tree.
# [22:42] <TabAtkins> SimonSapin: Paged Media also has a terminology problem with "page box".
# [22:42] <TabAtkins> SimonSapin: For each page, there's a root box, which contains the root boxes, and the box for the page content.
# [22:43] <TabAtkins> SimonSapin: Someone we say "page box" for the root box, sometimes for the content box.
# [22:43] <TabAtkins> fantasai: So, I thought we had an agreement several years ago regarding terminology, which is what's in the Fragmentation spec.
# [22:43] <TabAtkins> fantasai: But Dirk said he's confused.
# [22:43] * Joins: rhauck (~Adium@public.cloak)
# [22:44] <TabAtkins> Rossen_: And hopefully we make this the last time we talk about this.
# [22:44] <TabAtkins> shepazu: I think it would be valuable for everyone involved to have a very clear explanation fo this written in a spec.
# [22:45] <TabAtkins> fantasai: I think we could handle this between Display and Fragmentation.
# [22:45] <TabAtkins> TabAtkins: Yeah, I can take fantasai's explanation/diagram and put it in Display.
# [22:46] <TabAtkins> krit: So can we resolve to keep these terms?
# [22:47] <TabAtkins> shepazu: And resolve to put a good explanation of these terms somewhere?
# [22:48] * sgalinea_ is happy with almost any word except 'fragmentainer'
# [22:49] <glazou> let's absolutize the fragmentainers
# [22:49] <TabAtkins> Bert: I'd rather have "box" mean "rectangular".
# [22:50] <ChrisL> http://www.flickr.com/photos/50612995@N02/6418083471/
# [22:50] <TabAtkins> florian: I'm confused by "region box". If it's none of those, we shouldn't use the existing words.
# [22:51] <TabAtkins> krit: Why not use "box" for "fragmentainer"?
# [22:51] <TabAtkins> fantasai: Because not all boxes are fragmentainers.
# [22:51] <TabAtkins> plinss: Why not call it "fragmenter"?
# [22:51] * dauwhe there has to be a joke about breaker boxes here somewhere, but I can't find it.
# [22:53] <TabAtkins> RESOLVED: use the terminology "element", "box", and "fragment"
# [22:53] * liam was just reviewing page boxes and viewports this morning, as it happens, comparing XSL-FO to css page
# [22:55] <TabAtkins> RESOLVED: put Elika's explanation of element/box/fragment distinction in Display and Fragmentation.
# [22:55] * dauwhe liam: could FO help with how to define pages and margin boxes in relation to elements, boxes, and fragments?
# [22:57] * dauwhe padding bochs, margin bochs...
# [22:57] <dbaron> dbaron: 4 wrenches: content box, padding box, border box, margin box
# [22:57] <dbaron> dbaron: could use * edge, * rectangle
# [22:57] * liam suspects page-viewport-area wouldn't go down too well
# [22:58] * dauwhe liam: true.
# [22:58] <dbaron> SimonSapin: * area
# [22:58] * tantek recommends a field trip to nearest The Container Store
# [22:58] * liam link - http://www.w3.org/TR/xsl11/#fo_simple-page-master - there's a diagram a little way down.
# [22:59] * sgalinea_ wants to see tantek fragmenting boxes at The Container Store
# [22:59] * tantek sgalineau we can practice box-sizing
# [22:59] <ChrisL> page-viewport-area? why not generator-of-sets-of-page-viewport-areas?
# [22:59] <TabAtkins> RESOLVED: Don't use "element", "box", or "fragment" in new terms that aren't elements, boxes, or fragments. Where possible, convert old terminology accordingly as well.
# [23:00] <liam> because it isn't that.
# [23:00] * tantek wonders what is a box
# [23:00] * tantek … compared to a block
# [23:01] * sgalinea_ thought a block was the thing that says where the boxes of the next element lay out by default
# [23:01] <TabAtkins> fantasai: So, let's say we have a large border-radius on a box, and it's fragmented partway through the curve.
# [23:02] <TabAtkins> fantasai: Do we keep the curve sliced across the fragment edge, or do we "correct" the edges in one fragment to connect to the box edge.
# [23:02] <TabAtkins> smfr: I think graphical slice is right - it'll keep the relationship with background.
# [23:02] <TabAtkins> fantasai: Yeah, probably.
# [23:03] <TabAtkins> krit: WK does that. FF "corrects" the border-radius.
# [23:03] <TabAtkins> dbaron: Mats Palmgren wrote some patches to do the slicing behavior, it hasn't landed yet.
# [23:04] <TabAtkins> RESOLVED: border-radius should get sliced across fragments, maintaining unfragmented geometry.
# [23:05] <fantasai> Clarify that for variable-widthf ragments, this is handled like for bg images
# [23:06] <TabAtkins> fantasai: If box fragments have different widths/heights, each piece draws its portion fo the bg, assuming the whole element has the same width as the fragment's piece.
# [23:06] <TabAtkins> fantasai: [is just quoting from the spec]
# [23:07] <fantasai> http://dev.w3.org/csswg/css-break/#joining-boxes
# [23:07] <florian> "piece" should be "fragment"
# [23:07] <TabAtkins> krit: What about the height?
# [23:07] <TabAtkins> fantasai: You lay out the box and fragment.
# [23:08] <TabAtkins> krit: Oh, so you sum the height of the fragments, and use that?
# [23:08] <TabAtkins> fantasai: Yeah. Backgrounds and borders are drawn after layout, so that's fine.
# [23:08] <TabAtkins> fantasai: But Shapes are done before/during layout, which might be a problem.
# [23:09] <TabAtkins> krit: If you take a fragment with the largest width, this'll be your "reference box" for general layout...
# [23:09] <TabAtkins> fantasai: No.
# [23:09] <TabAtkins> fantasai: This only doesn't work if you have an image with an aspect-ratio, where the height of the image depends on the width of the box.
# [23:09] <TabAtkins> fantasai: So in each fragment the image's progress changes, it's not monotonic.
# [23:10] <TabAtkins> fantasai: So you have to figure out the image's height, and use that through the entire tiling process.
# [23:10] <TabAtkins> fantasai: We use the width of the widest fragment for this, to disambiguate.
# [23:10] <TabAtkins> fantasai: So if you want an SVG image to stretch across the entire box, that'll work even if you fragment into different sizes.
# [23:10] <TabAtkins> fantasai: It'll be stretched/squished in some fragments, but it'll work.
# [23:10] <TabAtkins> krit: The spec seems to be unclear on this, it seems to say two different things about height.
# [23:11] <TabAtkins> krit: So I'd like more detail.
# [23:11] <TabAtkins> krit: Just make sure that it's really explicit.
# [23:12] * leaverou is now known as leaverou_away
# [23:13] <TabAtkins> krit: Another issue.
# [23:13] <TabAtkins> krit: Transform-origin is relative to border-box.
# [23:13] <TabAtkins> krit: So it's changed in each fragment.
# [23:15] <TabAtkins> krit: But if something overflows, and the *overflowing content* gets fragmented, what's the transform-origin in that stuff?
# [23:16] <TabAtkins> dbaron: The spec isn't clear, but I thought we'd agreed to do a single origin, based on the union of the fragments.
# [23:16] <TabAtkins> [confusion over whether the union is the unfragmented box, or the bounding box of the fragments]
# [23:16] <TabAtkins> krit: In Tucson, we resolved to do transform origin per fragment.
# [23:17] <TabAtkins> fantasai: The question was whether you transform first and then fragment, or fragment first and then transform.
# [23:17] * sgalinea_ thought we punted on transforms of inlines due to their fragmentation. This seems complicated for similar reasons...
# [23:18] <TabAtkins> fantasai: But I dont' think we specifically talked about transform origin.
# [23:18] <TabAtkins> Rossen_: I think it's more natural to do origin per fragment.
# [23:18] <TabAtkins> dbaron: I've seen people want to transform inlines, and if it gets split across lines, to rotate as a whole, rather than per-line.
# [23:19] <TabAtkins> krit: WK just does visual slicing right now.
# [23:21] <TabAtkins> [I think dbaron said that he wants to do a single transform-origin in the unfragmented coordinate space of the box]
# [23:21] <dbaron> yes..
# [23:22] <TabAtkins> fantasai: (1) take the bounding box of all fragments and use transform origin in that.
# [23:22] <TabAtkins> TabAtkins: (Which is nonsensical.)
# [23:22] <dbaron> I believe the spec did at one point say to do (1), though.
# [23:22] <TabAtkins> fantasai: (2) Each fragment computed origin per its fragment rectangle.
# [23:22] <smfr> q+
# [23:22] <TabAtkins> fantasai: (3) Take the composite (unfragmented) box (same as we do for background positioning), find the transform origin in that, then have each fragment use that origin.
# [23:23] <dbaron> I think (3) produces substantially better results from (2).
# [23:23] <TabAtkins> szilles: The Tucson minutes are clear that we resolved on per-fragment transforms (and implicitly origins)
# [23:24] <TabAtkins> dbaron: I don't recall that was what we were discussing, and I may have misunderstood at th etime. I'd object tothat now.
# [23:25] <TabAtkins> krit: [shows WK doing visual slicing, but FF doing per-fragment transforms]
# [23:25] <TabAtkins> florian: WK doing option 3, FF doing option 2.
# [23:25] <TabAtkins> smfr: [something about hyatt]
# [23:25] <TabAtkins> krit: hyatt agreed that it should be per border-box, and each column fragment gets its own border box
# [23:26] <TabAtkins> smfr: I think authors transforming fragmented content are crazy anyway.
# [23:26] <TabAtkins> smfr: The whole reason we punted on inlines was to avoid this issue.
# [23:27] <dbaron> dbaron: I take back what I said earlier; I'm ok with doing option (2).
# [23:27] <smfr> smfr: should box-decoration-break affect this behavior?
# [23:27] <TabAtkins> TabAtkins: So with option (2), what happens with the overflowing content in the original example?
# [23:27] <smfr> [people say no]
# [23:28] <dbaron> (Which, looking at http://lists.w3.org/Archives/Public/www-style/2013Feb/0472.html , Is what we resolved in Tucson.)
# [23:28] <TabAtkins> krit: Mailing list explanation is that the overflowing fragment effectively has a 0-height box at the start of its fragmenting.
# [23:29] <krit> http://jsfiddle.net/WLByL/
# [23:29] <TabAtkins> florian: And we have agreement that the overflowing content fragments?
# [23:29] <TabAtkins> TabAtkins: Yeah, we have browsers doing that.
# [23:30] <TabAtkins> plinss: I'm not sure about the fragmented overflow.
# [23:30] <TabAtkins> plinss: If an element creates two fragments, then when it overflows, that overflow should just extend from that second fragment.
# [23:30] <TabAtkins> plinss: It can't go to the third column, because there's no third fragment.
# [23:31] <TabAtkins> plinss: Thus, if we want overflow to go in the third column, then by definition we've created a third fragment.
# [23:31] <TabAtkins> florian: I don't find that multicol defines block-direction overflow
# [23:31] <TabAtkins> plinss: Doesn't surprise me at all.
# [23:31] <TabAtkins> plinss: So something needs to define this.
# [23:33] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [23:33] * Joins: koji (~koji@public.cloak)
# [23:33] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [23:33] <TabAtkins> astearns: Note that column balancing uses the height of the overflowing stuff too.
# [23:34] <TabAtkins> TabAtkins: That's fine; the third fragment can still be zero height. The balancing algo would just refer to the height of the overflow of each fragment, rather than to the height of each fragment.
# [23:34] <TabAtkins> florian: Why does column balancing use the height of the overflow?
# [23:34] <TabAtkins> astearns: I can't explain it. It makes no sense to me. I just observe that behavior.
# [23:35] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [23:36] * Joins: koji (~koji@public.cloak)
# [23:36] * Joins: stakagi (~stakagi@public.cloak)
# [23:36] <fantasai> The reason is that many pages are created just from abspos elements, which means the entire page overflows the zero-height root.
# [23:37] <fantasai> We still want to print all of that, so the overflow creates pages.
# [23:37] <fantasai> If it creates pages, it should also create columns.
# [23:37] <fantasai> We want columns and pages to behave the same way.
# [23:37] <fantasai> "overflowing overflow is still overflow"
# [23:38] <fantasai> ?^: Fragmentation is a way of handling overflow.
# [23:40] <TabAtkins> RESOLVED: Overflow that breaks into a new fragment container does so by forcing its container to generate an additional fragment.
# [23:40] <fantasai> s/fragment/fragmentainer/
# [23:40] <smfr> q-
# [23:40] <dbaron> peterl: zero height or width depending on overflow direction
# [23:40] <TabAtkins> fantasai, no, that's not an accurate regex.
# [23:41] * fantasai doesn't understand the resolution then
# [23:41] <astearns> I want to loop back on shape serialization at some point
# [23:41] <fantasai> Topic: Flexbox
# [23:41] <fantasai> TabAtkins: There's an issue in Flexbox where it doesn't interact well with animation in certain cases
# [23:42] <fantasai> TabAtkins: e.g. start with inflexible items, then try to animate an item to flex: 1
# [23:42] <fantasai> TabAtkins: the item snaps from inflexible to taking all the free-space immediately
# [23:42] <fantasai> TabAtkins: Same thing for shrinking; it's discontinuous between 0 and non-0
# [23:43] <fantasai> TabAtkins: To change it I made a small tweak to flex algorithm, which afaict makes zero difference to all existing cases where sum of flexes is either zero or is 1 or greater
# [23:43] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [23:43] <fantasai> TabAtkins: but is continuous between 0 and 1
# [23:43] <fantasai> TabAtkins: dholbert agrees with the problem and the rough solution to the algorithm
# [23:44] <fantasai> TabAtkins: If anyone has opinions on that, or have an implementation, please review
# [23:44] <fantasai> TabAtkins: There's another issue, but we don't understand it well yet
# [23:44] <fantasai> file:///home/fantasai/w3c/csswg/css-flexbox/issues-cr-2012.html#issue-23
# [23:45] <fantasai> er
# [23:45] <fantasai> TabAtkins: dholbert thinks Chrome's behavior is more sensible than Firefox's in this case. We haven't quite figured this out yet
# [23:45] <fantasai> TabAtkins: So won't bring it up now
# [23:47] <fantasai> TabAtkins: Also have issue of min-size of flex items
# [23:47] <fantasai> fantasai: Rossen and I did some interesting testing
# [23:47] <fantasai> fantasai: IE does what Alex proposed -- min-size of min-content, except when overflow is scrolling
# [23:47] <fantasai> TabAtkins: Ok... I will talk to our implementers
# [23:47] <fantasai> TabAtkins: I *think* we can make the change, because doesn't affect [...]
# [23:48] <fantasai> fantasai: element issue
# [23:48] <fantasai> file:///home/fantasai/w3c/csswg/css-flexbox/issues-cr-2012.html#issue-28
# [23:48] * fantasai needs to stop loading her local copy
# [23:49] <fantasai> TabAtkins: Issue comes up when creating anonymous flex items
# [23:49] * dbaron waits to start using whiteboard markers on tab's fancy computer-glasses
# [23:49] <fantasai> TabAtkins: Flex item creation splits things on element boundaries: each child element becomes a flex item, and runs of text between get wrapped in anonymous flex item
# [23:50] <fantasai> TabAtkins: e.g. <flexbox>foo bar</flexbox> creates 3 flex items
# [23:50] <fantasai> TabAtkins: However, if you replace with , then it's all one flex item
# [23:50] <fantasai> TabAtkins: In chrome it's because is treated kindof like text
# [23:51] <fantasai> dbaron: We do this for , but also for some MathML stuff
# [23:51] <fantasai> dbaron: There is a rule for Flexbox that conversions that happen for computed value of display
# [23:51] <fantasai> dbaron: Inlines that are children of a flexbox have their computed display changed to block
# [23:51] <fantasai> dbaron: So that span there is display: block
# [23:51] <fantasai> dbaron: Then code comes over that does this
# [23:51] <fantasai> dbaron: It runs over what should go into an anonymous frame
# [23:52] <fantasai> dbaron: by using a test of "does this participate in inline layout?"
# [23:52] <fantasai> dbaron: span with display : block doesn't
# [23:52] <fantasai> dbaron: but does
# [23:52] <fantasai> dbaron: I believe the same is true for some MathML elements
# [23:52] <fantasai> SteveZ: Doesn't start a new block?
# [23:53] <fantasai> TabAtkins: is weird goo
# [23:53] <fantasai> plinss: Logically behaves same as page break, line break, whatever
# [23:53] <fantasai> plinss: Like having a line-break-after property on it
# [23:54] <fantasai> plinss: is an element. Should get a box. Should be an element with a line-break-before element
# [23:54] <fantasai> SimonSapin: Can we remove the magic from and spec it?
# [23:54] <fantasai> florian: Is it an element?
# [23:54] <fantasai> plinss, Tab: yes, it's an element in the DOM
# [23:54] <fantasai> dbaron: It gets its own box, it's just an interesting sort of box. :)
# [23:54] <fantasai> TabAtkins: Firefox, for example, will honor 'display: none'. Chrome doesn't
# [23:54] <SimonSapin> HTML says br { content: '\A'; white-space: pre; }
# [23:55] * Joins: stakagi (~stakagi@public.cloak)
# [23:55] <fantasai> dauwhe: We use display: none on a lot
# [23:55] <fantasai> TabAtkins: Ok, we somehow need to figure out that works in this way...
# [23:56] <fantasai> dbaron: I'm not saying our behavior is desireable
# [23:56] <fantasai> fantasai: What else do we use inline slurping for?
# [23:56] <fantasai> dbaron: block-in-inline splitting, maybe?
# [23:56] <fantasai> TabAtkins: I guess, would you want to change so that becomes a flex item?
# [23:56] <fantasai> dbaron: I'd be fine with that if it makes more sense
# [23:56] <fantasai> ...
# [23:56] * dauwhe to force a line break in one format, set to display: none in other formats.
# [23:57] * sgalinea_ http://img2.imagesbn.com/p/9780425264607_p0_v1_s260x420.JPG
# [23:57] <fantasai> dbaron: If in between foo and bar you have a span that is floating or absolutely positioned, it's out-of-flow and doesn't count
# [23:57] <fantasai> TabAtkins: So right now flexbox and reality don't agree
# [23:57] <fantasai> TabAtkins: Also, we need to define what does
# [23:58] <fantasai> ...
# [23:58] <fantasai> fantasai: what are reasons why HTML's definition doesn't work?
# [23:59] <fantasai> plinss: If we make it CSS-defined, then changing display or other properties has to be respected
# [23:59] <fantasai> fantasai: Spec for will require lots of testing. has lots of weirdness. I don't remember what they all are, just remember it had a lot of weirdness
# Session Close: Wed Jan 29 00:00:00 2014

The end :)