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

[CSSWG] Minutes and Resolutions 2010-09-08

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 21 Sep 2010 01:47:06 -0700
Message-ID: <4C98710A.2010200@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: Accept Bert's changes for CSS2.1 Issue 121 with slight edit
     suggested by dbaron in the minutes.
   - RESOLVED: Accept fantasai's proposal for CSS2.1 Issue 158
   - Reviewed proposal for CSS2.1 Issue 158; more edit work needed.
   - RESOLVED: Accept fantasai's proposal for CSS2.1 Issue 172
   - RESOLVED: Accept fantasai's proposal for CSS2.1 Issue 187
   - RESOLVED: Accept updated wording for CSS2.1 Issue 187
   - Reviewed CSS2.1 Issue 197: need test case results and proposed text.
   - Reviewed CSS2.1 Issue 199

====== Full minutes below ======
   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Håkon Wium Lie
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/09/08-CSS-irc
<glazou> dbaron: do you have plans to extend -moz-*-gradient() to the CSS 3 values of <position> ?
<glazou> (as in CSS 3 Images spec...)
<dbaron> you mean the new background-position syntax?
<dbaron> glazou, ^
<dbaron> I think we'd do that at the same point we implemented that new background-position syntax
<dbaron> which we should probably do
<dbaron> but don't have immediate plans for
<dbaron> (I'm not even sure if there's a bug on it.)
<glazou> ok thx

The bridge doesn't seem to like dbaron's phone today.
<dbaron> I guess I'll try calling in from home next week.

Scribe: Tab


   plinss: Anything to add to the agenda?
   Bert: I sent an email a few minutes ago about a workshop in Japan
         that I'd like to have on the agenda.

