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