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