CSS2.1 Issues

   plinss: Open issues.  First up, 101.
   plinss: Says we were waiting for a testcase from Arron?
   arronei: Test case was created.
   plinss: Anyone had a chance to review the testcase yet?
   TabAtkins: I didn't know about it had been done yet.
   arronei: I just created them in the last two days.  I just sent an
            email about them to the list.
   dbaron: There were testcases in the original email.  Is this testcase
           for the rule 3, 5, or 7 case?
   dbaron: There were already testcases, so I'm not sure why this issue
           had testcase creation assigned to it.  I think what was needed
           was proposed text to adjust the spec.
   plinss: From the minutes, all that was discussed was testcases.
   dbaron: I had an action item to write text, but I said I couldn't get
           to it for a little while.  Arron volunteered to write some test
           cases instead.
   plinss: Will you or someone else be able to step in and write some text
           for this?
   dbaron: Probably not in the next few weeks, so if someone else can do
           it that would be good.
   TabAtkins: I can try and write text for it.

   plinss: Next issue, 121.  Bert sent in a proposal on this one.
   dbaron: I responded to this a few minutes ago.  I'm fine with the
           changes, though I'm not sure the "Generally..." bit is true.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Aug/0411.html
   <dbaron> is the proposal
   dbaron: I'm not really objecting to the change, I just think some of the
           wording adjustments in the proposal I don't think are quite right.
   dbaron: I think it would help if it clarified that the paragraph in
           question had only one font; then I think it'd be true.
   <fantasai> Bert, that should be s/block-level box/block container/
   Bert: That's what the "etc" was meant to cover, but I can make it explicit.
   dbaron: That might be worth mentioning.
   <Bert> (Fantasai, isn't that already in the issues list?)
   RESOLVED: Accept Bert's changes for issue 121, with the slight edit
            suggested by dbaron.

   plinss: Next up is issue 129.
   * fantasai notes that going through all Bert's edits here is not a good
     use of time. We should focus on issues assigned ot the WG
   Bert: I need to merge 129 with 139.  It's straightforward; there's an
         email from Yves.
   plinss: issue 142.
   fantasai: Could we talk about issues that need WG discussion, rather
             than overseeing Bert's edits?
   * dsinger yeah, I thought we were basically done with 2.1 at the ftf,
     and that's all that's on the agenda?
   plinss: I'm trying to just go over the ones that looked like they needed work.
   fantasai: But we only have half an hour, and have a bunch of issues
             to look at.
   plinss: let's skip ahead then.

   plinss: 158?
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Aug/0458.html
   <dbaron> I'm fine with the edits
   TabAtkins: I'm fine with this edit, though there's a seperate note about
              something later in this thread in issue 203.
   Bert: I think it's fine.
   RESOLVED: Accept fantasai's edits for issue 158.
   * oyvind notes a typo... "the where"

   plinss: Issue 159.
   fantasai: This should be completely editorial.  I've discussed it with
             Arron and Michael.
   dbaron: What says that margins are non-adjoining due to min-height?
   fantasai: "The top and bottom margins of a box with used height other
             than 0".
   dbaron: This is a change to say that max-height has an effect.  If
           max-height is 0 and height is non-0, the margins would collapse
           here, while that wasn't true before.
   TabAtkins: Any clue what impls actually *do* with that?
   arronei: I don't have a testcase specifically for that.
   dbaron: I think it would be good to write a testcase to see what impls
           actually do.
   fantasai: Opera, Konqueror, Chrome, and Firefox do not collapse margins
             if max-height is 0 and height is non-0.
   arronei: I see consistency across the board here.
   dbaron: There's a bullet point about "bottom margin of element and bottom
           margin of last in-flow child" and the one after that - the
           problem with those two is that they change the latter changes
           the conditions of the former in the situation where all the
           margins collapse with each other.
   fantasai: I don't understand.
   dbaron: The question is, does the bottom margin of a last child collapse
           with the bottom margin of its parent?
   dbaron: In particular, the case where the parent has non-zero min-height,
           but auto height.
   fantasai: The last condition requires no children.
   dbaron: Then there's a discontinuity if you have children or not, which
           is odd and I think might be a change from the spec.
   fantasai: The fourth bullet has to be changed to say 0 min-height and
             auto height, but I don't know how that'll interact with stuff
             from the CSS3 box model.
   fantasai: I'll update the proposal to explicitly fix that part.
   plinss: Anything else with this one?

   plinss: Next, issue 172.
   fantasai: I did make a normative change, about honoring explicit widths.
   dbaron: Seems fine.
   RESOLVED: Accept fantasai's edits for issue 172.

   plinss: Issue 173?
   fantasai: I've worked on it, but it's a mess.
   TabAtkins: Also, Henri responded to it this morning, so there's still
              work to be done on it.
   plinss: We'll come back to it.

   plinss: Issue 187?
   <TabAtkins> I like the text now, though I have no clue about it matching
               reality or whatnot.
   <fantasai> Reality seems kind of confused when last I tested it :)
   * bradk has no idea about this one
   Bert: I like it.  Seems precise.
   <bradk> :)
   RESOLVED: Accept fantasai's edits for issue 187.

   plinss: Issue 191.
   [Reviewing proposed text to implement previous resolution.]
   TabAtkins: I agree with this.
   arronei: Do we say anywhere that markers create a line box?
   fantasai: We say they *may*.

   plinss: Issue 192.
   plinss: At the ftf we decided the 3rd issue was invalid, but there
           was some pushback on that?
   dbaron: There's a *lot* of references in Anton's email, that you have
           to read in the right order to know what is being talked about.
   TabAtkins: I'll produce an "executive summary" of all the references,
              so we can know what's being referred to exactly.

   plinss: Issue 197.
   fantasai: Boris just replied to this and gave an example:
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Sep/0198.html
   TabAtkins: That's why we don't hoist inline clearing up to its containing
              block normally.  Can't recall why we did it in this case.
   fantasai: Because we thought that's what the prose was trying to say.
   TabAtkins: Since IE is the only browser that implements run-in, can we
              get a quick test-case to see what it does here?
   <oyvind> we do too...
   arronei: I think there's going to need to be a few testcases for this.
            I can put them together so we can see them next week.
   <oyvind> (opera matches IE8 on those as far as I can see)
   TabAtkins: Can we do the rest of these tests off-call?
   <fantasai> arronei: 
   <fantasai> arronei: Question is, does clearance move the silver box in both cases?
   <fantasai> arronei: Or the silver box in one case and the text in the other?

   plinss: Issue 199.
   TabAtkins: I sent an email to the list yesterday to define that lineboxes
              are *not* created in the relevant situations, rather than the
              somewhat circular prose currently in the spec.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Sep/0190.html - Tab's proposal
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Sep/0194.html may also be helpful
   * fantasai thinks we should mark run-in at risk
   * fantasai is ok with Tab's proposal
   * oyvind would like a definition of in-flow
   <fantasai> oyvind, not out-of-flow :)
   dbaron: If a linebox isn't created, what are the positions of the things
           that would have otherwise been there?
   fantasai: You could instead say that such lineboxes are only used to
             calculate the position of boxes that would be in the linebox,
             but not for any other purpose.
   TabAtkins: I will send an updated proposal that says something to that
              effect today.

   fantasai: Last thing was issue 203, which is a testable change in margin
             collapsing.  Arron and I talked with Michael in Oslo and it
             seemed that implementations actually agreed on it.
   plinss: Okay, we'll talk about that next week.

Meeting closed.

<oyvind> fantasai, I'm not sure if you're joking or if that's actually
          defined somewhere :)
<fantasai> oyvind: that's actually the definition
<oyvind> but is it assumed to be obvious what counts as "out-of-flow"?
<oyvind> http://www.w3.org/TR/CSS21/visuren.html#img-floateg "non-positioned in-flow blocks"
<fantasai> oyvind: if you want to file an issue, you must send an email
<oyvind> yeah, I'll do that tomorrow or something
Received on Tuesday, 21 September 2010 08:47:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:50 UTC