[CSSWG] Minutes and Resolutions 2010-12-22

   - Reviewed status of last call comments on WOFF and Progress Events
   - Reviewed tests for Issue 138
   - RESOLVED:   1. CSS2.1 will not mandate a required range of integers
                    (No change to spec.)
                 2. Update integer overflow tests to fail only if returning
                    negative number
                    (i.e. any supported range is ok, but overflowing is not)
                 3. Mark such tests as 'may' because overflow behavior is
                    currently not defined
                 4. Add assumption of 32-bit integers to test suite
                    assumptions page

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

   David Baron
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Peter Linss
   Geoffrey Snedders
   Daniel Weck (via IRC)
   David Singer
   Steve Zilles
   Unidentified Microsoft Rep

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

Last Call Comments

   glazou: two items on agenda, one about comments to other wgs
   glazou: first one was WOFF, other was Progress Events
   glazou: jdaggett requested deferring WOFF until next call, since he
           can't attend today
   glazou: Any other comments?
   sylvain: Bert sent comments, but we need them on the public mailing list
   glazou: progress events or woff?
   sylvain: woff
   glazou: We'll discuss that next time
   glazou: Progress Events?
   glazou: Simon and I agree we have nothing else to say. Any other opinion?
   glazou: Ok, I will send a message that we have no comments

CSS2.1: Test Suite Issues

   Arron: I'm looking at the issues list, looks like there are a couple
          open issues still
   glazou: Any issues we can deal with now?
   fantasai: Issue 138 is apparently not clear enough to justify one of
             its tests
   dbaron: I tend to think that we should fix the spec
   Arron: Only Opera, Safari, and Chrome fail it. All others pass, including
          old versions
   plinss: Missing data for Gecko
   dbaron: Gecko fails
   arronei: In 3 it passes
   arronei: FF3.6 it passes
   <glazou> yes it does
   dbaron: So in 4 it's failing
   fantaai: regression?
   plinss: I don't see it passing in 3
   fantasai: passes on my machine, Linux
   Arron: Passes for me on Windows
   <gsnedders> Passes in 3.6 and fails in 4.0 on Linux.
   <glazou> failed with FF4 on mac
   dbaron: I think there's something funny about the test, but maybe we
           should discuss the spec issue
   dbaron: The spec issue, basically the quesiton is, if you have a float
           that is inside a relpos inline, does the relpos of the inline
           move the float?
   dbaron: That's what the summary of issue 138 says, but the emails in
           138 were specific to block-within-inline positioning
   dbaron: If there's a block inside the inline, then the float does move,
            and we clarified that.
   dbaron: But this is just a float inside an inline
   dbaron: The spec doesn't say currently anything to imply that the relpos
           affects the float
   glazou: Any opinions here?
   arronei: I'm still looking
   arronei: I'm not going to be able to give a quick answer here
   glazou: Seems this discussion will take some time to figure out the
           correct answer.
   glazou: On the other hand we already have two impl passing the test
   glazou: So the question is, is it something that we can deal with as
           an errata after the spec is done?
   arronei: My only problem with errata in my case is that it could
            completely change what is correct
   arronei: It's not "here's more info", it's "we're changing this behavior"
   glazou: Does it fail in FF4 because the impl changed, or is it a bug?
   dbaron: When I analyzed the spec, on October 13th, my understanding was
           that the test was testing something that the spec didn't say
   fantasai notes that floats are blocks and that the spec explicitly says
            that blocks inside inlines are moved
   dbaron: That part of the spec also talks about splitting inlines around
           blocks, and I'm pretty sure we don't want that to apply to floats
   <dbaron> (and it says "in-flow")
   glazou: going in circles
   glazou: dbaron, have an opinion?
   glazou: I suggest we action someone to write a proposal
   glazou: Any volunteers?
   dbaron: I could do it
   ACTION dbaron Write proposal to handle position of float inside relpos'd
   <trackbot> Created ACTION-284
   glazou: If we don't decide, we'd have to remove the test and make the
           behavior undefined.
   glazou: Any other issue or test we could review right now?
   <plinss> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Dec/0158.html

   arronei: did we ever finish discussing issue 159?
   glazou: We discussed it in October 27 and resolved on it
   glazou: I think it was fixed.
   arronei: sounds like a =bert= edit
   <dbaron> resolved in minutes here:
   glazou: actions were 270 and 271

   glazou: Anything else?
   glazou: Peter pasted something
   plinss: Responses to invalid tests in RC4
   arronei: I have 10 more cases but am pretty much done
   glazou: How many cases are still considered invalid?
   arronei: I have 13, but other people think there are a lot more than that
   plinss: I have a list of tests that have been reported invalid and not touched,
   plinss: But there's a large number of tests here that need to be addressed
   fantasai: Most of the invalid ones are the page breaking ones
   glazou: Fixing the invalid tests takes a long time
   fantasai points to her email that analyzes the invalid tests
   <plinss> http://test.csswg.org/harness/results?s=CSS21_%HTML_RC4&t=0&f[]=1&f[]=2&f[]=4&f[]=16

