- 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