- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 25 Dec 2010 13:18:51 -0500
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0122.html
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
inline
<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:
http://lists.w3.org/Archives/Public/www-style/2010Oct/0842.html
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
incrementing
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
assumptions.)
<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
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0040.html
<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
supported)
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
pass
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