W3C home > Mailing lists > Public > www-style@w3.org > June 2011

RE: [CSSWG] Minutes and Resolutions F2F Kyoto Sat: CSS3 Fonts, Regions, @viewport, Variables, @supports, Selectors4, Administrivia

From: John Jansen <John.Jansen@microsoft.com>
Date: Sat, 11 Jun 2011 03:19:31 +0000
To: Vincent Hardy <vhardy@adobe.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <C340671BECD4364E8F9EBA27E8E231322F502444@DF-M14-05.exchange.corp.microsoft.com>


> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Vincent Hardy
> Sent: Friday, June 10, 2011 4:55 PM
> To: fantasai; www-style@w3.org
> Subject: Re: [CSSWG] Minutes and Resolutions F2F Kyoto Sat: CSS3 Fonts,
> Regions, @viewport, Variables, @supports, Selectors4, Administrivia
> 
> Hi Fantasai,
> 
> Thanks for putting together the summary in addition to the raw log.
> 
> For the CSS Regions part, my notes have a few more resolutions and action
> items:
> 
> RESOLVED:
> 
> - use flow-into and flow-from properties and explain the interaction with
> the css3 contents module definition of the content property. The flow-into
> and flow-from properties should be <string>

It's very difficult to tell from the minutes why this was resolved to be a string. Alex asked this as well [1]. Can anyone clarify?

http://lists.w3.org/Archives/Public/www-style/2011Jun/0155.html



> - content selection should not be mentioned in the spec.
> - confirmed that the event propagation model should not be modified.
> - make the section on DOM events model informative.
> - CSS OM View:
>     - confirmed the current proposal (NamedFlow + Element interface
> extension)
>     - agreed to add event on changes to regionOverflow and flowRanges
> 
> ACTION ITEM:
> 
> - Regions spec. editors to specify a model for breaking flow content
> across areas that accounts for regions, columns and pages. Build on paged
> media and propose behavior for nested flows breaks.
> 
> 
> Vincent
> 
> 
> 
> On 6/10/11 9:39 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
> 
> >CSS3 Fonts
> >----------
> >
> >   - Discussed same origin restriction on @font-face. There are differing
> >     opinions on whether resources loaded through @font-face should be
> >     restricted or unrestricted by default. It was pointed out that the
> >     restriction s on anything loaded through @font-face, not on fonts
> >     only; conversely it does not apply to font files loaded via other
> >     mechanisms. It was also pointed out that the suggested solutions were
> >     HTTP-secific, whereas @font-face is protocol-agnostic.
> >
> >   - Discussed superscripts/subscripts and fantasai and dbaron's proposal:
> >       http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html

> >     The proposal handles nested superscripts/subscripts, changes in font
> >     size within the superscript/subscript, and the inclusion of atomic
> >     inlines such as images. It works y computing values that synthesize
> >     the superscripts/subscripts and then undoing the synthesis settings
> >     when setting characters for which specialized glyphs are vailable.
> >
> >Flexbox
> >-------
> >
> >   - Reviewed status of spec and implementations
> >
> >CSS Regions
> >-----------
> >
> >   - RESOLVED: Switch content-order to take <integer>
> >
> >   - Discussed syntax for pushing to/pulling from named flows.
> >
> >   - Briefly discussed integration of regions with multicol and grid
> >layout
> >
> >Device Adaptation
> >-----------------
> >
> >   - Re-reviewed the draft. Some issues were raised against the draft;
> >     some concerns were raised about putting this in CSS. No objections
> >     were raised for moving towards FPWD.
> >
> >Variables and Mixins
> >--------------------
> >
> >   - RESOLVED: Allow Tab to work on a css3 variables editor's draft,
> >               no guarantee we'll move it to WD
> >   - Tab presented a mixins proposal and received very strong objections.
> >   - Tab presented a proposal to nest style rules which received a
> >lukewarm
> >     reception.
> >
> >CSS3 Conditional Rules
> >----------------------
> >
> >   dbaron presented a draft for
> >     - @supports rule to check for property:value support in the UA
> >     - @document rule to apply rules to a particular set of URLs
> >     - nesting at-rules inside @media
> >   RESOLVED: Add css3-conditional
> >
> >Selectors Level 4
> >-----------------
> >
> >   fantasai presented the idea of a new level of Selectors. The current
> >   draft excludes pseudo-elements (which would be a separate module) and
> >   adds
> >     - :matches() and :not() that take a comma-separated list of selectors
> >     - :dir(ltr) and :dir(rtl) that match against the markup-determined
> >       directionality
> >     - the ability to choose which component of a selector represents its
> >       subject
> >
> >   RESOLVED: Move forward with Selectors 4
> >
> >Other: text-overflow, gradients
> >-------------------------------
> >
> >   - RESOLVED: Add the two-value <string> syntax to text-overflow in
> >css3-ui,
> >              marked at-risk
> >
> >   - RESOLVED: gradients use bearing angles
> >
> >Administrivia: Module Template, Test Suite Owners, Charter, F2F
> Scheduling
> >--------------------------------------------------------------------------
> >
> >   - RESOLVED: Update all modules to the latest module template, once
> >             it has been updated with the latest Snapshot wording
> >
> >   - RESOLVED: Establish official "test owner" position parallel to the
> >editor,
> >               who is responsible for ensuring the correctness and
> >completion
> >               of the test suite
> >
> >   - RESOLVED: that the charter lists should be oganized not by
> >"priority" but
> >               by what status we expect specs to reach by the end of the
> >charter
> >               (and need to be edited accordingly)
> >
> >   - RESOLVED: Meet for 3 days at TPAC
> >
> >   - RESOLVED: Try to schedule a meeting in August probably in Seattle
> >               or France
> >
> >====== Full minutes below ======
> >
> >Present:
> >   David Baron (Mozila)
> >   Bert Bos (W3C)
> >   John Daggett (Mozilla)
> >   Daniel Davis (Opera)
> >   Elika Etemad (Invited Expert)
> >   Sylvain Galineau (Microsoft)
> >   Vincent Hardy (Adobe)
> >   Koji Ishii (invited Expert)
> >   Peter Linss (HP)
> >   Luke Macpherson (Google)
> >   Alex Mogilevsky (Microsoft)
> >   Shinyu Murakami (Antenna House)
> >   Ted O'Connor (Apple)
> >   Florian Rivoal (Opera)
> >   Shunchi Seko (NTT)
> >   Shane Stevens (Google)
> >   Steve Zilles (Adobe)
> >
> ><RRSAgent> logging to http://www.w3.org/2011/06/04-css-irc

> >
> >Scribe: Ted O'Connor
> >
> >CSS3 Fonts: same-origin restriction
> >-----------------------------------
> >
> >   jdaggett: Two issues: same-origin restriction & super/sub-script
> >handling
> >
> >   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction

> >   jdaggett: starting with the same-origin restriction
> >   jdaggett: came out of discussion in fonts/woff group
> >   jdaggett: description of SOR used to be in an appendix of the css3
> >fonts spec
> >   jdaggett: fonts group's charter calls for making SOR a requirement
> >   jdaggett: now we have a split between woff spec & css3 fonts spec
> >   jdaggett: objection from apple that it doesn't make sense for SOR to be
> >             tied to the format
> >   jdaggett: we came to conclusion that it makes sense for this to live in
> >             the css3 fonts spec
> >   jdaggett: the text has been moved into the body from the appendix
> >   jdaggett: open issues: what should the default behavior be
> >   ff & ie? restrict by default, allow CORS for relaxing
> >   jdaggett: annevk thinks this is weird
> >   jdaggett: inconsistent with other parts of web platform
> >   jdaggett: problems with data leakage
> >   jdaggett: e.g. canvas' dirty flag
> >   jdaggett: [describes example of embedding security problem on
> >whiteboard]
> >   jdaggett: these issues are beyond fonts & images
> >   jdaggett: there are even issues if script can see the response code
> >from
> >             certain cross-origin images
> >   jdaggett: we have normative prose (section 4.8.1)
> >   jdaggett: annevk doesn't like the default restriction
> >   jdaggett: he'd prefer no restriction by default & users would need to
> >             explicitly set an exception
> >
> >   sylvaing: annevk's first objection is that CORS isn't the right tech
> >for this
> >   jdaggett: [as annevk] the web has evolved because people can link
> >willy-nilly
> >   florian: why solve this for fonts only?
> >   Bert: fonts are different
> >   <jdaggett> siteA --> siteB gimme xxx
> >   <jdaggett> siteA <-- here you go (no CORS header)
> >   <jdaggett> UA sees no CORS header, doesn't download resource
> >   jdaggett: how does the existing text in 4.8.1 work?
> >   <jdaggett> siteA --> siteB gimme xxx
> >   <jdaggett> siteA <-- here you go (CORS header: siteB use ok -or- all
> >sites ok)
> >   <jdaggett> UA sees CORS header, check for a match, downloads resource
> >   jdaggett: instead, annevk's proposal:
> >   <jdaggett> siteA --> siteB gimme xxx
> >   <jdaggett> siteA <-- siteB here you go (no From-Origin header)
> >   <jdaggett> UA sees no From-Origin restriction, <uses default behavior>
> >   <florian> link to where annevk discusses this:
> >             http://annevankesteren.nl/2011/02/from-origin

