- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 11 Jun 2011 01:39:00 +0900
- To: "www-style@w3.org" <www-style@w3.org>
CSS3 Fonts
----------
- Discussed same origin restriction on @font-face. There are differing
opinions on whether resources loaded through @font-face should be
restricted or unrestricted by default. It was pointed out that the
restriction is on anything loaded through @font-face, not on fonts
only; conversely it does not apply to font files loaded via other
mechanisms. It was also pointed out that the suggested solutions were
HTTP-specific, whereas @font-face is protocol-agnostic.
- Discussed superscripts/subscripts and fantasai and dbaron's proposal:
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 by computing values that synthesize
the superscripts/subscripts and then undoing the synthesis settings
when setting characters for which specialized glyphs are available.
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 organized not by "priority" but
by what status we expect specs to reach by the end of the charter
(and need to be edited accordingly)
- RESOLVED: Meet for 3 days at TPAC
- RESOLVED: Try to schedule a meeting in August probably in Seattle
or France
====== Full minutes below ======
Present:
David Baron (Mozilla)
Bert Bos (W3C)
John Daggett (Mozilla)
Daniel Davis (Opera)
Elika Etemad (Invited Expert)
Sylvain Galineau (Microsoft)
Vincent Hardy (Adobe)
Koji Ishii (invited Expert)
Peter Linss (HP)
Luke Macpherson (Google)
Alex Mogilevsky (Microsoft)
Shinyu Murakami (Antenna House)
Ted O'Connor (Apple)
Florian Rivoal (Opera)
Shunchi Seko (NTT)
Shane Stevens (Google)
Steve Zilles (Adobe)
<RRSAgent> logging to http://www.w3.org/2011/06/04-css-irc
Scribe: Ted O'Connor
CSS3 Fonts: same-origin restriction
-----------------------------------
jdaggett: Two issues: same-origin restriction & super/sub-script handling
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction
jdaggett: starting with the same-origin restriction
jdaggett: came out of discussion in fonts/woff group
jdaggett: description of SOR used to be in an appendix of the css3 fonts spec
jdaggett: fonts group's charter calls for making SOR a requirement
jdaggett: now we have a split between woff spec & css3 fonts spec
jdaggett: objection from apple that it doesn't make sense for SOR to be
tied to the format
jdaggett: we came to conclusion that it makes sense for this to live in
the css3 fonts spec
jdaggett: the text has been moved into the body from the appendix
jdaggett: open issues: what should the default behavior be
ff & ie? restrict by default, allow CORS for relaxing
jdaggett: annevk thinks this is weird
jdaggett: inconsistent with other parts of web platform
jdaggett: problems with data leakage
jdaggett: e.g. canvas' dirty flag
jdaggett: [describes example of embedding security problem on whiteboard]
jdaggett: these issues are beyond fonts & images
jdaggett: there are even issues if script can see the response code from
certain cross-origin images
jdaggett: we have normative prose (section 4.8.1)
jdaggett: annevk doesn't like the default restriction
jdaggett: he'd prefer no restriction by default & users would need to
explicitly set an exception
sylvaing: annevk's first objection is that CORS isn't the right tech for this
jdaggett: [as annevk] the web has evolved because people can link willy-nilly
florian: why solve this for fonts only?
Bert: fonts are different
<jdaggett> siteA --> siteB gimme xxx
<jdaggett> siteA <-- here you go (no CORS header)
<jdaggett> UA sees no CORS header, doesn't download resource
jdaggett: how does the existing text in 4.8.1 work?
<jdaggett> siteA --> siteB gimme xxx
<jdaggett> siteA <-- here you go (CORS header: siteB use ok -or- all sites ok)
<jdaggett> UA sees CORS header, check for a match, downloads resource
jdaggett: instead, annevk's proposal:
<jdaggett> siteA --> siteB gimme xxx
<jdaggett> siteA <-- siteB here you go (no From-Origin header)
<jdaggett> UA sees no From-Origin restriction, <uses default behavior>
<florian> link to where annevk discusses this:
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 implemented the cors approach
jdaggett: others haven't implemented either
jdaggett: consensus that some kind of mechanism is a good thing
jdaggett: don't want to allow cross-origin font linking by default
jdaggett: the cors approach hits the 80/20 point for fonts
jdaggett: vs. the from-origin proposal, which requires you to raise a
flag to get the typical behavior
florian: yes for fonts, but for all resources, from-origin hits the
default correctly
jdaggett: should the default for fonts be different?
jdaggett: our (ff) security guys think all new resource types should
default to SOR
TabAtkins: [describes attack that extracts font data out of a tainted
<canvas>]
Bert: the problem is the javascript, not the resources
TabAtkins: then you wouldn't be able to do anything with fonts in javascript
TabAtkins: e.g. canvas
dbaron: or figure out the width of text
Bert: there should be 2 kinds of things on the web: programs and documents
Bert: text/html is document, maybe application/html could have these
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 doesn't want to have things in css3 fonts that will block
it moving forward
jdaggett: has labelled what impls are doing & put wording that
captures where this will change if consensus changes
jdaggett: what the consensus will be isn't quite clear
jdaggett: marked this as risk
jdaggett: does that suffice to move this forward? i don't know
sylvaing: from-origin is broader, will be more controversial
jdaggett: so it'll take longer
florian: opera prefers annevk's position, but isn't locked into it
jdaggett: annevk prefers a mechanism to work across resource types
and the default should be no restriction
jdaggett: howcome is ambivalent here
sylvaing: This is about any resources loaded by src: in @font-face, not about
fonts v. other resources
fantasai: so images loaded via @font-face would be restricted by default
sylvaing: yes
jdaggett: we can't go back and change the default for images
jdaggett: wanted to make people aware of the wording here that this is
at risk etc.
plinss: bottom line is we're not making the restriction decision here
in csswg
plinss: you want to decouple so we can advance
jdaggett: yes
jdaggett: delicate negotiations with the web fonts group
Bert: not for csswg, because fonts can be embedded via xsl, etc.
hober: we define @font-face, so we define restriction for that embedding point
everyone: [we didn't develop woff for origin restriction reasons]
Bert: sounds like annevk's proposal is better
Bert: what is the reason for woff if all fonts are restricted?
jdaggett: existing font formats weren't for the web, etc., needed to
be a web font format
szilles: woff had 2 requirements: transmission prevent dropping into
client os, 2. can post on web without anyone willy-nilly
being able to use it
jdaggett: @font-face is here, so restriction has to be here
jdaggett: web fonts group has the format
web fonts charter isn't woff-specific
plinss: bert's point is that we & svg etc should use same mechanism
plinss: we shouldn't be deciding the restriction
plinss: is there an actionable item here?
jdaggett: proposals have to be detailed and go to web fonts group & css group
florian: opera is satisfied with this wording
florian: we'd welcome clearly-defined alternatives
florian: this is good enough, allows for alternative proposals
?: we can't go to CR with this
jdaggett: we can mark it at risk
Bert: what about non-HTTP urls, we need to still work
plinss: yes, this is very http-specific
szilles: it's not woff pushing it back on us, they were conviniced this
is acceptable solution to one of their problems
szilles: if we push back, woff group would have to start over
jdaggett: [doesn't want to create other thing that we can't reference
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-size glyph, strokes shrink
too, so super/sub scripts don't have same typographic color
as surrounding text
jdaggett: 'vertical-position' addresses lots of cases [footnotes, etc.]
jdaggett: doesn't address putting images in <sup> or nesting other
sorts of things in <sup>/<sub>
jdaggett: superscripts&subscripts are semantic, so can't be treated
like other font variants
szilles: we've already discussed this; what's the new information?
jdaggett: if I use 'vertical-position: superscript' for s^2 and look
at content in an older browser, I see s2
jdaggett: authors need a way to ensure the right thing happens
jdaggett: the current spec makes 'vertical-position' a shorthand
jdaggett: [reads from section 6.4 on how fallback works]]
jdaggett: allows you to make styles for <sub> and <sup> that work
well in older UAs, as long as you only have text
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html
fantasai describes proposal
fantasai: new property 'magic'
[fantasai & dbaron's replacement for vertical-position]
magic: none | super | sub
fantasai: [describes proposal in email jdaggett linked above]
fantasai: if magic matches vertical-align, then computed font size is
set by multiplying size ratio to parent's font size & we
ignore specified font size
szilles: you're setting the font size to the size that's in the font
fantasai: yes
dbaron: let's explain the goals of this approach
fantasai: we're trying to handle basic super/sub scripts with special
glyphs if available, & synthesizing if they're not available
fantasai: second goal: handle atomic inlines & nested super/subscripts,
what happens if you have a span with changed font size inside
these thigns
fantasai: we're not perfectly handling mixing special glyphs with other
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 handle using lengths or percentages for vertical
align & mixing with this feature
fantasai: won't get the right glyphs if you try to position the
super/sub-script differently than what the font does
Bert: [expresses scepticism]
jdaggett: this could be a case for @supports
jdaggett: if someone's explicitly enabling this, we document that it
works this way, so they're aware of the tradeoffs
dbaron: fantasai & my proposal makes this more complex, but allows
ua stylesheet to have this on by default
plinss: So basically you synthesize superscripts/subscripts font size
and vertical alignment, and anything but the special glyphs
will draw in synthesized state
fantasai: yes. You reverse the synthesis settings in order to draw the glyphs
szilles: is this opentype feature turned on by default?
jdaggett: we're not talking about unicode code points
plinss: if you're using those code points, you're not using <sup> or <sub>
Bert: you have super, sub, and none, but why not just 'yes' / 'no'?
Bert: turn it on from root element
fantasai: That's one of the alternatives listed at the bottom of the proposal
jdaggett: vertical-align controls the baseline, if other properties
affect this, this makes me uncomfortable
jdaggett: behavior of this feature dependent on this other value
szilles: we've got other such cases
szilles: property-refining properties are common
plinss: it's a per-glyph undo of what vertical-align does
fantasai: won't change the line box if you have the right glyphs
jdaggett: font metrics aren't correct
[plinss fantasai: talk re: vertical-align causes baseline change in
even empty line boxes]
plinss: as soon as you start nesting, you want to affect the line height
jdaggett: divergence between opentype spec and what fonts actually do
jdaggett: i want to set this up for people who know how to use it,
without breaking existing content
Bert: what happens if font has some of the special glyphs but not others
jdaggett: you'll synthesize
jdaggett: color won't match, stroke width will be different in synthesized
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 prefer note that says there are alternate proposals
jdaggett: i have to try to impl this before we can do more
fantasai: what other open issues are in this spec?
fantasai: maybe we should defer this issue so spec can reach LC
jdaggett: there are a number of issues
jdaggett: is tightening the wording based on impl feedback
jdaggett: wanted to make people aware of the issue & hear other ideas
fantasai, Steve: i want to have this proposal findable from the spec
Flexbox update
--------------
alexmog: in ie10 we have fairly complete impl of spec
alexmog: for ie10 we won't have the new syntax
alexmog: don't want two prefixed syntaxes
alexmog: the timing isn't right for ie10
alexmog: for new spec, we want to see what other browsers are doing
alexmog: we need to have multiline back in spec
TabAtkins: will be bringing multiline back
TabAtkins: webkit is working on impl of the new spec
TabAtkins: will see that in the near future
alexmog: if the spec stayed in the old syntax, we could drop prefix;
but we don't need to reopen that
dbaron: we [ff] also have someone working on the new spec
sylvaing: any issues, dbaron?
dbaron: haven't heard any, don't know how far along things are
alexmog: we can map most of new syntax to old impl; biggest difference
is using the flex function notation
alexmog: would require parser change
alexmog: different alignment too
alexmog hopes feedback from other impls will help next version of spec
stabilize
sylvaing: flex notation, alignment modes, multiline--want to see
feedback from other implementors
plinss: anything else?
alexmog: whats' the eta?
TabAtkins: wants to publish a new wd sometime by the end of June
TabAtkins: hopefully ready for LC soon after that
<br duration="15min" />
Scribe: TabAtkins
CSS Regions
-----------
vhardy: content-order is a float right now, which people say are odd -
z-index is an integer, frex.
vhardy: We did it that way so that you could, say, insert between two
consecutive items.
vhardy: But the precedent means we should just switch to <integer>s.
Bert: Is there any way to avoid using numbers at all?
szilles: The regions aren't inherently ordered - they just pull
whatever's in the stream.
Bert: Why not push to a stream?
vhardy: We thought of that model, but given that many regions aren't
named, it becomes more difficult. It seemed simpler to name
the flow and have regions pull.
vhardy: We sketched out some ideas for an @region-chain rule where
you'd list the sequence of regions.
Bert: That's similar to what I did with Template - a property that
listed a chain of cells that content flowed across in order.
szilles: That fails somewhat in paged media, where you can have multiple
copies of cells with the same name.
vhardy: I also had an idea to have a region-name property that would
name a region, but it didn't seem quite harmonious.
vhardy: Can we agree on moving it to <integer> for now?
RESOLVED: Switch content-order to take <integer>
vhardy: Another syntactic issue is that the 'flow' property uses
<string> for value, and is referred to by a string.
vhardy: So the question is should that just be an ident?
szilles: Didn't we have a similar discussion in february?
<arronei> Ident +1
TabAtkins: That was for fonts, which are a problem because their
names come form outside CSS. It's okay to do idents in
author-defined syntax.
plinss: But you do sometimes shoot yourself in the foot when you
use idents, because it makes it hard to add new
language-defined idents in the future, as you might collide.
plinss: If it's guarded as a functional value, it's a bit better.
szilles: I'd be afraid of it being a quoted string in 'flow' and
unquoted in a function in 'content'.
hober: Yeah, not doing that. Consistency.
<arronei> Yeah but I don't want a flow to have a string like this.
"{}{]}##<"
TabAtkins: I think that we can work our way around the problem later
if we just restrict the 'flow' to a single author-defined
ident for now.
plinss: We'll need to do something like a dummy keyword so we can
have a distinguished syntax for CSS-defined values, which
is dumb.
TabAtkins: Another option is to make 'flow' take a to(<ident>)
function for now, which pairs with the from(<ident>)
function in 'content'.
szilles: That sounds good.
Bert: I'm not sure we need from(), and so to() seems unnecessary too.
szilles: You definitely need from(), to disintiguish it from other
values in 'content'.
<arronei> Functions removes the issues if you want to add keywords later.
Bert: I'd need to familiarize myself with the syntax more, but
'content' may not be the right place.
alexmog: Given that 'content' sets the contents to something other
than the natural contents, it seems appropriate to use it here.
plinss: Potentially we could use another property, and still get the
ability to add things to the flow's contents by using the
'contents' keyword (defined in CSS3 Content).
szilles: But that's another issue.
[chatter about 'content' and potential 'flow-from']
szilles: Wouldn't that mean I need to set two properties?
plinss: No, setting 'flow-from' would just change the meaning of
"content:auto" to pull from the region. And then potentially,
when "content:contents" is defined, that can combine.
alexmog: We're afraid of author-defined idents colliding with future
CSS-defined keywords, right?
alexmog: I think from the OM model pov I'd prefer two properties that
take strings than something that takes one-off functions.
<arronei> I still prefer content: from(...) for it's simplicity.
TabAtkins: Arronei dislikes strings because it becomes easier to write
unreadable region names.
szilles: You can write unreadable idents too.
<arronei> But it's not as easy to do
Bert: Can we duplicate flow content across multiple regions?
vhardy: That's an issue that was brought up on the mailing list.
Bert: In previous approaches to this idea we named the flow specifically
to allow duplication. Newer approaches like Grid didn't need that.
[some difficult-to-understand discussion about being able to omit the
name of the flow]
Bert: template is naming regions, but not naming flows
[moving it to the list so we can throw down syntax, because everyone's
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 16:39:34 UTC