[CSSWG] Minutes and Resolutions 2010-03-24

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