> >   jdaggett: explicit restriction instead of explicit relaxation
> >   <jdaggett> siteA --> siteB gimme xxx
> >   <jdaggett> siteA <-- siteB here you go (From-Origin: no cross-linking
> >please)
> >   <jdaggett> UA sees From-Origin restriction, doesn't download resource
> >
> >   jdaggett: this could be used for images, scripts, wider set of
> >resource types
> >   jdaggett: both ff & ie have implemeted the cors approach
> >   jdaggett: others haven't implemented either
> >   jdaggett: consensus that some kind of mechanism is a good thing
> >   jaggett: don't want to allow cross-origin font linking by default
> >   jdaggett: the cors approach hits the 80/20 point for fonts
> >   jdaggett: vs. the from-origin proposal, which requires you to raise a
> >             flag to get the typical behavior
> >   florian: yes for fonts, but for all resources, from-origin hits the
> >            default correctly
> >   jdaggett: should the default for fonts be different?
> >   jdaggett: our (ff) security guys think all new resource types should
> >            default to SOR
> >   TabAtkins: [describes attack that extracts font data out of a tainted
> >               <canvs>]
> >   Bert: the problem is the javascript, not the resources
> >   TabAtkins: then you wouldn't be able to do anything with fonts in
> >javascript
> >   TabAtkins: .g. canvas
> >   dbaron: or figure out the width of text
> >
> >   Bert: there should be 2 kinds of things on the web: programs and
> >documents
> >   Bert: text/html is document, maybe application/html could have these
> >        restrictions
> >   jdaggett: existing content
> >   Bert: the power of the web is transclusion
> >   jdaggett: we can't get there from here
> >   TabAtkins: [describes <iframe> v. <img> differences]
> >   Bert: fonts are different
> >   Bert: you can't right click on a font
> >   Bert: this is why we have woff
> >   Bert: need to say "this font is for this document"
> >   jdaggett sylvaing: that's not what woff does
> >   [eot v. woff, root string disagreement]
> >   plinss: </tangent>
> >
> >   jdaggett: still contention about mechanism & default
> >   jdaggett: this is not a css-only discussion
> >   jdaggett: is a web-wide discussion
> >   jdaggett desn't want to have things in css3 fonts that will block
> >            it moving forward
> >   jdaggett: has labelled what impls are doing & put wording that
> >             captures where this will change if consensus changes
> >   jdaggett: what the consensus  will be isn't quite clear
> >   jdaggett: marked this as risk
> >   jdaggett: does that suffice to move this forward? i don't know
> >   sylvaing: from-origin is broader, will be more controversial
> >   jdaggett: so it'll take longer
> >   florian: opera prefers annevk's psition, but isn't locked into it
> >   jdaggett: annevk prefers a mechanism to work across resource types
> >            and the default should be no restriction
> >   jdaggett: howcome is ambivalent here
> >
> >   sylvaing: This is about any resources loaded by src: in @font-face,
> >not about
> >             fonts v. other resources
> >   fantasai: so images loaded via @font-face would be restricted by
> >default
> >   sylvaing yes
> >
> >   jdaggett: we can't go back and change the default for images
> >   jdaggett: wante to make people aware of the wording here that this is
> >             at risk etc.
> >   plinss: bottom line is we're not making the restriction decision here
> >           in csswg
> >   plinss: you want to decouple so we can advance
> >   jdaggett: yes
> >   jdaggett: delicate negotiations with the web fonts group
> >   Bert: not for csswg, because fonts can be embedded via xsl, etc.
> >   hober: we define @font-face, so we define restriction for that
> >embedding point
> >   everyone: [we didn't develop woff for origin restriction reasons]
> >
> >   Bert: sounds like annevk's proposal is better
> >   Bert: what is the reason for woff if all fonts are restricted?
> >  jdaggett: existing font formats weren't for the web, etc., needed to
> >             be a web font format
> >   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
> >   jdaggett: @font-face is here, so restriction has to be here
> >   jdaggett: web fonts group has the format
> >   web fonts charter isn't woff-specific
> >   plinss: bert's point is that we & svg etc should use same mechanism
> >   plinss: we shouldn't be deciding the restriction
> >
> >   plinss: is there an actionable item here?
> >   jdaggett: proposals have to be detailed and go to web fonts group &
> >css group
> >   florian opera is satisfied with this wording
> >   florian: we'd welcome clearly-defined alternatives
> >   florian: this is good enough, allows for alternative proposals
> >   ?: we can't go to CR with this
> >   jdaggett: we can mark it at risk
> >
> >   Bert: what about non-HTTP urls, we need to still work
> >   plinss: yes, this is very http-specific
> >   szilles: it's not woff pushing it back on us, they were conviniced this
> >            is acceptable solution to one of their problems
> >   szilles: if we push back, woff group would have to start over
> >   jdaggett: [doesn't want to create other thing that we can't reference
> >              normatively]
> >   jdaggett: put it here, mark it at risk, and go on
> >
> >   jdaggett: by the time we have impls, test suite, etc. this will be
> >worked
> >             out one way or another
> >   jdaggett: font EULAs say you need to do referrer checking when ua
> >doesn't
> >             support [sor mechanism]
> >   fantasai: if user turns off Referer header, can't get fonts
> >   jdaggett: post detailed proposals, not just "i want this"
> >
> >CSS3 Fonts: superscripts and subscripts
> >---------------------------------------
> >
> >   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop

> >   jdaggett: Next issue: dealing with superscripts and subscripts
> >   'vertical-position' property
> >   jdaggett: lets you turn on super/sub-script variants in fonts
> >   jdaggett: within the font, variants of the number 2, say, that fit
> >             in normal em box
> >   jdaggett: by using this, line box doesn't change, etc.
> >   jdaggett: currently, baseline shifts and font size changes
> >   jdaggett: so you see changes in the line box
> >   jdaggett: doesn't look good
> >   jdaggett: when you shrink down the normal-sizeglyph, strokes shrink
> >             too, so super/sub scripts don't have same typographic color
> >             as surrounding text
> >   jdaggett: 'vertical-position' addresses lots of cases [footnotes, etc.]
> >   jdaggett: doesn't address putting images in <sup> or nesting other
> >             sortsof things in <sup>/<sub>
> >   jdaggett: superscripts&subscripts are semantic, so can't be treated
> >             like other font variants
> >
> >   szilles: we've already discussed this; what's te new information?
> >   jdaggett: if I use 'vertical-position: superscript' or s^2 and look
> >             at content in an older browser, I see s2
> >   jdaggett: authors need a way to ensure the right thing happens
> >   jdaggett: the current spec makes 'vertical-position' a shorthand
> >   jdaggett: [reads from section 6.4 on how fallback works]]
> >   jdaggett: allows you to make styles for <sub> and <sup> that work
> >             well in older UAs, as long as you only have text
> >
> >   <jdaggett>
> >http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html

