[CSSWG] Minutes and Resolutions 2010-05-26


   - RESOLVED: Murakami-san added as editor of CSS3 Lists
   - Discussed various open CSS2.1 issues, various actions assigned.
   - RESOLVED: Accept Yves proposal for CSS2.1 Issue 139
   - RESOLVED: Accept fantasai's proposal for issue 146
   - RESOLVED: Accept dbaron's proposal for CSS2.1 Issue 122
   - RESOLVED: No change for CSS2.1 Issue 144 (it's a quirks mode question)
   - RESOLVED: Removes nonsensical sentence listed in
               for CSS2.1 Issue 147
   - RESOLVED: Accept fantasai's proposal for CSS 2.1 Issue 153
   - RESOLVED: Add Bert's example about clearance for CSS2.1 Issue 157

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

   César Acebal
   Tab Atkins
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Hĺkon Wium Lie
   Peter Linss
   Alex Mogilevsky
   Shinyu Murakami (via IRC)

<RRSAgent> logging to http://www.w3.org/2010/05/26-CSS-irc
   Scribe: Tab Atkins


   glazou: first item is about adding murakami-san as new editor for css3 lists.
   <fantasai> +1
   glazou: any objection?
   RESOLVED: Murakami-san added as 3rd editor of css3 lists
   <murakami> thanks

CSS2.1 Actions

   glazou: First lets review the issues for everyone.
   glazou: dbaron is not on the call yet.

   glazou: elika?
   fantasai: I haven't done any work on issues yet.
   glazou: When will you?
   fantasai: Early june, as I reported last week.

   glazou: Sylvain?
   sylvaing: Anton got back to me; we're basically done, but he's asking me
             to reconsider something.  I need to read through the whole
             thread which is very time-consuming.
   glazou: You're confident you can have a proposal for the issue by next week?
   sylvaing: Yes.

   glazou: Bert?
   Bert: 120 and 121 are being added.  I don't think any of the others
         need further discussion, though.

   glazou: Arron?
   arronei: Created test cases, but had some problems with uploading
            them last night; access was blocked for some reason.

   glazou: Tab?
   <glazou> http://wiki.csswg.org/spec/css2.1#issue-138
   TabAtkins: I'm still discussing issue 161 with boris, but I think I'm
              finally to a point where he's happy with the wording (even
              if not with the proposal itself).  I should have it wrapped
              up this week.

