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

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 is 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-specific, whereas @font-face is protocol-agnostic.

   - Discussed superscripts/subscripts and fantasai and dbaron's proposal:
     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 by computing values that synthesize
     the superscripts/subscripts and then undoing the synthesis settings
     when setting characters for which specialized glyphs are available.


   - 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

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
     - :matches() and :not() that take a comma-separated list of selectors
     - :dir(ltr) and :dir(rtl) that match against the markup-determined
     - the ability to choose which component of a selector represents its

   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 organized 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 ======

   David Baron (Mozilla)
   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:
   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 implemented the cors approach
   jdaggett: others haven't implemented either
   jdaggett: consensus that some kind of mechanism is a good thing
   jdaggett: 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
   Bert: the problem is the javascript, not the resources
   TabAtkins: then you wouldn't be able to do anything with fonts in javascript
   TabAtkins: e.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
   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 doesn'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 position, 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: wanted 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
   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-size glyph, 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
             sorts of 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 the new information?
   jdaggett: if I use 'vertical-position: superscript' for 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]
   magic: none | super | sub
   fantasai: [describes proposal in email jdaggett linked above]
   fantasai: if magic matches vertical-align, then computed font size is
             set by multiplying size ratio to parent's font size & we
             ignore specified font size
   szilles: you're setting the font size to the size that's in the font
   fantasai: yes
   dbaron: let's explain the goals 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
   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 handle 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 element
   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: color won't match, stroke width will be different in synthesized
   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
   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
   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 prefer 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 want two prefixed syntaxes
   alexmog: the timing isn't right for ie10
   alexmog: 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 to 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
   sylvaing: flex notation, 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
   TabAtkins: 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

   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


   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
   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
   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
   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

     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
   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.


   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?

   <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
   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
   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


   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
   Sylvain: "Can we have one discussion at a time?"
   Tab: Aside from naming issues, this is something we want to pursue
   <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


   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:
   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
   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
   [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


   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


   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
   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.

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.


   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 16:39:34 UTC