W3C home > Mailing lists > Public > www-style@w3.org > May 2010

[CSSWG] Minutes and Resolutions 2010-05-12

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 16 May 2010 00:45:31 -0700
Message-ID: <4BEFA29B.80501@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - Reviewed status and ETA for actions on owned issues
   - RESOLVED: For CSS2.1 Issue 86, leave exact position of the bullet undefined.
       http://wiki.csswg.org/spec/css2.1#issue-86
   - RESOLVED: Mark 4a undefined in CSS2.1, accept dbaron's proposal
               (drop 4 and add parenthetical to 3) for 4b and 4c.
               Accept 10a. For 10b, add a note saying that baseline info is
               found in the font and this may be further explained in CSS3.
               http://wiki.csswg.org/spec/css2.1#issue-117
   - RESOLVED: Copy Selectors 3 wording into 2.1 for issue 143
               http://wiki.csswg.org/spec/css2.1#issue-143
   - RESOLVED: Add 'unicode-bidi: embed' to all blocks in CSS2.1 Appendix D
               http://wiki.csswg.org/spec/css2.1#issue-148
   - Also discussed
       http://wiki.csswg.org/spec/css2.1#issue-119
       http://wiki.csswg.org/spec/css2.1#issue-129

====== Full minutes below ======

Present:
   Tab Atkins (via IRC)
   David Baron
   Bert Bos
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Brad Kemper
   Chris Lilley
   Peter Linss
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/05/12-CSS-irc
<fantasai> ScribeNick: fantasai

Administrative
--------------

   glazou: please send minutes from last week
   * fantasai forgot
   glazou: No extra agenda items today

CSS2.1 Issues
-------------

   http://lists.w3.org/Archives/Member/w3c-css-wg/2010AprJun/0083.html
   glazou: Arron sent me an email on the status of the spec. We have 57
           open issues on CSS2.1
   glazou: list is in the agenda
