[CSSWG] Minutes and Resolutions 2010-05-12

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 UTC