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: Vincent Hardy <vhardy@adobe.com>
Date: Fri, 10 Jun 2011 16:55:16 -0700
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CA17FBDE.7226%vhardy@adobe.com>
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>
- 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 Friday, 10 June 2011 23:56:02 GMT

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