CSS2.1: Testing Range of Integers

   <dbaron> http://test.csswg.org/suites/css2.1/20101210/html4/counter-increment-013.htm
   dbaron: I think the counter-increment tests are invalid
   dbaron: In the first test, it tests that the implementation truncates the
           counter to a 32-bit signed integer
   arron: That test was created after the F2F in Japan
   dbaron: But that's not what we agreed to.
   dbaron: We agreed that you could test for a reasonable range of values
   * gsnedders http://www.w3.org/TR/CSS2/generate.html#propdef-counter-incremen
               claims to be an ED, nice…
   dbaron: But implementing beyond that range is allowed
   arronei: What I was trying to test there is that you don't overflow into
            a negative number
   arronei: I could change the test so that it allows either truncation or
   glazou: If it's not in the spec, it doesn't need testing
   arronei: The only statement in the spec is that you support <integer>, but
            the range is undefined
   arronei: According to the spec, you only need to specify one number.
   sylvaing: Is there anything in the test that mandates overflow behavior?
   arronei: No
   fantasai: You could test that the implementaiton supports the full 32-bit
             unsigned range
   fantasai: by testing that the counter can go up to its limits
   fantasai: this would test for a reasonable range
   sylvaing: That's not in the spec
   fantasai explains that the test suite needs to make some assumptions that
     are not in the spec, for example, it assumes that lines will break at
     spaces and that they will break as close as possible to the edge of the
     containing block. This isn't required by the spec: the implementation
     could, theoretically, break at every 'p' instead and break at half the
     containing block width. But it's a reasonable assumption.
     The test suite can also make an assumption about the range of integers
     that are supported in the implementation. It can test that up to that
     range is supported without testing that beyond the range is unsupported.
     If an implementation is an incompatible set of limits, e.g. an 8-bit
     implementation for a Nintendo box when the test suite assumes 32-bit
     integers, then the implementor can submit and use an alternate,
     equivalent set of tests for these features to make its conformance claim.
     (We don't expect that to happen because we'll try to pick reasonable
   <gsnedders> I'm +1 with what fantasai is saying now, FWIW.
   dbaron: The agreement was that this would be a test suite assumption
   <TabAtkins> We still need to spec a required supported range for <integer>.
   discussion on test suite assumptions vs spec requirements
   <TabAtkins> (Separate from the test distinction, which we did indeed discuss.)
   plinss: integer overflow behavior isn't covered in the spec. We can add
           it to the spec later
   glazou: I suggest we add a clarification to the spec that we expect 32-bit
           integers, and write tests for it
   fantasai: I don't think we need to put this in the spec. Test suite
             assumption is enough
   fantasai: all we need is to have the tests only check that the range is
             supported, not check overflow behavior
   <dbaron> there are already separate tests for the case you want to change
            this one to
   <dbaron> I listed two different sets of tests in
   <dbaron> the tests in the first half test overflow behavior; the tests in
            the second half don't
   Simon: I don't agree that the spec should require 32-bit integers
   simon: But I do think that the spec should specify what happens when you
          overflow whatever range you support
   <szilles> +1 for what simon says
   dsinger: It's reasonable for a spec to specify a range that must be
            supported, and what's outside the range is implementation-dependent
   <smfr> http://www.w3.org/TR/CSS2/syndata.html#value-def-integer
   dbaron: one comment about what simon said, some of the test reach an
           overflow by using counters to take two integers within the 32-bit
           range and add them
   dbaron: Others do the overflow at parse times
   dbaron: So there are two different overflow conditions happening

   plinss: Here's my concrete proposal.
   plinss: We leave the 32-bit assumption in the test suite
   plinss: Define overflow behavior in a future spec
   plinss: Remove this test for now
   plinss: Change the test to match the overflow behavior in the spec
   plinss: and allow e.g. 64-bit implementations pass
   plinss: Instead of removing this test we could make it a may or a should
   glazou: Peter, do you accept an action to write a clarification?
   <dsinger> or at least a 'note' (Note: counters up to 32 bits are normally
   fantasai: If we keep the tests, then they should be a 'may', because the
             behavior is not recommended, just allowed
   fantasai: Also they should be updated so that a 64-bit implementation will
   plinss: Failure condition should be showing a negative number
   plinss: truncating for 255 should be valid according to the test
   fantasai draws up a Proposal:
   1. No change to spec
   2. Update tests to fail only if returning negative number
      (i.e. any supported range is ok, but overflowing is not)
   3. Mark tests as 'may' because overflow behavior is currently not defined
   4. Add assumption of 32-bit integers to test suite assumptions page
   <bradk> +1
   <dbaron> I'd have preferred keeping the tests that test values within the
            32-bit range as required, given (4).
   <fantasai> Yes, only mark the tests for overflow behavior as may :)
   arronei: I agree that this is fine
   <dbaron> I'm happy with fantasai's proposal.
   <TabAtkins> I'm fine with that.
   dsinger: Might want to add a note that stepping outside 32-bit integers is
            not a good idea so authors know
   glazou: Any objections to the propsoal?
   RESOLVED: Proposal above accepted.
   ACTION plinss: Create a note for the errata
   <trackbot> Created ACTION-285

Meeting closed.

<arronei> What should we do about + and * notation in the value definitions?
<arronei> What assumption should the test suite be making about those?
fantasai suggests 30
arronei says they're currently 32, so suggests leaving them at 32

Received on Saturday, 25 December 2010 18:19:29 UTC