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

[CSSWG] Minutes and Resolutions 2010-06-30

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 01 Jul 2010 18:51:55 -0700
Message-ID: <4C2D463B.70301@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - CSS2.1 Test Suite Beta 1 planned for publication this week
   - RESOLVED: 3mo (not 6mo) for next CSS2.1 CR period
               (Current set of changes probably need an LCWD.)
   - Discussed status of CSS2.1 issues, including some discussion
     of anonymous box containing blocks and white space normalization.

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

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

<RRSAgent> logging to http://www.w3.org/2010/06/30-CSS-irc
Scribe: Sylvain

CSS2.1 test suite

   fantasai: hoping to publish today but still working through testcases
   glazou: how many test updates do we need to make to account for issue
           resolutions ?
   fantasai, arronei: it will take a few days to get caught up
   glazou: so you're confident we are still on track for a september release
   arronei, fantasai: yes
   glazou: I think we should publish the CR and release the test suite together
   glazou: topic now is implementation reports. when do browser vendors plan
           on producing them ?
   fantasai: modulo spec edit updates, we have all the testcases that will be
             in the testsuite
   fantasai: then we can track which testcases have changed so vendors know
             which to rerun
   glazou: browser vendors, can you run the tests when the testsuite beta 1
           is ready
   arronei: msft has already started
   simonfr: for webkit, we can start when the testcases are ready.
   dbaron: for Mozilla it's hard to say
   arronei: running the whole thing for one browser takes ~3 days to just
            record the results
   smfr: do they need a manual run or are they automated ?
   fantasai: some are (mozilla's reftests) but the bulk are manual
   (talk about improving the harness)

CSS2.1 spec

   glazou: next question is about the spec itself. we have made a lot of
           changes so we would back to LCWD, then CR with the test suite
   glazou: the open question is the CR period which is usually 6 months,
           thus preventing us from reaching PR by end of year
   glazou: note, that is important from a W3C point of view to reach PR
           by the end of the current charter
   <szilles> +1 for shorter CR
   fantasai: given that the spec has been CR several times, I don't think
             we need a 6 months minimum
   fantasai: we need enough time to generate impl. reports and analyze them
   <szilles> +1 for 3mo period
   glazou: a 3 months period would be ideal
   RESOLVED: next css21 CR period is 3 months

   <plinss_> http://wiki.csswg.org/spec/css2.1#issue-26
   bert: still have to edit it
   glazou: I'm waiting for answers from Thunderbird and others
   bert: I haven't done any review yet
   fantasai: we have the testcases for this one
   tab: I will try to finish this by next wednesday
   bert: I can finish this in the next 2 weeks
   fantasai: I have started and have general definitions. in progress.
             planning on working on it this week
   bert: no work on this one yet
   bert: I can write a proposal this week
   (editorial, done)
   fantasai: I would add a sentence to the anonymous block section to
             have percentages resolved against the containing block
             before anonymous boxes are generated, but not sure if that's
   dbaron: what other things is the idea of the containing block used for ?
   tabatkins: percentages, positioning...anything else ?
   dbaron: I suspect that in some cases implementations agree on anonymous
           boxes not being containing block at all. this might be worth
           writing testcases
   (to be revisited next week)
   tabatkins: fantasai, I and I think authors agree on the proposal.
              dbaron's preference was more aligned with implementations
   sylvaing: will it cause testcase failures for implementations ?
   tabatkins: implementations all disagree today anyway
   <dbaron> I'm trying to remember what other issues were related to this
            issue from the time we decided to change the spec from what
            you want to say to what it currently says...
   <dbaron> (I think this is a proposal to change the spec back to what
            it used to say.)
   tabatkins: I believe we talked about this at the f2f.
   (to be followed up)
   (target next week)
   dbaron: I think we need to clarify height the way it was in CSS2
   (reads proposal)
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Jun/0570.html
   RESOLVED: accept dbaron's proposal for issue-153
   tabatkins: this really is about empty clearing elements
   glazou: everyone to review, look again next week
   * fantasai thinks you might need two images
   arronei: I am working with jdaggett on an image for this. but this
            could be left to CSS3 Fonts or CSS3 Text
   * dbaron wonders if any of the images in http://dbaron.org/css/2000/01/dibm would be useful
   fantasai: you can't put some measurements on the same diagram
   fantasai: it may be easier if it is split in two images
   glazou: let's defer to next week then
   fantasai: not done yet. i'll get to it for next week
   fantasai: not done yet
   zwol: this one ties back to the tokenizer backup issue; whoever works
         on the latter should know they're closely related
   <zwol> I can summarize the proposal
   <dbaron> comments: http://lists.w3.org/Archives/Public/www-style/2010Jun/0658.html
   * zwol skims
   (to be continued)
   <zwol> bert: the thing you need to know for the backup issue, is that
          most of the changes to strings in my proposal were necessitated
          by \-EOF not having been defined.
   <zwol> bert: also, when I wrote that, I didn't know that the prose
          defines the behavior of EOF within a comment.  The grammar
          should still handle it, but whatever i said about it in that
          old message is probably wrong.
   glazou: authors would not expect these properties to have no effect imo
   arronei: IE handles min-height but I believe no one handles max-height
   * glazou will need to leave precisely at the top of the hour
   <dbaron> I think gecko handles max-height as I described in
   smfr: webkit seems to ignore min-height on table cells
   tabatkins: I agree that I expect min/max-height to do something but I
              don't know what right now
   glazou: bradk, tabatkins to review dbaron's proposal
   <dbaron> Er, wait, when I was talking about Gecko's behavior I was
            thinking about what it does for min/max-width...
   fantasai: not done yet
   fantasai: I think the original intention was that linebreaks had been
             normalized before whitespace processing rules were applied
   fantasai: that is why CSS3 Text talks about linebreak characters
   fantasai: I suggest I apply CSS3 Text's generalization to the 2.1
             text, and then we discuss what codepoints map to the linebreak
   plinss: we will rediscuss based on fantasai's new proposal

Meeting closed.

<zwol> an interesting question for folks with the ability to grep the
        web, would be to see if there are real documents with CR-only
        (not CRLF) linebreaks in a context where those linebreaks must
        be honored (<pre>, to first order)
<zwol> I mean the actual character, not an escape
<fantasai> I'm quite sure there are
<fantasai> that was the default line break character on Macs for a long time
<fantasai> you'd get entire documents authored with only CRs as line breaks
<zwol> s'true, but not since OSX, which is nearly ten years old now?
        so it seems like that would have to be very old content
<sylvaing> IE6 is 10yo too (sigh)
<zwol> (groan) point taken
<dbaron> zwol, but that's already handled by normalization that happens
          during parsing
<dbaron> zwol, everything gets normalized to LF at parse time
<zwol> dbaron: i was thinking that if we no longer need that for webcompat,
                we could drop bare-CR from the normalization set
<dbaron> zwol, I think we do need it for webcompat.
<zwol> dbaron: ok, if you and fantasai both think we still need it, i
                believe you.
* zwol out
<fantasai> thanks, zwol
Received on Friday, 2 July 2010 05:00:49 UTC

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