> >   fantasai describes proposal
> >   fantasai: new property 'magic'
> >   [fantasai & dbaron's replacement for vertical-position]
> >   maic: none | super | sub
> >   fantasai: [describes proposal in email jdaggett linked above]
> >   fantasai: if magic matches verticl-align, then computed font size is
> >             set by multiplying size ratio to parent's font size & we
> >             ignore specified fontsize
> >   szilles: you're setting the font size to the size that's in the font
> >   fantasai: yes
> >   dbaron: let's explain the gals of this approach
> >   fantasai: we're trying to handle basic super/sub scripts with special
> >             glyphs if available, & synthesizing if they're not available
> >   fantasai: second goal: handle atomic inlines & nested super/subscripts,
> >             what happens if you have a span with changed font size inside
> >             these thigns
> >   fantasai: we're not perfectly handling mixing special glyphs with other
> >             content
> >   fantasai: if font metrics are off, such mixed content will look ugly
> >   dbaron: but that's true of all proposals that use font's special glyphs
> >   jdaggett: adobe ships same same metrics in all of their fonts, which
> >             shows that such metrics are unreliable
> >   jdaggett: 99% use case, you'll (probably) be ok
> >   fantasai: also don't hande using lengths or percentages for vertical
> >             align & mixing with this feature
> >   fantasai: won't get the right glyphs if you try to position the
> >             super/sub-script differently than what the font does
> >
> >   Bert: [expresses scepticism]
> >   jdaggett: this could be a case for @supports
> >   jdaggett: if someone's explicitly enabling this, we document that it
> >             works this way, so they're aware of the tradeoffs
> >
> >   dbaron: fantasai & my proposal makes this more complex, but allows
> >           ua stylesheet to have this on by default
> >   plinss: So basically you synthesize superscripts/subscripts font size
> >           and vertical alignment, and anything but the special glyphs
> >           will draw in synthesized state
> >   fantasai: yes. You reverse the synthesis settings in order to draw the
> >glyphs
> >
> >   szilles: is this opentype feature turned on by default?
> >   jdaggett: we're not talking about unicode code points
> >   plinss: if you're using those code points, you're not using <sup> or
> ><sub>
> >   Bert: you have super, sub,and none, but why not just 'yes' / 'no'?
> >   Bert: turn it on from root elemen
> >   fantasai: That's one of the alternatives listed at the bottom of the
> >proposal
> >
> >   jdaggett: vertical-align controls the baseline, if other properties
> >             affect this, this makes me uncomfortable
> >   jdaggett: behavior of this feature dependent on this other value
> >   szilles: we've got other such cases
> >   szilles: property-refining properties are common
> >   plinss: it's a per-glyph undo of what vertical-align does
> >   fantasai: won't change the line box if you have the right glyphs
> >   jdaggett: font metrics aren't correct
> >   [plinss fantasai: talk re: vertical-align causes baseline change in
> >    even empty line boxes]
> >   plinss: as soon as you start nesting, you want to affect the line
> >height
> >   jdaggett: divergence between opentype spec and what fonts actually do
> >   jdaggett: i want to set this up for people who know how to use it,
> >             without breaking existing content
> >
> >   Bert: what happens if font has some of the special glyphs but not
> >others
> >   jdaggett: you'll synthesize
> >   jdaggett: colr won't match, stroke width will be different in
> >synthesized
> >             case
> >   szilles: if you don't have all the glyphs, synthesize everything
> >   plinss: if you don't have all the glyphs, pretend you have none
> >   fantasai: allow the UA to be smarter, but don't require complex
> >analysis
> >   jdaggett: wants to work on impl & experiment
> >   jdaggett: expects to see things we're not anticipating
> >   fantasai: that's a reasonable thing to do
> >   jdaggett: same fallback issue as with vertical text
> >   szilles: put a note in that points to the font feature with an
> >appropriate
> >            warning
> >   fantasai: we can do that in the line box spec
> >
> >   szilles: was strongly in favor of fantasai/dbaron's proposal, but sees
> >            point of @supports approach
> >   fantasai: author of stylesheet might not know what's in the content
> >   szilles: italic or bold isn't a problem
> >   Bert: magic property seems short; can it be keyword(s) of font-variant
> >         property?
> >   fantasai: might make sense
> >   jdaggett: tricky because font-variant is shorthand (reset problem)
> >
> >   szilles: can we put it in @font-face?
> >   florian: "this font supports being magic; use it if you can"
> >   fantasai: not tied to the choice of the font
> >
> >   fantasai: can we link to this email from the spec?
> >   jdaggett: would pefer note that says there are alternate proposals
> >   jdaggett: i have to try to impl this before we can do more
> >   fantasai: what other open issues are in this spec?
> >   fantasai: maybe we should defer this issue so spec can reach LC
> >   jdaggett: there are a number of issues
> >   jdaggett: is tightening the wording based on impl feedback
> >   jdaggett: wanted to make people aware of the issue & hear other ideas
> >   fantasai, Steve: i want to have this proposal findable from the spec
> >
> >Flexbox update
> >--------------
> >
> >   alexmog: in ie10 we have fairly complete impl of spec
> >   alexmog: for ie10 we won't have the new syntax
> >   alexmog: don't wnt two prefixed syntaxes
> >   alexmog: the timing isn't right for ie10
> >   alemog: for new spec, we want to see what other browsers are doing
> >   alexmog: we need to have multiline back in spec
> >   TabAtkins: will be bringing multiline back
> >   TabAtkins: webkit is working on impl of the new spec
> >   TabAtkins: will see that in the near future
> >   alexmog: if the spec stayed in the old syntax, we could drop prefix;
> >            but we don't need to reopen that
> >   dbaron: we [ff] also have someone working on the new spec
> >   sylvaing: any issues, dbaron?
> >   dbaron: haven't heard any, don't know how far along things are
> >   alexmog: we can map most of new syntax t old impl; biggest difference
> >            is using the flex function notation
> >   alexmog: would require parser change
> >   alexmog: different alignment too
> >   alexmog hopes feedback from other impls will help next version of spec
> >           stabilize
> >   sylvaing: flex nottion, alignment modes, multiline--want to see
> >             feedback from other implementors
> >   plinss: anything else?
> >   alexmog: whats' the eta?
> >   TabAtkins: wants to publish a new wd sometime by the end of June
> >   Tabtkins: hopefully ready for LC soon after that
> >
> ><br duration="15min" />
> >
> >Scribe: TabAtkins
> >
> >CSS Regions
> >-----------
> >
> >   vhardy: content-order is a float right now, which people say are odd -
> >           z-index is an integer, frex.
> >   vhardy: We did it that way so that you could, say, insert between two
> >           consecutive items.
> >   vhardy: But the precedent means we should just switch to <integer>s.
> >
> >   Bert: Is there any way to avoid using numbers at all?
> >   szilles: The regions aren't inherently ordered - they just pull
> >            whatever's in the stream.
> >   Bert: Why not push to a stream?
> >   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.
> >   vhardy: We sketched out some ideas for an @region-chain rule where
> >           you'd list the sequence of regions.
> >   Bert: That's similar to what I did with Template - a property that
> >         listed a chain of cells that content flowed across in order.
> >   szilles: That fails somewhat in paged media, where you can have
> >multiple
> >            copies of cells with the same name.
> >   vhardy: I also had an idea to have a region-name property that would
> >           name a region, but it didn't seem quite harmonious.
> >   vhardy: Can we agree on moving it to <integer> for now?
> >   RESOLVED: Switch content-order to take <integer>
> >
> >   vhardy: Another syntactic issue is that the 'flow' property uses
> >           <string> for value, and is referred to by a string.
> >   vhardy: So the question is should that just be an ident?
> >   szilles: Didn't we have a similar discussion in february?
> >   <arronei> Ident +1
> >   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.
> >   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.
> >   plinss: If it's guarded as a functional value, it's a bit better.
> >   szilles: I'd be afraid of it being a quoted string in 'flow' and
> >            unquoted in a function in 'content'.
> >   hober: Yeah, not doing that. Consistency.
> >   <arronei> Yeah but I don't want a flow to have a string like this.
> >             "{}{]}##<"
> >   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.
> >   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.
> >   TabAtkins: Another option is to make 'flow' take a to(<ident>)
> >              function for now, which pairs with the from(<ident>)
> >              function in 'content'.
> >   szilles: That sounds good.
> >   Bert: I'm not sure we need from(), and so to() seems unnecessary too.
> >   szilles: You definitely need from(), to disintiguish it from other
> >            values in 'content'.
> >   <arronei> Functions removes the issues if you want to add keywords
> >later.
> >   Bert: I'd need to familiarize myself with the syntax more, but
> >         'content' may not be the right place.
> >
> >   alexmog: Given that 'content' sets the contents to something other
> >            than the natural contents, it seems appropriate to use it
> >here.
> >   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).
> >   szilles: But that's another issue.
> >   [chatter about 'content' and potential 'flow-from']
> >   szilles: Wouldn't that mean I need to set two properties?
> >   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.
> >
> >   alexmog: We're afraid of author-defined idents colliding with future
> >            CSS-defined keywords, right?
> >   alexmog: I think from the OM model pov I'd prefer two properties that
> >            take strings than something that takes one-off functions.
> >   <arronei> I still prefer content: from(...) for it's simplicity.
> >   TabAtkins: Arronei dislikes strings because it becomes easier to write
> >              unreadable region names.
> >   szilles: You can write unreadable idents too.
> >   <arronei> But it's not as easy to do
> >
> >   Bert: Can we duplicate flow content across multiple regions?
> >   vhardy: That's an issue that was brought up on the mailing list.
> >   Bert: In previous approaches to this idea we named the flow
> >specifically
> >         to allow duplication. Newer approaches like Grid didn't need
> >that.
> >   [some difficult-to-understand discussion about being able to omit the
> >    name of the flow]
> >   Bert: template is naming regions, but not naming flows
> >   [moving it to the list so we can throw down syntax, because everyone's
> >    confused]
> >
> >   vhardy: Currently there's nothing about selecting the content in a
> >region.
> >   vhardy: User selections, that is.
> >   dbaron: A single selection usually operates in terms of the DOM.
> >   dbaron: Which could be confusing if you select across a region, and end
> >           up getting some content elsewhere in the page.
> >   dbaron: You could do a more visual-based selection, but no impl does
> >           that yet.
> >   plinss: I built a box-selection extension for Firefox that
> >auto-computed
> >           the ranges.
> >   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.
> >   szilles: What do we do with bidi right now?
> >   fantasai: We specify absolutely nothing for that right now.
> >   vhardy: Okay, so I'll remove the issue about selection from the spec.
> >
> >   vhardy: Next is about the event model.
> >   vhardy: Right now there's a section that says event propogation is not
> >           modified - it runs on the plain DOM.
> >   vhardy: But I've had some requests that you can listen for, say, clicks
> >           on a region.
> >   TabAtkins: I don't want to think about event propagation being
> >sensitive
> >              to exactly when we do style recalc.
> >   vhardy: Okay, so we'll keep it DOM-based.  Should I remove it entirely,
> >           or make it an informative note?
> >   TabAtkins: If people have asked you about it, so you should probably
> >              keep a note around.
> >
> >   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?
> >   TabAtkins: From an interaction 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.
> >   szilles: Is there a way to ask an element what region it's in?
> >   vhardy: That'll be in the CSSOM section.
> >   szilles: That seems to satisfy the rquirement.
> >
> >   vhardy: Now, the CSSOM View section.
> >   vhardy: It has two parts.  The first is the "named flow interface".
> >   vhardy: [explains the "named flow interface" section]
> >   vhardy: It's meant to allow you to see if the flow fits in the regions
> >           that exist.
> >   alexmog: Why do you have a "named flow" interface and not just a
> >concept
> >            of regions?
> >   vhardy: If you only have it on regions, you can only access regions
> >that
> >           are actually elements.
> >   alexmog: If you want that, then just add elements.
> >   szilles: That violates that "css zen garden" school of philosophy.
> >   TabAtkins: We can already interact with pseudos in at least some ways
> >              via the CSSOM.
> >   alexmog: I don't think it's necessary to extend the "Element" concept
> >            to pseudos.
> >   [...minute overflow]
> >
> >   alexmog: It's good to still have an event that tells when a region
> >changes.
> >   TabAtkins: Like when a region overflows?  Or more like a mutation event
> >              for contents in the region?
> >   alexmog: When the contents of the region changes.
> >   dbaron: What sort of changes do you want to know, exactly?
> >   alexmog: Whenever the contents change.
> >   dbaron: We already have onresize
> >   TabAtkins: I think what's useful is notification when a region goes
> >into
> >              overflow state and notification when a region becomes empty.
> >   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.
> >   alexmog: Yeah.
> >   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.
> >   vhardy: So I can put them all down in the spec for now, and we can see
> >           what exactly we want later.
> >
> >   vhardy: So next topic, how do we access regions?  Through an element,
> >           or through the flow?
> >   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.
> >   szilles: I tend to like the last one, because it ties into the Flow
> >            concept, which is primary.
> >   hober: I don't like the Element version, because it separates regions
> >          into first-class and second-class regions - DOM are first-class,
> >          pseudos are second-class.
> >   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.
> >   vhardy: I could fire events on the NamedFlow interface instead.
> >   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.
> >   szilles: We can just focus on Flows as a concept, rather than pseudos.
> >   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
> >           (4) full functionality for both pseudos and DOM
> >   vhardy: And this is kind of a requirements discussion.
> >   vhardy: I'd prefer 4, even though it's painful.
> >   alexmog: I think we should start with DOM and see how far we can go.
> >   TabAtkins: I think we'd be okay with functionality for DOM elements,
> >              plus a simple way to ask a flow if it's overflowing.
> >   TabAtkins: Basically, what's in the spec.
> >
> >   alexmog: If you duplicate a flow into multiple views, you can't get a
> >            single answer to "is the flow overflowing?".
> >   vhardy: Right now multiviews don't exist - they're talked about in an
> >issue.
> >   vhardy: So I'll keep it as it is right now, and put in an issue
> >regarding
> >           accessing the flow directly.
> >   vhardy: Next is about content duplication (multiviews).
> >   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.
> >   vhardy: Someone asked if there's a way to duplicate flow contents.
> >   vhardy: It would cause a lot of issues, though, so right now I suggest
> >           not doing it.
> >   fantasai: Wouldn't this let you do pullquotes?
> >   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.
> >   szilles: Another use-case is ToC.
> >   vhardy: For now, Regions is complex enough that I think we should skip
> >           it for now.
> >   plinss: I think it's appropriate to push it to Regions 2.
> >
> ><br type=lunch duration=1h/>
> >
> ><fantasai> jdaggett:
> >http://dev.w3.org/csswg/css3-writing-modes/#writing-mode

