[CSSWG] Minutes and Resolutions 2010-06-16

Summary:

   - CSS2.1 Test Suite Alpha 3 published
       http://www.w3.org/Style/CSS/Test/CSS2.1/
   - Reviewed status of open issues

   - RESOLVED: Bert's proposal accepted for CSS2.1 Issue 71
                 http://wiki.csswg.org/spec/css2.1#issue-71
               (Parsing rules for @page changed to be forwards-compatible
                with css3-page; parsing rules for normal declaration blocks
                unchanged.)
   - RESOLVED: Bert's proposal accepted for CSS2.1 Issue 119
                 http://wiki.csswg.org/spec/css2.1#issue-119
   - RESOLVED: CSS2.1 Issue 134 closed No Change. Testcases and
               implementation need updates.
                 http://wiki.csswg.org/spec/css2.1#issue-134
   - RESOLVED: CSS2.1 Issue 165 closed No Change. Already have
               interop on current definition.
                 http://wiki.csswg.org/spec/css2.1#issue-165
   - Issues 167, 170, and 171 deferred to next week.
       http://wiki.csswg.org/spec/css2.1#issue-165
       http://wiki.csswg.org/spec/css2.1#issue-170
       http://wiki.csswg.org/spec/css2.1#issue-171

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

Present:
   David Baron
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Håkon Wium Lie
   Chris Lilley
   Peter Linss

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

Peter: Anything else for the agenda?
Arron: Two new issues for CSS2.1

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

   Peter: Test suite status?
   fantasai: published Alpha 3
   fantasai: Have known issues with MS testcases -- arron is working on them
   fantasai: i18n tests have been added
   fantasai: Didn't add all of Mozilla's testcases -- didn't know the ones
             in incoming were to be added until last night, and it was
             too late to fix the remaining format problems
   fantasai: can't build tests with conflicting filenames or using support
             files not in support/

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

   dbaron: We shouldn't let open issues block CR/PR/REC
   chrisl: We need to publish REC at some point, and there are always open issues
   fantasai: I don't mind publishing a spec with issues about things
             being undefined, but I don't want to publish a spec
             where we know things are wrong
   fantasai: If we don't have time to make a definition, we should
             say it's undefined
   dbaron: We ship browsers with errors in them all the time
   peter: I don't think anyone objects to marking things undefined
   dbaron: I would prefer not to try to say things are undefined there
   peter: then we'll come back to this one (101) in the near future

   peter: issue 60?
   sylvain: Working on it this week. Planning to give Anton one last
            response. Unless he has a strong objection, that's what
            we'll take b/c this could go on forever. Should wrap up
            early next week.
   sylvain: I don't want to mess with that part of the spec too much,
            and we have 80% of what we want already

   Peter: Arron?
   Arron: Trying to commit a testcase right now, and that's my last one
   Arron: For the image, I need some help from jdaggett
   Arron: testcase is for issue 107
   Arron: image is for 154
   peter: kicking 165 back to WG?
   fantasai: I found a testcase in hixie's collection, so closed
             arron's action to write one

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-71
   peter: remember discussing this f2f, don't remember if we got
          anywhere with it
   peter: any opinions on Bert's proposal?
   fantasai: seems reasonable to me
   Peter: ... recall hearing ?? was too broad change, so I'm actually
          happy with this
   Sylvain: So 3 is the proposal, right?
   Peter: Yeah
   Peter: Am I hearing silence because people are reading and thinking,
          or dont' care?
   Chris: I don't have an opinion
   <arronei> I don't have any opinion on this either
   Peter: Not hearing any objections, so propose we adopt proposal
   RESOLVED: Bert's proposal accepted for CSS2.1 Issue 71

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-119
   Chris: Proposal from Bert looks good to me
   arron: It actually makes more sense now
   fantasai: I like it too
   dbaron: ok
   RESOLVED: Bert's proposal accepted for CSS2.1 Issue 119

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-134
   <oyvind> tc is 404
   * fantasai notes that the .htm versions are generated by a makefile,
     and sometimes it runs a clobber to rebuild everything from scratch
   <fantasai> http://test.csswg.org/source/contributors/microsoft/incoming/top-with-negative-top-001.xht
   dbaron: Looks like the top is vertically centered, not the whole
           thing exactly centered
   beth: In webkit it's way up at the top
   dbaron: I think this is a change we made a few years ago
   <dbaron> Yeah, CSS 2.0 said:
   <dbaron> For 'top' and 'bottom', if the height of the containing block
            is not specified explicitly (i.e., it depends on content height),
            the percentage value is interpreted like 'auto'.
   fantasai: We have two passes, let's close no change
   fantasai: or is it supposed to be exactly centered?
   <dbaron> see also http://www.w3.org/mid/4A2965C2.9080002@moonhenge.net
   fantasai: The testcase is wrong. The text in the middle of it should
             be exactly centered
   fantasai: I still think we should close this no change.
   fantasai: The spec makes sense, but implementations have a bug to fix
   Peter: So no change to spec, fix test?
   Arron: I'll fix the test
   dbaron: Trying to figure out if it's certain that there aren't
           cyclic dependencies
   dbaron: Haven't convinced myself yet because of scrollbars
   dbaron: But that should be a separate issue if there are
   peter: something for errata
   RESOLVED: No change to spec for issue 134, implementations and test
             suite need updates

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-165
   dbaron: So the emails from last time suggested it needed testcases
           and now there's a testcase url there
   Arron: Looks like we all do the same thing
   Arron: So at least we have consistency
   dbaron: So for everyone floats stick out of the left edge of
           the containing block?
   Arron: Right
   dbaron: Then I guess we resolve no change
   peter: Is that because we have interop or because it's the behavior we want?
   dbaron: I think it's not the best behavior, but also not worth changing
   Peter: The email from Gresley says Opera/Safari/IE7 not complying with spec
   Arron: IE7 is the only one that's inconsistent
   Arron: IE7 overflows to the right for the LTR case
   peter: any opinions?
   * fantasai defers to dbaron :P
   dbaron: I think given that it's interoperable we should leave it
   <oyvind> as for Opera, it seems to have been a bug fixed about a
            major version ago
   <sylvaing> agrees with dbaron, arronei
   RESOLVED: No change for CSS2.1 issue 165
