- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 30 Mar 2010 23:17:01 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed status of i18n test submissions
- RESOLVED: Change prose of url() syntax definition to match grammar,
specifically, drop the requirement to escape commas.
- CSSWG received a request to review the View Modes spec
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
- RESOLVED: No comments or spaces between a and n in an+b for :nth-child.
Comments and spaces allowed at other (token) boundaries.
- RESOLVED?: No // comments in CSS -- nice to have, but too late to add.
- RESOLVED: Physical directions in CSS are absolute: margin-top is always
the top margin even in other writing-modes.
- Filed issue on whether overflowing floats are sensitive to bidi
- RESOLVED: Physical directions in CSS are absolute: margin-top is always
the top margin even in other writing modes.
====== Full minutes below ======
Present:
Tab Atkins (Google)
David Baron
Bert Bos (late)
Brad Kemper
Beth Dakin
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Håkon Wium Lie
Chris Lilley
Peter Linss
<RRSAgent> logging to http://www.w3.org/2010/03/24-CSS-irc
Scribenick: TabAtkins
Administrative
--------------
glazou: If you're attending the ftf and haven't notified anyone at apple,
please do so.
glazou: Bert is going to organize a social event on tuesday night, please rsvp
glazou: Most of us will be in town on Sunday, can we meet for dinner?
glazou: Meet at Cupertino Inn at 7pm and find a place.
<smfr> dbaron: rsvp on the day should be fine
<ChrisL> I land at 21:45 so thats too late for diner by the time I get
from sfo to cupertino
howcome: Any additional registration requirements beyond the attendance form?
glazou: No, if you said you would attend Tues night on the form, it's fine.
<dbaron> I'm also arriving in town too late to meet for dinner
<sylvaing> Registration form at http://www.w3.org/2002/09/wbs/32061/css-wg-cupertino-2010/
includes tuesday social RSVP
glazou: extra agenda items?
glazou: Request from jdaggett to defer the font-size-adjust issue to the ftf.
glazou: fantasai, any problem?
fantasai: It was dbaron's idea, actually.
CSS2.1 Test Suite
-----------------
glazou: Test suite!
glazou: Peter and I have an update on the i18n tests from Ishida.
glazou: He showed me evidence that he began proposing his tests a year ago,
so we can acccept his tests.
glazou: They were ready months ago; this wasn't someething that just popped up
arronei: I looked over the tests. They need some small tweaks, but
otherwise should be able to be put right in.
glazou: Anything else on the test suite?
arronei: Just need more people to review the suite.
fantasai: If you review and it's good, please let me know (obviously, tell
us if it's bad).
TabAtkins: Location of the test cases?
fantasai: /Style/CSS/Test, you can get to it from there
CSS2.1 Issues
-------------
glazou: We have 2 relatively big items on the agenda, and several minor ones.
Let's start with the minors and maybe leave majors for ftf.
everyone: yes
glazou: First is from sylvain, about escaping commas in unquoted urls.
sylvaing: Essentially, part of the prose appears to be out of sync with
tokenization rules.
sylvaing: In URIs you need to escape commas, but that's not true, such as
with data: uris with a comma before the base64 bit.
sylvaing: We ran into this when we tried to implement the mandatory
escaping, so the prose is out of place.
ChrisL: In a data URI, the comma is in a known position. You can parse
it because you know exactly where that should be.
ChrisL: Does this appear in other uri schemes or just data?
dbaron: Plenty of http uris with commas in the file names
dbaron: CSS parsers uniformly accept them.
dbaron: Don't know offhand of examples of using it in the CSS; I see it
often in page urls.
<dbaron> See e.g., the "United News and Deals" URLs on http://www.united.com/
ChrisL: The CSS parser isn't tripping up on that, right? So the
grammar/parser is fine, but the prose is wrong?
sylvaing: Yeah, we need to fix the prose.
ChrisL: So what exactly needs to be removed?
dbaron: The prose lists what needs to be escaped, we just need to remove
the commas. Everything else the prose lists is fine.
glazou: Objections?
everyone: no.
<ChrisL> just checking that the others listed were all correct
RESOLVED: Change prose of URI production to match the grammar, dropping
the requirement to escape commas.
View Modes Spec
---------------
<glazou> http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
glazou: Request to review the View Modes spec.
glazou: Saying we need an event-based part of the spec, not just basing
it on media queries.
glazou: So let's send comments in 2 weeks time.
:nth-child and comments
-----------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0190.html
glazou: Next is clarification. nth-child and comments inside the argument.
glazou: We never thought originally of comments inside the argument.
glazou: Tokenization rules allow comments everywhere.
glazou: From a "respect to the spec", we should allow comments everywhere.
glazou: But also the an+b parsing is already very complex, and I wonder
if it is worthwhile to allow another level of complexity.
glazou: I don't care either way.
ChrisL: It currently says comments everywhere between tokens; I'd be
unhappy if it said "most comments between most tokens".
ChrisL: We'd have to make it a single atomic token, if we want to be consistent.
+Bert
TabAtkins: And then we just have to detail the production of an+b in prose?
ChrisL: Sounds like it.
howcome: Comment from an opera dev, he thinks the definition of the n term
is wrong.
howcome: He thinks that using the terms odd and even is mixing up the
grammar and lexer spec.
fantasai: Two grammers in Selectors, one is general grammar you plug into
selectors. The second is a more specific grammar for the an+b
notation.
fantasai: That one is not there to be a grammar so much, that you would
plug into your parser, but rather to make sure the syntax is
unambiguous.
<howcome> First of all, an integer followed by an {N} will be tokenized as a
<howcome> DIMENSION. The grammar above will match: "2/*comment*/n" but not "2n".
glazou: Mozilla doesn't implement this grammar, frex, it tokenizes normally
according to CSS.
dbaron: Question for us is, in terms of that grammar does the an part of
an+b have to tokenize as DIMENSION, or can it tokenize as NUMBER
plus IDENT.
fantasai: I think it should tokenize as dimension.
TabAtkins: What's the technical difference?
glazou: In DIMENSION you can't have a comment, NUMBER plus IDENT does.
fantasai: If you accept NUMBER plus IDENT you'd accept "2 n", which is wrong.
dbaron: No, because we wouldn't look for whitespace.
howcome: I just pasted in my developer's feedback; he says that the grammar
will match 2/*comment*/n, but *not* 2n.
TabAtkins: I think DIMENSION would be better, since if I put a comment in
there, I expect whitespace to be there too.
fantasai: He missed the DIMENSION token.
glazou: He looked just at the special subgrammar, not as the normal CSS
tokenization.
fantasai: I think we should clarify that it should parse as a dimension.
fantasai: And we should clarify where comments are allowed.
fantasai: So based on the real grammar, we should be allowing comments
between n the sign, and between sign and b.
dbaron: I think that's not really the way to fix it.
dbaron: I don't think we want a grammar for an+b to describe where the
comments can go.
dbaron: We should describe that the an+b does *not* describe a grammar
itself, that you should accept normal CSS tokens.
dbaron: And that the an+b grammar is just a restriction.
glazou: So we specify that the first token has to start with n or - or
be a dimension.
sylvaing: So comments are not allowed?
glazou: Not between the a and the n.
fantasai: comments wherever there is a space token allowed.
fantasai: We can add a comment that we expect the an part to tokenize
as a dimension or an identifier.
<dbaron> Also, the whole thing can tokenize as a dimension/identifier,
e.g., n-1 is an identifier and 2n-1 is a dimension.
sylvaing: Extra problem we ran into. We keep implementing something,
and then someone says, "Oh, that's the wrong grammar!".
sylvaing: Too much arcane knowledge about which grammar overrides what.
This is a problem.
sylvaing: Seems easy for implementors to get this wrong, for them to
implement a subgrammar that should only be informative, etc.
howcome: Agree that it should be clearly labled to supplement the prose.
sylvaing: Yeah, it's not a *huge* problem, but it happens regularly.
sylvaing: Now that we have modules, it's more broken apart, and we need
to be more clear about it.
ChrisL: That should be easily dealt with by putting in an informative
sentence that says, "Aspects of this grammar are modified by
the grammar/prose over at XXX."
ChrisL: We should know all the grammar details while writing something.
RESOLVED: No comments or spaces between a and n in an+b, allowed elsewhere.
ACTION glazou: Revise prose in an+b section of nth-child to specify
comments and productions.
// Comments
-----------
glazou: item 7 jdaggett asked to defer
glazou: item 8 - someone again asking for comments with a //
glazou: It's easier for authors and so on.
TabAtkins: I used // comments a lot when I was first starting, and didn't
notice errors since the invalid rule that it started got
swallowed by } and such.
glazou: Yeah, and it trips me up a lot when I switch between javascript
and css
howcome: This should have been there from the beginning, but don't have
as much luxury to change it now.
ChrisL: It already says comments are allowed anywhere, right? Could we
just put this in?
dbaron: It does break the forward-compatible grammar, in that old
implementations will screw things up.
<dbaron> ... if they see a //-commented-out {
plinss: It comes up once a year, and we always say no.
glazou: That's not very satisfying.
fantasai: We have comments, just not in the particular syntax that people
want. I agree with Peter that it's probably too late now.
fantasai: At this point it would likely cause too many problems to add.
glazou: Okay, issue closed.
% Height Calculation
--------------------
glazou: Two items left, % height calculations and float bidi issues.
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0080.html
dbaron: % height is helped by a whiteboard.
Float bidi issue
----------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0088.html
glazou: Defer to ftf, then.
glazou: Float bidi issues, then.
TabAtkins: As far as I can tell, the first link is asking whether, when
we float:start or end, the scrolling/overflow behavior of the
containing box should change.
dbaron: Frex, if you're in ltr and you ahve an auto left margin, it
right-aligns the block if it's narrower than the container,
but left-aligns if it's wider so you don't have content
that's unscrollable.
<dbaron> ... and the question, I think, is whether we want to do the
same thing for floats.
dbaron: So the question is if we want to do the same thing for floats.
dbaron: Last time we tested, I think some impls did this.
fantasai: I think start and end should compute to a used value of left
or right, and then should just act normally.
TabAtkins: I agree. That means there's no issue?
glazou: So, fantasai, there's nothing to do?
fantasai: Nothing special to do for start/end.
fantasai: dbaron's talking about a different issue, not actually related
to start and end.
TabAtkins: Yeah, the first email is indeed talking about something
independent of float:start/end.
glazou: Do we need to bring this up during ftf?
dbaron: I think someone needs to write some tests and figure out what
implementations do. I may have done it in the past.
glazou: Let's defer this to a later time, then.
Filed as http://wiki.csswg.org/spec/css2.1#issue-165
Writing mode and directional properties
---------------------------------------
glazou: Next email, we have left/right values for a lot of properties,
but not start/end.
dbaron: I think there's been discussion about padding/border before,
and me and fantasai separately did proposals for that.
dbaron: outline isn't relevant, because we don't have outline:left/right.
fantasai: We talked about background-position in a ftf.
fantasai: We decided to deal with that in the next level, because it
may also touch on flipping the image and such.
<dbaron> there was also a more recent thread on background-position
glazou: David, how does mozilla implement margin/paddings in an rtl context?
<dbaron> http://lists.w3.org/Archives/Public/www-style/2009Dec/0269.html
dbaron: We implement -moz-margin-start, etc.
sylvaing: [something about changing what left/right/top/bottom refers
to when changing writing direction]
glazou: When a web author has to reverse the content of a webpage for rtl,
he has to tweak the stylesheet.
fantasai: I think that having margin-start, etc would be great.
fantasai: There was was a proposal from Andrew to have :ltr and :rtl
selectors that would select based on the direction information
in the markup language (@dir in HTML).
glazou: That's equivalent to writing two stylesheets, though.
fantasai: I think we've got two proposals for *-start, etc, so we should
discuss those. Not today, there are complex cascading issues.
howcome: It's a can of worms. We don't want to go there.
glazou: It's because you're not writing webpages in Arabic.
howcome: Left is left and right is right in lebanon.
howcome: You can use, say, the lang selector today to style differently.
ChrisL: Not sufficient anyway. We have ltr languages, and then bidi
languages, which are rtl some of the time and ltr others.
You can't just reverse things unilaterally.
<ChrisL> others - meaning numerals, which are written ltr
<sylvaing> http://lists.w3.org/Archives/Public/www-style/2010Mar/0279.html
sylvaing: I'd like to bring up murakami-san's email.
sylvaing: Essentially, he noticed that some browsers like IE change
top/bottom/left/right based on writing mode.
sylvaing: So if you're in japanese and set padding-top, it pushes your
content to the left.
sylvaing: He proposed a way to detect this. It's hacky, but I understand
what he's trying to solve.
sylvaing: He brought up an important issue - ebooks and epub, which is
xhtml and css2.
sylvaing: People will address this themselves and come up with their
own properties if we don't solve this ourselves.
fantasai: I think that's a great point. I think we should definitely
address this.
fantasai: I think it was clear from previous WG discussions that the
physical directions should be absolute - margin-top should
always be the top margin.
fantasai: If we need something to respond to the writing mode, it
should be an appropriately-named property.
everyone: yes
RESOLVED: Physical directions in CSS are absolute: margin-top is always
the top margin even in other writing-modes.
glazou: All for today, have a safe trip, we'll meet at apple at 9am.
Received on Wednesday, 31 March 2010 06:19:53 UTC