CSS2.1 Issues

   glazou: issue 138
   TabAtkins: I think that what fantasai explained as what it's "trying
              to say" is correct, but as boris says, we need to clarify it.
   fantasai: What about abspos?
   TabAtkins: Abspos elements act like blocks anyway, so that case should
              be less ambiguous.
   <fantasai> So we want something like appending "If any floats are
              contained by the anonymous box, then those floats are
              shifted, too." ?
   glazou: Who volunteers to write a proposal?
   TabAtkins: I'll try it out.
   ACTION Tab: Write proposal for issue 138

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-139
   glazou: Next, issue 139, a grammar issue.
   TabAtkins: Did we agree that that's a valid report?  If so, then it's
              clearly an error - the escape character should never appear
   glazou: Any objections?
   RESOLVED: Accept Yves's proposal for issue 139.
   Bert: I'll make the edit.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-146
   glazou: Issue 146.
   glazou: Seems pretty simple.  The marker box shouldn't be optional.
   TabAtkins: Are we going to accept elika's wording?
   glazou: It can be more explicit.
   fantasai: What do you mean?
   glazou: It should say "no marker when list-style-type:none", etc.
   fantasai: That's specified in the list section; this is the box
             generation section.
   RESOLVED: Accept fantasai's proposal for issue 146.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-118
   glazou: Now to the issues with no owner at all.  First is 118.
   * fantasai wishes dbaron was here
   Bert: It's imprecise.  The glyphs aren't centered, the "em box" is.
   TabAtkins: Yeah, not sure if we want to use the *term* "em box",
              but that's definitely the idea we're shooting for.
   fantasai: What other term would we use?
   TabAtkins: What about inline-blocks?
   fantasai: This section is about text; you need the assumption of
             a font for this to make sense.
   bradk: Some glyphs are taller than others.
   TabAtkins: Yeah, but their em boxes are the same if their font-size is.
   bradk: Do we define "em box" anywhere?
   TabAtkins: No.  It's a standard definition in fonts, but we should
              probably add a token definition of it.
   glazou: So we more or less agree; who's going to write the proposal?
   <sylvaing> thought the leading was line-height-font-size and went
              on top/bottom of the content area where the glyphs go
   Bert: I guess we need some text that says we assume each glyph is
         defined relative to an "em box".
   fantasai: And we assume that the font-size is mapped to the em box.
   <fantasai> or rather, the em box is mapped to the font size
   ACTION Bert: Write proposal for issue 118.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-122
   glazou: Next is issue 122, related to fonts.
   glazou: Reporter complains that the spec is redefining what "serif"
           and "sans serif" means.
   glazou: And we have a proposal from dbaron to solve that.
   TabAtkins: Agreed with dbaron's proposal - fonts already know if
              they're serif or whatever, and we can just have a weak
              description of what the terms mean.
   <howcome> http://somuchpun.com/?s=serif
   RESOLVED: Accept dbaron's proposal to resolve issue 122.
   ACTION Tab: Propose text for resolving issue 122.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-140
   glazou: I think david's proposal makes sense - it's probably the
           only way to solve this problem.
   TabAtkins: I don't have a deep enough understanding of the core
              grammar to know how good of a solution dbaron's proposal
              is, or what a better one is.
   Bert: Another option, certainly, is to change the example that
         spawned the issue, and remove the braces from between the
   glazou: People could still write that sort of thing, correct?
   Bert: Right, people can write things that can't be tokenized, and
         we just don't know what to do with them.
   glazou: I don't think that's a good enough solution.
   Bert: Do we want to define the meaning of every possible bytestream?
         I don't think that's needed.
   glazou: I think it would be useful.  ^_^
   glazou: I recommend waiting for dbaron to attend a call and get his input.
   Bert: It's probably okay to allow braces inside parens, but I'm
         still a little bit afraid.
   glazou: We'll revisit next week, and move on for now.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-142
   TabAtkins: We do need a definition of what the "ancestor box" is,
              because Boris and I disagreed on that while discussing
              my abspos-in-tables issue.
   glazou: So what's suggested to rewrite?
   Bert: Make it clear what the ancestor box is in all contexts.
   TabAtkins: Boris says 3 instances, and I'd *like* to depend on
              the definition of "ancestor box" in my table issue too.
   Bert: If it's only in chapter 10, i can do it.
   * sylvaing does, in his weaker moments, hope CSS gives box generation
              the HTML5 parsing algorithm treatment.
   * TabAtkins wants to do that too.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-144
   TabAtkins: I don't think we need to worry about 144 - it's pointed
              out that the reporter's results were from looking at it
              in quirks mode; the spec defines it precisely and all
              browsers agree in standards mode.
   glazou: So no action on this.  Any objections?
   RESOLVED: No action on 144 - not a problem.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-145
   fantasai: The i18nWG has been going back and forth on issue 145
             for a while.
   fantasai: We probably need to defer this for them.
   TabAtkins: i18n is having a meeting for bidi in html second week of
              june that fantasai and i are attending.  We can make sure
              it's discussed then.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-147
   fantasai: It makes sense to recommend scaling for images, but not
             necessarily for java applets, etc.
   fantasai: Sometimes you just want to rescale the box and just tell
             the replaced element to redraw itself in the new space.
   fantasai: Frex, java applet or iframe.
   fantasai: So I don't think it makes sense to specify how a replaced
             element draws in normative terms here.
   TabAtkins: Agreed.
   RESOLVED: No change for issue 147

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-153
   TabAtkins: I think the test case just needs to be updated, no spec
              change, right?
   glazou: fantasai says the spec is vague.
   TabAtkins: Ah, yes, I see that now.
   glazou: Any objections to elika's proposal?
   arronei: That means the test case needs to be updated too.
   TabAtkins: fantasai already provided an updated test case.
   RESOLVED: Accept fantasai's proposal to resolve issue 153.
   Action fantasai: Write text for 153.

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Dec/0322.html
   fantasai: Wrt the previous issue, 147, there's an email not tracked
             in the issue list pointing out a sentence that doesn't
             make any sense at all.
   fantasai: I think it should be removed, and Tantek agrees.
   * sylvaing YES! I could never understand this.
   * sylvaing ...now imagine documenting to the EU whether/how you comply
              with this one
   Bert: I don't see what's wrong with it.
   fantasai: If you specify a height, the width of the replaced element's
             box may not be intrinsic.
   Bert: Oh, in that sense.
   fantasai: It's weird, and it doesn't add anything since everything is
             otherwise specified.  So I think we should just remove it.
   RESOLVED: Remove the offending sentence in visudet.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-157
   TabAtkins: I don't think it's circular.  I think it can look like it to
              a surface reading, but it's just a statement of constraints.
   glazou: dbaron and bert have long messages explaining why it's not circular.
   fantasai: Bert has a nice examle that I think would clarify things.
   glazou: Can you add the example to the spec?
   RESOLVED: Add Bert's example about clearance, otherwise no change for issue 157.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-158
   TabAtkins: This isn't even a change, just a clarification.
   ACTION Tab: Suggest text to resolve issue 158.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-159
   TabAtkins: dbaron already has some rough text to resolve the issue.
   fantasai: I can take this; I'll probably be doing other margin-related
             things anyway.
   <glazou> http://wiki.csswg.org/spec/css2.1#issue-114

   glazou: Anyone know what SVG is doing about 114?
   arronei: Chris sent me a message about it yesterday.
   glazou: So they're working on it, excellent.

Meeting closed.
* fantasai will not be on the call next week
* glazou neither

Received on Thursday, 27 May 2010 04:36:12 UTC