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

[CSSWG] Minutes and Resolutions 2010-08-04

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 04 Aug 2010 13:05:20 -0700
Message-ID: <4C59C800.5070207@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

  - RESOLVED: Proposal for CSS2.1 Issue 120 accepted with changes mentioned
              in minutes.

  - RESOLVED: Proposal accepted for CSS2.1 Issue 167 as corrected by Bert

  - Discussed CSS2.1 Issue 167 and definition of em box

  - RESOLVED: For CSS2.1 Issue 184, "Pseudo-elements behave just like real
              elements except as described below and elsewhere (i.e. section

   - Discussed zero-height floats. (CSS2.1 Issue 185) Proposed resolution to
     not consider them for line-box shortening.

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


   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   John Jansen (Microsoft)
   Brad Kemper
   Peter Linss
   David Singer
   Steve Zilles

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


   no more agenda items to add

CSS Test Suite

   arronei: Lots of tests need updating in response to review comments. Plan to get these done before the F2F.


   <glazou> http://wiki.csswg.org/spec/css2.1#issue-120
   glazou: Asked everyone to review issue 120, and if no comments, it's accepted
   glazou: Are there any comments?
   Bert: I just sent my review of the text. I had three places where
         I didn't agree with the replacements.
   Bert: block-level is not defined
   Bert: second issue is the definition of atomic inline box
   Bert: I'm wondering if it's necessary -- it's only used in one place
   fantasai: That seems alright to me.
   Steve: I'm fine with that as a resolution. However if we ever get around
          to Tab's split of the 'display' property or something similar,
          it would be a useful term to have.
   Steve: The concept is a useful one for people to understand
   fantasai agrees with Steve
   Steve: If there's no harm in introducing it here, it could be useful in
          the future.
   Bert: My third comment is wrt its use in the z-index property description,
         where I don't think we should use it.
   Bert: So we would define the term but not use it anywhere in CSS2
   Steve: That's fine, I think just the recognition that there is such a
          thing would be useful.
   * oyvind doesn't like "atomic" but doesn't have a better suggestion
   Bert: The other changes seem fine to me.
   fantasai: There were some comments on the mailing list, mostly editorial,
             about improving the text there. I will need to incorporate
             those as well.
   RESOLVED: Proposal for 120 accepted with changes mentioned above.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-167
   Bert's response to 167: http://lists.w3.org/Archives/Public/www-style/2010Aug/0052.html
   Bert: In some cases a backslash is not an escaping mechanism.
   Bert: The way he defines that is to say it has "no special meaning",
         and then defines "no special meaning" inside a note, which is
         a non-normative part.
   Bert: Otherwise I think his changes are fine, other than the
         non-normative part.
   Bert: I would rather not define "no special meaning", but instead
         just say that the backslash stands for itself directly.
   glazou: Other comments?
   fantasai: I agree with Bert's changes, and I trust Bert to have made
             sure the proposal is correct
   RESOLVED: Proposal accepted for issue 167 as corrected by Bert

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-118
   Steve: Basically I went back and looked at OpenType standard, and
          then checked with some font guys at Adobe to make sure I
          understood it.
   Steve: The catch is, the em-box a) isn't really defined, other than
          to say that the coordinate system used in other values is
          given in units per em
   Steve: and b) its position is not really defined
   Steve: The ascent and descent values which dbaron mentioned are
          related to this
   Steve: There are three sets of such values
   Steve: One that tends to be Mac-centric
   Steve: One set tends to be Windows-centric
   Steve: And the third set, were put in to be platform independent.
   Steve: Those should be used if they exist.
   Steve: Then it's recommended that the distance between them equal
          one em, but it's not required.
   Steve: There are fonts for which it doesn't hold.
   Steve: I suggest the difference between that and an em be split,
          half above and half below, just like leading
   Steve: The last point is, the reason you need to do that is that
          leading + embox  = line height.
   glazou: Do you mean we can't rely on the font's definition of
           embox because it doesn't exist?
   Steve: Right. I didn't get as far as suggesting a rewording of the text.
   Steve: I got hung up on what centering meant.
   Bert: I can come up with wording for that.
   Bert: I have one concern which is, this applies to OpenType, but
         what about other font formats?
   Steve: I think the general approach I talk about works for any
          font with ascent and descent information. We assume that
          information exists.
   dbaron: We could say more broadly for any font that has any
           measurement relating the baseline to the edges of it
   dbaron: What Steve describes matches what we implement more than
           Bert's definition.
   dbaron: Although we never calculate the em-box, we just use the
           ascent and descent and compute the half-leading differently --
           which is a shortcut for the same results.
   Bert: Do we still keep the references to OpenType fields?
   Steve: I would put it in an appendix or a note.
   fantasai: I would suggest putting the field names in a note, but
             using ascent and descent generically in the normative text.
   Brad would like to make sure there's interop for the use of
        OpenType tables.
   Steve suggests writing a test.
   fantasai and Steve note that CSS tries to be font format agnostic.
   Bert: I think we can't make this more precise wrt OpenType in CSS2.
   glazou: Do you have enough to come up up with wording?
   Bert: I think so
   ACTION: Bert to write updated proposal for 167
   <trackbot> Created ACTION-247 - Write updated proposal for 167

   glazou: Any progress on other issues?
   glazou: Let's have proposals done by the F2F

   <dbaron> TabAtkins_, Where's the message you mentioned sending that had questions about margin collapsing?
   <TabAtkins_> dbaron, http://lists.w3.org/Archives/Public/www-style/2010Jul/0525.html and 528

   glazou: Issues assigne to the WG:

   glazou: Issue 184
   <glazou> http://wiki.csswg.org/spec/css2.1#issue-184
   Tab: I think several things are way easier if you consider pseudo-elements
        as part of the element tree
   Bert: But then the element tree is not a tree
   glazou: Could say which sections pseudo-elements are treated as elements
   fantasai: That would be pretty much the entire spec except the Selectors
   SteveZ: I support the "except" proposal in the issues list
   dbaron: I might go so far as saying :before and :after are treated as
           real elements except where specified, and have :first-line and
           :first-letter just be defined by the Selectors chapter
   fantasai: That doesn't give them enough definition -- e.g. how do we
             assign properties to them?
   dbaron: That's already pretty bizarre
   fantasai: But the way we do define it is explained as differences from
             normal behavior. We don't want to duplicate the spec of
             normal behavior here just for :first-line and :first-letter.
   glazou: "Pseudo-elements behave just like real elements except as
            described below and elsewhere."
   Steve: But then I have to search the entire spec.
   Steve: At least point to the relevant sections
   fantasai: I think the relevant section is 12.1
   RESOLVED: "Pseudo-elements behave just like real element except as
              described below and in section 12.1"

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-185
   dbaron: There are 2 different cases here, and I'm not sure which one
           he tested.
   dbaron: There's one where you have a zero-height float whose position
           is right at the edge of a line
   dbaron: And the other is where you have a zero-height float whose
           position is in the middle of the line (e.g. below another float)
   dbaron: If the top of a float is even with the bottom of a line, or
           the bottom of a float is even with the top of a line, that's
           not considered an intersection.
   dbaron: I'm not sure about the case of a zero-height float in the
           middle of a line
   dbaron: But we should be careful that we're testing the right cases here.
   dbaron: There's another bug in browsers where floats that don't
           intersect the top of a line are not considered. This shows
           up in Wikipedia a lot because they use floats for their
           intended purpose.
   dbaron: The only browsers that handle that right are IE6/7 and recent
           versions of Gecko
   <dbaron> I think
   Tab: If you have two floats stacked on top of each other, one which
        is at the top of a line, and then a cleared float in the middle
        of the line, that second float doesn't push the line box even
        if it's wider than the line box.
   Tab: In Gecko it pushes only if it's visible; if it's zero height it
   Tab: I don't mind Gecko's current behavior. And everyone else who
        doesn't match, they have a bug anyway.
   Tab: I could go either way on it -- detecting or not detecting
        zero-height floats both make sense.
   SteveZ: It makes sense for consistency to ignore it; since when it
           falls between lines it's ignored.
   SteveZ: Why would one have a zero-height float?
   SteveZ: I understand how it can happen; but is there a use case for it?
   Tab can't think of one
   Bert: It's a bit like positioned elements, that it's positioned at
         the auto position
   Bert: I don't know if it would make sense to use a zero-height float
         instead of abspos, but if you wanted to make it overlap...
   Brad: What about a transition from zero-height to another height?
   Brad: You might want to cause reflow vertically, but not horizontally.
   SteveZ:  Is there a use case that isn't an edge use case for this?
   glazou: If we have no use case, what do you suggest?
   SteveZ: If we have interop, then it seems strange to break that.
   * TabAtkins_ suggests that we just spec what browsers do in that case.
   Bert: What interop do we have?
   dbaron: The other possibility is that we say zero-height floats never
           push lines. Which is nice, because it makes one implementation
           strategy easier.
   dbaron: We split each side of a bfc into vertical ranges, and we check
           for whether to push lines by checking for an intersection.
   dbaron: If we need to check for zero-height floats, then we need to
           deal with zero-height ranges, which is a bit of a pain.
   glazou notes we are over time
   <TabAtkins_> Isn't that exactly what's being proposed?
   dbaron: If floats are changing height, there will be a lot of reflow anyway
   SteveZ: So, proposed to make zero-height floats not affect line boxes,
           will ask for objections and resolve next week.

Meeting closed.
Received on Wednesday, 4 August 2010 20:05:58 GMT

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