> ><jdaggett> hmmm, that's in an example
> ><jdaggett> that wording isn't strong enough
> ><fantasai> what is not strong enough about it?
> ><jdaggett> form elements are included in this list
> ><jdaggett> *normative* wording needs to say this includes form elements
> ><jdaggett> otherwise you give folks too much weasel room
> ><fantasai> form elements are either replaced, or they're not
> ><fantasai> if they're replaced, then that word applies
> ><fantasai> if they're not, then 'writing-mode' applies because it's CSS
> >layout
> ><fantasai> where's the gap here?
> ><jdaggett> well, we already have problems because css sorta affects them,
> >            sorta doesn't
> ><jdaggett> just do the right thing... ;)
> ><jdaggett> you understand and mean the sentence to mean xyz
> >
> >
> >ScribeNick: fantasai
> >
> >Scheduling
> >----------
> >
> >   Topic: Afternoon Agenda
> >   Discussion of agenda for this afternoon
> >   Florian: Would like device adaptation, should not take long
> >   Tab: I want variables
> >   that was what we agreed
> >   the normative text is above the two examples
> >   dbaron: would like to discuss @supports briefly
> >
> >   Topic: F2F Scheduling
> >   plinss: Proposal is to possibly add another F2F
> >   dbaron: Feels like we have a lot to do, and have a pretty crammed
> >           schedule here
> >   dbaron: Our summer meeting is at the early end, and the next meeting
> >           is a shortened meeting at TPAC
> >   dbaron: We have only TPAC for the next 9 months
> >   dbaron: So either we need another meeting, or significantly longer at
> >TPAC
> >   Vincent: Personally propose second meeting, gives us time to work
> >            on drafts in between f2f days
> >   some concern about people who have to travel
> >   jdaggett: Can't travel in September
> >   suggestion to do combined fx and css meeting in August
> >   plinss: Missing ppl who likely to have date conflicts
> >   Bert: I have some budget problem, unless I host it myself
> >   plinss: A lot of ppl would have trouble paying for another trip this
> >year
> >   plinss: unless we do Europe or Bay Area
> >   Alex: Could do 3 TPAC days plus another meeting
> >   dbaron: For the 2 TPAC days, we should assume one full day of CSSF2F
> >           amount of work
> >   fantasai: Likely options are West Coast or Europe to reduce budget
> >constraints.
> >   fantasai: Note TPAC is in bay area
> >   fantasai: Who's got budget constraints?
> >   Bert, Vincent maybe, Daniel probably, anyone else?
> >   Alex: For some ppl end of year is July 1st
> >   dbaron: Would be nice to know where TPAC and AC will be
> >   plinss: I'm hearing another meeting would be good, and adding a day
> >           to TPAC would be good
> >   RESOLVED: Add a day to TPAC
> >   RESOLVED: Try to schedule a meeting in August probably in Seattle
> >             or France
> >
> >Device Adaptation
> >-----------------
> >
> >   danield: On desktop browsers viewport is same size as the window
> >   danield: On mobile devices, that's not true.
> >   danield: You can force page to lay out at device width or arbitrary
> >width
> >   danield: So the veiwport meta tag is obviously a meta tag
> >   danield: One problem with this currently is it's not completely
> >specified
> >   danield: There isn't a full spec available to the public
> >   danield: undefined whether commas or semicolons used, e.g.
> >   danield: If I do this, it's viewable without zooming
> >   danield: The details .. Apple currently
> >   danield: The width can be in pixels or same as device width
> >   danield: Can also set scale, to not allow user to scale, so it behaves
> >            more like native app
> >   danield: but has accessibility problem
> >   danield: This W3C CSS spec CSS Device Adaptation effectively lays out
> >            what exists as a CSS specification
> >   danield: Benefit is it's an open spec, also it's not content it's
> >presentation
> >   danield: The syntax of it is [shows syntax]
> >
> >   jdaggett: What have Safari guys said about this?
> >   plinss: They said the meta tag is a hack and they'd like to get rid of
> >it
> >
> >   danield gives demos
> >   danield: We have prefixed demo in Opera
> >   jdaggett: So what would be the meaning of this for desktop browsers?
> >   danield: Probably nothing
> >   fantasai: where do you draw the line between desktop browser and
> >             non-desktop browser?
> >   plinss: I would think that any rules like this could be targetted
> >           with media queries
> >   jdaggett: It seems weird that you're implying that a desktop browser
> >             would blow these off
> >   danield: So maybe you'd show it at 320px and zoom in
> >   plinss: zooming could be a UI choice
> >   plinss: Might have other reasons to use this, e.g. someone might want
> >           to display their page as landscape paged
> >
> >   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
> >   dbaron: So they had to come up with this zooming thing
> >   dbaron: viewport meta was designed to allow pages to opt out of that
> >
> >   jdaggett: You're saying that it should be shown ...
> >   ?: That depends on the page design
> >   discussion of designing pages for mobile
> >   jdaggett: I don't think all pages that fit into the idea of designing
> >             for 320px
> >   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
> >   fantasai: And then the UA knows to display at minimum at that size and
> >             zoom out accordingly.
> >
> >   Florian: The iPhone's zoom and pan model is good for the Web as
> >currently
> >             designed.
> >   Florian: You can have a media query and design for the small screen
> >   Florian: But if you don't do that, then pan+zoom is better
> >   plinss: Most of the pages that use this meta tag have different content
> >   plinss: my mobile banking has mobile versions of their pages --
> >stripped
> >           down content
> >   plinss: wikipedia does the same thing
> >   Florian: It's valid to use this
> >   Florian: And it's valid to us min-width as fantasai said
> >   Florian: But one method is in use
> >   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
> >   danield: If I set the width of the root to 320, then I have all this
> >            blank space I scroll around in
> >   fantasai: That's kindof stupid then
> >   plinss: That's a bug. If there's nothing to scroll to, don't scroll to
> >it
> >   plinss: If you don't have overflow, you shouldn't scroll to it
> >   ?: Another issue is, if you do set the width of the root element, but
> >you
> >      have a long string that sticks out
> >   fantasai: then that's overflowing the ICB. You should be able to scroll
> >             to it, but it's outside the ICB.
> >   ...
> >   plinss: I'm concerned about having a zoom control in CSS
> >   danield: So author should not be able to turn off zooming?
> >   plinss: Why should I be *not allowed* to zoom in on a page?
> >   plinss: Designer designed page for my iPhone, but I'm old and I want
> >           to make it bigger. Why can't I do that?
> >   ?: First reason is you want to disable zooming gestures from zooming
> >      the page to use them for something else
> >   ?: Say you have a webapp inbox that's just a vertical column of
> >elements
> >   ?: If the user is allowed to zoom and pan, and therefore change the
> >width
> >      so that they can pan
> >   ?: then that changes the interaction with the app
> >   plinss: That's a usability issue, that's not something web page authors
> >           should be able to dictate
> >   ?: I think web page authors should be able to dictate
> >   Bert: But if they create a page that's unusable...
> >   plinss: Firefox zooms in and out on my desktop. Should I not be able to
> >           do that?
> >   dbaron: This is a different notion than the zoom in your desktop
> >firefox
> >   dbaron: Someone could add zoom like in desktop browser to a mobile
> >browser,
> >           but this is a different thing.
> >   plinss: Zoom is a UA thing. Not something the web author should be able
> >           to override and disable
> >   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
> >   plinss: That's not a CSS issue, that's an event model issue
> >   ...
> >   sylvaing: They also want to turn of user-selection, e.g. in a menu in
> >             their webapp
> >
> >   Florian: We think the spec is good and needs more review, so we want
> >            to do a WD
> >   dbaron: I think you should have something in the spec that answers
> >           John's question
> >   dbaron: The question is, what does this do on the desktop browser?
> >           (And what's a desktop browser)
> >   Florian: So do we do that as an editor's draft or what?
> >   fantasai: You have two options: address it in the draft, or mark it
> >             as an issue.
> >   Bert: 2 questions
> >   Bert: What's interactions of @viewport and @page
> >   Bert: If you put @viewport, can you put @viewport in @media? Say what
> >         it means?
> >   fantasai: would it make sense to have the media query in the @viewport
> >             directly?
> >   Florian: Question of when you match media queries, before or after
> >            processing @viewport
> >   fantasai: Similar to @page. Copy text from @page?
> >   dbaron: I'm not convinced this belongs in CSS; it really seems like
> >           a different layer.
> >   Bert: I would throw away pixel-sized viewports. Should never use pixel
> >sizes
> >   ? talks about dashboard widgets
> >   <dbaron> fantasai, I don't see text in css3-page that describes how
> >            'size' and media queries interact.
> >   ACTION: Rune add 3 questions above to draft
> >   <trackbot> Created ACTION-328
> >   Bert: I'm fine with publishing if there's red text making it's clear
> >         that there are issues
> >
> >   plinss: Yeah, just opening it up for discussion. Might decide not to
> >           do this, but need to discuss it
> >   dbaron: I'm 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
> >   dbaron: Would like document status to discuss status of the document
> >   fantasai: Problem is there's so much W3C boilerplate in the status
> >             section that nobody ever reads it
> >   <dbaron> <h2>Status of this Document</h2> should have a subsection
> >            called <h3>Status of <em>this</em> Document</h3>
> >
> >Variables and Mixins
> >--------------------
> >
> >   plinss: I would like to set a time limit on this discussion
> >   Tab: half-hour
> >   plinss: ok
> >   Tab: This is the draft I have right now.
> >   Tab: Variables is sth we've talked about for a decade
> >   <dbaron> http://www.xanthir.com/blog/b4AD0

> >   <shans> oh :)
> >   Tab: It's never gotten anywhere unfortunately, but it's more and more
> >        necessary as years go by
> >   Tab: Applications keep getting more complex
> >   Tab: CSS include more and more duplication
> >
> >   jdaggett: Don't think this is delayed due to desire to solve problem
> >   jdaggett: Just there's hard problems to solve
> >   Tab: Just want to make sure group wants to work on this
> >   Florian: Not sure that's the universal view
> >   Florian: Variables is a hard problem, but we've solved harder problems
> >before
> >   Florian: It makes things a little more difficult for authors to
> >understand.
> >   Florian: For the big guys, this is not necessary, because you have
> >            a backend system that can generate that on the fly
> >   Florian: For small ppl learning CSS from a book, this is likely
> >            to go way over their head.
> >   Florian: It gives some convenience, but doesn't allow anything new.
> >   Florian: Things that this simplifies can be done on the server side
> >   Tab: I think your concern about small authors being confused is
> >totally wrong.
> >   Tab: If you're doing minor page of few hundred lines, you won't need
> >this
> >   Florian: But you'll see it anyway
> >   ...
> >   Sylvain: If you think CSS is easy, you're crazy. Cascading and
> >            inheritance is hard
> >   ?: Variable declarations are easy to understand.
> >   Tab gives example of modifying a color everywhere.
> >   <sylvaing> (meaning it's 'crazy' to say CSS is easy until this
> >               capability is added)
> >
> >   Alex: We have 3 issues
> >   Alex: 1. There are reasons for variables.
> >   Alex: 2. Hard problems for variables
> >   Alex: 3. What Tab is proposing
> >   Bert: Different people may want different things from variables.
> >   fantasai: If you look at a real CSS preprocessor, it does a lot of cool
> >             stuff. I'm concerned about going down that path.
> >
> >   Tab summarizes his proposal.
> >   @var $main-color blue;
> >   p {
> >     color: $main-color;
> >     background: url(foo) $main-color;
> >     list-style-image: radial-gradient($main-color, $secondary-color);
> >   }
> >   Tab: Not allowed to define cycles, but allowed to use variables within
> >        variable declarations
> >   Tab: Variables are global
> >   Tab: last declaration wins
> >   Tab: Not expanded as parse time
> >
> >   Florian:
> >     a = foo
> >     b = a
> >     a = bar
> >   Florian: What's b?
> >   Tab: bar
> >   Alex: What about naming conflicts, e.g. if I import a style sheet that
> >         uses the same name I'm using
> >   ?: You want your variable names to be conceptual.
> >   ...
> >
> >   dbaron: One thing ppl wanted with variables was ability to change them
> >           dynamically later on from JS
> >   dbaron: If you want that, I don't see how to have the later set
> >           overrides the earlier set.
> >   Tab: This is consistent with defining identifiers in an at-rule
> >   Tab: e.g. with @font-face
> >   jdaggett: This is actually wrong. If you look very carefully, we have
> >             a unicode-range.
> >   jdaggett: The presence of that means what you just said is not correct
> >   jdaggett: For a single set of @rules, you can have multiple fonts.
> >             You can have multiple @font-face rules
> >   dbaron: @font-face rules are mostly additive, rather than replacing
> >   jdaggett: They will have a computed unicode-range, which is the
> >             intersection of the actual unicode-range and the cmap
> >   dbaron: And it also depends on whether the font can be loaded
> >   dbaron: @font-face is the worst possible example you could have picked
> >
> >   Florian: Even though you define how collisions are resolved, you still
> >            get them and you reduce the shareability of CSS
> >   Tab: Ok, that I can agree with that. If you're creating a library then
> >        you have that issue.
> >   Tab: One way to deal with that is if you're creating a library,
> >        prefix your names.
> >   Tab: Another option is a namespacing option
> >   fantasai notes that the CSS Namespaces module's syntax could be reused
> >            if it came to that...
> >   <fantasai> not that I think we should go there
> >   discussion of other author-defined names in CSS: counter-style,
> >     keyframes, etc.
> >
> >   Tab: Having functionality of having variables that can refer to other
> >        variables is great
> >   fantasai: do you need that for JS-accessible variable,s or just for
> >             macros variables (parse-time substitution)
> >   dbaron: If you have a parse-time substitution mechanism, you have a
> >           lot more constraints wrt scoping
> >   dbaron: That requirement slows down how you load and parse style sheet
> >   dbaron: depending on the scoping rules
> >   fantasai: scoping rules in my proposal don't have that problem
> >
> >   Tab: undeclared variables are treated as invalid values until resolved
> >   Tab: Another reason to work this way is you want this out-of-orderness
> >   Tab: CSS works so that you can almost reorder style sheet arbitrarily
> >        without changing things.
> >   Tab: Usually resolve things based on specificity, not order
> >   Tab: This trained us to import style sheets in any order, append
> >        things to document
> >   Tab: Preserving that with variables
> >   Tab: e.g. throw in corporate styles anywhere in include path of doc,
> >        won't affect how things are parsed
> >   dbaron: resolved dynamically
> >   Tab: Covered multiple variables with same name, last one wins
> >   Tab: If you import a style sheet after the doc loaded, it gets
> >        processed same way as if they were in from the start
> >   Tab: If you use a variable that's not defined, it's treated as always
> >        invalid
> >   Tab gives example
> >   fantasai suggests to make the examples use green/red consistently with
> >            the test suite conventions
> >   Tab: bzbarsky suggested it still be valid, but be set to the inital
> >state
> >   dbaron: ...
> >   fantasai: p { color: red; } p { color: $foo } should always, always
> >             be equivalent to p { color: red; color: $foo; }
> >   <dbaron> I think it's important that "p { color: green} p { color:
> >$foo }"
> >            does the same whether $foo is undefined or invalid.
> >   <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.
> >
> >   Tab reviews dependency cycle breaking
> >   @var $foo red;
> >   @var $bar $foo;
> >   @var $foo $bar;
> >   Tab: You would get $foo as red
> >   dbaron: I would rather throw out the whole thing.
> >   <dbaron> throw out $foo rather than use red for $foo
> >   Tab: Ok, crash both variables in the cycle
> >   dbaron: The cycle detection should be after you've parsed all the
> >variables
> >           and thrown out previous definitions.
> >
> >   Tab: Some concern about grammar
> >   fantasai: I would prefer using glazou's syntax of var()
> >   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.
> >   fantasai: And you can prefix it if you use functional notation
> >
> >   Tab: Want to know if we can start doing experimental implementations
> >of this.
> >   Tab: Management wants to know if we are approved to work on variables.
> >   Tab: Start work on an editor's draft that could move to WD
> >   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.
> >   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.
> >   dbaron: Given the amount of work it is, and it doesn't give authors
> >           anything really new
> >   dbaron: I would not put this near the top of any priority lists.
> >   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
> >   Florian: It lets fewer people write CSS faster.
> >
> >   ...
> >   fantasai makes a comment about other ppl's preprocessor stuff being
> >really
> >            intelligent and us being the wrong people to work on that
> >level of
> >            syntactic sugar
> >   Bert: Could make a Community Group
> >   Tab: ... besides the point ...
> >   Alex talks about priorities of different vendors
> >   Bert: SVG is also working on something like this, the parameter model
> >   Bert: They have variables that you can inherit from outside the style
> >sheet
> >   Alex: What Doug has is a superset of that
> >   Tab: They could potentially work together
> >   Alex: Initial values of variables ...
> >   Tab: No problem working together with schepers
> >   jdaggett: I still 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"
> >   Tab: Looking for explicit acceptance that if I work on this and address
> >        issues, it /can/ get to WD.
> >   Florian: I'm not convinced that any variable system can bring more than
> >            it costs.
> >   <shepazu_vacation> (I am very flexible about how we get parameters
> >                       working for both SVG and CSS)
> >   Tab: Are you ok with me pursuing this in WD form until we can decide
> >        whether it's worth doing?
> >   Florian: Not authorized to say.
> >
> >   Florian: I look at this: it's too much and not enough.
> >   ... JS ...
> >   jdaggett: That's a good point. Maybe modifications to the CSSOM is a
> >             better use of time.
> >   talk of other important things
> >   Alex: It's a stake in the ground, when we talk about variables, this
> >         is what variables mean.
> >   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.
> >
> >   plinss: Let me try to sum up here.
> >   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.
> >   plinss: I don't think anybody can guarantee it's ever going to go
> >anywhere.
> >   plinss: Might be where we gather all the data and then kill it.
> >   plinss: As soon as I write a style sheet, I want this capability.
> >   plinss: As soon as I think about the implications of this capability,
> >           I want this to stay away.
> >   ?: From an implementers perspective?
> >   plinss: No. From authors perspective even.
> >   plinss: Your argument that variables would make things harder to read,
> >           I think it will make them much easier to read.
> >   plinss gives an example
> >   plinss: But when you start getting into what does this do when I change
> >           this, what does this do when I change that.
> >   plinss: For implementers, we can figure this out and solve it.
> >   plinss: But for authors it will be hard to figure out.
> >   plinss: Why did this break everything all of a sudden? i think this
> >will
> >           make things harder to understand.
> >   ...
> >   plinss: You can't do this proposal in a preprocessor, it has to be done
> >           at run-time in the client.
> >   plinss: That's a whole different class of problems.
> >   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.
> >   plinss: So my conclusion is that you can put this in an editor's draft,
> >           but there's no guarantee it will go anywhere.
> >   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
> >   plinss: Maybe doing this in CSSOM extensions would be a better idea.
> >   RESOLVED: Allow Tab to work on a css3 variables editor's draft,
> >             no guarantee we'll move it to WD
> >
> ><br duration="15min">
> >Quote of the Day -
> >dbaron: If your well-defined rules for handling that take less than 50
> >         pages, you don't have well-defined rules.
> >
> >@supports
> >---------
> >
> >   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
> >   plinss: because you have interdependent properties
> >   dbaron: I think this is going to become a particularly big issue as
> >           we add new layout systems
> >   fantasai: Does anybody not understand the problem we're solving?
> >   <silence>
> >
> >   <dbaron>
> >http://lists.w3.org/Archives/Public/www-archive/2011Jun/att-