[see addendum]
   glazou lists assigned actions
   glazou: 23 open and unassigned
   glazou: We have to solve all of these asap.
   glazou: Ideally we'd like to have all the proposals by the end of this month
   glazou: and assign the actions to update the spec and the test suite
   Bert: It's not as bad as it seems. All but 2 of mine are editorial.
   glazou: Let's browse the issues

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-26
   <glazou> http://wiki.csswg.org/spec/css2.1#issue-101
   dbaron: We came to a resolution for 26, but I need to write wording.
           101 I need to look into
   glazou: Can you do that before the end of the month?
   dbaron: I think so

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-53
   fantasai: I'm supposed to work on the test suite, so I probably won't
             get to CSS2.1 issues until beginning of June
   glazou: How do these issues impact the test suite?
   fantasai: Some will require test changes, other require more tests.
   arronei: I've been trying to track issues and write tests, but haven't
            caught everything
   <glazou> http://wiki.csswg.org/spec/css2.1#issue-60
   fantasai ... June
   arronei: Sylvain's issue, I think he just needs to send out a summary
            email on that.

   glazou: Bert?
   Bert: Haven't read through the anonymous table one, I had promised
         to do that before editing.
   Bert: The one on table captions and block-level items, #120, that
         will take me time
   Bert: but should be possible before the end of the month

   glazou: Arron?
   arronei: I should have the testcase ones today or tomorrow.
   arronei: I assigned one to myself about creating images for
            line-height etc. I can have that done this week

   glazou: Tab sent an email about his actions
   glazou: He did issue 161

   glazou: And will have a proposal for 110 by Friday.
   glazou: We have 11 issues assigned to the WG, and 12 that are unassigned

   arronei: Do we have feedback on the SVGWG one yet?
   ChrisL: In summary, I'm halfway through porting your testcases to SVG.
           Should be done by end of this week. We have an F2F end of may,
           so should be able to discuss and close the issue June 2nd

   glazou: First unassigned issue is 86
   http://wiki.csswg.org/spec/css2.1#issue-86
   dbaron: The horizonal position is straightforward, vertical maybe harder.
   dbaron: Could also leave it undefined
   fantasai: Prefer to leave it undefined, define in CSS3 Lists
   Arron agrees.
   <dbaron> actually, the complexity of horizontal and vertical isn't
            that different
   RESOLVED: Leave exact position of the bullet undefined.
   <fantasai> "The position of the list-item marker in the presence of
              floats and when text-align is not its initial value is undefined in CSS2.1."
   <bradk> "when adjacentg to floats" maybe?
   <fantasai> better

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-117
   <dbaron> I think this is basically
            http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html :-)
   <dbaron> at least 4a
   dbaron: I think 4b and 4c are relatively straightforward.
   dbaron: I think this was a point we missed when we added the strut
   dbaron: I think the solution is to remove bullet  and add a parenthetical
           to 3 mentioning the strut
   dbaron: "(Including the strut described below.)"
   dbaron: Although we don't actually say strut, we say "what TeX calls a strut"
   <fantasai> I suggest "(taking into consideration the strut mentioned below)"
   dbaron: 4a is the same as my message from 1999.
   dbaron: I think we resolved to leave it undefined in 2.1 and define it in 3
   glazou: fine by me
   fantasai: Do we need to make it explicitly undefined?
   dbaron: It's not currently stated as undefined
   RESOLVED: Mark 4a undefined in CSS2.1, accept dbaron's proposal
             (drop 4 and add parenthetical to 3) for 4b and 4c.
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html
   dbaron: I think 10a is editorial, but probably a good idea
   <dbaron> I think 10b is editorial; I have no opinion either way.
   Bert: There's more explanation in CSS3, but I wouldn't want to copy it all.
   several happy to leave explanation to CSS3
   fantasai: I don't see us having a motivation to work on CSS3 Line
             in the near future
   glazou: What are our options?
   Bert: The issue there is to mention that baselines are found in the
         font. Maybe we can make a note about baselines being found in
         the font metrics somewhere
   Chris: Yes, I think that's enough of a hint to say that they're in
          the font without having to import the whole css3 line module.
   arron: And maybe say at the end of that that this will be defined
          further in a future specification.
   RESOLVED: Accept 10a. For 10b, add a note saying that baseline info is
             found in the font and this may be further explained in CSS3.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-119
   arron: I think this can be done at the same time 120 is being updated
          with a new proposal
   dbaron: I think they're actually done rather different. The definition
           Anton cites for table cells is not really the definition that
           we want here anyway
   dbaron: The baseline of a block is the baseline the block would have
           if it had text in it
   dbaron: The problem is that what the baseline actually is depends on
           what characters are in the block. We just sort of ignore that
           issue and pick one
   dbaron: This another reason why the anonymous root inline box idea
           works better than the strut idea.
   dbaron: That said, I think the proposal in the issues list, to remove
           "block's", is the right idea here.
   * scribe didn't catch what Bert said, but it seemed to be agreeing
       with dbaron
   dbaron: I can also see changing block's baseline to line's baseline.
           But I'd be ok either way, and maybe Bert can come up with
           something better
   Bert: Either would work for me. Don't know which is better. Can't
         think of a third option.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-129
   Bert: It's a bit more complex than that. To get all the backup out
         of the parser, we'd have to change some of the tokens. I'm
         not in favor of that.
   Bert: There aren't many cases that change.
   glazou: Zack's email was mostly concerned about performance of the scanner.
   glazou: It is not necessary to implement CSS parsing using the tokens
           in the grammar, they are just there to define things.
   Bert: Yes, but you'd still have to buffer things no matter how you implement.
   dbaron: The point Zack made is something we generally want to be true:
           anything that is itself a token in the tokenizer, you want the
           same thing minus one character to also be a token.
   dbaron: Whether or not that thing is the same token is less important.
   dbaron: You don't want to start parsing a long token, realize it
           doesn't end, and have to go back all the way to the beginning.
   dbaron: The current place we have this problem is the url() token.
   dbaron: Gecko gets around this by handling it in the parser.
   glazou: The prose says it is a URI. If it's not a valid URI, it should
           be an invalid token.
   dbaron: ... we're scanning all these characters. We build a character
           buffer of the characters that will be the URL.
   dbaron: If we get a valid URL token, then we save it. If we don't, we
           go backwards to the start.
   dbaron: If you need to backtrack you have to go and reparse and match
           parentheses and things
   peter: Parentheses aren't allowed unquoted.
   dbaron: But essentially, if you're using a tokenizer, you have to
           backtrack through the whole thing and retokenize so you handle
           brackets and quotes correctly
   glazou: Is ... necessary?
   dbaron: I don't know.
   peter: We already say that url parsing is its own special world anyway
   dbaron: But in the error cases, you don't match that token. So if you
           follow the spec as written, you need to go back and retokenize
   dbaron: An example of an invalid url token is url(a'b)
   dbaron: One of the things Zack was proposing was to add a new token
           for invalid URIs so that you don't have to backtrack.
   dbaron: A token that represents the invalid cases so you don't have
           to go back and count brackets and braces.
   peter: I think I prefer that.
   peter: It may be a bit weird to define that token
   glazou: Ok, let's defer this until next week so we have time to discuss,
           dbaron with Zack, etc.

   http://wiki.csswg.org/spec/css2.1#issue-137
   Chris: I have some proposals for other issues
   <ChrisL> ISSUE 143 has already been dealt with, a very clear spec
            change looks good to me, suggest closing it
   <ChrisL> http://dev.w3.org/cvsweb/csswg/selectors3/Overview.html.diff?r1=1.66&r2=1.67&f=h
   ChrisL: fantasai's wording changes look good, let's put those in
   RESOLVED: Copy Selectors 3 wording into 2.1 for issue 143

   <ChrisL> http://wiki.csswg.org/spec/css2.1#issue-148
   <ChrisL> Add 'unicode-bidi: embed'  should be there
   dbaron: It was removed in the first WD of 2.1, but I can't find a
           record of why.
   ChrisL: It might have been removed because someone didn't understand
           why it was there. We all agree it should be there, so let's
           put iback in
   RESOLVED: Accept proposal for 148
   <dbaron> So I think the reason it might have been taken out was
            concern about embedding levels bumping above 63.
   <fantasai> Hm, yes, but we should have wording to prevent embedding
              levels from increasing on blocks

   <ChrisL> http://wiki.csswg.org/spec/css2.1#issue-156
   Issue 156 was resolved at F2F, resolution was not copied into issues list.

Wrap-up
-------

   * ChrisL vendor prefixes considered harmful
   glazou: Please review the vendor prefixes thread so we can discuss it.
   arron: Please everyone take a look through the unowned issues

Meeting closed.

====== Selected Excerpt from agenda ======

1. CSS 2.1 Test Suite status
----------------------------

We have *57* open issues for CSS 2.1 at this time. CSS 2.1 is then
not only the highest priority on our radar again but the sole
priority at this time.

http://wiki.csswg.org/spec/css2.1

We _must_ close down on these issues or we'll miss the end of the
year for this spec, and that is not acceptable.
Below is the list of open issues. We request that all due proposals
be submitted to the Working Group *BEFORE THE END OF MAY* to be
discussed immediately. We'll discuss today how to dispatch the
unassigned issues. If some issues are incorrectly listed as open,
please update the status as soon as possible.

dbaron (2):
Issue 26  http://wiki.csswg.org/spec/css2.1#issue-26
Issue 101  http://wiki.csswg.org/spec/css2.1#issue-101

fantasai (6):
Issue 53  http://wiki.csswg.org/spec/css2.1#issue-53
Issue 149  http://wiki.csswg.org/spec/css2.1#issue-149
Issue 151  http://wiki.csswg.org/spec/css2.1#issue-151
Issue 160  http://wiki.csswg.org/spec/css2.1#issue-160
Issue 162  http://wiki.csswg.org/spec/css2.1#issue-162
Issue 166  http://wiki.csswg.org/spec/css2.1#issue-166

Sylvain (1):
Issue 60  http://wiki.csswg.org/spec/css2.1#issue-60

Bert (19):
Issue 69  http://wiki.csswg.org/spec/css2.1#issue-69
Issue 71  http://wiki.csswg.org/spec/css2.1#issue-71
Issue 73  http://wiki.csswg.org/spec/css2.1#issue-73
Issue 84  http://wiki.csswg.org/spec/css2.1#issue-84
Issue 109  http://wiki.csswg.org/spec/css2.1#issue-109
Issue 111  http://wiki.csswg.org/spec/css2.1#issue-111
Issue 115  http://wiki.csswg.org/spec/css2.1#issue-115
Issue 120  http://wiki.csswg.org/spec/css2.1#issue-120
Issue 121  http://wiki.csswg.org/spec/css2.1#issue-121
Issue 127  http://wiki.csswg.org/spec/css2.1#issue-127
Issue 128  http://wiki.csswg.org/spec/css2.1#issue-128
Issue 130  http://wiki.csswg.org/spec/css2.1#issue-130
Issue 136  http://wiki.csswg.org/spec/css2.1#issue-136
Issue 141  http://wiki.csswg.org/spec/css2.1#issue-141
Issue 150  http://wiki.csswg.org/spec/css2.1#issue-150
Issue 152  http://wiki.csswg.org/spec/css2.1#issue-152
Issue 155  http://wiki.csswg.org/spec/css2.1#issue-155
Issue 163  http://wiki.csswg.org/spec/css2.1#issue-163
Issue 164  http://wiki.csswg.org/spec/css2.1#issue-164

arronei (3):
Issue 107  http://wiki.csswg.org/spec/css2.1#issue-107
Issue 134  http://wiki.csswg.org/spec/css2.1#issue-134
Issue 165  http://wiki.csswg.org/spec/css2.1#issue-165

Tab (2):
Issue 110  http://wiki.csswg.org/spec/css2.1#issue-110
Issue 161  http://wiki.csswg.org/spec/css2.1#issue-161

WG (11):
Issue 86  http://wiki.csswg.org/spec/css2.1#issue-86
Issue 117  http://wiki.csswg.org/spec/css2.1#issue-117
Issue 119  http://wiki.csswg.org/spec/css2.1#issue-119
Issue 129  http://wiki.csswg.org/spec/css2.1#issue-129
Issue 137  http://wiki.csswg.org/spec/css2.1#issue-137
Issue 138  http://wiki.csswg.org/spec/css2.1#issue-138
Issue 139  http://wiki.csswg.org/spec/css2.1#issue-139
Issue 143  http://wiki.csswg.org/spec/css2.1#issue-143
Issue 146  http://wiki.csswg.org/spec/css2.1#issue-146
Issue 148  http://wiki.csswg.org/spec/css2.1#issue-148
Issue 156  http://wiki.csswg.org/spec/css2.1#issue-156

No Owner (12):
Issue 118  http://wiki.csswg.org/spec/css2.1#issue-118
Issue 122  http://wiki.csswg.org/spec/css2.1#issue-122
Issue 140  http://wiki.csswg.org/spec/css2.1#issue-140
Issue 142  http://wiki.csswg.org/spec/css2.1#issue-142
Issue 144  http://wiki.csswg.org/spec/css2.1#issue-144
Issue 145  http://wiki.csswg.org/spec/css2.1#issue-145
Issue 147  http://wiki.csswg.org/spec/css2.1#issue-147
Issue 153  http://wiki.csswg.org/spec/css2.1#issue-153
Issue 154  http://wiki.csswg.org/spec/css2.1#issue-154
Issue 157  http://wiki.csswg.org/spec/css2.1#issue-157
Issue 158  http://wiki.csswg.org/spec/css2.1#issue-158
Issue 159  http://wiki.csswg.org/spec/css2.1#issue-159

SVGWG (1):
Issue 114  http://wiki.csswg.org/spec/css2.1#issue-114
Received on Sunday, 16 May 2010 07:46:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT