/irc-logs / w3c / #css / 2011-06-04 / end

Options:

# Session Start: Sat Jun 04 00:00:00 2011
# Session Ident: #css
# [00:00] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# [00:07] * Joins: arno (arno@192.150.10.200)
# [00:09] * Quits: karl (karlcow@128.30.54.58) (Client exited)
# [00:14] * Joins: karl (karlcow@128.30.54.58)
# [00:28] * Quits: plinss (plinss@61.214.117.102) (Ping timeout)
# [01:03] * Joins: szilles (chatzilla@219.127.245.113)
# [01:17] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [01:31] * Quits: nmccully (nmccully@124.144.75.245) (Quit: Colloquy for iPad - http://colloquy.mobi)
# [01:32] * Joins: nmccully (nmccully@124.144.75.245)
# [01:36] * Quits: konaya (konaya@83.250.39.172) (Quit: Leaving)
# [01:46] * Joins: plinss (plinss@125.207.177.35)
# [01:54] * Joins: dbaron (dbaron@125.207.177.35)
# [01:55] * Joins: hober (ted@125.207.177.35)
# [02:07] * Joins: jdaggett (jdaggett@125.207.177.35)
# [02:11] * Joins: danield (danield@125.207.177.35)
# [02:11] * Joins: smfr (smfr@17.203.14.12)
# [02:13] * Joins: shans (qw3birc@128.30.52.28)
# [02:14] <hober> ScribeNick: hober
# [02:14] <hober> Topic: CSS3 Fonts
# [02:15] * Joins: vhardy (vhardy@125.207.177.35)
# [02:15] <hober> jdaggett: Two issues: same-origin restriction & super/sub-script handling
# [02:15] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction
# [02:15] <hober> jdaggett: starting with the same-origin restriction
# [02:15] * Joins: sylvaing (sylvaing@125.207.177.35)
# [02:17] <hober> jdaggett: came out of discussion in fonts/woff group
# [02:17] <hober> jdaggett: description of SOR used to be in an appendix of the css3 fonts spec
# [02:18] <hober> jdaggett: fonts group's charter calls for making SOR a requirement
# [02:18] <hober> jdaggett: now we have a split between woff spec & css3 fonts spec
# [02:18] <hober> jdaggett: objection from apple that it doesn't make sense for SOR to be tied to the format
# [02:18] <hober> jdaggett: we came to conclusion that it makes sense for this to live in the css3 fonts spec
# [02:19] <hober> jdaggett: the text has been moved into the body from the appendix
# [02:19] * Joins: TabAtkins (tabatkins@125.207.177.35)
# [02:19] <hober> jdaggett: open issues: what should the default behavior be
# [02:19] <hober> ff & ie? restrict by default, allow CORS for relaxing
# [02:19] <hober> jdaggett: annevk thinks this is weird
# [02:20] <hober> jdaggett: inconsistent with other parts of web platform
# [02:20] <hober> jdaggett: problems with data leakage
# [02:20] <hober> jdaggett: e.g. canvas' dirty flag
# [02:20] <hober> jdaggett: [describes example of embedding security problem on whiteboard]
# [02:22] * Joins: murakami (murakami@118.154.209.3)
# [02:22] <hober> jdaggett: these issues are beyond fonts & images
# [02:23] <hober> jdaggett: there are even issues if script can see the response code from certain cross-origin images
# [02:23] <hober> jdaggett: we have normative prose (section 4.8.1)
# [02:23] <hober> jdaggett: annevk doesn't like the default restriction
# [02:24] <hober> jdaggett: he'd prefer no restriction by default & users would need to explicitly set an exception
# [02:24] <hober> sylvaing: annevk's first objection is that CORS isn't the right tech for this
# [02:24] * Joins: florian (florianr@125.207.177.35)
# [02:24] <hober> jdaggett: [as annevk] the web has evolved because people can link willy-nilly
# [02:24] <hober> florian: why solve this for fonts only?
# [02:25] <hober> Bert: fonts are different
# [02:25] <jdaggett> siteA --> siteB gimme xxx
# [02:25] <jdaggett> siteA <-- here you go (no CORS header)
# [02:25] <jdaggett> UA sees no CORS header, doesn't download resource
# [02:25] <hober> jdaggett: how does the existing text in 4.8.1 work?
# [02:25] * Parts: florian (florianr@125.207.177.35)
# [02:25] <jdaggett> siteA --> siteB gimme xxx
# [02:25] <jdaggett> siteA <-- here you go (CORS header: siteB use ok -or- all sites ok)
# [02:25] <jdaggett> UA sees CORS header, check for a match, downloads resource
# [02:26] * Joins: florian (florianr@125.207.177.35)
# [02:26] <hober> jdaggett: instead, annevk's proposal:
# [02:27] <jdaggett> siteA --> siteB gimme xxx
# [02:27] <florian> link to where annevk discusses this: http://annevankesteren.nl/2011/02/from-origin
# [02:27] <jdaggett> siteA <-- siteB here you go (no From-Origin header)
# [02:27] <jdaggett> UA sees no From-Origin restriction, <uses default behavior>
# [02:27] <hober> jdaggett: explicit restriction instead of explicit relaxation
# [02:27] <jdaggett> siteA --> siteB gimme xxx
# [02:27] <jdaggett> siteA <-- siteB here you go (From-Origin: no cross-linking please)
# [02:27] <jdaggett> UA sees From-Origin restriction, doesn't download resource
# [02:28] * Joins: szilles (chatzilla@125.207.177.35)
# [02:28] <hober> jdaggett: this could be used for images, scripts, wider set of resource types
# [02:28] <hober> jdaggett: both ff & ie have implemented the cors approach
# [02:28] <hober> jdaggett: others haven't impled eithet
# [02:28] <hober> s/eithet/either/
# [02:28] <hober> jdaggett: consensus that some kind of mechanism is a good thing
# [02:29] <hober> jdaggett: don't want to allow cross-origin font linking by default
# [02:29] <hober> jdaggett: the cors approach hits the 80/20 point for fonts
# [02:29] <hober> jdaggett: vs. the from-origin proposal, which requires you to raise a flag to get the typical behavior
# [02:29] <hober> florian: yes for fonts, but for all resources, from-origin hits the default correctly
# [02:30] <hober> jdaggett: should the default for fonts be different?
# [02:30] <hober> jdaggett: our (ff) security guys think all new resource types should default to SOR
# [02:31] <hober> TabAtkins: [describes attack that extracts font data out of a tainted <canvas>]
# [02:31] <hober> Bert: the problem is the javascript, not the resources
# [02:31] <hober> TabAtkins: then you wouldn't be able to do anything with fonts in javascript
# [02:31] <hober> TabAtkins: e.g. canvas
# [02:31] <hober> dbaron: or figure out the width of text
# [02:31] <hober> Bert: there should be 2 kinds of things on the web: programs and documents
# [02:31] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [02:32] <hober> Bert: text/html is document, maybe application/html could have these restrictions
# [02:32] <hober> jdaggett: existing content
# [02:32] <hober> Bert: the power of the web is transclusion
# [02:33] <hober> jdaggett: we can't get there from here
# [02:34] <hober> TabAtkins: [describes <iframe> v. <img> differences]
# [02:34] <hober> Bert: fonts are different
# [02:34] <hober> Bert: you can't right click on a font
# [02:34] <hober> Bert: this is why we have woff
# [02:34] <hober> Bert: need to say "this font is for this document"
# [02:34] <hober> jdaggett sylvaing: that's not what woff does
# [02:35] <hober> [eot v. woff, root string disagreement]
# [02:35] <hober> plinss: </tangent>
# [02:35] <hober> jdaggett: still contention about mechanism & default
# [02:35] <hober> jdaggett: this is not a css-only discussion
# [02:35] <hober> jdaggett: is a web-wide discussion
# [02:36] <hober> jdaggett doesn't want to have things in css3 fonts that will block it moving forward
# [02:36] <hober> jdaggett: has labelled what impls are doing & put wording that captures where this will change if consensus changes
# [02:36] <hober> jdaggett: what the consensus will be isn't quite clear
# [02:36] <hober> jdaggett: marked this as risk
# [02:37] <hober> jdaggett: does that suffice to move this forward? i don't know
# [02:37] <hober> sylvaing: from-origin is broader, will be more controversial
# [02:37] <hober> jdaggett: so it'll take longer
# [02:37] <hober> florian: opera prefers annevk's position, but isn't locked into it
# [02:37] <hober> jdaggett: annevk prefers a mechanism to work across resource types and the default should be no restriction
# [02:38] <hober> jdaggett: howcome is ambivalent here
# [02:38] <hober> sylvaing: any resources loaded by src: in @font-face, not about fonts v. other resources
# [02:39] <hober> fantasai: so fonts loaded in <img src> would behave differently
# [02:39] <hober> sylvaing: yes
# [02:39] <hober> jdaggett: we can't go back and change the default
# [02:40] <hober> jdaggett: wanted to make people aware of the wording here that this is at risk etc.
# [02:40] <hober> plinss: bottom line is we're not making the restriction decision here in csswg
# [02:40] <hober> plinss: you want to decouple so we can advance
# [02:40] <hober> jdaggett: yes
# [02:41] <hober> jdaggett: delicate negotiations with the web fonts group
# [02:42] <hober> Bert: not for csswg, because fonts can be embedded via xsl, etc.
# [02:42] <hober> hober: we define @font-face, so we define restriction for that embedding point
# [02:42] <hober> everyone: [we didn't develop woff for origin restriction reasons]
# [02:43] <hober> Bert: sounds like annevk's proposal is better
# [02:43] <hober> Bert: what is the reason for woff if all fonts are restricted?
# [02:44] <hober> jdaggett: existing font formats weren't for the web, etc., needed to be a web font format
# [02:44] <hober> szilles: woff had 2 requirements: transmission prevent dropping into client os, 2. can post on web without anyone willy-nilly being able to use it
# [02:45] <hober> jdaggett: @font-face is here, so restriction has to be here
# [02:45] <hober> jdaggett: web fonts group has the format
# [02:45] <hober> web fonts charter isn't woff-specific
# [02:46] <hober> plinss: bert's point is that we & svg etc should use same mechanism
# [02:47] <hober> plinss: we shouldn't be deciding the restriction
# [02:48] <hober> plinss: is there an actionable item here?
# [02:48] <hober> jdaggett: proposals have to be detailed and go to web fonts group & css group
# [02:48] <hober> florian: opera is satisfied with this wording
# [02:48] <hober> florian: we'd welcome clearly-defined alternatives
# [02:49] <hober> florian: this is good enough, allows for alternative proposals
# [02:49] <hober> fantasai: we can't go to cr with this
# [02:49] <hober> jdaggett: we can mark it at risk
# [02:50] <hober> Bert: what about non-http urls, we need to still work
# [02:50] <hober> plinss: yes, this is very http-specific
# [02:50] * Joins: szilles (chatzilla@125.207.177.35)
# [02:51] <hober> szilles: it's not woff pushing it back on us, they were conviniced this is acceptable solution to one of their problems
# [02:51] <hober> szilles: if we push back, woff group would have to start over
# [02:52] <hober> jdaggett: [doesn't want to create other thing that we can't reference normatively]
# [02:52] <hober> jdaggett: put it here, mark it at risk, and go on
# [02:53] <fantasai> s/fantasai: so fonts loaded in <img src> would behave differently/fantasai: so images loaded via @font-face would be restricted by default/
# [02:53] <hober> jdaggett: by the time we have impls, test suite, etc. this will be worked out one way or another
# [02:53] * hober fantasai: ahh, sorry
# [02:54] <hober> jdaggett: font EULAs say you need to do referrer checking when ua doesn't support [sor mechanism]
# [02:54] <hober> fantasai: if user turns off Referer header, can't get fonts
# [02:55] <hober> jdaggett: post detailed proposals, not just "i want this"
# [02:55] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop
# [02:55] <hober> jdaggett: Next issue: dealing with superscripts and subscripts
# [02:55] <hober> 'vertical-position' property
# [02:56] <hober> jdaggett: lets you turn on super/sub-script variants in fonts
# [02:56] <hober> jdaggett: within the font, variants of the number 2, say, that fit in normal em box
# [02:56] <hober> jdaggett: by using this, line box doesn't change, etc.
# [02:56] <hober> jdaggett: currently, baseline shifts and font size changes
# [02:56] <hober> jdaggett: so you see changes in the line box
# [02:57] <hober> jdaggett: doesn't look good
# [02:57] <hober> jdaggett: when you shrink down the normal-size glyph, strokes shrink too, so super/sub scripts don't have same typographic color as surrounding text
# [02:58] <hober> jdaggett: 'vertical-position' addresses lots of cases [footnotes, etc.]
# [02:58] <hober> jdaggett: doesn't address putting images in <sup> or nesting other sorts of things in <sup>/<sub>
# [02:59] <hober> jdaggett: superscripts&subscripts are semantic, so can't be treated like other font variants
# [02:59] <hober> szilles: we've already discussed this; what's the new information?
# [03:00] <hober> jdaggett: if I use 'vertical-position: superscript' for s^2 and look at content in an older browser, I see s2
# [03:00] <hober> jdaggett: authors need a way to ensure the right thing happens
# [03:00] <hober> jdaggett: the current spec makes 'vertical-position' a shorthand
# [03:01] <hober> jdaggett: [reads from section 6.4 on how fallback works]]
# [03:01] <hober> jdaggett: allows you to make styles for <sub> and <sup> that work well in older UAs
# [03:01] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html
# [03:02] <hober> fantasai: describes her proposal
# [03:02] <hober> fantasai: new property 'magic'
# [03:02] <hober> [fantasai & dbaron's replacement for vertical-position]
# [03:02] <hober> magic: none | super | sub
# [03:02] <hober> fantasai: [describes proposal in email jdaggett linked above]
# [03:04] <hober> fantasai: if magic matches vertical-align, then computed font size is set by multiplying size ratio to parent's font size & we ignore specified font size
# [03:04] <hober> szilles: you're setting the font size to the size that's in the font
# [03:04] <hober> fantasai: yes
# [03:04] <hober> dbaron: let's explain the goals of this approach
# [03:05] <hober> fantasai: we're trying to handle basic super/sub scripts with special glyphs if available, & synthesizing if they're not available
# [03:06] <hober> fantasai: second goal: handle atomic inlines & nested super/subscripts, what happens if you have a span with changed font size inside these thigns
# [03:06] <hober> fantasai: we're not handling mixing special glyphs with anything else
# [03:06] <hober> fantasai: if font metrics are off, this will look ugly
# [03:06] <hober> dbaron: that's true of all proposals that use font's special glyphs
# [03:06] <hober> jdaggett: adobe ships same same metrics in all of their fonts
# [03:07] <hober> jdaggett: 99% use case, you'll (probably) be ok
# [03:07] <hober> fantasai: also don't handle using lengths or percentages for vertical align & mixing with this feature
# [03:08] <hober> fantasai: won't get the right glyphs if you try to position the super/sub-script differently than what the font does
# [03:08] <hober> Bert: [expresses scepticism]
# [03:08] <hober> jdaggett: this could be a case for @supports
# [03:09] <hober> jdaggett: if someone's explicitly enabling this, we document that it works this way, so they're aware of the tradeoffs
# [03:10] <hober> dbaron: fantasai & my proposal makes this more complex, but allows ua stylesheet to have this on by default
# [03:10] <hober> fantasai: might not look good when some glyphs have this and others don't
# [03:11] <hober> plinss: anything but the special glyphs will draw in synthesized state
# [03:11] <hober> fantasai: yes
# [03:11] <hober> szilles: is this opentype feature turned on by default?
# [03:11] <hober> jdaggett: we're not talking about unicode code points
# [03:12] <hober> plinss: if you're using those code points, you're not using <sup> or <sub>
# [03:13] <hober> Bert: you have super, sub, and none, but why no 'yes'?
# [03:13] <hober> Bert: turn it on from root element
# [03:13] <hober> jdaggett: vertical-align controls the baseline, if other properties affect this, this makes me uncomfortable
# [03:14] <hober> jdaggett: behavior of this feature dependent on this other value
# [03:14] <hober> szilles: we've got other such cases
# [03:14] <hober> szilles: property-refining properties are common
# [03:15] <hober> plinss: it's a per-glyph undo of what vertical-align does
# [03:15] <hober> fantasai: won't change the line box if you have the right glyphs
# [03:15] <hober> jdaggett: font metrics aren't correct
# [03:16] * Quits: smfr (smfr@17.203.14.12) (Quit: smfr)
# [03:16] <hober> [plinss fantasai: talk re: vertical-align causes baseline change in even empty line boxes]
# [03:17] <hober> plinss: as soon as you start nesting, you want to affect the line height
# [03:17] <hober> jdaggett: divergence between opentype spec and what fonts actually do
# [03:17] <hober> jdaggett: i want to set this up for people who know how to use it, without breaking existing content
# [03:18] <hober> Bert: what happens if font has some of the special glyphs but not others
# [03:18] <hober> jdaggett: you'll synthesize
# [03:18] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [03:18] <hober> jdaggett: color won't match, stroke width will be different in synthesized case
# [03:19] <hober> szilles: if you don't have all the glyphs, synthesize everything
# [03:19] <hober> plinss: if you don't have all the glyphs, pretend you have none
# [03:20] <hober> fantasai: allow the UA to be smarter, but don't require complex analysis
# [03:21] <hober> jdaggett: wants to work on impl & experiment
# [03:21] <hober> jdaggett: expects to see things we're not anticipating
# [03:21] <hober> fantasai: that's a reasonable thing to do
# [03:21] <hober> jdaggett: same fallback issue as with vertical text
# [03:22] <hober> szilles: put a note in that points to the font feature with an appropriate warning
# [03:22] <hober> fantasai: we can do that in the line box spec
# [03:23] <hober> szilles: was strongly in favor of fantasai/dbaron's proposal, but sees point of @supports approach
# [03:23] <hober> fantasai: author of stylesheet might not know what's in the content
# [03:24] <hober> szilles: italic or bold isn't a problem
# [03:24] <hober> Bert: magic property seems short; can it be keyword(s) of font-variant property?
# [03:24] <hober> fantasai: might make sense
# [03:25] <hober> jdaggett: tricky because font-variant is shorthand (reset problem)
# [03:25] <hober> szilles: can we put it in @font-face?
# [03:26] <hober> florian: "this font supports being magic; use it if you can"
# [03:26] <hober> fantasai: not tied to the choice of the font
# [03:27] <hober> fantasai: can we link to this email from the spec?
# [03:27] <hober> jdaggett: would prefer note that says there are alternate proposals
# [03:27] <hober> jdaggett: i have to try to impl this before we can do more
# [03:28] <hober> fantasai: what other open issues are in this spec?
# [03:28] <hober> fantasai: maybe we should defer this issue so spec can reach lc
# [03:28] * Joins: szilles (chatzilla@125.207.177.35)
# [03:28] <hober> jdaggett: there are a number of issues
# [03:28] <hober> jdaggett: is tightening the wording based on impl feedback
# [03:29] <hober> jdaggett: wanted to make people aware of the issue & hear other ideas
# [03:29] <hober> fantasai: i want to have this findable from the spec
# [03:30] <hober> Topic: Flexbox update
# [03:30] <hober> alexmog: in ie10 we have fairly complete impl of spec
# [03:31] <hober> alexmog: for ie10 we won't have the new syntax
# [03:31] <hober> alexmog: don't want two prefixed syntaxes
# [03:31] <hober> alexmog: the timing isn't right for ie10
# [03:32] <hober> alexmog: for new spec, we want to see what other browsers are doing
# [03:32] <hober> alexmog: we need to have multiline back in spec
# [03:32] <hober> TabAtkins: will be bringing multiline back
# [03:32] <hober> TabAtkins: webkit is working on impl of the new spec
# [03:32] <hober> TabAtkins: will see that in the near future
# [03:33] <hober> alexmog: if the spec stayed in the old syntax, we could drop prefix; but we don't need to reopen that
# [03:33] <hober> dbaron: we [ff] also have someone working on the new spec
# [03:33] <hober> sylvaing: any issues, dbaron?
# [03:33] <hober> dbaron: haven't heard any, don't know how far along things are
# [03:34] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [03:34] <hober> alexmog: we can map most of new syntax to old impl; biggest difference is using the flex function notation
# [03:35] <hober> alexmog: would require parser change
# [03:35] <hober> alexmog: different alignment too
# [03:36] <hober> alexmog hopes feedback from other impls will help next version of spec stabilize
# [03:37] <hober> sylvaing: flex notation, alignment modes, multiline--want to see feedback from other implementors
# [03:37] <hober> plinss: anything else?
# [03:38] <hober> alexmog: whats' the eta?
# [03:39] <hober> TabAtkins: wants to publish a new wd sometime in the next 80 years
# [03:39] <hober> s/in the next 80 years/by the end of june/
# [03:39] <hober> TabAtkins: hoepfully ready for lc soon after that
# [03:40] <hober> <br duration="15min" />
# [03:40] * Joins: arronei (arronei@166.205.143.215)
# [03:49] * Quits: plinss (plinss@125.207.177.35) (Quit: plinss)
# [03:51] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [03:52] * Joins: plinss (plinss@125.207.177.35)
# [03:55] * Quits: nmccully (nmccully@124.144.75.245) (Client exited)
# [03:58] * Joins: boblet (Adium@122.27.197.150)
# [04:02] <TabAtkins> ScribeNick: TabAtkins
# [04:03] * Joins: szilles (chatzilla@125.207.177.35)
# [04:04] <TabAtkins> Topic: CSS Regions
# [04:05] <TabAtkins> vhardy: content-order is a float right now, which people say are odd - z-index is an integer, frex.
# [04:05] <TabAtkins> vhardy: We did it that way so that you could, say, insert between two consecutive items.
# [04:05] <TabAtkins> vhardy: But the precedent means we should just switch to <integer>s.
# [04:06] <TabAtkins> Bert: Is there any way to avoid using numbers at all?
# [04:07] * arronei wishes it was easier to drive and read the logs at the same time.
# [04:07] <TabAtkins> szilles: The regions aren't inherently ordered - they just pull whatever's in the stream.
# [04:07] <TabAtkins> Bert: Why not push to a stream?
# [04:08] <TabAtkins> vhardy: We thought of that model, but given that many regions aren't named, it becomes more difficult. It seemed simpler to name the flow and have regions pull.
# [04:09] <TabAtkins> vhardy: We sketched out some ideas for an @region-chain rule where you'd list the sequence of regions.
# [04:09] * Joins: alexmog (alexmog@125.207.177.35)
# [04:09] <TabAtkins> Bert: That's similar to what I did with Template - a property that listed a chain of cells that content flowed across in order.
# [04:09] * Joins: nmccully (nmccully@124.144.75.245)
# [04:09] <TabAtkins> szilles: That fails somewhat in paged media, where you can have multiple copies of cells with the same name.
# [04:11] <TabAtkins> vhardy: I also had an idea to have a region-name property that would name a region, but it didn't seem quite harmonious.
# [04:12] <TabAtkins> vhardy: Can we agree on moving it to <integer> for now?
# [04:12] <TabAtkins> [agreement]
# [04:13] <TabAtkins> vhardy: Another syntactic issue is that the 'flow' property uses <string> for value, and is referred to by a string.
# [04:14] <TabAtkins> vhardy: So the question is should that just be an ident?
# [04:15] <TabAtkins> szilles: Didn't we have a similar discussion in february?
# [04:15] <arronei> Ident +1
# [04:15] <TabAtkins> TabAtkins: That was for fonts, which are a problem because their names come form outside CSS. It's okay to do idents in author-defined syntax.
# [04:16] <TabAtkins> plinss: But you do sometimes shoot yourself in the foot when you use idents, because it makes it hard to add new language-defined idents in the future, as you might collide.
# [04:17] <TabAtkins> plinss: If it's guarded as a functional value, it's a bit better.
# [04:18] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [04:19] <TabAtkins> szilles: I'd be afraid of it being a quoted string in 'flow' and unquoted in a function in 'content'.
# [04:19] <TabAtkins> hober: Yeah, not doing that. Consistency.
# [04:20] <arronei> Yeah but I don't want a flow to have a string like this. "{}{]}##<"
# [04:20] <TabAtkins> TabAtkins: I think that we can work our way around the problem later if we just restrict the 'flow' to a single author-defined ident for now.
# [04:20] <TabAtkins> plinss: We'll need to do something like a dummy keyword so we can have a distinguished syntax for CSS-defined values, which is dumb.
# [04:21] <TabAtkins> TabAtkins: Another option is to make 'flow' take a to(<ident>) function for now, which pairs with the from(<ident>) function in 'content'.
# [04:21] <TabAtkins> szilles: That sounds good.
# [04:22] <TabAtkins> Bert: I'm not sure we need from(), and so to() seems unnecessary too.
# [04:22] <TabAtkins> szilles: You definitely need from(), to disintiguish it from other values in 'content'.
# [04:23] <arronei> Functions removes the issues if you want to add keywords later.
# [04:23] <TabAtkins> Bert: I'd need to familiarize myself with the syntax more, but 'content' may not be the right place.
# [04:24] <TabAtkins> alexmog: Given that 'content' sets the contents to something other than the natural contents, it seems appropriate to use it here.
# [04:24] <TabAtkins> plinss: Potentially we could use another property, and still get the ability to add things to the flow's contents by using the 'contents' keyword (defined in CSS3 Content).
# [04:25] <TabAtkins> szilles: But that's another issue.
# [04:25] * Joins: szilles (chatzilla@125.207.177.35)
# [04:26] <TabAtkins> [chatter about 'content' and potential 'flow-from']
# [04:27] <TabAtkins> szilles: Wouldn't that mean I need to set two properties?
# [04:28] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [04:28] <TabAtkins> plinss: No, setting 'flow-from' would just change the meaning of "content:auto" to pull from the region. And then potentially, when "content:contents" is defined, that can combine.
# [04:29] <TabAtkins> alexmog: We're afraid of author-defined idents colliding with future CSS-defined keywords, right?
# [04:30] <TabAtkins> alexmog: I think from the OM model pov I'd prefer two properties that take strings than something that takes one-off functions.
# [04:31] <arronei> I still prefer content: from(...) for it's simplicity.
# [04:31] <TabAtkins> TabAtkins: Arronei dislikes strings because it becomes easier to write unreadable region names.
# [04:31] <TabAtkins> szilles: You can write unreadable idents too.
# [04:32] <TabAtkins> Bert: Can we duplicate flow content across multiple regions?
# [04:32] <arronei> But it's not as easy to do
# [04:32] <TabAtkins> vhardy: That's an issue that was brought up on the mailing list.
# [04:33] * fantasai likes flow: to(foo); content: from(foo);
# [04:34] <TabAtkins> Bert: In previous approaches to this idea we named the flow specifically to allow duplication. Newer approaches like Grid didn't need that.
# [04:34] <TabAtkins> [some difficult-to-understand discussion about being able to omit the name of the flow]
# [04:35] <dbaron> Bert: template is naming regions, but not naming flows
# [04:35] <TabAtkins> [moving it to the list so we can throw down syntax, because everyone's confused]
# [04:35] <TabAtkins> vhardy: Currently there's nothing about selecting the content in a region.
# [04:36] <TabAtkins> vhardy: User selections, that is.
# [04:36] <TabAtkins> dbaron: A single selection usually operates in terms of the DOM.
# [04:37] <TabAtkins> dbaron: Which could be confusing if you select across a region, and end up getting some content elsewhere in the page.
# [04:37] <TabAtkins> dbaron: You could do a more visual-based selection, but no impl does that yet.
# [04:38] <TabAtkins> plinss: I built a box-selection extension for Firefox that auto-computed the ranges.
# [04:39] <TabAtkins> fantasai: Selection is out-of-scope for this module. Right now it's UA-dependent and up to them to come up with good ideas.
# [04:39] <TabAtkins> szilles: What do we do with bidi right now?
# [04:39] <TabAtkins> fantasai: We specify absolutely nothing for that right now.
# [04:39] <TabAtkins> vhardy: Okay, so I'll remove the issue about selection from the spec.
# [04:40] <TabAtkins> vhardy: Next is about the event model.
# [04:40] <TabAtkins> vhardy: Right now there's a section that says event propogation is not modified - it runs on the plain DOM.
# [04:40] <TabAtkins> vhardy: But I've had some requests that you can listen for, say, clicks on a region.
# [04:41] <TabAtkins> TabAtkins: I don't want to think about event propagation being sensitive to exactly when we do style recalc.
# [04:42] <TabAtkins> vhardy: Okay, so we'll keep it DOM-based. Should I remove it entirely, or make it an informative note?
# [04:43] <TabAtkins> TabAtkins: If people have asked you about it, so you should probably keep a note around.
# [04:43] <TabAtkins> Bert: If you're writing an editor, you may want to, say, select a region to put a background on it. How would you do that?
# [04:44] <TabAtkins> TabAtkins: From an interactioni point of view, this is roughly similar to making a bunch of divs and then absposing content to make it look like they're inside the divs. If you click the content, the click fires at it and walks up the dom that way. If you click the area around the content, you'll get the div.
# [04:44] <TabAtkins> szilles: Is there a way to ask an element what region it's in?
# [04:44] <TabAtkins> vhardy: That'll be in the CSSOM section.
# [04:44] <TabAtkins> szilles: That seems to satisfy the rquirement.
# [04:45] <TabAtkins> vhardy: Now, the CSSOM View section.
# [04:45] <TabAtkins> vhardy: It has two parts. The first is the "named flow interface".
# [04:46] <TabAtkins> vhardy: [explains the "named flow interface" section]
# [04:46] <TabAtkins> vhardy: It's meant to allow you to see if the flow fits in the regions that exist.
# [04:46] <TabAtkins> alexmog: Why do you have a "named flow" interface and not just a concept of regions?
# [04:49] <TabAtkins> vhardy: If you only have it on regions, you can only access regions that are actually elements.
# [04:49] <TabAtkins> alexmog: If you want that, then just add elements.
# [04:49] <TabAtkins> szilles: That violates that "css zen garden" school of philosophy.
# [04:50] <TabAtkins> TabAtkins: We can already interact with pseudos in at least some ways via the CSSOM.
# [04:51] <TabAtkins> alexmog: I don't think it's necessary to extend the "Element" concept to pseudos.
# [04:52] <TabAtkins> [...minute overflow]
# [04:52] <TabAtkins> alexmog: It's good to still have an event that tells when a region changes.
# [04:53] <TabAtkins> TabAtkins: Like when a region overflows? Or more like a mutation event for contents in the region?
# [04:54] <TabAtkins> alexmog: When the contents of the region changes.
# [04:54] * Joins: arron (Arron@24.17.123.244)
# [04:54] <TabAtkins> dbaron: What sort of changes do you want to know, exactly?
# [04:54] <TabAtkins> alexmog: Whenever the contents change.
# [04:54] * Quits: arronei (arronei@166.205.143.215) (Quit: Colloquy for iPhone)
# [04:55] <dbaron> dbaron: We already have onresize
# [04:55] <dbaron> TabAtkins: I think what's useful is notification when a region goes into overflow state and notification when a region becomes empty.
# [04:56] <TabAtkins> vhardy: So basically you're saying that you can get X information from a region, and you'd like to be notified about changes in that.
# [04:56] <TabAtkins> alexmog: Yeah.
# [04:57] <TabAtkins> TabAtkins: I'd want to separate the ideas of a "regionEmpty" and "regionOverflow" events from a "regionMutation" event. The former are easy to see the utility of, the latter not so much imo.
# [04:57] <TabAtkins> vhardy: So I can put them all down in the spec for now, and we can see what exactly we want later.
# [04:58] <TabAtkins> vhardy: So next topic, how do we access regions? Through an element, or through the flow?
# [04:59] <TabAtkins> vhardy: So we can stick to the element interface in 4.2 right now, or we go from the Document which returns a NamedFlow abstraction, which gives you access to the list of regions.
# [05:00] <TabAtkins> szilles: I tend to like the last one, because it ties into the Flow concept, which is primary.
# [05:01] <TabAtkins> hober: I don't like th eElement version, because it separates regions into first-class and second-class regions - DOM are first-class, pseudos are second-class.
# [05:02] <TabAtkins> TabAtkins: There really *are* first and second-class, though. Pseudos can't have listeners on them, for example. If we fire "regionEmpty" events, frex, you can only listen for that on DOM elements acting as regions.
# [05:02] * Quits: nmccully (nmccully@124.144.75.245) (Quit: Colloquy for iPad - http://colloquy.mobi)
# [05:02] <TabAtkins> vhardy: I could fire events on the NamedFlow interface instead.
# [05:05] * Joins: nmccully (nmccully@124.144.75.245)
# [05:06] * Quits: nmccully (nmccully@124.144.75.245) (Client exited)
# [05:06] <TabAtkins> TabAtkins: My primary problem is that making pseudos nearly-real gets closer to exposing the transformed formatting structure that CSS exposes into a real tree. So far we've been able to hide that for the most part.
# [05:06] * Joins: nmccully (macnmm@124.144.75.245)
# [05:06] <TabAtkins> szilles: We can just focus on Flows as a concept, rather than pseudos.
# [05:07] * Joins: szilles (chatzilla@125.207.177.35)
# [05:07] <TabAtkins> vhardy: (1) Current spec is minimal functionality for all regions (2) minimal funcitonality for pseudos and full for DOM (3) full functionality for DOM elements, none for pseudos
# [05:07] <TabAtkins> (4) full functionality for both pseudos and DOM
# [05:08] <TabAtkins> vhardy: And this is kind of a requirements discussion.
# [05:08] <TabAtkins> vhardy: I'd prefer 4, even though it's painful.
# [05:09] <TabAtkins> alexmog: I think we should start with DOM and see how far we can go.
# [05:11] <TabAtkins> TabAtkins: I think we'd be okay with functionality for DOM elements, plus a simple way to ask a flow if it's overflowing.
# [05:11] <TabAtkins> TabAtkins: Basically, what's in the spec.
# [05:11] <TabAtkins> alexmog: If you duplicate a flow into multiple views, you can't get a single answer to "is the flow overflowing?".
# [05:12] <TabAtkins> vhardy: Right now multiviews don't exist - they're talked about in an issue.
# [05:12] <TabAtkins> vhardy: So I'll keep it as it is right now, and put in an issue regarding accessing the flow directly.
# [05:12] <TabAtkins> vhardy: Next is about content duplication (multiviews).
# [05:13] <TabAtkins> vhardy: Right now, if you put an element into a flow, it gets displayed once - a region consumes it and then it's not available anymore.
# [05:13] <TabAtkins> vhardy: Someone asked if there's a way to duplicate flow contents.
# [05:14] <TabAtkins> vhardy: It would cause a lot of issues, though, so right now I suggest not doing it.
# [05:14] <TabAtkins> fantasai: Wouldn't this let you do pullquotes?
# [05:15] <TabAtkins> vhardy: From talking to authors, it looks like pullquotes are very rarely the literal content from the document. There are rewordings, elidings, etc. They're really separate content.
# [05:15] <TabAtkins> szilles: Another use-case is ToC.
# [05:15] <TabAtkins> vhardy: For now, Regions is complex enough that I think we should skip it for now.
# [05:15] <TabAtkins> plinss: I think it's appropriate to push it to Regions 2.
# [05:18] <TabAtkins> <br type=lunch duration=1h>
# [05:38] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [05:54] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
# [05:57] * Joins: arno (arno@208.87.61.227)
# [06:08] * Joins: shans (qw3birc@128.30.52.28)
# [06:18] <fantasai> jdaggett: http://dev.w3.org/csswg/css3-writing-modes/#writing-mode
# [06:18] * Quits: arno (arno@208.87.61.227) (Quit: Leaving.)
# [06:19] <fantasai> ScribeNick: fantasai
# [06:19] <fantasai> Discussion of agenda for this afternoon
# [06:20] <fantasai> Florian: Would like device adaptation, should not take long
# [06:20] <fantasai> Tab: I want variables
# [06:20] <jdaggett> hmmm, that's in an example
# [06:20] <fantasai> that was what we agreed
# [06:20] <fantasai> the normative text is above the two examples
# [06:21] <jdaggett> that wording isn't strong enough
# [06:21] <fantasai> what is not strong enough about it?
# [06:21] <jdaggett> form elements are included in this list
# [06:21] <jdaggett> *normative* wording needs to say this includes form elements
# [06:21] <jdaggett> otherwise you give folks too much weasel room
# [06:21] <fantasai> form elements are either replaced, or they're not
# [06:21] <fantasai> if they're replaced, then that word applies
# [06:22] <fantasai> if they're not, then 'writing-mode' applies because it's CSS layout
# [06:22] <fantasai> where's the gap here?
# [06:22] <jdaggett> well, we already have problems because css sorta affects them, sorta doesn't
# [06:22] <jdaggett> just do the right thing... ;)
# [06:22] <fantasai> dbaron: would like to discuss @supports briefly
# [06:22] <jdaggett> you understand and mean the sentence to mean xyz
# [06:23] <fantasai> Topic: Meeting Scheduling
# [06:23] <fantasai> plinss: Proposal is to possibly add another F2F
# [06:23] <fantasai> dbaron: Feels like we have a lot to do, and have a pretty crammed schedule here
# [06:23] <fantasai> dbaron: Our summer meeting is at the early end, and the next meeting is a shortened meeting at TPAC
# [06:23] <fantasai> dbaron: We have only TPAC for the next 9 months
# [06:24] <fantasai> dbaron: So either we need another meeting, or significantly longer at TPAC
# [06:24] <fantasai> Vincent: Personally propose second meeting, gives us time to work on drafts in between f2f days
# [06:25] <fantasai> some concern about people who have to travel
# [06:25] <fantasai> jdaggett: Can't travel in September
# [06:25] <fantasai> suggestion to do combined fx and css meeting in August
# [06:25] <fantasai> plinss: Missing ppl who likely to have date conflicts
# [06:25] <fantasai> Bert: I have some budget problem, unless I host it myself
# [06:26] <fantasai> plinss: A lot of ppl would have trouble paying for another trip this year
# [06:26] <fantasai> plinss: unless we do Europe or Bay Area
# [06:26] <fantasai> Alex: Could do 3 TPAC days plust another meeting
# [06:26] <fantasai> dbaron: For the 2 TPAC days, we should assume one full day of CSSF2F amount of work
# [06:27] <fantasai> fantasai: Who's got budget constraints
# [06:28] <dbaron> fantasai: Likely options are West Coast or Europe to reduce budget constraints.
# [06:28] <dbaron> fantasai: TPAC is in bay area
# [06:28] <fantasai> Bert, Vincent maybe, Daniel probably, anyone else?
# [06:28] <fantasai> Alex: For some ppl end of year is July 1st
# [06:29] <fantasai> dbaron: Would be nice to know where TPAC and AC will be
# [06:29] <fantasai> plinss: I'm hearing another meeting would be good, and adding a day to TPAC would be good
# [06:30] <fantasai> RESOLVED: Add a day to TPAC
# [06:32] <fantasai> RESOLVED: Try to schedule a meeting in August in probably in Seattle or France
# [06:32] <fantasai> Topic: Device Adaptation
# [06:34] <fantasai> DD: On desktop browsers viewport is same size as the window
# [06:34] <fantasai> DD: On mobile devices, that's not true.
# [06:34] <fantasai> DD: You can force page to lay out at device width or arbitrary width
# [06:35] <fantasai> DD: So the veiwport meta tag is obviously a meta tag
# [06:35] <fantasai> DD: One problem with this currently is it's not completely specified
# [06:35] <fantasai> DD: There isn't a full spec available to the public
# [06:35] * Joins: kojiishi (kojiishi@125.207.177.35)
# [06:35] <fantasai> DD: undefined whether commas or semicolons used, e.g.
# [06:36] <fantasai> DD: If I do this, it's viewable without zooming
# [06:36] <fantasai> DD: The details .. Apple currently
# [06:36] <fantasai> DD: THe width can be in pixels or same as device width
# [06:36] <fantasai> DD: Can also set scale, to not allow user to scale, so it behaves more like native app
# [06:36] <fantasai> DD: but has accessibility problem
# [06:37] <fantasai> DD: This W3C CSS spec CSS Device Adaptation effectively lays out what exists as a CSS specification
# [06:37] <fantasai> DD: Benefit is it's an open spec, also it's not content it's presentation
# [06:37] <fantasai> DD: The syntax of it is ....
# [06:37] <fantasai> jdaggett: What have Safari guys said about this?
# [06:37] <fantasai> plinss: They said the meta tag is a hack and they'd like to get rid of it
# [06:38] <fantasai> DD gives demos
# [06:38] <fantasai> DD: We have prefixed demo in Opera
# [06:38] <fantasai> jdaggett: So what would be the meaning of this for desktop browsers?
# [06:38] <fantasai> DD: Probably nothing
# [06:39] <fantasai> fantasai: where do you draw the line between desktop browser and non-desktop browser?
# [06:39] <fantasai> plinss: I would think that any rules like this could be targetted with media queries
# [06:39] <fantasai> jdaggett: It seems weird that you're implying that a desktop browser would blow these off
# [06:40] <fantasai> DD: So maybe you'd show it at 320px and zoom in
# [06:40] <fantasai> plinss: zooming could be a UI choice
# [06:41] <fantasai> plinss: Might have other reasons to use this, e.g. someone might want to display their page as landscape paged
# [06:41] <fantasai> dbaron: A lot of this is really a hack to get around the fact that vast majority of pages on the Web don't work on mobile the way things were originally specified
# [06:41] <fantasai> dbaron: So they had to come up with this zooming thing
# [06:41] <fantasai> dbaron: viewport meta was designed to allow pages to opt out of that
# [06:42] <fantasai> jdaggett: You're saying that it should be shown ...
# [06:42] <fantasai> ?: That depends on the page design
# [06:44] <fantasai> discussion of designing pages for mobile
# [06:45] <fantasai> jdaggett: I don't think all pages that fit into the idea of designing for 320px
# [06:46] <fantasai> fantasai: Right. But if there's a minimum width beyond which the page design doesn't work, that width should be set as min-width on the root element
# [06:46] <fantasai> fantasai: And then the UA knows to display at minimum at that size and zoom out accordingly.
# [06:46] <fantasai> Florian: The iPhone's zoom and pan model is good for the Web as currently designed.
# [06:47] <fantasai> Florian: You can have a media query and design for the small screen
# [06:47] <fantasai> Florian: But if you don't do that, then pan+zoom is better
# [06:48] <fantasai> plinss: Most of the pages that use this meta tag have different content
# [06:48] <fantasai> plinss: my mobile banking has mobile versions of their pages -- stripped down content
# [06:48] <fantasai> plinss: wikipedia does the same thing
# [06:49] <fantasai> Florian: It's valid to use this
# [06:49] <fantasai> Florian: And it's valid to us min-width as fantasai said
# [06:49] <fantasai> Florian: But one method is in use
# [06:50] <fantasai> plinss: right, I agree with fantasai that honoring the width and height of the root element would be better, but there are a lot of pages that don't do this
# [06:51] <fantasai> DD: If I set the width of the root to 320, then I have all this blank space I scroll aroun din
# [06:51] <fantasai> fantasai: That's kindof stupid then
# [06:51] <fantasai> plinss: That's a bug. If there's nothing to scroll to, don't scroll to it
# [06:52] <fantasai> plinss: If you don't have overflow, you shouldn't scroll to it
# [06:54] <fantasai> ?: Another issue is, if you do set the width of the root element, but you have a long string that sticks out
# [06:54] <fantasai> fantasai: then that's overflowing the ICB. You should be able to scroll to it, but it's outside the ICB.
# [06:54] <fantasai> ...
# [06:54] <fantasai> plinss: I'm concerned about having a zoom control in CSS
# [06:54] <fantasai> DD: So author should not be able to turn off zooming?
# [06:55] <fantasai> plinss: Why should I be *not allowed* to zoom in on a page?
# [06:55] <fantasai> plinss: Designer designed page for my iPhone, but I'm old and I want to make it bigger. Why can't I do that?
# [06:55] <fantasai> ?: First reason is you want to disable zooming gestures from zooming the page to use them for something else
# [06:56] <fantasai> ?: Say you have a webapp inbox that's just a vertical column of elements
# [06:56] <fantasai> ?: If the user is allowed to zoom, and therefore change the width so that they can pan
# [06:56] <fantasai> ?: then that changes the interaction with the app
# [06:56] <fantasai> s/pan/zoom and pan/
# [06:56] <fantasai> plinss: That's a usability issue, that's not something web page authors should be able to dictate
# [06:56] <fantasai> ?: I think web page authors should be able to dictate
# [06:57] <fantasai> Bert: But if they create a page that's unusable...
# [06:57] <fantasai> plinss: Firefox zooms in and out on my desktop. Should I not be able to do that?
# [06:57] <fantasai> dbaron: This is a different notion than the zoom in your desktop firefox
# [06:57] <fantasai> dbaron: Someone could add zoom like in desktop browser to a mobile browser, but this is a different thing.
# [06:58] <fantasai> plinss: Zoom is a UA thing. Not something the web author should be able to override and disable
# [06:58] <fantasai> dbaron: WebApps need the ability on a mobile device to use the gestures that in this default huge-page scenario that are used for other things
# [06:58] <fantasai> plinss: That's not a CSS issue, that's an event model issue
# [06:59] <fantasai> ...
# [06:59] <fantasai> sylvaing: They also want to turn of user-selection, e.g. in a menu in their webapp
# [07:00] <fantasai> Florian: We think the spec is good and needs more review, so we want to do a WD
# [07:00] <fantasai> dbaron: I think you should have something in the spec that answers John's question
# [07:01] <fantasai> dbaron: The question is, what does this do on the desktop browser? (And what's a desktop browser)
# [07:01] <fantasai> Florian: So do we do that as an editor's draft or what?
# [07:01] <fantasai> fantasai: You have two options: address it in the draft, or mark it as an issue.
# [07:02] <fantasai> Bert: 2 questions
# [07:02] <fantasai> Bert: What's interactions of @viewport and @page
# [07:02] <fantasai> Bert: If you put @viewport, can you put @viewport in @media? Say what it means?
# [07:03] <fantasai> fantasai: would it make sense to have the media query in the @viewport directly?
# [07:04] <fantasai> Florian: Question of when you match media queries, before or after processing @viewport
# [07:04] <fantasai> fantasai: Similar to @page. Copy text from @page?
# [07:04] <dbaron> dbaron: I'm not convinced this belongs in CSS; it really seems like a different layer.
# [07:04] <fantasai> Bert: I would throw away pixel-sized viewports. Should never use pixel sizes
# [07:05] <fantasai> ? talks about dashboard widgets
# [07:05] <dbaron> fantasai, I don't see text in css3-page that describes how 'size' and media queries interact.
# [07:05] <fantasai> ACTION: Rune add 3 questions above to draft
# [07:05] * trackbot noticed an ACTION. Trying to create it.
# [07:05] * RRSAgent records action 8
# [07:05] <trackbot> Created ACTION-328 - Add 3 questions above to draft [on Rune Lillesveen - due 2011-06-11].
# [07:06] <fantasai> Bert: I'm fine with publishing if there's red text making it's clear that there are issues
# [07:07] <fantasai> plinss: Yeah, just opening it up for discussion. Might decide not to do this, but need to discuss it
# [07:07] <fantasai> dbaron somewhat concerned about things progressing down REC track just because they're on the REC track even if it's not desired to move down REC track
# [07:08] <fantasai> dbaron: Would like document status to discuss status of the document
# [07:09] <fantasai> fantasai: Problem is there's so much W3C boilerplate in the status section that nobody ever reads it
# [07:09] <fantasai> Topic: Variables and Mixins
# [07:09] <dbaron> <h2>Status of this Document</h2> should have a subsection called <h3>Status of <em>this</em> Document</h3>
# [07:10] <fantasai> plinss: I would like to set a time limit on this discussion
# [07:10] <fantasai> Tab: half-hour
# [07:10] <fantasai> plinss: ok
# [07:11] <fantasai> Tab: This is the draft I have right now.
# [07:11] * Quits: alexmog (alexmog@125.207.177.35) (Connection reset by peer)
# [07:11] <fantasai> Tab: Variables is sth we've talked about for a decade
# [07:11] <dbaron> http://www.xanthir.com/blog/b4AD0
# [07:11] <shans> oh :)
# [07:11] <fantasai> Tab: It's never gotten anywhere unfortunately, but it's more and more necessary as years go by
# [07:12] <fantasai> Tab: Applications keep getting more complex
# [07:12] <fantasai> Tab: CSS include more and more duplication
# [07:12] <fantasai> jdaggett: Don't think this is delayed due to desire to solve problem
# [07:12] <fantasai> jdaggett: Just there's hard problems to solve
# [07:13] <fantasai> Tab: Just want to make sure group wants to work on this
# [07:13] <fantasai> Florian: Not sure that's the universal view
# [07:13] <fantasai> Florian: Variables is a hard problem, but we've solved harder problems before
# [07:13] <fantasai> Florian: It makes things a little more difficult for authors to understand.
# [07:14] <fantasai> Florian: For the big guys, this is not necessary, because you have a backend system that can generate that on the fly
# [07:14] <fantasai> Florian: For small ppl learning CSS from a book, this is likely to go way over their head.
# [07:14] <fantasai> Florian: It gives some convenience, but doesn't allow anything new.
# [07:14] <fantasai> Florian: Things that this simplifies can be done on the server side
# [07:14] <fantasai> Tab: I think your concern about small authors being confused is totally wrong.
# [07:15] <fantasai> Tab: If you're doing minor page of few hundred lines, you won't need this
# [07:15] <fantasai> Florian: But you'll see it anyway
# [07:15] <fantasai> ...
# [07:15] <fantasai> Sylvain: If you think CSS is easy, you're crazy. Cascading and inheritance is hard
# [07:15] <fantasai> ?: Variable declarations are easy to understand.
# [07:15] <fantasai> Tab gives example of modifying a color everywhere.
# [07:16] <fantasai> Alex: We have 3 issues
# [07:16] <fantasai> Alex: 1. There are reasons for variables.
# [07:16] <fantasai> Alex: 2. Hard problems for variables
# [07:16] <fantasai> Alex: 3. What Tab is proposing
# [07:16] <sylvaing> (meaning it's 'crazy' to say CSS is easy until this capability is added)
# [07:17] <fantasai> Bert: Different people may want different things from variables.
# [07:18] <fantasai> fantasai: If you look at a real CSS preprocessor, it does a lot of stuff. I'm concerned about going down that path.
# [07:18] <fantasai> Tab summarizes his proposal.
# [07:18] <fantasai> @var #main-color blue;
# [07:18] <fantasai> s/#/$/
# [07:19] <fantasai> p {
# [07:19] <fantasai> color: $main-color;
# [07:19] <fantasai> background: url(foo) $main-color;
# [07:19] <fantasai> list-style-image: radial-gradient($main-color, $secondary-color);
# [07:19] <fantasai> }
# [07:20] <fantasai> Tab: Not allowed to define cycles, but allowed to use variables wtihin variable declarations
# [07:20] <fantasai> Tab: Variables are global
# [07:20] <fantasai> Tab: last declaration wins
# [07:21] <fantasai> Tab: Not expanded as parse time
# [07:21] <fantasai> Florian:
# [07:21] <fantasai> a = foo
# [07:21] <fantasai> b = a
# [07:21] <fantasai> a = bar
# [07:21] <fantasai> Florian: What's b?
# [07:21] <fantasai> Tab: bar
# [07:22] <fantasai> Alex: What about naming conflicts, e.g. if I import a style sheet that uses the same name I'm using
# [07:23] <fantasai> ?: You want your variable names to be conceptual.
# [07:23] <fantasai> ...
# [07:23] <fantasai> dbaron: One thing ppl wanted with variables was ability to change them dynamically later on from JS
# [07:23] <fantasai> dbaron: If you want that, I don't see how to have the later set overrides the earlier set.
# [07:23] <fantasai> Tab: This is consistent with defining identifiers in an at-rule
# [07:24] <fantasai> Tab: e.g. with #font-face
# [07:24] <fantasai> s/#/@/
# [07:24] <fantasai> jdaggett: This is actually wrong. If you look very carefully, we have a unicode-range.
# [07:24] <fantasai> jdaggett: The presence of that means what you just said is not correct
# [07:24] <fantasai> jdaggett: For a single set of @rules, you can have multiple fonts. You can have multiple @font-face rules
# [07:25] <fantasai> dbaron: @font-face rules are mostly additive, rather than replacing
# [07:25] <fantasai> jdaggett: They will have a computed unicode-range, which is the intersection of the actual unicode-range and the cmap
# [07:26] <fantasai> dbaron: And it also depends on whether the font can be loaded
# [07:26] <fantasai> dbaron: @font-face is the worst possible example you could have picked
# [07:26] <fantasai> Florian: Even though you define how collisions are resolved, you still get them and you reduce the shareability of CSS
# [07:27] <fantasai> Tab: Ok, that I can agree with that. If you're creating a library then you have that issue.
# [07:27] <fantasai> Tab: One way to deal with that is if you're creating a library, prefix your names.
# [07:27] <fantasai> Tab: Another option is a namespacing option
# [07:28] <fantasai> fantasai notes that the CSS Namespaces module could be reused if it came to that...
# [07:28] <fantasai> not that I think we should go there
# [07:29] <fantasai> discussion of other author-defined names in CSS: counter-style, keyframes, etc.
# [07:29] <fantasai> Tab: Having functionality of having variables that can refer to other variables is great
# [07:31] <fantasai> fantasai: do you need that for JS-accessible variable,s or just for macros variables (parse-time substitution)
# [07:31] <fantasai> dbaron: If you have a parse-time substitution mechanism, you have a lot more constraints wrt scoping
# [07:32] <fantasai> dbaron: That requirement slows down how you load and parse style sheet
# [07:32] <fantasai> dbaron: depending on the scoping rules
# [07:32] <fantasai> fantasai: scoping rules in my proposal don't have that problem
# [07:33] <fantasai> Tab: undeclared variables are treated as invalid values until resolved
# [07:33] <fantasai> Tab: Another reason to work this way is you wnat htis out-of-orderness
# [07:33] * Joins: alexmog (alexmog@125.207.177.35)
# [07:33] <fantasai> Tab: CSS works so that you can almost reorder style sheet arbitrarily without changing things.
# [07:33] <fantasai> Tab: Usually resolve things based on specificity, not order
# [07:33] <fantasai> Tab: This trained us to import style sheets in any order, append things to document
# [07:34] <fantasai> Tab: Preserving that with variables
# [07:34] <fantasai> Tab: e.g. throw in corporate styles anywhere in include path of doc, won't affect how things are parsed
# [07:34] <fantasai> dbaron: resolved dynamically
# [07:35] <fantasai> Tab: Covered multiple variables with same name, last one wins
# [07:35] <fantasai> Tab: If you import a style sheet after the doc loaded, it gets processed same way as if they were in from the start
# [07:35] <fantasai> Tab: If you use a variable that's not defined, it's treated as always invalid
# [07:35] <fantasai> Tab gives example
# [07:36] <fantasai> fantasai suggests to make the example use green
# [07:36] <fantasai> Tab: bzbarsky suggested it still be valid, but be ???
# [07:37] <fantasai> ??? = set to the inital state
# [07:39] <fantasai> dbaron: ...
# [07:39] <fantasai> fantasai: p { color: red; } p { color: $foo } should always, always be equivalent to p { color: red; color: $foo; }
# [07:39] <dbaron> I think it's important that "p { color: green} p { color: $foo }" does the same whether $foo is undefined or invalid.
# [07:40] * fantasai agrees with that too
# [07:40] <dbaron> fantasai and others think it's important that p { color: green; color: $foo; } and p { color: green } p { color: $foo } do the same thing.
# [07:40] <fantasai> Tab reviews dependency cycle breaking
# [07:40] <fantasai> @var $foo red;
# [07:41] <fantasai> @var $bar $foo;
# [07:41] <fantasai> @var $foo $bar;
# [07:41] <fantasai> Tab: You would get $foo as red
# [07:41] <fantasai> dbaron: I would rather throw out the whole thing.
# [07:41] <dbaron> throw out $foo rather than use red for $foo
# [07:41] <fantasai> Tab: Ok, crash both variables in the cycle
# [07:42] <dbaron> dbaron: The cycle detection should be after you've parsed all the variables and thrown out previous definitions.
# [07:42] <fantasai> Tab: Some concern about grammar
# [07:43] <fantasai> fantasai: I would prefer using glazou's syntax of var()
# [07:43] <fantasai> fantasai: Clearer that this is being preserved into the CSSOM, that it's only valid in property values. And it doesn't have grammar implications.
# [07:44] <fantasai> Tab: Want to know if we can start doing experimental implementations of this.
# [07:44] <fantasai> fantasai: And you can prefix it if you use functional notation
# [07:45] <fantasai> Tab: Management wants to know if we are approved to work on variables.
# [07:45] <fantasai> Tab: Start work on an editor's draft that could move to WD
# [07:45] <fantasai> dbaron: I don't know if I'm answering your question, but my feeling about this is that I think this is the sanest way to do variables that I've seen so far.
# [07:45] <fantasai> dbaron: Authors want this. I think it's a lot of work. And I think it doesn't let authors do anything that they couldn't do before.
# [07:46] <fantasai> dbaron: Given the amount of work it is, and it doesn't give authors anything really new
# [07:46] <fantasai> dbaron: I would not put this near the top of any priority lists.
# [07:46] <fantasai> Tab: I think while it's not new functionality, we think it adds value, and we'd like to work on it and pressure everyone else to implement it too
# [07:47] <dbaron> Florian: It lets fewer people write CSS faster.
# [07:47] <fantasai> ...
# [07:48] <fantasai> fantasai makes a comment about other ppl's preprocessor stuff being really intelligent and us being the wrong people to work on it
# [07:48] <fantasai> Bert: Could make a Community Group
# [07:48] <fantasai> Tab: ... besides the point ...
# [07:48] <fantasai> Alex talks about priorities of different vendors
# [07:49] <fantasai> Bert: SVG is also working on something liek this, the parameter model
# [07:49] <fantasai> Bert: They have variables that you can inherit from outside the style sheet
# [07:49] * Joins: myakura (myakura@118.111.219.27)
# [07:49] <fantasai> Alex: What Doug has is a superset of that
# [07:49] <fantasai> Tab: They could potentially work together
# [07:49] <fantasai> Alex: Initial values of variables ...
# [07:49] <fantasai> Tab: No problem working together with schepers
# [07:50] <fantasai> jdaggett: I sitll think while it's a good thing to work on it, it could still get to the point that ppl say "on balance, this is not what we should do"
# [07:50] <fantasai> Tab: Looking for explicit acceptance that if I work on this and address issues, it /can/ get to WD.
# [07:51] <fantasai> Florian: I'm not convinced that any variable ssystem can bring more than it costs.
# [07:51] <shepazu_vacation> (I am very flexible about how we get parameters working for both SVG and CSS)
# [07:51] <fantasai> Tab: Are you ok with me pursuing this in WD form until we can decide whether it's worth doing?
# [07:51] <fantasai> Florian: Not authorized to say.
# [07:51] <fantasai> Florian: I look at this, it's too much and not enough.
# [07:52] <fantasai> ... JS ...
# [07:52] <fantasai> jdaggett: That's a good point. Maybe modifications to the CSSOM is a better use of time.
# [07:52] <fantasai> talk of other important things
# [07:53] <fantasai> Alex: It's a stake in the ground, when we talk about variables, this is what variables mean.
# [07:53] <fantasai> Alex: If you have more workable proposal, then we'll consider it, but here's what we have so far, this is what we mean by CSS Variables, and that's orthogonal to whether we implement this now.
# [07:53] <fantasai> plinss: Let me try to sum up here.
# [07:54] <fantasai> plinss: So I think it's fair for you to start working on an official editor's draft so we have a place to gather all this information.
# [07:54] <fantasai> plinss: I don't think anybody can guarantee it's ever going to go anywhere.
# [07:54] <fantasai> plinss: Might be where we gather all the data and then kill it.
# [07:54] <fantasai> plinss: As as I write a style sheet, I want this capability.
# [07:55] <fantasai> plinss: As soon as I think about the implications of this capability, I want this to stay away.
# [07:55] <fantasai> ?: From an implementers perspective?
# [07:55] <fantasai> plinss: No. From authors perspective even.
# [07:55] <fantasai> plinss: Your argument that variables would make things harder to read, I think it will make them much easier to read.
# [07:55] <fantasai> plinss gives an example
# [07:56] <fantasai> plinss: But when you start getting into what does this do when I change this, what does this do when I change that.
# [07:56] <fantasai> plinss: For implementers, we can figure this out and solve it.
# [07:56] <fantasai> plinss: But for authors it will be hard to figure out.
# [07:56] <fantasai> plinss: Why did this break everything all of a sudden? i think this will make things harder to understand.
# [07:56] * hober contemplates "@var $foo red !important;"
# [07:56] <fantasai> ...
# [07:57] <fantasai> plinss: You can't do this proposal in a preprocessor, it has to be done at run-time in the client.
# [07:57] <fantasai> plinss: That's a whole different class of problems.
# [07:58] <fantasai> plinss: So I think about this, and I really don't want to do this. Or do this in a very very limited way, e.g. only do colors, which is most of the problem.
# [07:58] <fantasai> plinss: So my conclusion is that you can put this in an editor's draft, but there's no guarantee it will go anywhere.
# [07:59] <fantasai> Bert: I know ppl writing preprocessors are looking at what you're doing and want to incorporate it into their system. So be careful with what you write
# [07:59] <fantasai> plinss: Maybe doing this in CSSOM extensions would be a better idea.
# [08:00] <hober> <br duration="15min">
# [08:19] <fantasai> dbaron quote "If your well-defined rules for handling that take less than 50 pages, you don't have well-defined rules."
# [08:19] <fantasai> s/quote/qotd/
# [08:20] <fantasai> Topic: @supports
# [08:20] <fantasai> jdaggett: I see a number of problems in various specs including the fonts spec, where there's a feature and it's difficult to set up fallback that would work
# [08:20] <fantasai> plinss: because you have interdependent properties
# [08:20] <fantasai> dbaron: I think this is going to become a particularly big issue as we add new layout systems
# [08:21] <fantasai> fantasai: Does anybody not understand the problem we're solving?
# [08:21] <fantasai> <silence>
# [08:21] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2011Jun/att-0002/Overview.html
# [08:21] * hober notes dbaron forgot to include "Grid" in the module name
# [08:22] <fantasai> dbaron: first, want to add support for testing for property-value pairs
# [08:22] <fantasai> dbaron: It's a very simple thing. It gives you ability to test for properties and for values
# [08:22] <fantasai> dbaron: A little extra work if you just want to check a property, but probably a good thing [...]
# [08:22] <fantasai> dbaron: I think there's a strong use case for conjunction, disjunction, and negation
# [08:23] <fantasai> dbaron: i.e. not/and/or
# [08:23] * Bert and xor and nand? :-)
# [08:23] <fantasai> dbaron: You want negation so you can write your "if supported" case separate from your "not supported" case so you don't have to make a set of overrides in the supported case
# [08:23] <fantasai> dbaron: and for combination of features
# [08:24] <fantasai> dbaron: or is needed mainly for prefixed properties
# [08:24] * sylvaing briefly attempted to think of variables inside @support rules and hurt his brain
# [08:24] <fantasai> dbaron: Came up with syntax similar to media queries
# [08:24] <fantasai> dbaron: but has a few differences
# [08:25] <fantasai> dbaron: Media queries don't let you group operators in arbitrary ways
# [08:25] <fantasai> dbaron: So the syntax here allows combining in any nesting level, but requires parentheses
# [08:25] <fantasai> dbaron: can have a and b and c, but not a and b or c
# [08:25] <fantasai> dbaron: So no precedence rules
# [08:26] <fantasai> dbaron: Also, I didn't use commas or spaces, you have to write out the keywords
# [08:26] * Quits: myakura (myakura@118.111.219.27) (Client exited)
# [08:26] <fantasai> dbaron: and then you have (property: value)
# [08:27] <fantasai> jdaggett asks about the 'not' case
# [08:27] <fantasai> ppl give examples
# [08:27] <fantasai> wont' be useful in the near future, b/c we don't have support for @supports
# [08:27] <fantasai> but in the future it will become important
# [08:28] <fantasai> discussion of @import in @supports
# [08:28] <fantasai> dbaron: Would like @import stay at the top
# [08:28] <dbaron> could have supports() function part of @import rule
# [08:29] <fantasai> ...
# [08:29] <fantasai> plinss: Makes sense to have a supports check on @import, can figure out exact syntax later
# [08:30] <fantasai> dbaron: There's a couple other things in this draft
# [08:30] <fantasai> dbaron: Another is something according to plinss has been discussed 12 years ago, which is @media inside @media
# [08:30] <fantasai> dbaron: In 2.1, @media can only contain rulesets, not other @rules
# [08:30] <fantasai> dbaron: So I'm saying that @media can contain any @rule that can be interleaved with rulesets
# [08:31] <fantasai> dbaron: So it redefines @media with that definition
# [08:31] <fantasai> dbaron: then defines @supports
# [08:31] <fantasai> dbaron: and then a third proposal, that's been floating around for not quite a decade
# [08:31] <fantasai> dbaron: primary use case for this is user stylesheets
# [08:31] <fantasai> dbaron: @document
# [08:31] <fantasai> dbaron: Not sure how important to standardize, but I've heard some interest in it
# [08:32] * sylvaing @media ($display) { @supports($flexbox) { bike: shedding; } }
# [08:32] <fantasai> Alex gives a use case for that
# [08:32] <fantasai> Alex: If it could be used to conditionally load a file, could save a lot of downloading because would load styles relevant to the pages being visited
# [08:32] <fantasai> s/that/using that in @import/
# [08:33] <fantasai> Alex: It is an issue with performance, because people right now put all the style rules for their entire site in a single style sheet
# [08:33] <fantasai> Alex: They have 2-3 times more rules than necessary for the page
# [08:33] <fantasai> Alex: Slows down downloading, selector matches, etc.
# [08:33] <fantasai> Bert: Might want it all to be cached
# [08:33] <fantasai> Alex: ...
# [08:34] <fantasai> Alex: We've seen sites that can be improved dramatically by just shrinking their style sheets, among other things.
# [08:34] <fantasai> Alex: If they could write instead of complicated selectors, they coudl write for this area of my site I'm loading this set of style sheets, and for that area use this set
# [08:36] <fantasai> Bert discusses extra HTTP requests as another factor, not convinced this will help on @import
# [08:36] <fantasai> jdaggett: Sounds like you're looking for something to solve a problem that isn't necessarily a problem, just more an organizational problem
# [08:36] <fantasai> Alex: Def my problem, I think when ppl see this functionality it's something they will ask for
# [08:36] <dbaron> s/my problem/not my problem/
# [08:37] <fantasai> Florian: If you have @document but not on @import, you can still get selector-matching benefits
# [08:37] <fantasai> Florian: So there seem to be several valid use cases for this
# [08:37] <fantasai> jdaggett: Wrt @supports, are those conditions relatively complicated.. Are there parser questions? I guess we've already tackled a lot of this with media queries
# [08:38] <fantasai> dbaron: The parsing is not that bad, because I required parens around every prop:value pair, but not more than necessary
# [08:38] <fantasai> DD: I'm concerned about the syntax being different from Media Queries
# [08:38] <fantasai> dbaron: I think Media Queries did it wrong
# [08:39] <fantasai> dbaron: Also I think this is a strict superset of Media Queries, except for the comma
# [08:40] <fantasai> dbaron: I think the comma is confusing, because people don't know whether it's "or" or "and"
# [08:41] <fantasai> jdaggett: Could add "or" to Media Queries
# [08:41] <fantasai> plinss: So a question of when can a UA legally claim it supports something.
# [08:41] <fantasai> fantasai: That's defined in the Snapshot
# [08:42] <fantasai> dbaron: Ok, I could reference that
# [08:42] <fantasai> fantasai: or copy the text
# [08:42] <fantasai> ...
# [08:42] <fantasai> jdaggett: SVG has the idea of capabilities, and it turned out to not be very useful because of the problem you're talking about
# [08:42] <fantasai> plinss: It's a useful feature, but can be abused
# [08:42] <fantasai> dbaron: Part of the problem with SVG is that they tried to define sets of features.
# [08:43] <fantasai> dbaron: With adding support for values, CSS implementations have been pretty good at not parsing new values until they actually support them
# [08:43] <fantasai> dbaron: because of the known fallback where authors want the fallback
# [08:43] <fantasai> dbaron: So I think property:value pairs is the right level to do this
# [08:43] <fantasai> dbaron: It won't work perfectly, but most implementations will do it right most of the time
# [08:44] <fantasai> Florian: I think only time UA will lie about it on a site-specific basis
# [08:44] <fantasai> Florian: there are sites that block us (Opera) because they think we don't support things we do
# [08:44] <fantasai> plinss: I think we should put a stake in the ground that UAs must not lie about this.
# [08:45] <fantasai> jdaggett: We could also put in wording about passing tests in the test suite
# [08:45] <fantasai> fantasai: already in the Snapshot wording
# [08:45] <fantasai> Florian: Can this test for support for @variables
# [08:45] <fantasai> Severa: Stop.
# [08:45] <fantasai> plinss: Can we test for @rules? And is that useful?
# [08:46] <fantasai> dbaron: @font-face is the only case where I see a use for this
# [08:46] <fantasai> jdaggett: All of Tab's animation stuff, I don't want that in this
# [08:46] <fantasai> plinss: Paged Media 3 adds 16 new @rules for margin boxes
# [08:47] <fantasai> dbaron: One of the nices things about property-value pairs is that we already have code for parsing them.
# [08:47] * hober @supports atrule(font-face)
# [08:47] <fantasai> dbaron: @rules are much more context-dependent, so you'd almost have to have a separate @support parsing list
# [08:48] <fantasai> dbaron: So if we want this, we should make sure it's in the new charter
# [08:48] <fantasai> Bert: The scope is wider than just the list of modules, so no problem here.
# [08:49] <fantasai> dbaron: So other issue is what to call it
# [08:49] <fantasai> fantasai: css3-if :)
# [08:49] <hober> "CSS3?"
# [08:49] <fantasai> dbaron: Currently calling it css3-conditional
# [08:49] <fantasai> hober, @media is in 2.1
# [08:49] * hober fantasai: no, i mean call it "CSS3?" :) (wasn't serious)
# [08:50] * Joins: Ms2ger (Ms2ger@91.181.137.121)
# [08:50] * jdaggett current css3 text spec says "CSS Text Level 3" ;)
# [08:50] * Joins: szilles (chatzilla@219.67.44.188)
# [08:50] * jdaggett needs a "Module" in there
# [08:51] <fantasai> plinss: so I'm hearing consensus that we want this
# [08:51] <fantasai> dbaron: So "CSS Conditional Rules" aka css3-conditional
# [08:51] <fantasai> ?
# [08:52] <fantasai> fantasai: And Bert's bibliography can call it [CSS3IF] :)
# [08:53] <fantasai> dbaron: Ok, I'll put this in dev.w3.org, do some editing, and then ask for WD
# [08:53] <fantasai> Bert asks why @document isn't a selector
# [08:53] <fantasai> several don't like this idea
# [08:54] <fantasai> doesn't allow grouping
# [08:54] <fantasai> and doesn't help as much with selector matching performance
# [08:54] <fantasai> dbaron: Also makes it easier to allow user style injection
# [08:55] <fantasai> dbaron: So we can have UI for site-specific styles, and we just stick it in the @document {} rule
# [08:55] <fantasai> RESOLVED: Add css3-conditional
# [08:56] <fantasai> RESOLVED: Allow Tab to work on a css3 variables editor's draft, no guarantee we'll move it to WD
# [08:57] <fantasai> DD: How do we add "or" to Media Queries?
# [08:57] <fantasai> fantasai: Need to start a new draft, since MQ is closed to new features already
# [08:57] <fantasai> dbaron: Might want to start that new draft in the next 2 years, we have some other features to add, too
# [08:58] <fantasai> Topic: mixins
# [08:58] <fantasai> Tab: These are basically the same thing, this is variables 2.0
# [08:59] <fantasai> Tab: Mixins, rather than being single values that you then use in properties, they are declaration blocks you mix into other declaration blocks
# [08:59] <fantasai> Tab: Simple example, declare a mixin like this
# [08:59] <fantasai> Tab gives an example
# [08:59] <hober> http://www.xanthir.com/blog/b4Av0
# [08:59] <fantasai> jdaggett: So this is closer to preprocessing
# [09:00] <fantasai> Tab: What's very useful here is the ability to parametrize them
# [09:00] <fantasai> Florian: Are nonprogrammers going to understand that?
# [09:00] <fantasai> jdaggett: Why do we need to use the variable syntax?
# [09:00] <fantasai> Tab: Similar concept here
# [09:00] <fantasai> jdaggett: But the functionality is distinct, how it works
# [09:01] <fantasai> jdaggett: If you have variables in your mixin, there are two things that you're jumbling together
# [09:01] <fantasai> jdaggett: essentially local variables and global variables
# [09:02] <fantasai> fantasai: How is this different from my proposal, aside from parameters?
# [09:02] <dbaron> fantasai: "So, what question are you actually answering, and what's the answer to it?"
# [09:03] <fantasai> Tab mashes around some words and doesn't answer the question
# [09:03] * Quits: szilles (chatzilla@219.67.44.188) (Ping timeout)
# [09:04] * sylvaing mixins, variables: I think the module is css3-inception
# [09:04] <hober> fantasai's proposal: http://fantasai.inkedblade.net/style/specs/constants/
# [09:04] * Ms2ger css3-$$$?
# [09:05] <fantasai> bunch of discussion
# [09:05] * Bert .oO (will that make us rich?)
# [09:05] <fantasai> simultaneously
# [09:05] <dbaron> Sylvain: "Can we have one discussion at a time?"
# [09:05] <fantasai> Tab: Aside from naming issues, this is something we want to pursue experimentally
# [09:05] <dbaron> (participant in one of the other two discussions): "No."
# [09:05] * sylvaing only if $ is a unit
# [09:05] * Ms2ger Bert, no, but it will turn CSS into JavaScript ;)
# [09:06] <fantasai> fantasai asks for use cases for putting all this in the DOM and allowing JS to manipulateit
# [09:07] <fantasai> ??: debugging
# [09:07] <fantasai> Alex: ...
# [09:07] * Joins: szilles (chatzilla@219.67.44.188)
# [09:07] <fantasai> Alex: If we compare this to programming language, it's a really bad idea
# [09:08] <fantasai> s/.../... multiple inheritance .../
# [09:08] <fantasai> Tab: It's different.
# [09:09] <fantasai> Alex: really bad usage of multiple inheritance, trust me it's possible
# [09:09] <fantasai> ??: You've got a bunch of rules and a very clear set of resolution
# [09:10] <fantasai> fantasai: I'd like to understand why this proposal is better than mine, that we should use this and not that
# [09:10] <fantasai> Tab: parameters
# [09:11] <fantasai> Tab: and global scoping
# [09:11] <fantasai> fantasai: mine has a parameterization mechanism, just different
# [09:11] <fantasai> Tab: I think global scoping is simpler and matches what authors expect from the language
# [09:12] <fantasai> Tab: So do people want to go forward or hate it?
# [09:12] <fantasai> plinss: I hate it
# [09:12] <fantasai> Alex: I hate it
# [09:13] <fantasai> Tab: Useful for authors, using it in their preprocessors
# [09:13] <plinss> s/plinss: I hate it/plinss: I _really_ hate it/
# [09:13] <fantasai> fantasai: So use it in the preprocessors.
# [09:14] <fantasai> discussion of how preprocessors work and debugging tools work
# [09:16] <fantasai> Tab argues that debugging is better when you have mixins in the browser
# [09:16] <fantasai> plinss: I think this is a failure in your debugging toolchain
# [09:18] <fantasai> random unminuted comments
# [09:18] <fantasai> and bad jokes
# [09:18] <fantasai> dbaron: I have a CS professor named Norman Ramsey
# [09:18] <fantasai> dbaron: whose comment was that Knuth attempted to make TeX not a programming language, and failed, and so it is a bad programming language
# [09:19] <fantasai> Florian: You asked if some people hated it, and the answer is yes.
# [09:19] <dbaron> s/ named Norman Ramsey//
# [09:20] <fantasai> ??: Reuse is good for the Web, it's good for the authors, not manually preprocessing things.
# [09:20] <fantasai> Florian: The good thing about manually preprocessing is that you know exactly what's going on
# [09:20] <fantasai> plinss: There have been other proposals that are more CSS-like and not programming-language-like
# [09:21] <fantasai> plinss: That's another thing
# [09:21] <fantasai> plinss: Your fundamental question was is there a strong objection, and the ansewr is yes, there is a strong objection.
# [09:21] <fantasai> plinss: I'm not hearing anybody supporting this except you guys.
# [09:21] <fantasai> Vincent: I'm not objecting. I'm sympathetic to their arguments.
# [09:22] <fantasai> jdaggett: There's a level of complexity that's here. You're adding complexity and also solving problems. You have to balance it.
# [09:22] <fantasai> DD: If it was just a plain text-replace, I'd be more comfortable with that
# [09:23] <fantasai> Tab: But CSS is global scope for everything
# [09:23] * Quits: szilles (chatzilla@219.67.44.188) (Ping timeout)
# [09:23] <fantasai> s/DD:/danield:/g
# [09:23] <fantasai> Topic: Nesting
# [09:24] * Joins: szilles (chatzilla@219.67.44.188)
# [09:25] <fantasai> Tab: Once again drawn from preprocessors
# [09:26] * Quits: jdaggett (jdaggett@125.207.177.35) (Quit: jdaggett)
# [09:27] <fantasai> Tab summarizes his proposal, see www-style posting
# [09:28] * Quits: shans (qw3birc@128.30.52.28) (Quit: Page closed)
# [09:28] * Quits: szilles (chatzilla@219.67.44.188) (Ping timeout)
# [09:29] <fantasai> fantasai: what happens if you forget the & ?
# [09:29] <fantasai> Tab: It's an invalid selector. Selectors inside this scope must start with &
# [09:30] <sylvaing> if you define the nested & selector in an @mixin you'd have to resolve your @mixin at parse time....
# [09:31] <hober> Tab's nesting proposal: http://lists.w3.org/Archives/Public/www-style/2011Jun/0022.html
# [09:32] <fantasai> plinss: What if the original selector has a comma
# [09:32] <fantasai> fantasai: equivalent to replacing the & with :any()/:matches() with that selector as its argument
# [09:32] <fantasai> (using a full implementation of :matches())
# [09:32] <fantasai> fantasai: why ampersand?
# [09:32] <fantasai> Tab: Looking for something terse that's easily recognizable
# [09:33] <fantasai> fantasai: How about using a question mark?
# [09:33] <fantasai> Tab: could work
# [09:34] <fantasai> several ask if it has to be punctuation
# [09:34] <fantasai> plinss: need to distinguish it from a property
# [09:36] <fantasai> Alex: Can you do anything with this that you couldn't before?
# [09:37] <fantasai> Tab: purely syntactic sugar
# [09:37] <fantasai> plinss: better maintainability
# [09:38] <hober> h1, h2, h3, h4, h5, h6 { & a {}}
# [09:38] <fantasai> Tab: So, I would like to pursue this.
# [09:38] <fantasai> Tab: There are some problems that need to be worked on
# [09:38] * fantasai notes that the constants proposal addresses this problem by allowing variables as selectors
# [09:38] * fantasai although this is terser
# [09:39] <fantasai> Tab: There's a combinatorial problem here. The author can easily write a lot of rules that have to kept track of
# [09:40] * Joins: plinss__ (plinss@125.207.177.35)
# [09:40] * Quits: plinss (plinss@125.207.177.35) (No route to host)
# [09:40] <fantasai> Tab: This ability is simple. I just explained everything.
# [09:40] * Quits: vhardy (vhardy@125.207.177.35) (Ping timeout)
# [09:40] <fantasai> Tab: Out of everthing I talked about so far, only one that can be entirely done in preprocessor
# [09:40] * plinss__ is now known as plinss
# [09:40] <fantasai> Tab: But it's a huge win for maintainability
# [09:40] * Joins: hober2 (ted@125.207.177.35)
# [09:41] * Quits: hober2 (ted@125.207.177.35) (Client exited)
# [09:41] <fantasai> Alex: What will the adoption picture be fore this, when there is nothing you can do with this for a long while
# [09:41] * Joins: hober2 (ted@174.143.153.77)
# [09:41] * Quits: hober (ted@125.207.177.35) (Ping timeout)
# [09:41] <fantasai> Tab: Yeah, there's no fallback
# [09:41] <fantasai> Tab: You'd have to do preprocessor for now.
# [09:41] <fantasai> Alex: Something that like this improves readability but also enables something new...
# [09:42] <fantasai> Alex: you have to still do this in separate style sheets. Have new style sheet and old one
# [09:42] <fantasai> ?: we've written a JS that will do the processing in JS, might be good interim solution
# [09:42] <fantasai> plinss: could also do an apache plugin or something
# [09:42] <fantasai> plinss: What does this do to the CSSOM
# [09:42] <fantasai> Tab: Relatively simple change.
# [09:42] <fantasai> Tab: Add ... to ...
# [09:42] * hober2 is now known as hober
# [09:43] <fantasai> discussion of parsing in downlevel UAs
# [09:44] <fantasai> Tab: You have to put them at the bottom of the rule block
# [09:44] <fantasai> sylvaing: or put a semicolon at the end of each block
# [09:45] <fantasai> fantasai: Rather restrict it to one or the other, otherwise it's confusing and people will get it wrong
# [09:46] <fantasai> Tab: Happy to just require putting them at the end of the style block. I think it's more readable that way anyway
# [09:46] <fantasai> Bert raises issue of the Core Grammar
# [09:46] <fantasai> Tab: But plays well with forward-compatible parsing
# [09:46] <fantasai> Bert: But we're not supposed to change the Core Grammar
# [09:46] <fantasai> plinss: Almost anything we add that's new is ...
# [09:47] <fantasai> dbaron: The grammar in syndata.html is very general, and Bert is saying that new stuff has to match that
# [09:48] <fantasai> foo {
# [09:48] <fantasai> prop: val;
# [09:48] <fantasai> @nest:hover {
# [09:48] <fantasai> prop: val;
# [09:48] <fantasai> }
# [09:48] <fantasai> }
# [09:48] * Joins: vhardy (vhardy@125.207.177.35)
# [09:49] <fantasai> plinss: One of my concerns about the syntax, other than &, it looks reading it a very subtle distinction between having a space after the & or not
# [09:50] <fantasai> fantasai: One advantage of the @nest is that it looks more like a regular selector, where you make this distinction. With the & it's so short, it's easier to not notice the space distinction.
# [09:51] <fantasai> Bert: Would be easier to not use ampersand in cases where the space is there, so it's more different
# [09:51] <fantasai> Tab: But then you start parsing it like a property
# [09:51] <fantasai> fantasai: I think Bert's suggestion is much better-looking.
# [09:52] <fantasai> This is agreed, but it still creates a problem.
# [09:52] <fantasai> Discussion of Tab's priorities
# [09:52] <fantasai> Tab: List, images, flexbox
# [09:52] <fantasai> Tab: want to work next on positioning to make it editor's-draft ready
# [09:52] <fantasai> Alex: Which positioning?
# [09:53] <fantasai> Tab: Firming up abspos model, and then adding ability to attach edges to edges of other boxes
# [09:53] <fantasai> Tab: We put together a newsread app that's really slick, 3 cols of stories etc.
# [09:53] <fantasai> Tab: It was ridiculously hard to do in JS or CSS.
# [09:53] <fantasai> Tab: We wound up absposing everything and using a constraint solver in JS
# [09:54] <fantasai> Bert: I think abspos was a huge mistake
# [09:54] <fantasai> Tab: I agree that what we have in CSS2 is minimally useful
# [09:54] <fantasai> dbaron: I think it's harmful
# [09:54] <fantasai> plinss: I really like this feature
# [09:54] <fantasai> plinss: that's my 2cents
# [09:55] <fantasai> plinss: I accept it's a problem that it can't be used until universally supported
# [09:55] <dbaron> betweeen "I think it's harmful" and "I really like this feature" we switched back from discussing abspos to discussing tab's proposal
# [09:55] <fantasai> oh, heh :)
# [09:57] <fantasai> Tab: If you want preprocessor, you either need server-side scripting, or JS, and JS has perf issues (and doesn't work for ppl with JS turned off)
# [09:57] <fantasai> Tab: So should I work on this?
# [09:58] <fantasai> Nobody seems to be objecting, but only Tab and plinss seem to be enthusiastic
# [09:58] <fantasai> Florian: I'm tempted to say nay based on the fact that it doesn't fit within the grammar, but not sure I can say this in Opera's name.
# [09:59] <dbaron> I think it's not crazy; I'm scared of the OM implications. Doesn't seem like an implementation priority.
# [10:00] <fantasai> Alex: not committing to do this, will be pretty far down in priority list
# [10:00] <fantasai> Alex: Think there's value in writing up what syntax could look like
# [10:00] <fantasai> Alex: In right combination with other features, could be useful
# [10:02] <fantasai> fantasai is concerned about prioritization
# [10:03] <fantasai> plinss: I'm hearing a conditional yes, that it's low priority, doesn't impact other work, no guarantee of implementation
# [10:03] <fantasai> Topic: Selectors 4
# [10:05] <TabAtkins> fantasai: I've omitted the pseudoelems from this draft (they're not relevant for other selector-y thing like querySelector). They should go in a PseudoElements Module.
# [10:05] <TabAtkins> fantasai: I added a couple of things I felt were fairly uncontroversial.
# [10:05] <TabAtkins> fantasai: Main things is :matches() (previously called :any()).
# [10:05] <TabAtkins> fantasai: It means "an element which matches my argument".
# [10:05] <TabAtkins> fantasai: And :not() is the opposite.
# [10:06] <TabAtkins> fantasai: The argument is an arbitrary selector without combinators.
# [10:06] <TabAtkins> fantasai: So :matches(foo,bar,baz) is fine, but :matches(foo > bar) is not, because that gets into branching issues.
# [10:07] <TabAtkins> fantasai: I've also added a proposal for selecting the "subject" of a selector.
# [10:07] <sylvaing> Elika is reviewing http://dev.w3.org/csswg/selectors4/
# [10:07] <TabAtkins> fantasai: So, frex, in "ol > li:only-child", you may want the <ol> itself.
# [10:07] <TabAtkins> fantasai: You can write "!ol > li:only-child".
# [10:07] <TabAtkins> florian: That reminds me of "not".
# [10:08] <TabAtkins> fantasai: I've also tightened up some terminology.
# [10:09] <TabAtkins> fantasai: "simple selector" is the same as before. "compound selector" is a sequence of simple selector, without combinators.
# [10:09] <TabAtkins> sylvaing: Do you ahve anything about pseudoelements with pseudoclasses in it?
# [10:09] <TabAtkins> fantasai: I haven't touched that yet, but i think the pseudoelem should specify what pseudoclasses can apply to it.
# [10:10] <TabAtkins> fantasai: Another new feature is :dir([rtl | ltr]), which is the same as the older suggestion for :ltr/:rtl, but more consistent with :lang().
# [10:10] <TabAtkins> fantasai: I also believe we should pull in the various pseudos that HTML5 defines, because they should be defined on our side.
# [10:11] <TabAtkins> fantasai: And then HTML can just clarify what they apply to for HTML, rather than *defining* them.
# [10:11] <fantasai> http://wiki.csswg.org/spec/selectors4
# [10:12] <TabAtkins> fantasai: Here are some other features people have requested for Selectors.
# [10:12] <TabAtkins> fantasai: A lot of which I think are very cool.
# [10:15] <TabAtkins> fantasai: I think for now I just want to add the "current url" selector.
# [10:15] <TabAtkins> fantasai: And then publish as WD?
# [10:16] <TabAtkins> Bert: I think we're done with Selectors for a while.
# [10:17] <TabAtkins> florian: One comment from Opera, under the impression that :matches() was the only new thing, we're okay with it.
# [10:19] <TabAtkins> Bert: Shouldn't the HTML5 pseudoclasses be in the UI module?
# [10:22] <TabAtkins> fantasai: I'd prefer to have all selectors be defined in the Selectors module, otherwise it's kinda annoying to have to specifically define a conformance class in UI just for selectors-using stuff.
# [10:23] <TabAtkins> [discussion about naming]
# [10:23] <dbaron> Bert: We shouldn't do any specs in level 4 until we've done everything in level 3.
# [10:23] <dbaron> Peter: We've agreed to level modules independently.
# [10:25] <TabAtkins> vhardy: Why isn't the module's shortname "css4-selectors"?
# [10:25] <TabAtkins> fantasai: We determined a while ago that Selectors aren't CSS-specific, and the level 3 name was a historical mistake.
# [10:26] <hober> scribenick: hober
# [10:26] <hober> Topic: dropping prefixes
# [10:27] <hober> sylvaing: in recent snapshot we updated the rules for when impls can drop prefixes
# [10:27] <hober> sylvaing: let's update the spec template to match the snapshot
# [10:28] <fantasai> http://www.w3.org/TR/css-2010/#experimental
# [10:28] <fantasai> http://dev.w3.org/csswg/css-module/#conformance
# [10:28] <TabAtkins> fantasai: A related issue is that most of our modules don't follow the latest template, which has new text and boilerplate.
# [10:28] <hober> scribenick: tabatkins
# [10:29] <TabAtkins> sylvaing: When are we going to start doing this?
# [10:29] <TabAtkins> fantasai: How about right now?
# [10:29] <TabAtkins> TabAtkins: I can fix my modules to use the new boilerplate soon.
# [10:29] <TabAtkins> vhardy: Can we get the preprocessor to handle this for us?
# [10:30] <TabAtkins> fantasai: Some parts, yes. Sounds good - Bert and I will update the template and work on this.
# [10:31] <TabAtkins> RESOLVED: Update all modules to the latest module template, once Fantasai has checked in the necessary edits.
# [10:31] <TabAtkins> ACTION fantasai and bert to update the preprocessor template to match boilerplate.
# [10:31] * trackbot noticed an ACTION. Trying to create it.
# [10:31] <trackbot> Created ACTION-329 - And bert to update the preprocessor template to match boilerplate. [on Elika Etemad - due 2011-06-11].
# [10:32] <fantasai> RESOLVED: Move forward with Selectors 4
# [10:32] <TabAtkins> sylvaing: Given all the specs we're doing, should each spec have a "test owner" that tracks tests and determines coverage and such?
# [10:32] <TabAtkins> fantasai: That sounds like a wonderful idea.
# [10:33] <TabAtkins> florian: The only problem I have is that having a test owner will make the editors not care about tests.
# [10:33] <TabAtkins> sylvaing: That's today's situation. ^_^
# [10:34] <TabAtkins> fantasai: Also, having it official means that people like sylvain can go to management and say "I need a QA person in the group to be test owner for my spec".
# [10:34] <TabAtkins> RESOLVED: Establish official "test owner" position parallel to the editor, who keeps track of testing the module.
# [10:35] <fantasai> s/keeps track of/is responsible for ensuring the/
# [10:35] <fantasai> s/testing the/test suite of/
# [10:35] <TabAtkins> Topic: text-overflow
# [10:36] <TabAtkins> fantasai: There was a string value for text-overflow that let you specify what ellipsis you wanted.
# [10:36] <TabAtkins> fantasai: Moz has an impl of this.
# [10:36] <TabAtkins> fantasai: There was also a proposal to have two values.
# [10:37] <TabAtkins> fantasai: In a scrollable box, when you scroll you end up cutting off text on *both* sides. If you have a direction-sensitive ellipsis character, like an arrow, you want a different one for the other side.
# [10:37] <TabAtkins> fantasai: So the proposal is to let it take two strings (left and right) in addition to one string (both).
# [10:38] <TabAtkins> vhardy: We have a similar issue with CSS Regions, where we want something like a "(cont)" at the bottom of each region.
# [10:39] <TabAtkins> fantasai: We've had a proposal for a 'block-overflow' to handle that case. It doesn't live in any spec yet.
# [10:39] <TabAtkins> vhardy: I'll put it into Regions for now, just to give it a place to live.
# [10:39] <TabAtkins> alexmog: The feature gets significantly more complex if you want references and back-references "(cont on page 5)".
# [10:40] <TabAtkins> fantasai: Yes, but it's okay to deal with that later.
# [10:40] <TabAtkins> dbaron: Another issue is that we're implementing it unprefixed, because everyone else already has. That's... an issue.
# [10:40] <TabAtkins> plinss: Not happy about the unprefixed, but I understand the position you're in.
# [10:45] <TabAtkins> RESOLVED: Add the two-value syntax to text-overflow.
# [10:45] <fantasai> marked at-risk
# [10:45] <TabAtkins> Topic: Regions
# [10:46] <TabAtkins> vhardy: There's a question of integration with other specs.
# [10:46] <TabAtkins> vhardy: The issue is that, to use something as a region, it needs to be addressible in some way.
# [10:46] <TabAtkins> vhardy: Like a grid-cell, so you can use 'content' or 'flow-from' on it.
# [10:46] <TabAtkins> vhardy: This works with Grid Layout, because there's a pseudo for it.
# [10:46] <TabAtkins> vhardy: But there's none for multicol and flexbox.
# [10:47] <TabAtkins> vhardy: There's no way to address a column box in multicol.
# [10:47] <TabAtkins> vhardy: For example, you may want to make a flow of text and a flow of images, and put the images into the second column and flow the text into the first, third, and subsequent columns.
# [10:48] <TabAtkins> alexmog: Sounds like an exclusion.
# [10:48] <TabAtkins> vhardy: Or putting alternating content in columns.
# [10:49] <TabAtkins> alexmog: The way to address this is to make a Grid set up with the same dimensions as the columns that multicol would have given, and then flow into the grid cells.
# [10:50] <TabAtkins> vhardy: The question is if we want to integrate more closely into the multicol.
# [10:50] <TabAtkins> alexmog: Multicol is the only exception here. Grid was carefully designed so that it would size the same as grid.
# [10:50] <fantasai> s/grid/column/
# [10:51] <TabAtkins> TabAtkins: I think I must agree with alexmog. It makes more sense to flow into grid cells than to flow into multicol column boxes.
# [10:52] <TabAtkins> alexmog: And you can use, say, region styling to say "this region should have 'columns:3'".
# [10:52] <TabAtkins> vhardy: Okay, no column boxes as regions.
# [10:52] <TabAtkins> vhardy: next is, what is a grid cell exactly?
# [10:53] <TabAtkins> vhardy: There's a grid-cell-stacking property, and an issue that questions whether it should instead be 'display'.
# [10:54] <TabAtkins> hober: I agree with whatever Hyatt last said.
# [10:54] <TabAtkins> TabAtkins: I think Hyatt said he liked the 'display' version. I also strongly support it.
# [10:55] <TabAtkins> alexmog: Note that we don't have immediate plans to implement the ::grid-cell pseudos - our current experimental impl is from the November draft where you could only position boxes.
# [10:55] <TabAtkins> alexmog: But it makes sense to do so.
# [10:57] <TabAtkins> fantasai: [separate note] I think it makes sense to limit it to only pseudoelements being regions, not elements.
# [10:58] <TabAtkins> vhardy: There was some discussion on that on the mailing list.
# [10:59] <fantasai> Topic: Gradients
# [10:59] <fantasai> sylvain: When you say bottom left for the corner
# [11:00] <fantasai> fantasai: Animating keyword sides/corners through 0deg makes the gradient spin through the longest path instead of the shortest path
# [11:00] <fantasai> Tab: Oh, yes. I will fix that in the spec
# [11:01] <fantasai> fantasai: Next issue was direction of 0deg and direction of increase
# [11:02] <fantasai> fantasai: We posted to css3.info to ask for feedback from authors
# [11:02] <fantasai> fantasai: got 95+ comments, overwhelming majority, as you can see, was for C which is polar angles (zero degrees up)
# [11:03] <fantasai> fantasai: Arguments given were that it's consistent with the TRBL model that is used everywhere else in CSS, and the angles increment clockwise which is consistent with every other use of angles in CSS.
# [11:04] <fantasai> plinss: There was a small minority asking for 0deg to the right, increasing counter-clockwise.
# [11:04] <fantasai> noted that Brad objects to polar angles
# [11:05] <fantasai> RESOLVED: gradients use polar angles
# [11:05] <fantasai> s/polar/bearing/
# [11:05] <fantasai> s/polar/bearing/
# [11:05] <fantasai> WG: Polar Bears!
# [11:06] <plinss> s/Brad objects to polar angles/Brad objects to bearing angles/
# [11:06] <fantasai> s/polar/bearing/
# [11:08] <sylvaing> a gradient angle value e.g. 30deg is the end point of a gradient line
# [11:08] <sylvaing> however, an angle keyword e.g. top is the start point of the gradient line
# [11:09] <alexmog> Tab: �?�?
# [11:10] <sylvaing> this is somewhat confusing, especially once one starts transitioning linear gradients
# [11:13] <Bert> (If it is a direction, why isn't it called 'up' instead of 'top'?)
# [11:16] <Bert> (Or maybe north, nnw, nw, wnw, west....)
# [11:20] <fantasai> Bert, it means "attach my gradient to the top edge and then draw from there"
# [11:20] <dbaron> the allowed keywords should just be 东, 西, 北, 南, 東, 东北, 西北, 東北, 东南, 西南, 東南 :-)
# [11:21] <danield> So maybe 0 deg should also mean "attach my gradient to the top edge and then draw from there"
# [11:22] <fantasai> Florian: The cardinal directions map directly to degrees.
# [11:26] <dbaron> dbaron: associating expected status and priorities in the charter doesn't make sense
# [11:28] <fantasai> Agreement that the charter should be organized not by "priority" but by what status we expect specs to reach by the end of the charter
# [11:28] <fantasai> and the sections then need some severe editing
# [11:28] <fantasai> Specs expected to reach REC:
# [11:28] <fantasai> - css3-background
# [11:28] <fantasai> - css3-values, maybe
# [11:28] <fantasai> - css3-ui
# [11:28] <fantasai> Specs expected to reach CR:
# [11:29] <fantasai> - css3-fonts
# [11:29] <fantasai> - css3-2d-transforms
# [11:29] <fantasai> - css3-animations
# [11:29] <fantasai> - css3-writing-modes
# [11:29] <fantasai> - css3-text
# [11:29] <fantasai> - css3-images
# [11:29] <fantasai> - css3-lists
# [11:29] <fantasai> - css3-flexbox
# [11:29] <fantasai> - css3-transitions
# [11:30] <fantasai> plinss: multicol?
# [11:31] <fantasai> fantasai: If we are planning to test whether things paginate across columns correctly, no, not REC.
# [11:31] <fantasai> fantasai: If we're only testing whether you calculate columns correctly, then quite possible
# [11:31] <fantasai> dbaron: Have a "Expected to have test suite" bucket?
# [11:32] <fantasai> Specs expected to have a test suite:
# [11:32] <fantasai> - css3-multicol
# [11:32] <fantasai> s/a test/a complete test/
# [11:32] <fantasai> (and is in CR)
# [11:33] <fantasai> Vincent: Regions
# [11:34] <fantasai> fantasai: I think we can have CR as a goal, but I think not as an expectation
# [11:34] <fantasai> Testing bucket should be "Specs that are CR that we expect to have a complete test suite for"
# [11:35] <fantasai> Add css3-speech to CR bucket
# [11:36] <fantasai> Everything else will be in the WD-and-working-on-it bucket
# [11:37] <fantasai> plinss: "Expected to *be* CR with a complete test suite"
# [11:38] <fantasai> Meeting closed.
# [11:39] <fantasai> plinss thanks Google for dinner, Microsoft for lunch, and Koji and Seko-san for hosting
# [11:40] * Parts: danield (danield@125.207.177.35)
# [11:40] * Quits: plinss (plinss@125.207.177.35) (Quit: plinss)
# [11:40] * Quits: dbaron (dbaron@125.207.177.35) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [11:42] * Quits: vhardy (vhardy@125.207.177.35) (Quit: vhardy)
# [11:42] * Quits: florian (florianr@125.207.177.35) (Ping timeout)
# [11:42] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
# [11:43] <boblet> お疲れさま CSSWG!
# [11:43] * Quits: sylvaing (sylvaing@125.207.177.35) (Quit: sylvaing)
# [11:46] * Quits: alexmog (alexmog@125.207.177.35) (Quit: alexmog)
# [11:49] * Quits: TabAtkins (tabatkins@125.207.177.35) (Ping timeout)
# [11:51] * Quits: Ms2ger (Ms2ger@91.181.137.121) (Ping timeout)
# [11:51] * Quits: kojiishi (kojiishi@125.207.177.35) (Ping timeout)
# [11:52] * Quits: nmccully (macnmm@124.144.75.245) (Quit: byeeeeee!)
# [12:19] * Joins: Ms2ger (Ms2ger@91.181.137.121)
# [12:57] * Quits: Ms2ger (Ms2ger@91.181.137.121) (Ping timeout)
# [12:59] * Joins: Ms2ger (Ms2ger@91.181.230.41)
# [15:14] * Joins: florian (florianr@218.220.206.223)
# [15:36] * Quits: florian (florianr@218.220.206.223) (Ping timeout)
# [15:45] * Joins: plinss (plinss@61.214.117.102)
# [15:48] * Quits: plinss (plinss@61.214.117.102) (Ping timeout)
# [15:53] * Joins: florian (florianr@218.220.206.223)
# [15:54] * Parts: florian (florianr@218.220.206.223)
# [15:55] * Quits: shepazu_vacation (schepers@128.30.52.169) (Quit: shepazu_vacation)
# [16:50] * Quits: boblet (Adium@122.27.197.150) (Quit: Leaving.)
# [17:26] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [17:32] * Joins: arronei (arron.eich@131.107.0.117)
# [17:33] * Quits: arronei_ (arron.eich@131.107.0.87) (Ping timeout)
# [18:24] * Quits: Ms2ger (Ms2ger@91.181.230.41) (Quit: nn)
# [22:28] * Joins: szilles (chatzilla@24.6.120.172)
# [22:31] * Quits: szilles (chatzilla@24.6.120.172) (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027])
# [23:41] * Joins: vhardy (vhardy@219.127.245.113)
# Session Close: Sun Jun 05 00:00:00 2011

The end :)