[CSSWG] Minutes and Resolutions 2010-08-11

Summary:

   - CSS2.1 Test Suite Beta 3 scheduled for this weekend; please try to
     get test fixes in by then
   - RESOLVED: dbaron's proposal accepted for CSS2.1 Issue 185 with
               modifications in the minutes
               http://wiki.csswg.org/spec/css2.1#issue-185
   - RESOLVED: Bert's proposal accepted for CSS2.1 Issue 118 with
               modifications suggested by Steve Zilles
               http://wiki.csswg.org/spec/css2.1#issue-118
   - Discussed interaction of text-decoration and visibility (CSS2.1
     Issue 144) with no conclusion.
               http://wiki.csswg.org/spec/css2.1#issue-144

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

Present:
   David Baron
   Bert Bos
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Daniel Glazman
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/08/11-CSS-irc
Scribe: fantasai

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

   howcome: any questions about f2f?
   SteveZ: Wanted to add one thing to agenda; will send email.

Test Suite
----------

   fantasai: Arron and I went through issues list and identified
             which issues need tests.
   fantasai: want to do beta3 at end of week
   fantasai: Please try to get in fixes by the end of the week

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

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-185
   fantasai: The mailing list also brought up the question of
             negative-height floats
   <dbaron> I had a proposal: http://lists.w3.org/Archives/Public/www-style/2010Aug/0178.html
   dbaron: I do prefer the idea that zero-height floats don't push
           line boxes, because it's easier to think about the range
           we're dealing with
   dbaron: This proposal deals with them by using exclusive ranges.
   fantasai: And negative height floats would also be excluded because
             they can't satisfy both c and d at the same time
   fantasai: I would be okay with this if there was a note saying that
             zero-height floats don't affect line boxes (and maybe
             explain why that's the case wrt wording in the text,
             because the exclusive ranges thing is subtle)
   SteveZ asks what is meant by "vertical position"
   <dbaron> ok, so maybe s/is a vertical position/exists a point/ and
            add Note: this means that floats with zero height or
            negative height do not move line boxes.
   <ChrisL> maybe change "when there is" to "when there exists" and
   fantasai: Could we change "not above" to "below or at"? I think that
             would help
   <ChrisL> that is to "that satisfies all of these four conditions
   Bert: So this means the zero or negative height float won't affect
         line boxes next to it
   Bert: but if it has clear, it still can affect layout around it
   Bert: What about floats next to floats, are those rules clear?
   dbaron: I think they're clear, but it might be worth rereading
   fantasai pastes modified proposal:
       Add somewhere after:
         # However, line boxes created next to the float are shortened to
         # make room for the margin box of the float.
       The following:
         | A line box is next to a float when there exists a vertical position
         | that satisfies all of these four conditions:
         | (a) at or below the top of the line box, (b) at or above the
         | bottom of the line box, (c) below the top margin edge of the
         | float, and (d) above the bottom margin edge of the float.
         | Note: this means that floats with zero height or negative
         | height do not move line boxes.
   Arron: I have a testcase for zero-height floats in the middle of
          the line box.
   ... arron reports his results ...
   dbaron: Last I checked neither Opera nor Webkit handle positive
           height floats in the middle of the line anyway
   <dbaron> maybe Opera is ok; my memory is a little fuzzy
   dbaron and Arron discuss the testcase
   <arronei> http://test.csswg.org/source/contributors/microsoft/incoming/float-zero-height.htm
   <gsnedders> Opera indeed doesn't handle it
   Peter: Any other comments on the proposal?
   ChrisL: I'm hearing disagreement on which implementations need to
           change, but everyone seems to like the wording.
   RESOLVED: dbaron's proposal accepted as modified above

   Peter: CSS2.1 Issue 118
   <plinss> http://wiki.csswg.org/spec/css2.1#issue-118
   * fantasai is happy with the proposal if Steve and Bert are happy with it
   <glazou> +1
   Steve: The existing text makes a reference to centering, but it's not
          clear what it centers or what it means.
   Steve: The text I suggested clarifies that, and Bert confirms that's
          what it means
   Bert: I will try to avoid the word "centering"; your text describes
         what actually should be done.
   WG votes to resolve on this now and protest Bert's edits afterwards if
      necessary
   RESOLVED: Bert's proposal accepted with Steve's modifications as to be
             edited in by Bert

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-144
   dbaron: Given the new model for text decoration that we haven't implemented
           yet, I would follow Opera's lead on question one
   arronei: I'm running the tests and everyone shows the underline
   ChrisL: Is there a use case for showing the nderline under invisible text?
   fantasai: No, it's just something that falls out of the previous model.
   fantasai: It doesn't make much sense to show the underline if you're trying
             to hide something.
   <glazou> Gecko 2.0 underlines once the whole thing
   ChrisL: Then perhaps we should change it to be more useful, not as likely
           to break things.
   ChrisL: But if we don't have implementations, that will hold back PR.
   Steve: We could go with "it's undefined".
   dbaron: I think we're already at the place where most implementations
           disagree with the spec on text-decoration, and we're planning
           to fix it but we haven't gotten around to it yet
   Steve: So you're going to have to change it to match the current 2.1
          text anyway
   Steve: If that's true, fine, we'll just make it another piece of the
          model change.
   fantasai: we could change it and mark it at-risk
   Seem to have agreement that if the text isn't there, the underline
        shouldn't be either.
   Bert: I would expect to see the blue line, but not the red one in that email
   fantasai summarizes Appendix E's contents
   fantasai: If you want the underline visible but not the text, you can
             make the text transparent.
   Bert and Peter discuss the underlining model -- specifically that the
     underline is continuous through the child elements, and if they have
     underlines they are additional (may paint over)
   Steve: I'm confused about what the current model is.
   Steve: There's two ways of thinking about it. One is, the property
          draws an underline
   Steve: The other way is that it turns on a mode so that each glyph
          draws its own piece of the underline
   Steve: I thought that the latter model is what the new one is doing
   fantasai explains the current model
   fantasai: The question is now whether the underline is drawn with
             the color *and* visibility of the underlining element, or
             it uses the visibility of the element with the text being
             underlined
   Steve: Suppose that you're animating the text to disappear, so the
          underline is there. What should happen at the end of the
          animation?
   Steve: Does the underline now jump to the text around it?
   * fantasai is confused
   Bert: The underline's position can be adapted to the child elements;
         it doesn't have to but it may.
   fantasai: (but it has to be a single line per linebox)
   * glazou digresses a bit and sees that if a hidden span still has
            underline from the parent, its area has a decoration but
            is not selectable
   fantasai: Consider also if I set text-decoration on a <div> with
             block-level children
   fantasai: If you set visibility hidden on one of them, would it
             disappear the text but not the underlining?
   * sylvaing must resist the urge to bring up underlines with text on a path
   Arron: Older versions of IE don't draw the underline, but they're
          just mostly broken

Over time
Meeting closed.

Received on Wednesday, 11 August 2010 20:31:13 UTC