> 0002/Overview.
> >html
> >   dbaron: first, want to add support for testing for property-value pairs
> >   dbaron: It's a very simple thing. It gives you ability to test for
> >           properties and for values
> >   dbaron: A little extra work if you just want to check a property,
> >           but probably a good thing [...]
> >
> >   dbaron: I think there's a strong use case for conjunction, disjunction,
> >           and negation
> >   dbaron: i.e. not/and/or
> >   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
> >   dbaron: and for combination of features
> >   dbaron: or is needed mainly for prefixed properties
> >   dbaron: Came up with syntax similar to media queries
> >   dbaron: but has a few differences
> >   dbaron: Media queries don't let you group operators in arbitrary ways
> >   dbaron: So the syntax here allows combining in any nesting level, but
> >           requires parentheses
> >   dbaron: can have a and b and c, but not a and b or c
> >   dbaron: So no precedence rules
> >   dbaron: Also, I didn't use commas or spaces, you have to write out
> >           the keywords
> >   dbaron: and then you have (property: value)
> >   jdaggett asks about the 'not' case
> >   ppl give examples
> >   won't be useful in the near future, b/c we don't have support for
> >@supports
> >   but in the future it will become important
> >
> >   discussion of @import in @supports
> >   dbaron: Would like @import stay at the top
> >   <dbaron> could have supports() function part of @import rule
> >   ...
> >   plinss: Makes sense to have a supports check on @import, can figure
> >           out exact syntax later
> >
> >   dbaron: There's a couple other things in this draft
> >   dbaron: Another is something according to plinss has been discussed
> >           12 years ago, which is @media inside @media
> >   dbaron: In 2.1, @media can only contain rulesets, not other @rules
> >   dbaron: So I'm saying that @media can contain any @rule that can be
> >           interleaved with rulesets
> >   dbaron: So it redefines @media with that definition
> >   dbaron: then defines @supports
> >
> >   dbaron: and then a third proposal, that's been floating around for
> >           not quite a decade
> >   dbaron: primary use case for this is user stylesheets
> >   dbaron: @document
> >   dbaron: Not sure how important to standardize, but I've heard some
> >           interest in it
> >   Alex gives a use case for using that in @import
> >   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
> >   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
> >   Alex: They have 2-3 times more rules than necessary for the page
> >   Alex: Slows down downloading, selector matches, etc.
> >   Bert: Might want it all to be cached
> >   Alex: ...
> >   Alex: We've seen sites that can be improved dramatically by just
> >         shrinking their style sheets, among other things.
> >   Alex: If they could write instead of complicated selectors, they could
> >         write for this area of my site I'm loading this set of style
> >         sheets, and for that area use this set
> >   Bert discusses extra HTTP requests as another factor, not convinced
> >        this will help on @import
> >   jdaggett: Sounds like you're looking for something to solve a problem
> >             that isn't necessarily a problem, just more an organizational
> >             problem
> >   Alex: Def not my problem, I think when ppl see this functionality it's
> >         something they will ask for
> >   Florian: If you have @document but not on @import, you can still get
> >            selector-matching benefits
> >
> >   Florian: So there seem to be several valid use cases for this
> >   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
> >   dbaron: The parsing is not that bad, because I required parens around
> >           every prop:value pair, but not more than necessary
> >
> >   danield: I'm concerned about the syntax being different from Media
> >Queries
> >   dbaron: I think Media Queries did it wrong
> >   dbaron: Also I think this is a strict superset of Media Queries,
> >           except for the comma
> >   dbaron: I think the comma is confusing, because people don't know
> >           whether it's "or" or "and"
> >   jdaggett: Could add "or" to Media Queries
> >   plinss: So a question of when can a UA legally claim it supports
> >something.
> >   fantasai: That's defined in the Snapshot
> >   dbaron: Ok, I could reference that
> >   fantasai: or copy the text
> >   ...
> >
> >   jdaggett: SVG has the idea of capabilities, and it turned out to not be
> >             very useful because of the problem you're talking about
> >   plinss: It's a useful feature, but can be abused
> >   dbaron: Part of the problem with SVG is that they tried to define sets
> >           of features.
> >   dbaron: With adding support for values, CSS implementations have been
> >           pretty good at not parsing new values until they actually
> >support
> >           them
> >   dbaron: because of the known fallback where authors want the fallback
> >   dbaron: So I think property:value pairs is the right level to do this
> >   dbaron: It won't work perfectly, but most implementations will do it
> >           right most of the time
> >   Florian: I think only time UA will lie about it on a site-specific
> >basis
> >   Florian: there are sites that block us (Opera) because they think we
> >            don't support things we do
> >   plinss: I think we should put a stake in the ground that UAs must not
> >           lie about this.
> >   jdaggett: We could also put in wording about passing tests in the test
> >suite
> >   fantasai: already in the Snapshot wording
> >
> >   Florian: Can this test for support for @variables
> >   Several: Stop.
> >   plinss: Can we test for @rules? And is that useful?
> >   dbaron: @font-face is the only case where I see a use for this
> >   jdaggett: All of Tab's animation stuff, I don't want that in this
> >   plinss: Paged Media 3 adds 16 new @rules for margin boxes
> >   dbaron: One of the nices things about property-value pairs is that we
> >           already have code for parsing them.
> >   dbaron: @rules are much more context-dependent, so you'd almost have
> >           to have a separate @support parsing list
> >
> >   dbaron: So if we want this, we should make sure it's in the new charter
> >   Bert: The scope is wider than just the list of modules, so no problem
> >here.
> >   dbaron: So other issue is what to call it
> >   fantasai: css3-if :)
> >   <hober> "CSS3?"
> >   <fantasai> hober, @media is in 2.1
> >   dbaron: Currently calling it css3-conditional
> >   plinss: so I'm hearing consensus that we want this
> >   dbaron: So "CSS Conditional Rules" aka css3-conditional?
> >   fantasai: And Bert's bibliography can call it [CSS3IF] :)
> >   dbaron: Ok, I'll put this in dev.w3.org, do some editing, and then ask
> >for WD
> >
> >   Bert asks why @document isn't a selector
> >   several don't like this idea
> >   doesn't allow grouping
> >   and doesn't help as much with selector matching performance
> >   dbaron: Also makes it easier to allow user style injection
> >   dbaron: So we can have UI for site-specific styles, and we just stick
> >it
> >           in the @document {} rule
> >   RESOLVED: Add css3-conditional
> >
> >   danield: How do we add "or" to Media Queries?
> >   fantasai: Need to start a new draft, since MQ is closed to new
> >             features already
> >   dbaron: Might want to start that new draft in the next 2 years,
> >           we have some other features to add, too
> >
> >Mixins
> >------
> >
> >   Tab: These are basically the same thing, this is variables 2.0
> >   Tab: Mixins, rather than being single values that you then use in
> >        properties, they are declaration blocks you mix into other
> >        declaration blocks
> >   Tab: Simple example, declare a mixin like this
> >   Tab gives an example
> >   <hober> http://www.xanthir.com/blog/b4Av0

