- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 08 Apr 2010 00:14:46 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Administrative
--------------
- RESOLVED: CSSWG TPAC meeting on 1&2 November 2010
- Next CSSWG F2F tentatively planned for March at Mozilla offices
in Mountain View, CA
CSS2.1 Issues
-------------
- RESOLVED: Defer to Sylvain for resolution of Issue 60, Bert will
verify when editing that the changes are only editorial.
http://wiki.csswg.org/spec/css2.1#issue-60
- RESOLVED: In paged media where there is no viewport, a 'fixed' background
is fixed with respect to the page box and is therefore replicated
on every page.
http://wiki.csswg.org/spec/css2.1#issue-69
- RESOLVED: Backport jdaggett's css3-fonts text about 'bolder' and 'lighter'
values of 'font-weight' into CSS2.1.
<LINK TO PROPOSAL>
http://wiki.csswg.org/spec/css2.1#issue-111
- RESOLVED: In font-weight section pull bullet 4 (hole-mapping) out of bulleted
list and replace "typical mappings" from the sentence below it with
"this mapping" to make hole-mapping rules normative.
http://wiki.csswg.org/spec/css2.1#issue-156
- RESOLVED: Accept fantasai's proposal to distinguish zero clearance from no
clearance.
http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
http://wiki.csswg.org/spec/css2.1#issue-115
- Long rehashing of discussion around Issue 71. No conclusion.
http://wiki.csswg.org/spec/css2.1#issue-71
- For CSS2.1 Issue 26, general agreement that 'height' on table cell should
be a minimum height for the row, not a minimum height for an anonymous box
wrapped around the cell's contents. dbaron to write proposed wording.
http://wiki.csswg.org/spec/css2.1#issue-26
CSS2.1 Test Suite
-----------------
- Publication of test suite snapshots causing strain on W3C's server. Further
snapshots will be tarballs (with .htaccess files for charset tests); latest
snapshot will be hosted at current/
- Aiming to publish Beta 1 (including all of hixie's tests, i18n's tests, and
Mozilla's submitted reftests) in mid-April.
- CSS2.1 must be in PR by September.
Vendor Prefixes and Stabilizing Propeties
-----------------------------------------
- Conclusion: No change in CSS process. High-priority items should be extracted
from low-priority items into separate specs to facilitate faster progress.
Status of Specs
---------------
- CSS Styling Attributes waiting for response from SVGWG.
LC comments: http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
Should create tests for common parsing mistakes.
- Media Queries has many submitted tests in various formats. Waiting for someone
to turn them into a test suite. Chris Lilley actioned to find tests and check
them into test repo.
- CSS Namespaces needs implementation reports. Daniel Glazman actioned to create
them.
- CSS3 Paged Media pending a lot of work before another Last Call.
- Backgrounds and Borders pending test suite. fantasai to set up test suite with
some tests, Mozilla will submit their existing tests.
- CSS3 Color pending resolution of some non-trivial LC comments.
Issues List: http://wiki.csswg.org/spec/css3-color
CSS3 Backgrounds and Borders Issues
-----------------------------------
- RESOLVED: Add 'content-box' value to 'background-clip'
- RESOLVED: Allow setting 'background-origin' and 'background-clip' in shorthand
using [ border-box | padding-box | content-box ]{1,2} where one value
sets both, two sets origin then clip.
- RESOLVED: Change background shorthand to require position immediately before size:
<bg-position> [/ <bg-size>]
- RESOLVED: Proposal 3 accepted to drop recommendation for gradient corner blends
http://lists.w3.org/Archives/Public/www-style/2010Feb/0238.html
- RESOLVED: Add simple (shadow border-box as if opaque) version of 'box-shadow'
back to css3-background.
The changes above will all require a return to Last Call.
GCPM
----
Discussed proposal for env() content function to return data about user's environment
such as the file location and the current date/time. Discussion continues on Wednesday.
~fantasai
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
Beth Dakin
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Brad Kemper
Håkon Wium Lie
Chris Lilley
Peter Linss
Alex Mogilevsky
David Singer
Anne van Kesteren
Steve Zilles
Administrative
--------------
ScribeNick: TabAtkins
<sylvaing> http://wiki.csswg.org/planning/cupertino-2010
plinss: Anyone with new topics?
plinss: k, no new topics.
plinss: First topic, TPAC. Need to set our dates.
ChrisL: Request for monday/tuesday?
glazou: Yes, from szilles and others. Want to make sure everyone is
available for nov 1 and 2.
glazou: Two hotels around the venue, Hilton and something else.
glazou: Early rates, roughly 110 euros/night.
glazou: Cheaper in the center of Lyons, but it's further away, and
no easy connection via public transport.
glazou: Unless there's a strong objection to monday/tuesday, we
should let the w3c know.
RESOLVED: CSSWG meeting is on November 1 and 2.
glazou: We also need to discuss at some point the dates/location of
first meeting in 2011.
glazou: Who's willing to host in 2011?
dbaron: There's a bunch of us who could host in the Bay Area.
glazou: Probably fair to host in Bay Area after 2 meetings in Europe.
dbaron: I'd be happy to host. (Mozilla)
howcome: Seems to be too early to set up dates yet.
glazou: Anytime in March is good. No good in February.
dbaron: MIT spring break is march 21-26, and thus probably the AC
meeting.
glazou: So, if we meet on the last week of March, or 2nd or 3rd week,
it would be better.
<dbaron> Easter 2011 is April 24
glazou: Let's stick with the idea of a March meeting hosted by Mozilla,
and move on for now.
CSS 2.1 issues
--------------
<plinss> http://wiki.csswg.org/spec/css2.1
fantasai: Start with issue 60.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-60
sylvaing: Issue 60 is from Anton Prouse and issues about z-index and stacking.
sylvaing: There is no interop issues, it's mostly just cleanup and making
sure that different parts of the spec agree.
sylvaing: I suggested minimal changes, and he accepted most of them, there's
just a few things left. I think we can get it closed in a few days.
sylvaing: Mostly it's just terminology and a few other things that are
confusing.
sylvaing: Like intermixing "stacking order" and "painting order" and such.
sylvaing: So, mostly editorial. We'll try to close it.
sylvaing: In 9.9.1, there are a few errors, but browsers follow Appendix E,
which is the important one.
howcome: Seems like it's more than editorial, like #4 there.
sylvaing: Yeah, #4 was the one actual error where 9.9.1 is out of sync with
appendix E, but browsers do the right thing there.
szilles: My suggestion is that we reaffirm that Appendix E is the normative
text.
howcome: Don't we already say that somewhere?
szilles: I think we do, but it wouldn't hurt to affirm it as a Working Group.
plinss: So we're agreed to accept Sylvain's changes?
RESOLVED: Defer to Sylvain for resolution of Issue 60, Bert will verify
when editing that the changes are only editorial.
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-69
<fantasai> In paged media where there is no viewport, a 'fixed' background
is fixed with respect to the page box and is therefore replicated
on every page."
bradk: Should we mention something about box-decoration-break wrt fixed
backgrounds?
Arronei: Not in 2.1, but we'd have to in 3.
szilles: What about bleeds?
fantasai: Not addressed here. Backgrounds on the page box may bleed, but
not on the document.
howcome: There is a bleed property in gcpm.
RESOLVED: In paged media where there is no viewport, a 'fixed' background
is fixed with respect to the page box and is therefore replicated
on every page.
fantasai: Did we want to do #71?
Bert: I'm in the process of responding to that, but have email troubles.
fantasai: issue 73, peter was supposed to write a note?
ACTION: Plinss find or write note for issue 73 by this afternoon
plinss: Issue #111
<smfr> http://wiki.csswg.org/spec/css2.1#issue-111
plinss: Font-weight bolder/lighter, synchronize with css3?
fantasai: Don't have a strong opinion on this.
TabAtkins: So Daggett's suggestion was to make bolder/lighter act as if
there were only four weights.
ChrisL: As long as you can get to the other weights someway.
szilles: This isn't great, but it's less bad than others.
Bert: This is the same text as in the Fonts module?
szilles: Yes.
Bert: I'm okay with that.
szilles: Obvious issue is, what do current browsers do with this?
arronei: Currently, we test by having a list, and see if it's lighter
or darker. Purely visual.
szilles: Does the suggested algorithm keep this same behavior?
Arronei: Should.
RESOLVED: Accept Daggett's changed (from Fonts), back into CSS2.1.
plinss: Related is issue 156.
fantasai: ChrisL says "I'd prefer to see the mapping made normative."
fantasai: Different mapping from issue 111.
<fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-boldness
<fantasai> last bullet in the list
<fantasai> "If there are fewer then 9 weights in the family"
ChrisL: above that, it says "in typical cases", which makes it untestable.
ChrisL: So, I'd like to drop that sentence.
fantasai: OpenType fonts use a numerical scale, but they may not line
up with multiples of 100.
ChrisL: 4th bullet gives you a more precise description of that.
ChrisL: I've seen things like a font with weights like 400 and 250,
and that's fine. 200 and 300 aren't mapped explicitly.
fantasai: You might actually want to map the 250 to 100.
ChrisL: No, that'd expose more weights, but would put them in the
wrong place. If you need precise mapping, just use @font-face.
plinss: I think certain platforms made fonts map their weights wrong
to get around bad heuristics.
ChrisL: I haven't seen platform-specific weight tables like that.
fantasai: I'm happy to make bullet 4 normative, but I'm less convinced
about the other rules being normative.
fantasai: I think mapping fonts to weights can be messy, and we
shouldn't define that in css 2.1
fantasai: But after the font has been mapped into the CSS font-weight
scale, then we can follow the guidelines in bullet 4 to
find missing weights.
fantasai: That seems consistent.
fantasai: The rules before that are about establishing the scale,
and needs to be flexible to accomodate whatever twisted
things we get into with fonts.
* dbaron wonders if jdaggett should be around for this discussion
fantasai: So the specific changes for this would be to pull bullet 4
out of the list and remove "default".
Chris: Also replace "typical mappings" from the sentence below it
with "this mapping"
RESOLVED: Proposal above accepted.
plinss: Next is issue 114.
fantasai: let's defer until dbaron is back.
plinss: Issue 115
fantasai: Summary should be "Zero clearance should be distinguished
from not having clearance".
fantasai: There are some cases in which you have clearance, but it
calculates to 0, and the spec isn't clear about distinguishing
this from no clearance.
fantasai: Some things happen when there isn't clearance (margin collapsing,
frex).
fantasai: So these other behaviors should still trigger when there is
clearance, even if the value happens to compute to 0.
alexmog: Any interop issues?
plinss: Do we have testcases for current behavior?
fantasai: I doubt we need any. It would require very unnatural code.
fantasai: (to make 0 clearance act like no clearance)
plinss: So do we have tests for clearance showing interop?
fantasai: Sorta. Clearance is not the most interop portion of the spec.
arronei: According to test cases, we do have at least two browsers agreeing.
alexmog: I'm not sure if the first change is just about this issue...
fantasai: Check the second email, it overrides that.
fantasai: We'd take everything *but* the first change from the first
email, and then all the changes from the second email.
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-115
<fantasai> all but the first change in http://lists.w3.org/Archives/Public/www-style/2009May/0186.html
<fantasai> plus changes in http://lists.w3.org/Archives/Public/www-style/2009Aug/0394.html
<fantasai> http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
RESOLVED: Accept fantasai's proposals for issue 115.
<br type=coffee>
plinss: Bert sent an email for issue 71.
Bert: We discussed this a year ago, and I looked at the minutes for
that meeting.
Bert: If you find at @-rule in the middle of a declaration block,
the rule says to ignore the @-rule, but you *want* to ignore
the whole block.
Bert: I think the error is the rule for ignoring @ keywords is meant
for the rules, not declarations.
Bert: So I suggest to make that explicit.
<Bert> http://lists.w3.org/Archives/Public/www-style/2010Mar/0485.html
<fantasai> body {
<fantasai> @foo {}
<fantasai> background: green;
<fantasai> }
<fantasai> Does that handle this?
fantasai: We wanted the rule to stop ignoring at the close brace.
plinss: Is that what we want?
plinss: In paged media, we have @page which can be mixed with other @ blocks.
fantasai: Right; right now the rules say the background should *not*
be green - they say we should ignore until the semicolon.
plinss: So you want the background:green to apply.
fantasai: Right.
Bert: My proposal is to do what CSS 2.1 says. I thought that's what
we decided last year.
Bert: Which would mean we ignore up to the semicolon, so there would
be no green.
plinss: Any @ keyword followed by a block or a semicolon should be
ignored up to the next block or semicolon; we don't need to
go farther.
howcome: Is that what browsers do today?
Bert: Yes.
plinss: So existing browsers would ignore the background:green?
<fantasai> body { color: @foo {} background: red; }
<fantasai> body { @foo {} background: green; }
glazou: Right, that should be ignored up to the semicolon, since it's
inside the value of color.
glazou: But we didn't discuss @ rules inside @ rules.
fantasai: That's not what issue 71 is about.
<fantasai> body { color @foo {}: red; }
fantasai: After you start a declaration, as soon as you see a property,
the @ rules become invalid tokens.
anne: In CSSOM, at-rules always have to come at the end or the start.
Bert: I thought we resolved in css3-page that the @rules come after
the declarations
plinss: We have the problem of the existing behavior.
bradk: But changing existing behavior won't break any pages.
howcome: What's the value of fixing this in 2.1?
plinss: Compatibility with CSS3?
anne: We need to know the parsing rules.
howcome: If we decide it now, we could put it in css3.
glazou: We have only one parser. It will be the same in 2 or 3.
dbaron: The forward-compatible rules should be the same in all levels
and should not change.
howcome: I can probably live with fixing it.
Bert: But if you start with / or something, it would not be green.
glazou: But @ is an acceptable token inside a rule. A / is not.
glazou: @page is a declaration block.
plinss: It's something new, a mixed declaration and @ block.
anne: Bert is right.
anne: Declaration blocks don't currently have the notion of an @ block.
Bert: I don't understand why we want to keep the @page construct,
because that's where the error is.
fantasai: @page is deployed.
Bert: So is this.
fantasai: @page is deployed *and used*. This error isn't used.
fantasai: There are multiple impls. HP, Canon, Prince
fantasai: Antenna House and Epson.
anne: Question is, do we want to change the parsing to allow @ blocks
inside of declaration blocks in the future?
howcome: We can do cool stuff with it, and we can create nightmares.
ChrisL: I'd like to see named stylesets, bundles of properties applied
at once.
howcome: You want to represent these structures in the object model?
anne: Yes. [explanation of @page stuff]
howcome: That's a special fix for @page. We're talking about generic things.
anne: Yeah, if it was generic, we'd want a generic structure that
@page could inherit from.
<RRSAgent> logging to http://www.w3.org/2010/03/29-CSS-irc
anne: We have the problem for @page, for what goes inside of @page,
that we need to solve one way or another. We can make it
special or we can make it generic.
Bert: I proposed some time ago to create a 3rd type of block that
would allow @page.
Bert: But I think people wouldn't want that.
anne: That wouldn't solve the earlier problem, the background wouldn't
be green.
Bert: Right, but it would let you do what @page wants.
plinss: I'd prefer to see, if we see an @ rule, we parse it as a block,
throw it away as invalid, and don't trash more than that.
Bert: But that's inconsistent. Any other unknown token would throw
away until the next semicolon.
szilles: @ already has the role of being special.
glazou: I think we agree that if an @ occurs inside a value isn't an
@ rule.
glazou: Frex, if the first token inside the brace is an @ token, we'd
like it to be an @ rule.
Bert: If that's a change, we can't do it.
glazou: It's something new that wouldn't break anything.
Bert: It's in the spec.
howcome: This is a change in the eternal grammar.
anne: It doesn't change valid stylesheets. I think it's fine.
Bert: We have the error-recovery rules for consistency; you're changing
the rules, so you're losing consistency.
glazou: We are fighting about extensibility all the time.
Bert: Things like adding to a shorthand is different, it fits in the
grammar.
Bert: Show me a place in CSS3 that is incompatible with the
forward-compatible rules.
plinss: @page
ChrisL: @page is interoperably implemented. I don't see the benefit
of changing it; we should allow it, and use the extension
point it allows to do new things.
howcome: This is a change in the eternal grammar, but we don't really
have a great use-case.
howcome: A green background isn't a good use-case.
howcome: It's interoperable today, I'm not sure we should change it.
howcome: We're suggesting this change to get a generic extension mechanism.
plinss: We have @page, which allows intermingling of @ rules in a
declaration block.
plinss: If it's *only* valid here, with special rules and special error
recovery, that's very surprising.
howcome: Do we allow @page at the place where we're talking about?
<alexmog> adding a semicolon to the use case makes it green, interoparably:
body { @foo {}; background: green; }
plinss: No, not right now. But @page acts like a declaration block, and
allows more @ rules in it.
glazou: [gives an example showing @page]
plinss: If error-recovery from @foo inside @page's declaration block is
different from in other declaration blocks, that's very surprising
glazou: In @page, if you see another @page{}, it parses to that } and
throws it away, allowing the next rules to work.
glazou: But if you have @page{ @foo {} background: green; }, the background
is thrown away. That's very surprising.
plinss: The problem is that an unknown @ rule at one point in the stylesheet,
it parses to the }. If you put it at another spot, and it doesn't
parse to the }, that's weird.
dbaron: We already have that in some places. If an @rule appears in a
value, or in a selector, it just makes an invalid value or selector.
<dbaron> ... never mind what I said
szilles: What anne just pointed out, if we have a single recovery mechanism,
CSSOM can have a generic recovery mechanism.
glazou: Non-generic means one parsing impl for @page, and another for other
@ rules.
glazou: That's ugly.
<fantasai> We have different parsing of @keywords in different parts
of the style sheet with or without the change we're proposing.
<fantasai> For example, @keyword inside a declaration is still ignored as
an invalid token
<fantasai> However, having different parsing rules within a declaration block
depending on whether the declaraiton block is inside @page or
elsewhere, that is confusing
<fantasai> and it is a burden on implementors to implement two different
types of error-recovery
alexmog: I'm agreeing with what Bert is saying. I'm not seeing use-cases,
but we have interop against it.
<anne> advantages: 1) consistent rules for authors 2) one code path for
implementors
alexmog: We'll have syntax that is ignored in older browsers but paid
attention to in newer browsers.
alexmog: We can just add a semicolon to the end of the @block and all
browsers ignore it. It's not the prettiest, but it achieves
the goal.
anne: Advantages is consistent rules for authors, and implementors.
alexmog: How much time until browsers have changed sufficiently to allow it?
TabAtkins: No more time than it would take for any new @ rule to be usable.
plinss: He has a good point. If we introduce a new @ rule, then authors
using it will have their next declaration swallowed in older browsers.
anne: But can't it sometimes be a start of a selector then?
fantasai: No.
anne: If you recommend putting a semicolon after every @ rule, it is
the start of a selector, and you don't get a green background.
anne: IE "@foo {}; body { background: green; }" kills the body block.
Bert: Oh, no, not ; after everything.
anne: I think we can just recommend that authors put the @ blocks at
the end of the declaration block.
plinss: I think it will be really confusing if you would recommend
putting ; at the end of @ blocks inside a declaration block,
but not at the end of ones outside a declaration block.
Bert: I think we made a mistake on @page, not in the grammar.
plinss: I think we made a mistake in the grammar, instead.
fantasai: I think you can't stick an @ rule without braces is invalid
inside a declaration block in the core grammar.
fantasai: We have some options. We could do nothing, which means no
@ rules inside declaration blocks ever.
fantasai: And then just have Paged Media declare that @ rules have to
be at the end.
plinss: The problem is that the longer we put it out, the more
entrenched we'll get.
Bert: Not expensive? It's been in the spec for years!
anne: What kind of implementations are you thinking of?
Bert: TVs, etc.
glazou: They're all consistent right now, though, so nobody uses it
anyway. It can't even be used as a browser selector.
plinss: The problem isn't that it's an error now, but in a few years
when we have a spec that uses @ rules in that area.
anne: In a few years we'll have an upgraded set of browsers.
szilles: So older browsers will throw it away, so nothing weird.
Anne observes that if you put them at the end, it will
prevent any rules from being dropped.
Bert: So let's just put them at the end.
fantasai: It's still invalid by the grammar.
howcome: Eternal grammar isn't 'eternal', but I think it should
still be harder to change than just writing a spec that
says something different.
howcome: We should have a very good reason to do it, and I haven't
seen that reason.
szilles: It simplifies the CSSOM model, for one. It simplifies
parsing for CSS. It simplifies parsing for authors.
<TabAtkins> @mixin(border-rules)(n) {
-moz-border-radius: n;
-webkit-border-radius: n;
border-radius: n; }
div{ @mixin(border-rule, 8px) }
Bert: Why do you need an @rule in the one place where it's not allowed?
plinss: Because @rule already has rules for swallowing things to the
end of a block.
glazou: If you remember the time before CSS2, we didn't have @page.
glazou: Declaration were *only* for style rules. When we came up for
@page, we suddenly had a new place for declarations.
glazou: We want to be able to reuse an existing construct in the same way.
glazou: It would open up a new type of contributions for authors that
we can't usually do.
Bert: Imagine changing XML.
glazou: We did that when we added @media.
Bert: That in 1998.
szilles: I recommend the chairs take a straw poll.
anne: And the options are 1) special handling of @page, or
2) generic handling?
and 3) require at-rules at the end for @page
plinss: Given the current definition of @page, legacy handling would
mean swallowing @margin rules inside of it, because @page
contains a declaration block, which doesn't allow @ rules
inside of it.
Bert: 4th proposal, which has no chance, is to change Paged Media.
Bert: And pull out @margin rules from the @page blocks.
fantasai: They should have probably been outside from the beginning,
but right now we can't change them.
howcome: Where would you put them if they were outside?
<ChrisL> CSS the Eternal Temple http://i40.tinypic.com/2nlwrjn.jpg
howcome: [illustrates the change]
<Bert> (One proposed change is in 13.2 say:... followed by a block
of declarations <ins>and at-rules</ins>.)
fantasai: Yeah, but we've got multiple implementations in printers,
and so it can't be changed now.
plinss: What's the point of putting @ at the end? It seems like an
arbitrary place.
fantasai: It makes it clearer how inheritance works.
howcome: So how do we deal with @page containing @top-left and such?
Bert: Right now, we don't. It's just invalid.
Bert: We could create a special thing, not a declaration block,
that would allow it.
plinss: I'm reading the parsing rules, and I'm not seeing anything
in CSS that says special handling of @ rules depending on
the position.
plinss: It doesn't say we only do this based on where it was.
Bert: Right, but we discussed that it should behave that way.
plinss: Please show me in the spec where it says it should behave
the way you say it should behave.
Bert: The two points above that.
Bert: The question is only if there is an exception if the @ keyword
appears right after a semicolon.
dbaron: We don't specify what happens when the formal grammar
disagrees with the prose.
plinss: But the formal grammar doesn't define the recovery rules,
only the prose does.
dbaron: we usually go with whatever's more specific
howcome: What if we used ::top-left or something?
fantasai: Should have been @page::top-left, but shrug.
Straw Poll:
1) Generic Handling
2) Special handling for @page in any order (current spec)
3) Special handling, but @rules at the end.
4) Change Paged Media to nuke margin boxes and rewrite @page.
smfr: 1
anne: 1
szilles: 1
<bradk> 1 generic
dethbakin: 1
sylvaing: abstain
alexmog: 3 or 4, whatever doesn't change CSS 2.1
ChrisL: 1
Bert: Prefer 4, second is 3. could also live with 2. Can't live with 1
arronei: 1
<sylvaing> sylvaing abstains in the absence of a use-case
fantasai: anything but 4, defer to dbaron
dbaron: 4
bradk: 1
TabAtkins: 1
glazou: 1
plinss: 1
howcome: 3
dsinger: 1
<fantasai> I think HP would raise a formal objection for 4
glazou: Twelve for #1, three or four for 3 and 4.
dsinger: We have agreement on *not* 2.
plinss: And we can't do 4 because of existing impls.
glazou: Existing impls do 2, so we're rejecting the current impls!
fantasai: Not sure if existing impls do 2, maybe they do 1?
ChrisL: How would you tell the difference?
fantasai: Just pop my testcase into a supporting impl.
<anne> <!DOCTYPE html><style> body { @foo {} background: green; } </style>
<ChrisL> it would be good to gather that implementation experience
for printers that currently handle @page
body {
@foo {
}
background: green;
}
glazou: People will write it like Tab has, what will they expect?
howcome: Prince considers this an error, and doesn't show a green background.
fantasai: So it implements 2?
anne: Or 3, we can't tell.
plinss: Elika, can you test with your printers and get back to us?
fantasai: Would be good to get AH. Can we ping Murakami-san?
fantasai: 3 would just mean normal 2.1 error-recovery mode.
plinss: We'll come back when we get more implementations.
howcome: Is there anyone that can't live with 3?
anne: #3 is actually pretty weird.
anne: So if you had @ rules, normal rules, then more @ rules, presumably
you should ignore all the normal rules since the appearance of
the @ implies the end?
howcome: I think we can live with #3 now, and then make #1 valid later.
dsinger: Can we write that we can possibly allow #1 later? Warn people
about it?
plinss: I don't think there's any point to saying "Sometime in the future,
we might add future-proofing."
<ChrisL> :)
dsinger: No, just that we might add a feature in the future that may
require more generic handling, so don't depend on certain
types of handling.
howcome: There is no hole right now. You're creating a hole and then
insisting it needs to be filled.
anne: Paged Media doesn't actually require them to be at the end.
plinss: In my perspective, it's a bug in 2.1.
plinss: In 2.1, we say when you see an @rule, swallow until the next
block or semicolon. We don't say to do that only at the rule
level.
plinss: We need to make this clear one way or another. Bert's proposal
is to say that applies only at the ruleset level, most others
are saying apply at all levels.
howcome: We have impl issues with that.
plinss: We have an existing spec that needs @rules like this, and at
least two more ideas I know of want that.
Bert: But no one implements it like that anyway.
plinss: Right. But my reading of CSS is that you throw away an invalid
@ rule as a unit.
Bert: Only at the toplevel.
plinss: But CSS doesn't say that.
howcome: This is a new situation. Bert is arguing *for* the browsers,
Peter is arguing against?
plinss: This isn't progressing. We'll get more examples. Until then
we're not convincing anyone.
szilles: Can we set a time for jdaggett's call? By my calc, 6am in
Tokyo is 2pm here.
szilles: Is 3pm okay for us (7am for him)?
plinss: We have a lot of things for him to weigh in on.
plinss: I'd like him as early as possible. I suggest we ask him when he's comfortable.
szilles: And then I"ll ask another Adobe employee to attend.
<br type=lunch duration=1h>
ScribeNick: fantasai
http://wiki.csswg.org/spec/css2.1#issue-114
http://wiki.csswg.org/spec/css2.1#issue-109
http://wiki.csswg.org/spec/css2.1#issue-26
dbaron: The way the spec currently says that vertical-align in table
cells works is
dbaron: You have a table
dbaron: like this
dbaron draws a table with 2 rows 2 cols
dbaron: And you have a table cell likes this
dbaron draws a cell box in the upper half of the first cell
dbaron: The spec says vertical-align aligns the cell box inside the cell
and it says that the 'height' property sets the height of a cell box
dbaron: Suppose it says the cell height is 200px
dbaron: The cell box will be 200px
dbaron: and if the row is 200px high
dbaron: the cell box stays put, and its contents are clearly not
vertical-align: bottom
dbaron: Nobody does this, everybody aligns the contents to the bottom
dbaron: There are 2 possible solutions here, with different implications,
and different browsers pick different ones
dbaron: One alternative is to say that instead of 'height' setting the
height of the cell box, it sets a minimal height for the row
dbaron: The other solution is to say that you have two boxes
dbaron: one of which wraps around the content, the other one of which
wraps around that, and vertical-align aligns both of them,
but the height only sets the height of the outer one
dbaron: The tricky cases are where you have baseline alignment
dbaron: You can get a case where baseline alignment requires more space
than either cell would require alone
dbaron: e.g. if you have a large-text box of auto height
dbaron: and a small-text cell of large height
dbaron: the baselines align
dbaron: but the second box extends way below the bottom of the first
dbaron draws this on the board
<css_projector> http://dbaron.org/css/test/2010/css21-issue-26
dbaron shows http://www.brunildo.org/test/td_height1.html
fantasai: I would not expect vertical-align to increase the size of
the cell there
fantasai: I would expect height to set the height of the same box
that you paint borders and backgrounds on, not on the
anonymous content holder inside it
<smfr> http://www.w3.org/TR/CSS21/tables.html#height-layout
fantasai: Does height include the padding?
fantasai: border-widths?
Looks like height in Mozilla is a border-box height
fantasai thinks we should say that the height sets the border-box
height of the cell box. Then the contents of the cell are
wrapped in an anonymous box, and that is aligned inside
the cell
Alex: What do Mozilla and WebKit do for flexbox?
dbaron: I'm not so concerned with that
Steve: So you have two boxes, one that most properties apply to,
and then the box that wraps the contents of the cell, that
gets vertical-aligned
Steve: The first box has border, padding, etc.
dbaron: We should figure out what we want so that someone can write
a proposal
dsinger asks a question
dbaron: baseline alignment is a relative thing. You take all the
cells in the row and baseline-align their contents.
dbaron: If the height of the row is taller than the height of the
aligned set of content, it's undefined what happens
Steve: So your question is that ... can we give names to these things?
dbaron: One of them is called the cell box, but it's not what you'd
think of as the cell box
dbaron: The simplest change it to go with IE and Opera and say that
'height' on the cell sets the minimum height of the row
<anne> http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
howcome talks about making a bar chart
dbaron: An explicit height on a table cell does not cause even the
contents of that cell from increasing the height of the cell
dbaron: Everything's like minimum heights in tables
Alex agrees with Opera's interepretation
Steve: If you want the other behavior, you can put a fixed height
on a <div> inside
plinss: Shouldn't require markup changes for layout
fantasai: This is the most intuitive interpretation.
fantasai: If I was an author, I'd associate the height of the table
cell with the height of the box that has borders and
backgrounds on it, not some invisible thing inside it
Simon: Hyatt doesn't really care which way this goes
ACTION: dbaron write proposal for IE-Opera behavior for issue 26
http://wiki.csswg.org/spec/css2.1#issue-114
fantasai explains that the spec is unclear about what is allowed and
what is invalid
Arron has a bunch of testcases showing that results are very different
across browsers
There are two proposals for clarifying the spec
one would make unquoted font names a series of identifier tokens
the other would make them a series of nmchars tokens
Chris suggests recommending quotes
The spec already recommends quotes
dbaron: right now in Gecko you have to escape or quote numbers
several: Let's allow everything
<ChrisL> everything but comma
fantasai: I don't like that, because you have to have some exceptions,
which is what we have already, and it's already causing
interop problems
http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
Chris: How about making a grammar for what the prose already says
discussion of what mistakes web authors are likely to make
<ChrisL> some font families that might be useful for tests -
"101 Dalmations" "3.14 Pi" "Twenty 4px"
dbaron: right now the spec has document conformance reqs but no ua
conformance reqs
arron: If you run the testcases, you'll see a lot of constency
except for numbers and brackets
Arron to write up test results
<br type=cookies>
CSS2.1 Test Suite
-----------------
glazou: First issue is about inode strain on the server
bert: it's not about space, it's our mirroring system
Alex: Would adding another 15000 tests facilitate upgrading the system? :)
Chris: It's generating emails to the mirrors for each file
glazou: If solving this for w3.org involves more work for us on
the test suite, let's just move.
glazou: I suggest we do nothing and wait
bert: I also have an action to get the issues list onto w3c servers
Chris: The SVGWG had its working its files off-site on a company
server, then that company got bought and the files disappeared.
Took months to get the tar files back.
fantasai, plinss: Our server is not controlled by a company, it's a
personal account, funded by HP, but under plinss's name. So
we won't have that problem.
fantasai: We could create tarballs for the snapshots, just publish
the latest expanded out.
Arron: We're not getting a lot of traction on review of testcases
Arron: It's something that needs to happen
fantasai: Also people are reporting errors when they review, but not
whether tests have passed their review. Makes it impossible
to mark tests as approved.
Plinss: We decided we'd drive reviews by people generating
implementation reports
plinss: And then people can object if they find test is wrong
glazou: When will the test suite be complete?
discussion between glazou and fantasai about scheduling test suite work
fantasai aims to publish ts beta 1 in mid-April
Arron: It should take each browser vendors 2 days of 8 hours each
to run an implementation report
Glazou: We must be in PR by September, keep that in mind
Vendor prefixes
---------------
Bert: Why?
glazou: There's been a bunch of discussion on www-style
glazou: I don't think the current situation is satisfactory from the
web authors pov
glazou: On filters and web-authoring tools side it's hell
Alex: Shouldn't be using experimental stuff until it's stable
dbaron: I think we should be able to find a way to declare things
stable until CR
Steve: There is a way. It's called CR. It hasn't received enough
review until then. It hasn't gone to last call
Steve: If you need to, make smaller modules.
<TabAtkins> @mixin border-radius(radius: 8px) {
<TabAtkins> -moz-border-radius: var(radius);
<TabAtkins> -webkit-border-radius: var(radius);
<TabAtkins> border-radius: var(radius);
<TabAtkins> }
<TabAtkins> .box-with-corners {
<TabAtkins> @mixin border-radius(12px);
<TabAtkins> border: 2px solid black;
<TabAtkins> }
<TabAtkins> ^^^ make an end-run around the issue with additions to syntax
glazou: I think we should have a frozen status for features
Steve: ... W3C process
dbaron: The versioning process of CSS isn't a W3C process issue
anne: What impl do or not doesn't have anything to do with process
Steve: You should be at CR when you write the tests because that's when
the spec is stable enough to write a test suite
Steve: We have good examples where removing the prefix would have been
a mistake
Howcome: We have had decisions in the past, when we said they will never
change again, even though they're not in CR. I think that makes
sense
Steve: The reason it doesn't make sense is that part of Last Call, which
is the part you're living out, is to get review from people /not/
in the WG. And you're not getting that review
Tab: I agree with Steve. I think we should stick with this model.
Bert: The problem is we do so many things simultaneously. We should focus
on things that are stable and /finish/ them. Then we wouldn't have
this problem.
Tab: We could make vendor-prefixes less painful for authors we could use
a mixins syntax
Tab: This example is simple one, for border-radius.
Tab: If one implementation had a slightly different syntax, you could just
change it in the mixin definition
Tab: And you only need to write it once
Tab: every time you need border-radius
glazou talks about HTML's versioning model
Tab: I don't like HTML5's model. It's much nicer in JavaScript
Tab: JavaScript can afford to be ugly because you can layer a nice api over it
dbaron: I think the big problem is not the model, but the timing of how
we've been advancing properties
howcome: It's been a problem only for a few, more than one but only a few
glazou: Whether it's a problem for a property depends a lot on how popular
it is
...
Alex: Isn't it a problem that we have an unprefixed 'zoom' property?
It looks like a regular standard property but it isn't
dbaron: We haven't changed our border-radius prefix because we don't
yet match the current spec
dbaron: Most of those issues are not even syntactic
dbaron: There are a lot of requirements in the current spec that we
don't implement
dbaron: I had questioned at the time whether the spec needed to
require things in that much detail
howcome: I think you should drop the prefix anyway. Even if you have
some bugs left. They're just bugs
Brad: If we had dropped the prefix for border-image earlier, we'd be
stuck with the old definition
Brad: We wouldn't be able to make the changes I proposed.
Brad: We thought it was stable.
dbaron: I've heard comments from people who were unhappy that the
prefixed versions didn't match the spec
...
Steve: Why isn't macros, by any other name, a good solution to this?
glazou asks questions that were answered previously
the minute-taker will not repeat the answers
plinss: If they have different behavior?
<Bert> (One way to do mixins, especially usefule if you work with
Ruby: http://sass-lang.com/ )
Tab: If it's just syntactic, you can work around it. If you can't,
then you're screwed anyway
Steve: If they don't do what you want, dropping the prefix isn't
helpful anyway
Plinss: The problem with this is, what if I change something via JavaScript?
Anne: Maybe you don't see it in JavaScript
...
howcome: This saves people 30 seconds of copy-pasting. It's not
really a problem
howcome: I think this problem is over-rated
<anne> I agree with howcome
Tab: If we want to drop prefixes on something not in CR, we should
pull it out into another module
Bert: We did that with css3-backgrounds, we dropped box-shadow so we
could move everything else forward
Tab: Yes. That would solve this while giving us all the benefits of CR.
Steve: We can solve this problem by focusing on what's important and
pushing that forward
glazou: You don't know whether something's going to be succesful when
you design it
some arguments that it doesn't matter, you'll find out quickly
others that you can predict it for some things anyway
Steve: Once you find out something is popular, then you progress it faster.
glazou: If we accept the extra work to extract properties and push it
forward, then it's not a problem
Chris: Depends on how much of the spec is stable. If it's mostly stable,
pull the unstable things out and move the whole thing
Chris: If it's mostly unstable, extract the stable parts and push that
forward.
Anne: Other WG's have pseudo-stable drafts that are implemented and
shipped, and only take small changes
Anne: It seems to work relatively well
Steve: Yes and no
-> offline
glazou: If we have a high-priority set of properties, let's try to extract
them to move faster
Status-type Stuff
-----------------
Style-attr Status
-----------------
glazou: Last Call period ended. Need to check comments and write
disposition of comments
fantasai: I'm waiting for a response from SVGWG, other than that it's
pretty much done
http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
dbaron: Should include tests for common problems
dbaron: like braces around the declaration block
Media Queries Status
--------------------
glazou: CR period ended a few months ago
glazou: We don't have a test suite, I think
Anne: a lot of tests submitted, but no suite
glazou: So, what do we do?
Anne: We find someone to go through the tests and make a test suite
howcome: We already found him
howcome: Can't you do that?
anne: I'm not sure I want to
howcome: That wasn't my question :)
anne: We have a lot of different tests, they're not all in the same format
Anne explains some of the types of tests that were submitted
discussion of how to test the 'grid' feature
glazou: Are you able to handle the media queries test suite, or not?
anne: I would rather not. I haven't done any work on it
anne: the tests are posted to various mailing lists
Anne: I'm sort of swamped with editing
ACTION: clilley Find tests for media queries and check into test repository
Namespaces Status
-----------------
glazou: We're in CR, it is implemented
dbaron: I think we fixed the one parsing bug we had
glazou: We need implementation reports
dbaron: If the bug is in the 2.1 implementation, can we say that the
bug is in the 2.1 spec implementation and for the purposes of
Namespaces it's a pass?
<dbaron> Implementation report Firefox 3.6.2 Linux: all tests pass
<dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/
ACTION: glazou make namespaces implementation reports
CSS3 Page Status
----------------
fantasai: It needs a lot more work before another Last Call
CSS3 Backgrounds and Borders Status
-----------------------------------
fantasai: Planning to write 10-15 tests to set up, then will be
easier to accept submissions. Probably nothing complete
until August F2F at the earliest
CSS3 Color Status
-----------------
dbaron: Some LC comments are non-trivial. We should go through the
comments some time this meeting
dbaron: The current editor's draft addresses most, but not all,
issues. Haven't sent responses yet.
<dbaron> http://wiki.csswg.org/spec/css3-color is the issues list
CSS3 Backgrounds and Borders Issues
-----------------------------------
ScribeNick: TabAtkins
fantasai: 4 issues, somewhat related.
fantasai: All effect the shorthand.
fantasai: sylvain's issue was background-clip.
fantasai: Start with background-clip, do we allow content-box?
fantasai: As well, in the shorthand, I suggest that if *-box appears once,
it sets both origin and clip, while if it appears twice, it
sets origin to the first and clip to the second
bradk: I wanted to do bg-size first, so I could bring up that we could use
a slash to disambiguate this as well.
bradk: [on board] Right now you've got like "/ <bg-size>".
bradk: So apply that the same to origin/clip, so you could say, like
"border-box / padding-box" or just "border-box" or just
"/ padding-box".
TabAtkins: I want to avoid / whenever possible, though.
bradk: We're already using /s in various properties, border-radius, font,
border-image.
TabAtkins: In a lot of those, though, you're splitting apart lists of
numbers, and it's *impossible* to tell where things start and
end without the /. With keywords you don't need to do that.
anne: Other places with keywords, like overflow, don't need a /.
anne: And background-repeat.
bradk: You need *something* to separate bg-position and bg-size.
anne: Yeah.
bradk: You get some freedom with how you write things with the /
anne: Is that freedom actually needed, though?
TabAtkins: I don't think we need to generalize in order to solve the
position/size issue. Other places where we have a /, we
definitely need it; other places where we don't, we
definitely don't.
fantasai: I think separating them would make things more difficult.
fantasai: When you're parsing, you can just shove stuff into data
structures directly.
fantasai: You don't have to remember what has come before.
fantasai: That's part of why Yves wanted to relax the restriction
on ordering, so you just have to look at the previous token
to see if it's valid to put in a bg-position, rather than
having to remember that you had a size earlier in the rule.
fantasai: position is always a position. If size is completely absent,
it's a position.
bradk: Don't you have to read ahead to see if there's a size?
fantasai: No, as soon as you hit lengths, you know it's a position.
And then, later, you might see a slash denoting a size.
Bert: I think the main issue is just one of readability.
[discussion about human/machine parsability with a / anywhere in
the rule versus / immediately before a size]
TabAtkins: So can we add content-box to bg-clip, and accept the shorthand?
strawpoll: Add content-box to background-clip?
Abstain? 6
Objections? 0
RESOLVED: Add content-box to bg-clip
RESOLVED: Allow setting bg-origin and clip in shorthand
fantasai: Disallow "/size position", definitely.
fantasai: Allow "position url /size" and "/size url position"?
fantasai: Or restrict it to *only* "position/size"?
RESOLVED: Change background shorthand to have "<bg-position> [/ <bg-size>]".
(Position is required if you specify size.)
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0238.html
fantasai: Small one about border-radius.
fantasai: 1) Define gradient stops in more detail.
2) Don't define color-transitions at all.
howcome: So what was the problem before?
sylvaing: Today with different-colored borders, you get a sharp border.
If we want a gradient, we need a way that's interop across
browsers.
ChrisL: Currently the spec tells you where on the curve the midpoint is.
ChrisL: I think we should still be able to get that, and I think that's
enough to get a gradient.
ChrisL: [describes a linear-gradient based one]
sylvaing: Could we get it back through CR quickly with that?
<ChrisL> in fact i descriped two gradients, one from the start color to
the midpoint color and one from the midpoint color to the end
color; both linear wrt *angle*
sylvaing: I see it as a different issue. I want to control my corners,
and then I want to control my borders.
fantasai: I think making it undefined is fine, and then we have an
informative appendix illustrating some nice ways to join corners.
szilles: The experience of leaving things undefined is that someone ends
up defining them.
ChrisL: I understand the argument of doing the simple thing now and the
complicated thing now. But what I don't like is some browsers
having a sharp transition and you do a smooth transition because
you think it looks better.
dbaron: I haven't seen authors complain about this yet, but authors
*do* complain about performance, and sharp vs gradients has
performance implications.
sylvaing: If we later do 45deg corners, you'll need a linear gradient, etc.
fantasai: I'm fine with leaving it undefined right now, and we'll define
it in level 4 and we'll be good.
szilles: But we won't have that freedom after a little bit.
dbaron: I think I'm okay with that lack of freedom.
fantasai: If our browsers do something right now that authors don't like,
we'll change.
dbaron: sometimes it's best to let the market decide
sylvaing: I'm fine with specifying sharp transitions, and I'm fine with
undefined.
<fantasai> Proposal is: "It is not defined what these transitions look like."
Tab: I'm fine with explicitly undefined, being defined later possibly
constrained by market forces.
Chris: I would prefer it to be defined, but I can live with the other options
arronei: From a testing perspective, I prefer defined.
dsinger: If someone *requires* a particular effect, they can use a
border-image, right? I'm okay with leaving it undefined
and waiting to see what people start hacking around it with.
dbaron: We can define the shape of the border, we can define the limits
of the transition, we just won't define what it looks like other
than that.
RESOLVED: proposal 3 accepted
szilles: So all existing hard-edged impls match that proposal?
glazou: yes.
glazou: howcome, you have the floor for box-shadow
howcome: box-shadow was removed to gain speed for the spec.
howcome: We now have 4 interoperable impls of box-shadow, so I think
we should put it back in.
howcome: Or else put it in it's own spec.
glazou: I have some tests, and it looks interoperable.
howcome: [looking at MS people] I suspect they have something up their sleeve.
sylvaing: We'd like to see it back in.
howcome: So we have interop, why was it removed?
TabAtkins: There were significant complications being suggested, to
the point where it *was* going to slow the draft. A very
simple box-shadow, what we have interop on, would have been ok.
howcome: My position is that we add it back in. Simple list of lengths,
a color, an inset/outset keyword. Purely rectangular (module
border-radius).
RESOLVED: Put the simple version of box-shadow back into B&B.
GCPM - env() function
---------------------
<plinss> http://dev.w3.org/csswg/css3-gcpm/
<plinss> http://dev.w3.org/csswg/css3-gcpm/#string-set
howcome: If you print in most browsers, the browser will put the time
of printing in the margin box.
howcome: The idea is to make it possible to get that info in CSS.
<ChrisL> env(location.lattitude)
<dbaron> Is this going to gradually turn into strftime?
dbaron, yes.
<dbaron> 2010年04月02日 vs. 2010-04-02 vs. 2/4/10 vs. 4/2/10 vs.
2/4/2010 vs. 4/2/2010
glazou: A long while ago, around CSS2, we had a proposal for a date()
function, Misha Wolf (sp?) gave a long, excellent argument
for why date is no good.
szilles: How does the system know what to output the date as?
glazou: From the system locale.
szilles: That assumes the locale it is printed in is the same as the
locale it is read for.
glazou: That's the same problem that you *already have* with dates
on printouts, you're just styling them now.
[discussion of how Word does stuff/locale bindings]
howcome: There is a way to just ask the system for the date, and
env(date) would just give that.
szilles: What's the use-case for this?
howcome: Use-case is, when a browser prints a page today, they put
the date on the printout. This would give you control over that.
szilles: I'm printing a document that's written in Armenian, and
I'm going to distribute it to my Armenian friends.
howcome: By adding this feature, we allow ourselves to turn it
off as well.
szilles: I could potentially turn it off with just a little checkbox
in some preferences.
TabAtkins: No browser lets you do that right now. We can solve it
through CSS.
Bert: Some javascript to get at things from your environment (such
as if you are counting in the jewish date) that you may not want.
glazou: You already have (new Date()).toLocaleString().
szilles: My issue isn't with whether you want url or date. My issue
is more the discussion from Mischa, where the date is a very
dangerous thing.
szilles: I don't think there's a such thing as the "date".
TabAtkins: You're trying to add things to what we just want to simply cssify.
<anne> javascript:(new Date).toLocaleString()
<anne> Monday March 29, GMT-0700 2010
smfr: Is the intent to limit it to Paged Media?
howcome: No, it can go in content property, so it can go anywhere potentially.
smfr: When is the date set? Is it live? Does it update when the
page is refreshed? What about if layout changes something?
glazou: More detail is needed there.
glazou: Sometimes when printing, the *username* is displayed on the printout.
We shouldn't give access to that.
howcome: So it seems like this is potentially a useful thing, but
there are security and i18n concerns.
bradk: Date, or date and time?
howcome: We can do env(date) and env(time).
plinss: Some printouts have the document title.
howcome: You can already pull that from <title> using string-set.
<smfr> http://dev.w3.org/csswg/css3-gcpm/#turning-elements-into-footnotes
howcome: Small issue with footnotes. If you're in the draft, look
at example XXIV
howcome: display footnotes stacked vertically, or flowed inline.
howcome: My first idea is to use display on the footnote element
that determines what it does here.
howcome: But I think this is sorta inconvenient, as when you're
floating an inline element you'd have to explicitly set
display:block.
arronei: What about float:footnote and float:inline-footnote?
Then you don't have to mess with display.
TabAtkins: I like that idea.
bradk: And could we then do display: list-item on the footnote to
auto-generate the marker.
glazou: You cannot use list-item, because it precludes an inline footnote.
howcome: Suggestion: Put display:inline on the @footnote rule, to
switch the display type of the footnotes. It's a bit of
a hack, but display is otherwise unused in @footnote.
<sylvaing> sylvaing has joined #css
howcome: Input is great, we'll discuss more on the list.
howcome: I'd also like a new editor's draft.
Meeting closed.
Received on Thursday, 8 April 2010 07:15:25 UTC