W3C home > Mailing lists > Public > www-style@w3.org > March 2011

[CSSWG] CSSWG F2F Mountain View March 2011 Day 1: CSS2.

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 11 Mar 2011 22:40:59 -0800
Message-ID: <4D7B157B.8000303@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Reviewed some of Bert's edits where the exact edited text was not
     yet approved by the WG.
   - RESOLVED: For CSS2.1 Issue 224, accept Tab's proposal.
   - RESOLVED: For CSS2.1 Issue 230, make precise numbering of list items
               undefined in 2.1. (It's defined in css3-lists.)
   - RESOLVED: For issue 231, accept proposal permit root list-item to
               degrade to block.
   - RESOLVED: For issue 236, make the behavior of underlines through
               tables undefined. (Address in CSS3 Text, when we have
               option to cancel underlines via UA style sheet.)
   - RESOLVED: For CSS2.1 Issue 232, make in-flow mean not out-of-flow,
               check that spec remains correct.
   - RESOLVED: For CSS2.1 Issue 233, no change.
   - RESOLVED: For CSS2.1 Issue 235, accept editorial.
   - RESOLVED: For CSS2.1 Issue 239, do not propagate direction from <body>
               to <html>. No change to spec.
   - RESOLVED: For issue 240, make min/max-width on internal table elements
               explicitly undefined.
   - RESOLVED: For CSS2.1 Issue 241, accept the proposed spec change.
   - RESOLVED: For CSS2.1 Issue 242, no change for now, push to errata
   - RESOLVED: For CSS2.1 Issue 199, use Tab's proposal with edit for
               "static position" (instead of "auto position") and then
               add tests after PR.
   - RESOLVED: For CSS2.1 Issue 207, no change to spec.
   - RESOLVED: For CSS2.1 Issue 208, no change to spec.
   - RESOLVED: For CSS2.1 Issue 219, fantasai's text accepted.
   - RESOLVED: For CSS2.1 Issue 244, no change to spec (but we agree that
               it *is* the rendering tree)
   - RESOLVED: For CSS2.1 Issue 245, no change. See Issue 60.
   - RESOLVED: For CSS2.1 Issue 211, no change.
   - RESOLVED: For CSS2.1 Issue 247, undefined via issue 215.
   - RESOLVED: For CSS2.1 Issue 248, not an issue, so no change.
   - RESOLVED: For CSS2.1 Issue 250, use fantasai's proposed text.
   - RESOLVED: For CSS2.1 Issue 252, no change, fix in CSS3.
   - RESOLVED: For CSS2.1 Issue 253, say in 4.2 that "end of line" means
   - RESOLVED: For CSS2.1 Issue 254, not an issue: --> is parsed as invalid
               tokens in @statement. No change to spec.
   - RESOLVED: For CSS2.1 Issue 255, add "and future versions" to section 3.1.
   - RESOLVED: For CSS2.1 Issue 256, no change.
   - RESOLVED: For CSS2.1 Issue 257, boxes do have properties. No change.
   - RESOLVED: For CSS2.1 Issue 260, no change.
   - RESOLVED: For CSS2.1 Issue 261, no change in 2.1; clarified in
               Selectors Level 3
   - RESOLVED: For CSS2.1 Issue 262, no change.
   - RESOLVED: For CSS2.1 Issue 263, nice to have, but no change for now.
   - RESOLVED: For CSS2.1 Issue 264, accept change proposed in the issue e-mail.
   - RESOLVED: For CSS2.1 Issue 265, no change.
   - RESOLVED: For CSS2.1 Issue 266, accept issue 6, defer the others to the errata.
   - RESOLVED: For CSS2.1 Issue 267, accept proposed edit.
   - RESOLVED: For CSS2.1 Issue 203 revisit, already resolved to allow two behaviors.
   - RESOLVED: For CSS2.1 Issue 268, no change; spec is correct.
   - RESOLVED: For CSS2.1 Issue 269, use line box edges instead of block edges.
   - RESOLVED: For CSS2.1 Issue 270, no change for 2.1. Clarify in CSS3 Text.
   - RESOLVED: Undefine bg-pos of aspect-ratio-only images in CSS2.1.
   - RESOLVED: Remove content-computed-value-001 as it is not valid
   - RESOLVED: Undefine sizing of replaced elements with intrinsic ratio only
               (No passing implementations due to misinterpretation of SVG spec.)
   - RESOLVED: Update CSS 2.1 exit criteria to the current (CSS3 standard)
               exit criteria, minus the 30-day implementation requirement.

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


   Tab Atkins
   David Baron
   Bert Bos
   John Daggett
   Tantek Çelik
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Arno Gourdol
   Soonbo Han (LG)
   Shinkuro Honda (NTT)
   Dave Hyatt (via IRC)
   Masayuki Ihara (NTT)
   Hiroyuki Ishii (NTT)
   Koji Ishii
   John Jansen
   Brad Kemper
   Peter Linss
   Håkon Lie
   Alex Mogilevsky
   Edward O'Connor (Apple)
   Kazutaka Yamamoto (NTT)
   Steve Zilles
   Toru Kobayashi (NTT AC Rep)

<RRSAgent> logging to http://www.w3.org/2011/03/07-css-irc

Scribe: Tab Atkins


   <glazou> http://wiki.csswg.org/planning/mountain-view-2011
   glazou: CSS 2.1 will take up the morning, I expect.  What about the
   jdaggett: I'd like the Fonts discussion to happen tomorrow, for
             Christopher Slye.
   dbaron: If Christopher could do wednesday we'd have an easier time,
           I believe.
   jdaggett: Wednesday AM would be fine.
   glazou: Writing Modes, when?
   fantasai: Writing Modes should be fine anytime, also Text.
   howcome: If we could do hyphenation early, would be great.
   jdaggett: And we can do Text this afternoon, if necessary.
   glazou: So, start with 2.1.
   dbaron: I'll take a dinner count just before lunch.
   <szilles>  I would strongly prefer to do text on Wednesday

CSS2.1 Issues

   johnjan: The new issues start at 224

   <Bert> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JanMar/0271.html

     * Ad 153: https://www.w3.org/Style/Group/css2-src/changes.html#q500

     The proposed new text (by David Baron) was

     |   In the following definitions, for inline non-replaced elements,
     |   the box used for alignment is the box whose height is the
     |   'line-height' (containing the box's content area and the
     |   half-leading on each side). For all other elements, the
     |   box used for alignment is the margin box.

     However, the parenthetical remark in the middle isn't correct. We
     explicitly do not define the content area of inlines. I used this

         In the following definitions, for inline non-replaced elements,
         the box used for alignment is the box whose height is the
         'line-height' (containing the box's glyphs and the
         half-leading on each side, see above). For all other elements, the
         box used for alignment is the margin box.

     And to make sure inline boxes actually have a height of 'line-height', I
     changed earlier in that section:

     |   The height of the inline box is then the smallest such that it
     |   encloses all glyphs and their leading, as well as all nested inline
     |   boxes.


         The height of the inline box encloses all glyphs and their leading
         and is thus exactly 'line-height'. Boxes of child elements do not
         influence this height.

   Bert: ??? [something about issue 153]
   szilles: How does the height of the ascenders/descenders work?
   Bert: Each glyph gets [something about leading]
   Bert: The height of the inline box is only based on its own glyphs, not
         its sub-elements.  They each have their own inline box.
   dbaron: The intent of what I proposed was taht the height of the content
           area was based only on the glyphs and not the descendants.
           If you are saying that explicitly, that's fine.
   Bert: I couldn't say "content area", because 10.6 says it's undefined.
   glazou: Accepted edits to 153.
   <sylvaing> actually, tiny nitpick: one change specifies the inline box
              to be glyphs + half-leading; the other 'all glyphs and their
              leading'. I'd prefer saying half-leading both times ?

   Bert: Next issue, 181.
   Bert: This was an issue about heights in the line box.  I needed to explain
         that it didn't refer to the content height nor the line box.
   Bert: There was a reaction afterwards from Anton Prowse, but I think that's
         solved now by the previous issue.
   <Bert> http://www.w3.org/mid/201103041709.55059.bert@w3.org
   glazou: Accepted edits to 181.

   Bert: next issue is 204.
   Bert: In 9.4.2 there is text about lineboxes formed from elements without
   Bert: It says they're ignored for the purpose of finding adjacent margins.
         This wasn't mentioned in 8.3.1, so the action was to make that clear.
   glazou: Accepted edits to 204.

   Bert: next is 213.  We weren't clear if :first applied to the first page
         generated by a forced line break, or to the page after it.  This
         makes that undefined.
   glazou: Accepted 213.

   Bert: 215 is about an inline with position:relative which is broken over
         two lines - what is its containing block?
   Bert: We decided to make it undefined.
   Bert: This makes the text in 10.1 much shorter.
   fantasai: Does this account for elements that have been split by bidi in a
             single line?
   Bert: I'm not sure; the issue only talks about breaking over multiple lines.
   szilles: So if it's on the same line, it does define a box, if they're on
            different lines it's undefined?
   fantasai: Yes.
   ACTION Bert to re-edit 215 to take into account bidi-reordered boxes on
               the same line.
   <trackbot> Created ACTION-302
   <fantasai> So the definition should say that the top left padding box
              corner of the leftmost box and the bottom right corner of
              the rightmost box define a rectangle which is the containing
   <fantasai> If the inline is split across multiple lines, it's undefined

   Bert: For 218, I just need a review.  I was removing all references to
         percentage intrinsic dimensions.
   glazou: Accepted edits to 218.

   ACTION fantasai: Check the rest of Bert's edits
   <trackbot> Created ACTION-303

   Bert: For 228, we missed that width and height calcs were subject to
         min/max calculations in one place.
   Bert: So I added a note saying that the width may have to be calculated
         multiple times to satisfy min/max width/height.
   glazou: Accepted edits to 228.

   Bert: And for 121, an explanation of why line-height works the way it does.
   Bert: If you have the same font throughout, you get a constant line-height.
         I changed the "generally" line to a more explicit note.
     Note. When there is only one value of 'line-height' for all inline
     boxes in a block container box and they are all in the same font
     (and there are no replaced elements, inline-block elements, etc.),
     the above will ensure that baselines of successive lines are exactly
     'line-height' apart.
   * fantasai suggests using "(and there are no atomic inlines)" to shorten

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-224
   fantasai: Issue 224 should be straightforward.
   TabAtkins: fantasai, your edit misses the "ratio but no width or height" case.
   TabAtkins: My edits are now consistent with the image-sizing rules elsewhere,
              and match Opera and IE9, and would match Webkit if used 1em
              instead of some weird value.
   RESOlVED: Accept Tab's proposal for issue 224.

   glazou: Next is 225.
   fantasai: 225 needs someone to analyze it and propose some text.

   glazou: Now on issue 229.
   ACTION dbaron Write a proposal for http://wiki.csswg.org/spec/css2.1#issue-229
   <trackbot> Created ACTION-304

   fantasai: Second issue 229, for some reason, about numbering in list items.
   <fantasai> no, that's 230
   RESOLVED: Make precise numbering of list items undefined in 2.1
             (it's defined in 3)

   RESOLVED: Accept proposal for issue 231.
   fantasai: Sometimes ::markers have to be siblings, so they'll have the
             desired behavior in overflow:scroll

   glazou: Now, issue 232.
   dbaron: This is editorial, but it may result in non-editorial changes to
           text-decoration which relies on the undefined term "in-flow".
   <fantasai> see issue 236

   fantasai: I think the best idea for the unresolved issues is to break
             into groups of 3, all take a single issue and work on it,
             while I go off and file the remaning issues.
   glazou: Won't work.
   <johnjan> I think we should approach this like this: what does it take
             to get done today, not Wednesday. And do our best to achieve
              that goal.

   fantasai: For 236, which relates to 232, the definition of "in-flow" I
             was using "not out-of-flow".
   fantasai: We have interop between IE9 and Opera for spreading the
             underline down.
   fantasai: dbaron brought up a problem with <u> <table/> </u>
   dbaron: The HTML5 parsing algorithm surrounding parsing of <table> in an
           inline has the consequence of forcing you to not spread underlines.
           In particular, if you pass underlines through to <table>, everything
           in Ebay becomes underlined.
   dbaron: Do we want the same behavior as blocks, or as inline-tables and
   fantasai: What about flexbox?
   arronei: If you had one in a <del>, you'd want the strike-through to go
            through it.
   arronei: How about for 236, we say the text-decoration propogation for
            <table>s is undefined.
   arronei: We can disable underlines in CSS3, so we can just fix the UA
            stylesheet at that point.  For now, CSS 2.1 can punt.
   <fantasai> ua.css: u table { text-decoration: no-underline; }
   RESOLVED: 236 makes the behavior of underlines through tables undefined.
   fantasai: So, back to 232, I say we should just make "in-flow" be
             "not out-of-flow".
   RESOLVED: 232 Make in-flow mean not out-of-flow, check that spec remains
   ACTION Bert to edit 232 and review for correctness.
   <trackbot> Created ACTION-305

   dbaron: Next issue, 233.  I thought we all fixed this bug this years ago,
           so I'm not sure why we want to change it now.
   fantasai: I just thought the behavior was really weird - if you have a
             4em table-cell and the screen is 80em, and you say text-indent:10%;,
             you get an indent of 8em, not .4em.
   fantasai: If it's interop, though, whatever.
   RESOLVED: No change for issue 233.

   glazou: Issue 234 - margin-collapsing and min-height.
   fantasai: There are 2 impls that do one thing, and 2 impls that do
              something else.
   <br dur=10m/>
   glazou: Back to issue 234.
   arronei: For 234's testcase, we have interop between IE, Opera, and Webkit.
            FF is the only one that does something different.
   glazou: So we have 3 passes?
   arronei: Not sure what the pass condition is, but we have interop.
   dbaron: A problem is that, if we change the spec, do we get an infinite
           loop?  With margin-collapsing and clearance that's possible.
   glazou: So if we change the spec and test, we may have 3 passes.
   arronei: Maybe.  And maybe we'll hit an infinite loop.
   <fantasai> while (marginCollapsing in spec) { RewriteSpec(); }
   dbaron: What's the spec change that would make the spec match what the
           other 3 browsers do?
   dbaron: 8.3.1 says an elements' own margins are adjoining if ...
   dbaron: The important clause is "if the min-height property is 0".
   [looking at a testcase]
   <dbaron> The bottom margin of an in-flow block box with a 'height' of
            'auto' is adjoining to its last in-flow block-level child's
            bottom margin if the element has no bottom padding or border.
   <dbaron> has no conditions on min-height
   ACTION dbaron reply to Alan's message w.r.t
      that (a) this testcase is exercising "The bottom margin of an in-flow
      block box with..." and therefore all browsers other than Gecko are
      correct and (b) add a test to the CSS 2.1 test suite for post-PR.
   <trackbot> Created ACTION-306

   glazou: Issue 235 now.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Sep/0728.html
   glazou: Editorial.

   glazou: issue 239.
   fantasai: I say no.
   dbaron: I think that HTML has a lot of history of authors putting
           <html dir> rather than <body dir>.
   dbaron: Hyatt says that IE does the <body> propagation, and so he did it
           for Webkit.
   arronei: IE propagates.
   dbaron: I'd rather not have propagation.
   RESOLVED: Do not propagate direction from <body> to <html>.
   <hyatt> that will be a compatibility issue
   <hyatt> i guess we'll do it in quirks mode. sigh.
   johnjan: We're willing to take the behavior as a bug.

   dbaron: For issue 240, I thought we already said that min/max-width was
   RESOLVED: For issue 240, min/max-width on internal table elements is

   alexmog: A problem - if you set overflow and direction on <body>, you
            get bad behavior.
   alexmog: Can we say the same thing as overflow?
   dbaron: That's weird because if you have <html dir=ltr><body dir=rtl>,
           the rtl will propagate to <html> invisibly.
   <dbaron> (alternative is just saying to use the value from body...
            though that's really not particularly different.)
   <hyatt> TabAtkins_: in webkit body direction only propagates to html
           direction if html doesnt' set it
   <hyatt> TabAtkins_: (similar to background propagation)
   <dbaron> hyatt, what does "doesn't set it" mean?
   <dbaron> hyatt, background propagation does it based on whether
            background-image is none
   <dbaron> hyatt, does it mean whether direction is ltr?
   <hyatt> dbaron: we actually detect if any CSS rule sets direction to any
   <hyatt> on the HTML
   <dbaron> We've never had anything like that in the spec
   <hyatt> actually maybe we don't do that
   <dbaron> we shouldn't cross the value computation line
   <hyatt> let me double check
   <dbaron> compute values -> do something with the computed values
   <hyatt> yeah that is what we do
   <hyatt> we set a flag if direction is ever set on the html
   <dbaron> is that what IE also does?
   <hyatt> i can't remember if i arrived at that because it's what IE did
   <hyatt> i discussed it in the bug at the time let me try to find
   dbaron: If we propagate, we have to decide how to propagate, and what
           Hyatt's describing for Webkit's behavior is pretty weird.
   <hyatt> not that weird. to an author, the concept of setting the
           direction explicitly via a rule is a simple one
   <hyatt> it's just weird since we have never done it before
   <johnjan> entire room is easily distracted by ropes flailing outside
             the window...
   <hyatt> the simpler option might be to just ignore the html whne body
           sets it
   <hyatt> i.e., just always propagate body
   <dbaron> which I think is fine since direction's inherited anyway
   <hyatt> i think that is what ie does
   <dbaron> I'd prefer that
   <hyatt> https://bugs.webkit.org/show_bug.cgi?id=48157
   <fantasai> why are FF and Opera getting away with not doing this, if
              it's a web compat issue?
   <hyatt> looks like my main reasoning for not ignoring the html was just:
   <hyatt> "This is in direct violation of CSS2.1 is the problem.  It
           states that the direction on the root element should be propagated
           to the initial containing block.  I don't think it makes sense to
           actually overwrite the direction specified on the <html> if it is
           there just because the <body> specified something different."
   <hyatt> so if the spec told me it was ok i'd have matched WinIE :)
   <hyatt> i was just concerned about ignoring the value on the html
   <hyatt> since that sounded like violating the spec language
   <hyatt> so o
   <hyatt> i'm fine with making body just overwrite html
   <hyatt> would just need the spec to say so
   <fantasai> well, CSS2.1 assigns a 'direction' value to HTML whether one's
              set explicitly or not
   <fantasai> so you're violating the spec either way
   <fantasai> by doing this at all
   <fantasai> I don't see anything in the bug explaining *why* you're doing
              this, though; there's nothing in the bug that says what the
              problem is with just following the spec instead of trying to
              copy IE
   <hyatt> it's broken out from another bug
   <hyatt> let me keep digging
   <hyatt> vaguely remember some dhtml menu on israeli sites not positioning
   <hyatt> used right: but didn't get computed correctly because the icb
           wasn't properly rtl or something
   dbaron: We use the direction of body to determine the scrolling direction
           of the viewport
   dbaron: But we don't actually propagate the 'direction' property
   dbaron: So when Gecko determines the scrollbars for root, we use the
           direction for <body>, but we don't do any other propagation.
           So it's really the scrollbars for the ICB.
   dbaron: We don't want a "propagated if not specified" in CSS.
   glazou: Let's move on.  We're not making immediate progress.

   <dbaron> issue 241: http://lists.w3.org/Archives/Public/www-style/2010Nov/0035.html
   <dbaron> I'd by happy to just make the change Øyvind suggests
   <dbaron> (change the spec)
   <dbaron> is a simple testcase
   RESOLVED: Accept the spec change for 241.

   glazou: Now issue 242.
   dbaron: I think we just need to action for a proposal.
   dbaron: I don't think anything has to be undefined here. We do need to
           make the change for consecutive block boxes.
   <fantasai> might be able to handle white space interaction in the phantom
              line boxes clause
   <dbaron> http://wiki.csswg.org/spec/css2.1#issue-142
   johnjan: There are some issues, starting with 142, that need an action
            for Bert edit.
   dbaron: As far as I can tell from reading the spec, the containing block
           for a child of a table cell, is the block that contains the table,
           which seems like a bug.
   dbaron: Boris's comments is asking for whether the table should be the
           containing block.  It seems to me that the table-cell should be
           the containing block, even if it's anonymous.
   fantasai: I think the table cell should be a containing block for the
             inner table cell box.
   dbaron: Is "inner table cell box" even in the spec yet?
   fantasai: I don't think so.
   dbaron: What Boris is talking about is what the containing block is for
           an inner table element, like table-row.
   Bert: I think the table-cell is fine; I believe the question was only
         about anonymous table-cells.

<br type=lunch duration=1h>
<fantasai> sylvaing: Can you answer http://lists.w3.org/Archives/Public/www-style/2010Nov/0435.html ? :-)
Scribe: Bert

   Topic: Issue 142 http://wiki.csswg.org/spec/css2.1#issue-142
   -> http://lists.w3.org/Archives/Public/www-style/2011Mar/0022.html Bert's proposal
   dbaron: So it seems we have a proposal. Somebody needs to respond to Boris.
   <dbaron> sounds like we concluded that followup 2 was ok since anonymous
            boxes can be containing blocks since we define containing blocks
            in terms of boxes
   Bert: Is that not what my proposed text does?
   dbaron: Needs to be explained better.
   plinss: So we are still stuck on this issue?
   dbaron: [reading the texts]
   ... In 2c, rule is skipping anonymous boxes.
   ... That may skip the table cell.
   -> http://lists.w3.org/Archives/Public/www-style/2011Mar/0023.html Boris'
      last reply
   JohnJan: It seems Boris essentially agrees, with maybe clarification.
   dbaron: I think anonymous boxes should not be skipped.
   Bert: They should be, except for anonymous table cells.
   fantasai: They aren't all skipped.
   <dbaron> And I think this makes the definition of containing block deviate
            from the definition of the box tree.
   plinss: Are there functional changes? Or only editorial?
   fantasai: We should have only one possible interpretation of the spec.
   plinss: If there is no test  in the suite that shows the difference,
           then let's defer this.
   RESOLVED: no change, push to errata

   Topic: issue 192
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-192
   TabAtkins: What happens to content that precedes the float in the source.
   TabAtkins: Implementations never move such content down.
   TabAtkins: Instead, they move the float down.
   dbaron: That is what the spec says should happen.
   dbaron: Float constraint include that top of float must not be above
           prior content.
   dbaron: So float *has* to be pushed down.
   dbaron: That is not stated explicitly, only as implicit result of the
   TabAtkins: OK, so that everything is fine.
   dbaron: Might be worth a note in the spec.
   -> http://lists.w3.org/Archives/Public/www-style/2011Mar/0064.html
      Bert's msg on 192
   plinss: Who is writing that note?
   TabAtkins: I could
   dbaron: I could, too.
   ACTION dbaron: write such a note for issue 192.
   <trackbot> Created ACTION-307

   Topic: issue 199
   -> http://wiki.csswg.org/spec/css2.1#issue-199 Issue 199
   -> http://lists.w3.org/Archives/Public/www-style/2010Oct/0707.html
      Tab's proposal
   TabAtkins: I think I did not test vertical and horizontal margins seperately
   dbaron: That may make a difference.
   dbaron: "The auto position" is a bit vague. Needs to be defined.
   ?: Use term 'static position'
   plinss: Any tests for this?
   JohnJan: Leave text as Tab proposed, with edit for "static" and then add
            tests after PR.
   RESOLVED: as JJ just said.

   Topic: Issue 204
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-204
   fantasai: Bert sent an e-mail, which is not yet in this list.
   ... Probably wherever it says "Bert edit" we don't have to discuss now.

   Topic: Issue 207
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-207
   -> http://wiki.csswg.org/spec/css2.1#issue-207 Issue 207
   dbaron: What do implementtions do?
   Arron: Impls are interoperable.
   Arron: ... Is the same as margin collapse clear test case.
   JohnJan: Spec remains underdefined.
   ... Is there an edit to do, or an errata later?
   plinss: Any proposals?
   [People trying to understand...]
   dbaron: Defer to errata?
   Arron: Seems possible, yes.
   RESOLVED: no action on 207

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-208
   Topic: issue 208
   <dbaron> 11.1.1: "In the case of a scrollbar being placed on an edge of
            the element's box, it should be inserted between the inner border
            edge and the outer padding edge. Any space taken up by the
            scrollbars should be taken out of (subtracted from the dimensions
            of) the containing block formed by the element with the scrollbars."
   dbaron: So it doesn't say that the width is changed.
   ... Reason may the case when 'width' is not 'auto'.
   Arron: You don't want to make the box bigger when you add scrollbars.
   ... So the content box width has to shrink.
   dbaron: But the value of 'width' doesn't change, and is thus different
           from the content box.
   dbaron: Is this different for 'height'?
   ... Assume the block has 'height: auto'
   ... Does the vertical scrollbar make the box taller?
   plinss: No tests for this I think? Should we skip the issue?
   Arron: No need to change the spec, it seems.
   plinss: Scrolling has always been a UA-dependent thing.
   fantasai: Still in scope for CSS, thought maybe not for CSS 2.1.
   Arron: Define some tests later and write it into CSS then.
   RESOLVED: no action on 208

   <smfr> http://wiki.csswg.org/spec/css2.1#issue-219
   Topic: issue 219
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Feb/0669.html
   [fantasai proposed text]
   RESOLVED: fantasai's text accepted.

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-244
   Topic: issue 244
   Topic: Issue 245
   JohnJan: No change needed.
   fantasai: Could do in in level 3.
   RESOLVED: no changes for issues 245

   Topic: issue 244
   dbaron: depends on defining rendering tree.
   <johnjan> we are not going to be able to define rendering tree in CSS21
   fantasai: should we still add that it depends on rendering tree, even
             if the rendering tree is undefined?
   <dbaron> http://www.w3.org/TR/CSS21/about.html#organization is quite
            out of date
   RESOLVED: no change for 244
   <dbaron> (but we agree that it *is* the rendering tree)

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-211
   Topic: Issue 211
   dbaron: Before margin collapsing text was reorganzized, there was a
   ... We had rules "A collapses with B" and "C does not collapse with D"
       and we assumed rules were transitive.
   ... We should only define what *does* collapse.
   fantasai: New text indeed moved in that direction.
   dbaron: We had a case with element with bottom and top collapsing together
           and the bottom collapsing with parent bottom, or not.
   ... It was possible that top and bottom were forbidden from collapsing,
       but both collapsed with the same other margins, so should collapse
       because of transitivity.
   Arron: You have a proposal?
   dbaron: My proposal might be against an old version of the spec.
   <dbaron> bottom margin of a last in-flow child and bottom margin of its
            parent if the parent has 'auto' computed height
   <dbaron> bottom margin of a last in-flow child and bottom margin of its
            parent if the parent has 'auto' computed height and '0' computed
   ... Change in bullet 3.3 in 2nd list of 8.3.1.
   ... Because the 4th bullet mentions zero 'min-height' and the 3rd doesn't.
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-234 is related
   dbaron: This morning we discussed 234. Ignore Gecko for that, because it
           has a bug.
   JohnJan: Seem FF does it the same as everybody else, though.
   dbaron: So whether 'min-height' stops collapsing depends on whether it's
           own bottom and top margins collapse.
   ... That test case is wrong.
   ... Say you have an elt with a 'min-height'. Its margins don't collapse.
       Now add an empty child.  Now it's margins do collapse.
   <dbaron> current spec says that last testcase should have a 1em gap and
            then a 2em gap
   fantasai: Should 3rd bullet check whether min-height has an effect, or
             whether it is set?
   dbaron: The latter, otherwise infinite loop is possible.
   ... Gecko still does the former, but has an explicit loop detector.
   <fantasai> That brings me to a brilliant suggestion. How about a
              "min-height: contains-floats" keyword, so we can get rid of
              all this clearfix junk?
   RESOLVED: no change for issue 211

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-247
   Topic: issue 247
   <dbaron> "When such an inline box is affected by relative
            positioning, the relative positioning also affects the
            block-level box contained in the inline box. "
   dbaron: The test case in the e-mail isn't right. There is a third answer,
            which he didn't consider.
   <dbaron> I think the test in
            is only considering 2 possible answers when there are really three
   <dbaron> dy%3E%0A%3C%2Fhtml%3E
   <dbaron> http://dbaron.org/css/test/2011/css21-issue-247
   Bert: Is this different from issue 215 from this morning?
   dbaron: Issue is that relative pos "affects" the block inside, but not
           specified how.
   ... Nobody does the behavior that I would have liked for that test case.
   plinss: So we should make it unefined?
   dbaron: Maybe we already did...
   <johnjan> Remain undefined in 2.1. Need to verify that this remains
             undefined after today's other edits.
   fantasai: ... The other edits make inside inline undefined. Is that
             inside the box tree or the element tree?
   RESOLVED: Undefined via 215.
   ACTION dbaron verify that once issue 215 is edited, that the case for
          issue 247 is also undefined
   <trackbot> Created ACTION-309
   Brad: It would make more sense from a web author's perspective for the
         relposed <span> to establish the containing block for any abspos
         elements inside it, even if they're inside a block that's inside
         the <span>.

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-248
   Topic: issue 248
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Dec/0020.html
   dbaron: Interesting case is a zero-height float followed by a 1px high
           float and the latter is wider.
   ... Zero-height float can only shorten line box if they have been pushed
       down to fall in the middle of a line box.
   ... Hard to find whether this is implemented correctly, because of other bugs.
   ... There should be test cases in the test suite already.
   ... Maybe the float-wrap-top set.
   dbaron: IE seems to do the zero-height float correctly.
   ... But probably the only browser to do so.
   ... There probably is no issue. But may need more tests to add later.
   RESOLVED: No change for issue 248

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-250
   Topic: issue 250
   Bert: fantasai's proposed text looks fine.
   RESOLVED: use fantasai's proposed text on issue 250.
   [Some more discussion about 250: should space not only be allowed, but
    required? Result: no.]

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-252
   Topic: Issue 252
   dbaron: I think Boris's response is wrong, though.
   -> http://lists.w3.org/Archives/Public/www-style/2011Jan/0092.html
      Boris's response
   dbaron: BAD_STRING is not allowed in a block, it seems.
   plinss: What does it mean to have a BAD_STRING in a block?
   <dbaron> I think BAD_* should be in any
   Bert: But the grammar defines what is valid, and BAD_STRING is never valid.
   dbaron: But then we have no rules for dealing with the error.
   Bert: Those rules are there: skip to the end of the block (or the decl,
         as the case may be).
   plinss: Do we need to do anything in CSS 2.1?
   <dbaron> (maybe not BAD_COMMENT)
   <dbaron> 4.1.1 says "The meaning of input that cannot be tokenized or parsed
            is undefined in CSS 2.1. "
   <dbaron> and we don't want all this error handling to fall into that clause
   dbaron: Last sentence of 4.1.1 says unparsable means undefined. But we
           have error rules.
   <dbaron> Proposal:
   dbaron: My proposal is to add BAD_URI and BAD_STRING to the "any" production.
   <dbaron> ... and then change "COMMENT tokens do not occur" to "COMMENT and
            BAD_COMMENT tokens do not occur"
   Bert: Counterproposal is to leave the grammar defining valid CSS, and add
         in 4.1.6. s/any tokens/any tokens (except BAD* tokens)/
   dbaron: We should remove the sentence "The meaning of input that cannot be
           tokenized or parsed is undefined in CSS 2.1 from 4.1.1
   plinss: It talks about the tokens that cannot be parsed.
   dbaron: But it makes the whole style sheet undefined.
   Arron: Usually we talk about "the part of the style sheet" so this seems
          to be about the whole style sheet.
   plinss: I think parsing is covered by 4.2
   dbaron: But what makes something a declaration that you can ignore is the
   <dbaron> dbaron: OK, let's just leave it, and fix it in css3.
   plinss: Objection to DB's proposal?
   Arron: We can always change it back in errata.
   dbaron: We can just leave it unchanged.
   RESOLVED: No change in 252

   <mihara> I ask for Tokyo forum to be discussed in Tue afternoon.
            I am not here on Wed.
   * sylvaing still has a few 'I have standards' IE9 t-shirts....
   * gsnedders appears looking vaguely interested
   * gsnedders (in the t-shirt, not in CSS)
   <jdaggett> http://www.amazon.com/Avoid-Huge-Ships-John-Trimmer/dp/0870334336/ref=sr_1_1?ie=UTF8&qid=1299540509&sr=8-1
   <jdaggett> hint: read the comments!
   * sylvaing this seems similar to http://www.amazon.com/Mountain-Three-Wolf-Short-Sleeve/dp/B002HJ377A
   * sylvaing I think this is the t-shirt for gsnedders
   * gsnedders sylvaing: pff, wolves, not vampires… *shakes head*
  * gsnedders sylvaing: there again, I presume the IE9 shirt doesn't haveLayout,
              so is just a bunch of random shapes scattered over the shirt

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-253
   Topic: Issue 253
   plinss: Are we OK with the proposed change of [??]?
   dbaron: Relates to last large DL of 4.2.
   ... Possible to reach end of style sheet and end of string at the same time.
   ... Should be more clear what end of line means.
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-254
   RESOLVED: say in 4.2 more clearly what end of line means.
   [That means end of line is a particular character from \r\n]

   Topic: Issue 254
   Daniel: Does this need edits?
   dbaron: Probably not.
   fantasai: Issue may be about whether the "-->" in the e-mail is a statement.
   Daniel: I propose no chnage.
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-255
   RESOLVED: no change for 254

   Topic: Issue 255
   JohnJan: Just say "HTML specifications"
   Daniel: Cannot reference HTML5 as it is not a REc.
   Daniel: Just add "in HTML"
   Tantek: *any version* of HTML.
   plinss: How about XForms?
   RESOLVED: "and future versions" added to  to section 3.1 for issue 255.

   Topic: issue 256
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-256
   plinss: Leave it as is.
   RESOLVED: No change for issue 256.

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-257
   Topic: Issue 257
   plinss: I think we do want boxes to have properties.
   dbaron: I agree.
   plinss: So no chnage?
   RESOLVED: no change for issue 257

   Topic: Issue 259
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-259
   Daniel: Indeed the 'inherit' keyword is never the computed value.
   howcome: In css3-values, 'inherit' is not the specified value.
   dbaron: We might have changed that already.
   Daniel: If 'inherit' is not returned as the specified value, that
           breaks editors.
   fantasai: Have to distinguish from what the CSSOM says: CSS specified
             value is not the same as CSSOM specified value.
   howcome: There is a "cascaded value" also, explained in css3-values.
            That is what editors need.
   ... The text in CSS 2.1 is consistent with css3-values.
   plinss: So no change?
   JohnJan: And do something in level 3?
   TabAtkins: Better not have level 3 contradict level 2.
   HL/JohnJan: Bahevior isn't different, there is just different terms:
               cascaded values.
   fantasai: Inconsistency between 3 and 2 is the missing term cascaded value.
   ... Could add a note about that.
   ACTION fantasai: write a proposed text for issue 259
   <trackbot> Created ACTION-310

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-260
   Topic: issue 260
   fantasai: We added that note to clarify something else. Opinions differ
             on what is more or less confusing. So no change.
   RESOLVED: no change for issue 260

   Topic: Issue 261
   Daniel: Nobody ever complained. Seems not worth a chnage.
   plinss: Is this already in Selectors spec?
   Daniel: No, that has the same prose as 2.1.
   plinss: No change needed. Selectors is a clearer, that's good enough.
   RESOLVED: No change issue 261

   [Discussion about issues list and numbers, duplicates]
   JohnJan: Issue 262 seems duplicate of 261 and 260.
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-262
   Topic: Issue 262
   plinss: Propose no change for issue 262.
   RESOLVED: No change issue 262
   [Discussion about what is best way to deal with minor editorial issues.
    At this point, just rejecting it is best, no risk of errors.]

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-263
   Topic: Issue 263
   Steve: Maybe we can make a boilerplate text for all these editorial
          rejected issues.
   ... For when we reply to the submitter of the issue.
   plinss: Seems same case again: Edit is nice to have, but not needed now.
   RESOLVED: no change for issue 263

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-264
   Topic: Issue 264
   dbaron: We discussed zero-height floats already today.
   JohnJan: Did the earlier discussion affect this issue?
   dbaron: No. The note in the issue is wrong.
   RESOLVED: accept change proposed in the issue e-mail for issue 264.

   Topic: Issue 265
   RESOLVED: No change issue 265

   Topic: Issue 266
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-266
   fantasai: I think we should make the suggested edits, they fix what we
             missied in the previous round for issue 120.
   JohnJan: And the ones you were not sure about?
   ... Issue 3 in the linked e-mail.
   [it's about whether table-caption is block-level]
   Arron: Doesn't seem to hurt anything to make it block-level.
   fantasai: If we don't fix it, we'll have to do it in errata anyway.
   [Discussion about how 'overflow' might apply if flex box is added to CSS]
   JohnJan: So take none of them, except issue 6.
   fantasai: What does Bert think?
   Bert: I don't know yet.
   RESOLVED: Accept issue 6, defer the others to the errata.
   [Above is for issue 266]

   Topic: Issue 267
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-267
   dbaron: The proposed edit matches impls that I tested.
   <dbaron> test is http://dbaron.org/css/test/2011/css21-issue-267
   <dbaron> (question is which is on top)
   <dbaron> actually, it doesn't test the issue
   dbaron: I think it is editorial.
   <dbaron> actually, hold on
   <bradk> 268 and 269 should be
   dbaron: Two browsers do one thing, two do the other.
   ... The proposal matches Opera and Webkit.
   RESOLVED: Accept propsoed edit for issue 267.

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-268
   Topic: Issue 268
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-203
   <johnjan> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html

   Topic: Issue 203 (again)
   JohnJan: Anton Prowse disagrees with our resolution.
   -> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html Anton's message
   dbaron: The reason for the hypothetical top border is so as not to move
           the element unnecessarily.
   Arron: Test cases are all interoperable.
   ... See margin-collapse-clear-005
   fantasai: Difficult to keep track of which clearance issues are the same
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-268
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0644.html
   <fantasai> resolved in that meeting
   RESOLVED: 203 was already discussed and we allowed two behaviors.
             (See issues list)
   <dbaron> s/move the element/move the element up/
   <dbaron> (I'm having trouble working out a testcase for why the hypothetical
            border edge is useful, though.)
   <dbaron> Though actually, maybe I'm misremembering the purpose.
   <dbaron> Maybe it's to prevent contradictions.

   Topic: Issue 268
   fantasai: I think the spec is correct.
   [People trying to find out what the issue is]
   Arron: Quite a few test cases for this.
   <johnjan> actual issue:
   [Mumble mumble]
   RESOLVED: No change for issue 268
   [DB and EE discuss some case]
   fantasai: All impls seem to agree on what the first formatted line is.

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-269
   Topic: Issue 269
   fantasai: propose to change to edges of line box, instead of block.
   RESOLVED: Use line box edges instea dof block edges in issue 269

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-270
   Topic: Issue 270
   fantasai: I can propose a text.
   dbaron: I might have some issues. I started implementing this.
   RESOLVED: No change for issue 270. Do something in level 3.

   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-271
   Topic: Issue 271
   Arron: I think the colon in the spec was intended to mean "e.g."

   [Discussion about what issues to discuss. Skip all editorial?]
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Dec/0312.html
   <fantasai> Anton's list of substantive issues ^
   dbaron: Turn the email into a wiki page so we can start dealing with it
   <fantasai> http://wiki.csswg.org/spec/css2.1/anton-lc-2010
   plinss: What can we discuss now?
   ... How dow we go through Anton's list?
   Arron: I have made comments on many of the issues.
   ... Most of them I found need no change.
   <johnjan> so Arron and Elika will get Anton's email into actionable issues
   <johnjan> discuss on wednesday.

CSS2.1 Test failures

   plinss: Background-fixed 4 and 5 were expecting a fix in Gecko.
   dbaron: Give me 15 seconds...
   Simon: Last week we suggested to leave it undefined.
   plinss: I agree with undefined. Unless we have a proposal for a spec change.
   dbaron: Gecko might take a month to fix.
   fantasai: bg-pos may apply to image with no intrinsic size.
   Arron: Is it not already undefined?
   dbaron: Might want to make it explicit, and say there is another spec
           that defines it.
   <fantasai> The background position of background images with an intrinsic
              ratio and no intrinsic size is undefined in CSS2.1, see CSS3
              Backgrounds and Borders.
   RESOLVED: Change bg-pos of images as fantasai just wrote.
   dbaron: So the test still needs fixing?

   Topic: test bidi-breaking-2
   fantasai: should be a may?
   <fantasai> http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/bidi-breaking-002.xht
   <fantasai> bidi-breaking-002 should work now; removed the HTML <br> bit
              of the test (since that's up in the air anyway)

   <dbaron> http://test.csswg.org/suites/css2.1/latest/xhtml1/block-in-inline-relpos-002.xht
   Topic: block-in-inline-relpos-002
   plinss: What do we do with this one?
   [DB trying to find out why various browsers fail.]
   dbaron: Related to what we discussed earlier, about relative pos. affecting
           nested block elements.
   ... Four browsers that all do different things.
   [DB and PL notice that two versions on diff. platforms of Opera do different
    things, too.]
   [People looking over other people's shoulders to see what various browsers
    do on different platforms...]
   dbaron: Somebody should take an action to figure out what to do. And not me.
   Arron: I can do it.
   ACTION Arron: propose a solution for block-in-inline-relpos-002
   <trackbot> Created ACTION-311

   <howcome> content-computed-value-001
   Topic:  content-computed-value-001
   RESOLVED: Remove the test

   Topic: replaced-intrinsic-ratio-001
   <smfr> we're going through the blocking tests on
   dbaron: Close to a patch for Gecko, just need to fix a few more existing
   plinss: It seems to be testing multiple things.
   fantasai: [something]
   plinss: Are you going to define behavior?
   fantasai: I might want to fix this.
   ... I will propose text.
   ... For the spec.
   howcome: Is this an SVG issue?
   fantasai: Yes, affects all SVG that doesn't have a fixed size (i.e.
             scalable SVG)
   RESOLVED: Change the spec in some way.
   fantasai: Proposal is to make sizing of replaced elements with intrinsic
             ratio but no size undefined.
   RESOLVED: ... and put the current rule in level 3 instead.
   Bert: It was put in on request from SVG wasn't it?
   <fantasai> no, it was put in a long time ago because it was it wasn't defined
   <fantasai> the test is failing because UAs misinterpreted SVG

   Topic: uri-016
   <johnjan> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/uri-016.htm
   plinss: We don't have the exit criteria from other CSS modules in the
           CSS 2.1 spec,
   ... Difference is about experimental builds.
   ... Didn't we resolve to fix that already?
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-272
   RESOLVED: Update CSS 2.1 exit criteria to the current (CSS3 standard)
             exit criteria, minus the 30-day implementation requirement.

[End of meeting for today]
Received on Saturday, 12 March 2011 06:41:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:57 UTC