> >   jdaggett: So this is closer to preprocessing
> >   Tab: What's very useful here is the ability to parametrize them
> >   Florian: Are nonprogrammers going to understand that?
> >   jdaggett: Why do we need to use the variable syntax?
> >   Tab: Similar concept here
> >   jdaggett: But the functionality is distinct, how it works
> >   jdaggett: If you have variables in your mixin, there are two things
> >             that you're jumbling together
> >   jdaggett: essentially local variables and global variables
> >   fantasai: How is this different from my proposal, aside from
> >parameters?
> >   Tab mashes around some words and doesn't answer the question
> >   fantasai: So, what question are you actually answering, and what's the
> >             answer to it?
> >   <hober> fantasai's proposal:
> >http://fantasai.inkedblade.net/style/specs/constants/

> >   bunch of discussion
> >   simultaneously
> >   Sylvain: "Can we have one discussion at a time?"
> >   Tab: Aside from naming issues, this is something we want to pursue
> >        experimentally
> >   <dbaron> (participant in one of the other two discussions): "No."
> >
> >   fantasai asks for use cases for putting all this in the DOM and
> >allowing
> >            JS to manipulate it
> >   ??: debugging
> >   Alex: ... multiple inheritance ...
> >   Alex: If we compare this to programming language, it's a really bad
> >idea
> >   Tab: It's different.
> >   Alex: really bad usage of multiple inheritance, trust me it's possible
> >   ??: You've got a bunch of rules and a very clear set of resolution
> >
> >   fantasai: I'd like to understand why this proposal is better than mine,
> >             that we should use this and not that
> >   Tab: parameters
> >   Tab: and global scoping
> >   fantasai: mine has a parameterization mechanism, just different
> >   Tab: I think global scoping is simpler and matches what authors expect
> >        from the language
> >
> >   Tab: So do people want to go forward or hate it?
> >   Alex: I hate it
> >   plinss: I _really_ hate it
> >   Tab: Useful for authors, using it in their preprocessors
> >   fantasai: So use it in the preprocessors.
> >   discussion of how preprocessors work and debugging tools work
> >   Tab argues that debugging is better when you have mixins in the browser
> >   plinss: I think this is a failure in your debugging toolchain
> >   random unminuted comments
> >   and bad jokes
> >
> >   dbaron: I have a CS professor
> >   dbaron: whose comment was that Knuth attempted to make TeX not a
> >           programming language, and failed, and so it is a bad
> >           programming language
> >
> >   Florian: You asked if some people hated it, and the answer is yes.
> >   ??: Reuse is good for the Web, it's good for the authors, not manually
> >       preprocessing things.
> >   Florian: The good thing about manually preprocessing is that you know
> >            exactly what's going on
> >   plinss: There have been other proposals that are more CSS-like and
> >           not programming-language-like
> >   plinss: That's another thing
> >   plinss: Your fundamental question was is there a strong objection,
> >           and the ansewr is yes, there is a strong objection.
> >   plinss: I'm not hearing anybody supporting this except you [Google]
> >guys.
> >   Vincent: I'm not objecting. I'm sympathetic to their arguments.
> >   jdaggett: There's a level of complexity that's here. You're adding
> >             complexity and also solving problems. You have to balance it.
> >
> >   danield: If it was just a plain text-replace, I'd be more comfortable
> >            with that
> >   Tab: But CSS is global scope for everything
> >
> >Nesting
> >-------
> >
> >   Tab: Once again drawn from preprocessors
> >   Tab summarizes his proposal, see www-style posting
> >   fantasai: what happens if you forget the & ?
> >   Tab: It's an invalid selector. Selectors inside this scope must start
> >with &
> >   <sylvaing> if you define the nested & selector in an @mixin you'd have
> >              to resolve your @mixin at parse time....
> >   <hober> Tab's nesting proposal:
> >           http://lists.w3.org/Archives/Public/www-style/2011Jun/0022.html

