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