- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 17 Nov 2010 14:55:20 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Mark the attr() function in Values & Units as at-risk.
- RESOLVED: Make it explicit in CSS2.1 that other unicode linebreaking
characters have undefined linebreaking behavior.
- RESOLVED: Remove the concept of percentage intrinsic widths and heights
from CSS2.1.
- RESOLVED: Update CSS2.1 definition of clip to be physical in nature.
- RESOLVED: Push 2007 snapshot to CR.
- RESOLVED: Don't change the border-image shorthand.
- RESOLVED: Proceed with publishing B&B to CR.
- RESOLVED: Publish 2010 snapshot as FPWD.
- Discussed remaining editorial issues with css3-writing-modes draft.
====== Full minutes below ======
Present:
tab Atkins
David Baron
Bert Bos
Cathy Chan (Nokia)
John Daggett
Arron Eicholz
Elika J. Etemad
Simon Fraser
Daniel Glazman
Koji Ishii
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Alex Mogilevsky
David Singer
Steve Zilles
Someone Zakim identifies as "Tal"
<RRSAgent> logging to http://www.w3.org/2010/11/17-CSS-irc
Scribe: Tab Atkins
CSS3 Values and Units
---------------------
plinss: Any late agenda additions?
arronei: My email about the attr() function.
arronei: At the meeting I thought we discussed marking it at-risk,
but I didn't see it in the at-risk list for Values & Units.
Are there additional updates pending, or did we decide not
to mark it at risk.
plinss: Doesn't seem that anyone really remembers...
arronei: I don't think anyone really implements it, except for a
partial impl from us (and maybe FF).
fantasai: There's no harm in marking something at-risk.
RESOLVED: Mark the attr() function in Values & Units as at-risk.
<oyvind> I believe we (Opera) implement it too
Getting 2.1 done
----------------
plinss: How's work on RC4 coming?
fantasai: I haven't worked on the testsuite since TPAC, so that's
my plan today and the rest of the week.
JohnJan: Does this friday still seem like a doable deadline?
* alexmog likes Daniel's proposal for named gridlines
fantasai: Not Friday. I think Monday was the deadline? Maybe.
fantasai: I'm sure I can fix all my tests, but I'm not sure how
many Hixie/Moz/etc. tests I'd need to update.
JohnJan: So the expectation is for vendors to review your changes
by Dec 3rd...
JohnJan: If you could get them done before Thanksgiving, I could
spend some time over thanksgiving weekend doing reviews.
plinss: is there anyone else who can help with that?
plinss: Any CSS2.1 issues?
fantasai: The white-space property says linebreaks are only caused
by linefeed chars, but that doesn't include the lineseparator
character, which isn't collapsed and which has different bidi
implications.
fantasai: So maybe we should change 2.1 to say that any noncollapsed
characters that, per unicode, should force a linebreak,
should force a linebreak.
bradk: Any danger that people might accidentally have them in their source?
fantasai: Probably not - they're pretty hard to type.
tabatkins: It feels like any breakage that would occur would be
extremely minor.
bradk asks if they would be copy-pasted from e.g. InDesign
Tab doesn't think so
tabatkins: Changing this would mean we need new tests?
fantasai: I'm already using them in a bidi testcase right now, so it's
already there.
plinss: So are we willing to make that change?
tabatkins: I'm probably not in a good position to make the decision,
but since we already are testing for it incidentally, I'm
okay with it.
plinss: Do we have any passes on the relevant tests?
fantasai: No.
fantasai: I think it's important to have going forward, because HTML5
needs the disctinction in linebreaking characters to handle
some of its bidi bugs.
plinss: If nobody passes a relevant test yet for it I'm uncomfortable
actually requiring it, but I'm okay with leaving it undefined.
tabatkins: Elika, are you okay with changing the text to explicitly
say that the linebreaking behavior of other unicode
linebreaking characters is explicitly undefined?
fantasai: Yes. It makes it hard to test some bidi things, but oh well.
RESOLVED: Make it explicit in CSS2.1 that other unicode linebreaking
characters have undefined linebreaking behavior.
plinss: With RC3 of our testsuite, we need 800 more passes. 770 or so
them we just need more results for.
<plinss> http://test.csswg.org/harness/results?s=CSS21_%HTML_RC3&f=29
tabatkins: As soon as RC4 publishes I'll do another full IR for Chrome.
plinss: What bothers me is that we have about 100 tests that nobody
passes right now.
plinss: So this worries me. We need to determine if the tests are wrong,
or if impls are wrong, or change the spec, or argue that we can
live with this failure and defend it somehow.
arronei: I know a fair number of the cases hinge on RC4 updates, and
browsers pass after the tests are fixed.
JohnJan: I think we also need to look at ones that only 1 browser has passed.
smfr: One criteria on impl is that the build must be at least a month
old. Does this mean that if we make a change to fix a pass, we
have to wait a month?
plinss: One of the IR requirements is that the feature must have been
stable for at least a month, to guard against a custom nightly
to pass a test that doesn't make it into main stream.
plinss: That doesn't affect whether or not we can use super-recent builds,
it just means we'll have to wait a month to report the results.
plinss: It's really just a restriction meant to keep people from gaming
the system.
plinss: arron, do you know how many blocking tests have been changed?
arronei: Not off the top of my head.
plinss: I'd like to get this list on the wiki so people can start doing
analysis.
JohnJan: Seems right to me.
plinss: So who can commit to making the page?
arronei: I was going to start working on that data anyway, so I can
work on that page.
arronei: I can get at least halfway today - definitely all the tests
listed, not necessarily all of them with details.
JohnJan: That would be a great start.
plinss: Ideally by next week I'd like to have a list of testcases where
we need to start discussing spec changes.
<arronei> http://wiki.csswg.org/test/css2.1/results
plinss: So everyone dig into this and start reporting status for these tests.
Topic: Percentage intrinsic widths and heights
plinss: Last week we wanted to remove percentage intrinsic widths and
heights, but were waiting for feedback from Apple.
plinss: We got that now, and they're okay with it. Any other objections
before we resolve?
RESOLVED: Remove the concept of percentage intrinsic widths and heights
from CSS2.1.
Topic: clip() logical vs physical
arronei: clip in the spec is defined logically, so in other writing modes
it will rotate, but all impls instead do physical.
arronei: I think we just need to change the spec for it.
arronei: If we changed impls to be logical it would probably break spriting
techniques.
dbaron: I think the original intention was to make it logical wrt overflow,
or something like that.
dbaron: But there's been a ton of change in this section, so I'm not
even sure anymore.
+howcome; got it
smfr: I talked to Hyatt and he thinks it should by physical.
RESOLVED: Update definition of clip to be physical in nature.
arronei: And now we'll have to think in CSS3 if we want to define a
logical version. ^_^
plinss: Do we have tests currently testing for this behavior?
arronei: No. I created a test for the mail, but we don't actually
have a test testing for logical/physical. I can convert
the test I wrote into one for the testsuite.
plinss: If it falls out of your work, do it; I was just wondering
if there were any tests needing to be changed.
border-image double slash grammar
---------------------------------
<Yves> http://lists.w3.org/Archives/Public/www-style/2010Nov/0078.html
Yves: The issue is the same as the previous one for background shorthand.
Yves: In background, it was possible previously to have a background
starting with a /.
Yves: Now in border-image there is the possibility of having two /s
in a row with no content between them.
Yves: Since / is used as a separator, it means that if you have a
parser you'll get nothing in between, which causes a problem
in the grammar.
tabatkins: That's just an empty group, right?
Yves: It causes a loop in grammar-based parsers. I suggest a value
to indicate that there is supposed to be nothing in the group.
dbaron: I don't understand the problem with the slashes. Is it a
technical problem, or is just something you don't like to
look at?
Yves: In CSS2.1 it says it's a separator.
dbaron: What part of CSS says it's a separator?
Bert: In the non-normative appendix only. In the normative grammar
it's just a token.
dbaron: So I don't believe this is really a grammar issue.
Bert: Depends on how strongly you believe in Appendix G.
fantasai: We did mark it non-normative.
<dbaron> I think Appendix G was also intended to be for CSS 2 and
not forward-compatible.
Bert: It might be easy to use a different separator.
fantasai: The current syntax has already hit CR.
Yves: I think that what you want is not really a separator, but rather
something that indicates the next section is not what you would
have expected, but a group higher up.
Yves: If it was not a separator, but some other character without that
meaning in CSS2.1, it would be better.
* glazou notes that CR is NOT an excuse for a potentially problematic syntax
Yves: This issue was raised when we talked about background properties;
it's been around for a while. It's just that only background was
fixed at the time, not this one too.
* fantasai doesn't see this as problematic, though. It doesn't violate
the core grammar, nobody else has raised an implementability concern.
It only violates the non-normative appendix grammar that is specific
to CSS Level 2
<glazou> Yves does raise an implementability concern right now
<sylvaing> I'd rather not change background syntax now
<Yves> it's not problemaic if you create a css3 parser or a css21
parser, but one that needs to read both... it's different :)
Bert: I agree it looks kind of ugly to have two slashes, but I don't
think it's a fundamental problem.
<dbaron> I think the "implementability concern" would also mean we'd
need to remove most of css3-selectors.
<Yves> not background, border-image
Yves: It's an issue if you want to parse both 2.1 and 3.
fantasai: Why can't you change the parser to parse the / per CSS3?
What in 2 wouldn't you be able to parse by making that change?
Yves: Basically it would mean changing most of it.
Bert: Only one place uses that right now, the font shorthand?
sylvaing: Why do we need one parser that can read both, as opposed to
two parsers?
<jdaggett> howcome: maybe we should have double-slash comments?
Yves: That's the code I have right now, and there's no version indicator
in CSS to switch off of.
<ChrisL> sylvaing - because there is no verson ihfo in css files, and
they can contain a mix of syntaxes from different levels
bradk: You can't just parse "//" as "/initial/"?
<sylvaing> ChrisL, so what ? you can run it through 21 and do 3 if
that fails.
* fantasai doesn't understand why Yves cannot change '/' to parse as
a normal token instead of something special
tabatkins: So what's the problem again? This is a CSS3 property, not
a 2.1 property. Why does it matter?
Yves: The way the parser/grammar works, it doesn't know this is a CSS3
property yet and so just registers a general parse error.
dbaron: I think the problem is the parser using Appendix G.
Yves: If the / isn't used in CSS2.1 I can deal with this.
* glazou this is another proof we don't have levels but versions...
fantasai: it's used only in the font shorthand.
Yves: I can see about that, but I'd like it removed from the Appendix too.
<ChrisL> @version 2.1;
<Bert> :-)
<Yves> if / was used as a separator in CSS3, then it won't be a different
version ;)
<glazou> plinss: move to next topic ?
Bert: We talked about removing the appendix entirely, because it
confuses people.
plinss: So any quick wrapup on this?
* fantasai suggests treating '/' as a unary operator
<fantasai> or something similar
<Bert> (Anybody has engineers with free time to help update the
validator?...)
tabatkins: The fix is just to change Appendix G, right? That doesn't
affect anything else in CSS.
<glazou> ChrisL: this level/version thing plagues us
<ChrisL> glazou, i agree it does
dbaron: The point of Appendix G is *just* for CSS2.1.
<glazou> plinss: let's move on for jdaggett 's sake :)
<ChrisL> and it would be lovely to tie the validator to css-beijing
or snapshot or whatever
tabatkins: [stuff about it only mattering for validating CSS2.1]
* ChrisL tired of removing orange or ::before from stylesheets to
pass pubrules
fantasai: I suggest *not* using the Appendix G grammar, and just
changing the grammar the impl is using to match what you need.
* bradk likes the slash, and thinks it is used elegantly in border-image
Yves: i can look at that, but I'd want appendix G grammar to be updated
for forwards-compatibility.
<glazou> TIME !!!
fantasai: What we're trying to tell you is the appendix G is *not*
meant to be a forwards-compatible grammar, it's *only*
for CSS2.1. The more restrictive and specialized for 2.1
it is, the better it is at its goal. That is not your goal,
that's okay.
<Yves> usure, thanks for your time!
plinss: let's take the rest of this discussion to email.
Transition requests
-------------------
<fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2010OctDec/0180.html
plinss: Elika entered 4 requests. First was 2007 snapshot transition to CR.
RESOLVED: Push 2007 snapshot to CR.
plinss: B&B
plinss: Yves issue is the only one that was raised, apparently?
fantasai: There were others raised.
<fantasai> http://dev.w3.org/csswg/css3-background/issues-lc-2010
<ChrisL> Can't rejoin. I support the publication requests
plinss: The others were all addressed?
fantasai: Yeah.
plinss: So for the // issue am I hearing that we aren't accepting it
as an issue?
fantasai: It's past the deadline, but I can add it to the list.
RESOLVED: Don't change the border-image shorthand.
RESOLVED: Proceed with publishing B&B to CR.
* sylvaing yay CR !
<szilles> +1 to publish B&B
<dbaron> Is there a draft of the 2010 snapshot somewhere?
<fantasai> http://dev.w3.org/csswg/css-2010/
<fantasai> sorry, forgot to send it to the list
plinss: Now, 2010 snapshot as FPWD. Everyone okay with that?
RESOLVED: Publish 2010 snapshot as FPWD.
plinss: Now, Writing Modes.
howcome: In Opera I'm seeing an end-of-comment marker before the
end of section 7.
howcome: So I'm not certain if something is supposed to be commented
and is not, or what?
<dbaron> I see end-of-comment markers both right before section 7 and in the middle of 6.1
<fantasai> http://dev.w3.org/csswg/css3-writing-modes/Overview.src.html
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Nov/0151.html
howcome: 6.2.5 (?) is different lengths in Opera and Firefox
jdaggett: <describes above email>
jdaggett: section 4.1 (especially second bullet point), section 6.1
jdaggett: it would be good to say: In CSS 2.1 we have sections 10.3
(widths) and 10.6 (heights), and those algorithms are inverted.
jdaggett: I see a lot of things that are weird editorially. I see
references to old writing-mode values (section 2 ex. 1,
several in 6.1.1)
jdaggett: Also, I think list of references is needed.
jdaggett: Also, this and grid alignment spec behave very strangely with
wide screen; illustrations fall behind examples. Was default
style sheet changed?
fantasai: I just made it float.
jdaggett: Seems to be causing a problem.
jdaggett: I'd like to see more text that points people in the right
direction of what calculations you're talking about.
fantasai: I can list those as examples but I can't be exhaustive.
jdaggett: I'm not looking for exhaustive list in FPWD.
jdaggett: But I think a lot of people have been confused about whether
we're doing logical properties are not, and I think the
current text is confusing about answering that confusion.
jdaggett: I think referring to CSS 2.1 spec and saying which algorithms
are switched, etc., would help.
fantasai: Would adding ... ?
<fantasai> "For example, the rules in 10.x are used to calculate the
height instead of the width, and the rule sin 10.y are used
to calculate the width instead of the height"
jdaggett: There are places where things don't say how it relates to 2.1;
I don't think it needs to be more than one sentence. But I
think there are cases where the used value and computed value
can be confused.
fantasai: (reads)
fantasai: I can give examples; can't say these are the only calculations
needed to consider.
jdaggett: I think the spec isn't really capturing the background material.
It would help if the first section (introduction or section 2)
gave more real documentation on what it is we're trying to solve.
jdaggett: Are we trying to solve vertical text, or also solve cases of
mixtures of scripts in various writing modes (which makes problem
more complicated).
fantasai: There's a reference from UTN22.
fantasai: I could copy examples from UTN22 into the spec if necessary.
jdaggett: That would be great... to copy enough examples to show the complexity.
fantasai and Bert work out what the preprocessor is munging and fix the
markup problems
Received on Wednesday, 17 November 2010 22:55:57 UTC