> >   plinss: What if the original selector has a comma
> >   fantasai: equivalent to replacing the & with :any()/:matches() with
> >that
> >             selector as its argument
> >   fantasai: (using a full implementation of :matches())
> >
> >   fantasai: why ampersand?
> >   Tab: Looking for something terse that's easily recognizable
> >   fantasai: How about using a question mark?
> >   Tab: could work
> >   several ask if it has to be punctuation
> >   plinss: need to distinguish it from a property
> >
> >   Alex: Can you do anything with this that you couldn't before?
> >   Tab: purely syntactic sugar
> >   plinss: better maintainability
> >   <hober> h1, h2, h3, h4, h5, h6 { & a {}}
> >
> >   Tab: So, I would like to pursue this.
> >   Tab: There are some problems that need to be worked on
> >   Tab: There's a combinatorial problem here. The author can easily
> >        write a lot of rules that have to kept track of
> >   Tab: This ability is simple. I just explained everything.
> >   Tab: Out of everthing I talked about so far, only one that can be
> >        entirely done in preprocessor
> >   Tab: But it's a huge win for maintainability
> >
> >   Alex: What will the adoption picture be for this, when there is
> >         nothing you can do with this for a long while
> >   Tab: Yeah, there's no fallback
> >   Tab: You'd have to do preprocessor for now.
> >   Alex: Something that like this improves readability but also
> >         enables nothing new...
> >   Alex: you have to still do this in separate style sheets. Have
> >         new style sheet and old one
> >   ?: we've written a JS that will do the processing in JS, might
> >      be good interim solution
> >   plinss: could also do an apache plugin or something
> >
> >   plinss: What does this do to the CSSOM
> >   Tab: Relatively simple change.
> >   Tab: Add ... to ...
> >
> >   discussion of parsing in downlevel UAs
> >   Tab: You have to put them at the bottom of the rule block
> >   sylvaing: or put a semicolon at the end of each block
> >   fantasai: Rather restrict it to one or the other, otherwise it's
> >             confusing and people will get it wrong
> >   Tab: Happy to just require putting them at the end of the style block.
> >        I think it's more readable that way anyway
> >
> >   Bert raises issue of the Core Grammar
> >   Tab: But plays well with forward-compatible parsing
> >   Bert: But we're not supposed to change the Core Grammar
> >   plinss: Almost anything we add that's new is ...
> >   dbaron: The grammar in syndata.html is very general, and Bert is
> >           saying that new stuff has to match that
> >   foo {
> >     prop: val;
> >     @nest:hover {
> >       prop: val;
> >     }
> >   }
> >
> >   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
> >   fantasai: One advantage of the @nest is that it looks more like a
> >             regular selector, where you make this distinction already.
> >             With the & it's so short, it's easier to not notice the
> >             space distinction.
> >   Bert: Would be easier to not use ampersand in cases where the space
> >         is there, so it's more different
> >   Tab: But then you start parsing it like a property
> >   fantasai: I think Bert's suggestion is much better-looking.
> >   This is agreed, but it still creates a parsing problem.
> >
> >   Discussion of Tab's priorities
> >   Tab: List, images, flexbox
> >   Tab: want to work next on positioning to make it editor's-draft ready
> >   Alex: Which positioning?
> >   Tab: Firming up abspos model, and then adding ability to attach edges
> >        to edges of other boxes
> >   Tab: We put together a newsread app that's really slick, 3 cols of
> >stories etc.
> >   Tab: It was ridiculously hard to do in JS or CSS.
> >   Tab: We wound up absposing everything and using a constraint solver in
> >JS
> >   Bert: I think abspos was a huge mistake
> >   Tab: I agree that what we have in CSS2 is minimally useful
> >   dbaron: I think it's harmful
> >
> >   back to Tab's proposal
> >   plinss: I really like this feature
> >   plinss: that's my 2cents
> >   plinss: I accept it's a problem that it can't be used until universally
> >           supported
> >   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)
> >
> >   Tab: So should I work on this?
> >   Nobody seems to be objecting, but only Tab and plinss seem to be
> >enthusiastic
> >   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.
> >   <dbaron> I think it's not crazy; I'm scared of the OM implications.
> >            Doesn't seem like an implementation priority.
> >   Alex: not committing to do this, will be pretty far down in priority
> >list
> >   Alex: Think there's value in writing up what syntax could look like
> >   Alex: In right combination with other features, could be useful
> >   fantasai is concerned about prioritization of WG attention
> >   plinss: I'm hearing a conditional yes, that it's low priority, doesn't
> >           impact other work, no guarantee of implementation
> >
> >Selectors 4
> >------------
> >
> >   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.
> >   fantasai: I added a couple of things I felt were fairly
> >uncontroversial.
> >   <sylvaing> http://dev.w3.org/csswg/selectors4/