<Zakim> -glazou
* glazou sorry phone battery dead

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-167
   * fantasai is happy with any proposal to 167 that satisfies both
     Bert and dbaron
   dbaron: I don't think I have time to understand the proposal in
           the remaining time in the telecon
   Peter: Let's defer this til next week
   Chrisl: Overall it looks good, but I agree it is a fairly
           complicated proposal
   Sylvain: Seems to be about two issues
   Sylvain: Are they really both the same issue
   dbaron: I think it's two issues with one proposal to address both
   Peter: One's about backslashes outside a string, another about
          backslashes inside a string. Don't see the first one being
          addressed
   fantasai: So defer to next week? If we have issues for Zack, we
             can ask him to clarify
   Peter: deferred to next week

   http://wiki.csswg.org/spec/css2.1#issue-171
   fantasai: I think if we want a proposal here, we need a clue of
             what the proposal should be
   fantasai: There's some text in css3-lists that say ::marker
             should appear immediately before ::before
   fantasai: Which would mean Opera and Safari have to change
   fantasai: I think their behavior would look weird if the nested
             lists had more than one item

   <dbaron> I think 170 needs some discussion too... I think there
            are at least three obvious possibilities.
   dbaron: I think there's 3 possibilities for min/max height on
          tables and rows
   dbaron: I'm not sure which Gecko implements.. I think it
           implements possibility 2 for min/mad width
   dbaron: But not sure for height
   dbaron: possibility 1 is to just ignore them
   dbaron: Possibility 2 is to treat them as limits when computing a
           computed width for each cell preferred widths
   dbaron: possibility 3 is to apply them to the row as a whole
   * fantasai prefers 2, but is not sure
   Peter: we're out of time
   Peter: David, can you send an email?
   dbaron: ok

Peter: That's it for this week. Thanks everyone

<dbaron> I thought of a fourth possibility too, and posted to www-style
<dbaron> oops, now I have a fifth

Received on Tuesday, 22 June 2010 21:28:57 UTC