> >
> >   fantasai: Main things is :matches() (sometimes called :any()).
> >   fantasai: It means "an element which matches my argument".
> >   fantasai: And :not() is the opposite.
> >   fantasai: The argument is an arbitrary selector without combinators.
> >   fantasai: So :matches(foo,bar,baz) is fine, but :matches(foo > bar)
> >             is not, because that gets into branching issues.
> >
> >   fantasai: I've also added in an old proposal for choosing the
> >"subject" of
> >             a selector.
> >   fantasai: So, frex, in "ol > li:only-child", you may want the <ol>
> >itself.
> >   fantasai: You can write "!ol > li:only-child".
> >   florian: That reminds me of "not".
> >
> >   fantasai: I've also tightened up some terminology.
> >   fantasai: "simple selector" is the same as before.  "compound selector"
> >             is the previous "sequence of simple selectors", without
> >combinators.
> >
> >   sylvaing: Do you have anything about pseudoelements with
> pseudoclasses
> >in it?
> >   fantasai: I haven't touched that yet, but I think the pseudoelem should
> >             specify what pseudoclasses can apply to it.
> >
> >   fantasai: Another new feature is :dir([rtl | ltr]), which is the same
> >             as the older suggestion for :ltr/:rtl, but more consistent
> >             with :lang().
> >   fantasai: I also believe we should pull in the various pseudos that
> >             HTML5 defines, because they should be defined on our side.
> >   fantasai: And then HTML can just clarify what they apply to for HTML,
> >             rather than *defining* them.
> >
> >   fantasai: Here are some other features people have requested for
> >Selectors.
> >   <fantasai> http://wiki.csswg.org/spec/selectors4

> >   fantasai: A lot of which I think are very cool.
> >   fantasai: I think for now I just want to add the "current url"
> >selector.
> >   fantasai: And then publish as WD?
> >   Bert: I think we're done with Selectors for a while.
> >   florian: One comment from Opera, under the impression that :matches()
> >            was the only new thing, we're okay with it.
> >   Bert: Shouldn't the HTML5 pseudoclasses be in the UI module?
> >   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 e.g. UI just for
> >selectors-using
> >             stuff.
> >   [discussion about naming]
> >   Bert: We shouldn't do any specs in level 4 until we've done everything
> >         in level 3.
> >   Peter: We've agreed to level modules independently.
> >
> >   vhardy: Why isn't the module's shortname "css4-selectors"?
> >   fantasai: We determined a while ago that Selectors aren't CSS-specific,
> >             and the level 3 name was a historical mistake.
> >   RESOLVED: Move forward with Selectors 4
> >
> >Module Template
> >---------------
> >
> >   sylvaing: in recent snapshot we updated the rules for when impls
> >             can drop prefixes
> >   sylvaing: let's update the spec template to match the snapshot
> >   <fantasai> http://www.w3.org/TR/css-2010/#experimental

> >   <fantasai> http://dev.w3.org/csswg/css-module/#conformance

> >   fantasai: A related issue is that most of our modules don't follow
> >             the latest template, which has new text and boilerplate.
> >Scribe: Tab Atkins
> >   sylvaing: When are we going to start doing this?
> >   fantasai: How about right now?
> >   TabAtkins: I can fix my modules to use the new boilerplate soon.
> >   vhardy: Can we get the preprocessor to handle this for us?
> >   fantasai: Some parts, yes.  Sounds good - Bert and I will update
> >             the template and work on this.
> >   RESOLVED: Update all modules to the latest module template, once
> >             Fantasai has checked in the necessary edits.
> >   ACTION fantasai and bert to update the preprocessor template to
> >          match boilerplate.
> >   <trackbot> Created ACTION-329
> >
> >Test Suite Owners
> >-----------------
> >
> >   sylvaing: Given all the specs we're doing, should each spec have a
> >             "test owner" that tracks tests and determines coverage and
> >such?
> >   fantasai: That sounds like a wonderful idea.
> >   florian: The only problem I have is that having a test owner will make
> >            the editors not care about tests.
> >   sylvaing: That's today's situation. ^_^
> >   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".
> >   RESOLVED: Establish official "test owner" position parallel to the
> >editor,
> >             who is responsible for ensuring the correctness and
> >completion
> >             of the test suite
> >
> >text-overflow
> >-------------
> >
> >   fantasai: There was a string value for text-overflow that let you
> >             specify what ellipsis you wanted.
> >   fantasai: Moz has an impl of this.
> >   fantasai: There was also a proposal to have two values.
> >   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.
> >   fantasai: So the proposal is to let it take two strings (left and
> >right)
> >             in addition to one string (both).
> >
> >   vhardy: We have a similar issue with CSS Regions, where we want
> >something
> >           like a "(cont)" at the bottom of each region.
> >   fantasai: We've had a proposal for a 'block-overflow' to handle that
> >case.
> >             It doesn't live in any spec yet.
> >   vhardy: I'll put it into Regions for now, just to give it a place to
> >live.
> >   alexmog: The feature gets significantly more complex if you want
> >            references and back-references "(cont on page 5)".
> >   fantasai: Yes, but it's not needed for inline overflow
> >
> >   dbaron: Another issue is that we're implementing it unprefixed, because
> >           everyone else already has.  That's... an issue.
> >   plinss: Not happy about the unprefixed, but I understand the position
> >           you're in.
> >   RESOLVED: Add the two-value syntax to text-overflow in css3-ui,
> >             marked at-risk
> >
> >Regions
> >-------
> >
> >   vhardy: There's a question of integration with other specs.
> >   vhardy: The issue is that, to use something as a region, it needs to
> >           be addressible in some way.
> >   vhardy: Like a grid-cell, so you can use 'content' or 'flow-from' on
> >it.
> >   vhardy: This works with Grid Layout, because there's a pseudo for it.
> >   vhardy: But there's none for multicol and flexbox.
> >   vhardy: There's no way to address a column box in multicol.
> >   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.
> >   alexmog: Sounds like an exclusion.
> >   vhardy: Or putting alternating content in columns.
> >   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.
> >   vhardy: The question is if we want to integrate more closely into the
> >           multicol.
> >   alexmog: Multicol is the only exception here.  Grid was carefully
> >            designed so that it would size the same as column.
> >   TabAtkins: I think I must agree with alexmog.  It makes more sense to
> >              flow into grid cells than to flow into multicol column
> >boxes.
> >   alexmog: And you can use, say, region styling to say "this region
> >should
> >            have 'columns:3'".
> >   vhardy: Okay, no column boxes as regions.
> >
> >   vhardy: next is, what is a grid cell exactly?
> >   vhardy: There's a grid-cell-stacking property, and an issue that
> >           questions whether it should instead be 'display'.
> >   hober: I agree with whatever Hyatt last said.
> >   TabAtkins: I think Hyatt said he liked the 'display' version.
> >              I also strongly support it.
> >   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.
> >   alexmog: But it makes sense to do so.
> >
> >   fantasai: [separate note] I think it makes sense to limit it to only
> >             pseudoelements being regions, not elements.
> >   vhardy: There was some discussion on that on the mailing list.
> >
> >Gradients
> >---------
> >Scribe: fantasai
> >
> >   sylvain: When you say bottom left for the corner
> >   fantasai: Animating keyword sides/corners through 0deg makes the
> >gradient
> >             spin through the longest path instead of the shortest path
> >   Tab: Oh, yes. I will fix that in the spec
> >
> >   fantasai: Next issue was direction of 0deg and direction of increase
> >   fantasai: We posted to css3.info to ask for feedback from authors
> >   <fantasai> http://www.css3.info/angles-in-gradients/

> >   fantasai: got 95+ comments, overwhelming majority, as you can see,
> >             was for C which is bearing angles (zero degrees up)
> >   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.
> >   plinss: There was a small minority asking for 0deg to the right,
> >           increasing counter-clockwise.
> >   Noted that Brad objects to bearing angles
> >   RESOLVED: gradients use bearing angles
> >
> >   <sylvaing> a gradient angle value e.g. 30deg is the end point of a
> >              gradient line
> >   <sylvaing> however, an angle keyword e.g. top is the start point of
> >              the gradient line
> >   Tab: ¿?¿?
> >   <sylvaing> this is somewhat confusing, especially once one starts
> >              transitioning linear gradients
> >   <Bert> (If it is a direction, why isn't it called 'up' instead of
> >'top'?)
> >   <Bert> (Or maybe north, nnw, nw, wnw, west....)
> >   <dbaron> the allowed keywords should just be 东, 西, 北, 南, 東, 东北,
> >            西北, 東北, 东南, 西南, 東南 :-)
> >   <fantasai> Bert, it means "attach my gradient to the top edge and
> >              then draw from there"
> >   <danield> So maybe 0 deg should also mean "attach my gradient to the
> >             top edge and then draw from there"
> >   Florian: The cardinal directions map directly to degrees.
> >
> >Charter
> >-------
> >
> >   dbaron: associating expected status and priorities in the charter
> >           doesn't make sense
> >   RESOLVED: that the charter lists should be organized not by "priority"
> >but
> >             by what status we expect specs to reach by the end of the
> >charter
> >   And the sections then need some severe editing
> >
> >   Specs expected to reach REC:
> >   - css3-background
> >   - css3-values, maybe
> >   - css3-ui
> >   Specs expected to reach CR:
> >   - css3-fonts
> >   - css3-2d-transforms
> >   - css3-animations
> >   - css3-writing-modes
> >   - css3-text
> >   - css3-images
> >   - css3-lists
> >   - css3-flexbox
> >   - css3-transitions
> >   - css3-speech
> >   plinss: multicol?
> >   fantasai: If we are planning to test whether things paginate across
> >             columns correctly, no, not REC.
> >   fantasai: If we're only testing whether you calculate columns
> >correctly,
> >             then quite possible
> >   dbaron: Have a "Expected to have test suite" bucket?
> >   CR-level specs expected to have a completed test suite:
> >   - css3-multicol
> >
> >   Vincent: Regions
> >   fantasai: I think we can have CR as a goal, but I think not as an
> >expectation
> >   Everything else will be in the WD-and-working-on-it bucket
> >   plinss: "Expected to *be* CR with a complete test suite"
> >
> >Meeting closed.
> >plinss thanks Google for dinner, Microsoft for lunch, and  Koji and
> >Seko-san for hosting
> >

Received on Saturday, 11 June 2011 03:20:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:41 GMT