Re: Call for implementation ideas

Just to throw out some comments about CSS 2.1, more than anything else:

On 17/05/11 09:41, James Graham wrote:
> I believe the CSS WG considered 2. to be "two UAs that interoperably
> implement all features". This is to ensure that the spec can't reach PR
> with UAs A and B implementing subset X of the features and C+D
> implementing subset Y but implementing the union X|Y being impossible. I
> think this makes sense although it is a considerably higher bar than
> just having two implementations of all features.

I believe this was the original intention. However, as it is today, no 
one UA passes all CSS 2.1 tests. It was considered, I believe, IE9 (and 
more recently 10) being able to pass almost all of the tests (with known 
reasons for all failures) was proof that the entire spec could be 
implemented without contradiction, and then just required (effectively) 
one other implementation passing each test.

> In any case we also need tests for all features. The stated CSS policy
> seemed to be to drop features that didn't have sufficient tests.

I can't really think of any case where it's been lack of tests rather 
than lack of implementations causing features to be dropped, though 
there might be so.

> In general, it should be noted that dropping features isn't necessarily
> easy. For example if we can't get two perfectly interoperable
> implementations of the exact details of how script scheduling works, it
> isn't possible to just pull that feature from the spec wholesale without
> a huge amount of work and a huge amount of undefined behavior. So there
> needs to be scope to compromise on the requirements or the timeline.

That's a fair way from what actually has happened with CSS 2.1 
by-and-large. While yes, features tend to be dropped if they have no 
implementations, if features are implemented in a non-interoperable 
manner, the behaviour is defined to be undefined, and a non-normative 
note of what the behaviour is expected to be in CSS3 is added (pretty 
much making non-interoperable requirements informative).

My opinion (at this point in time, we'll pretty much have to just see 
where we are when we're trying to get to PR) is that requiring one 
completely compliant UA (proving the entire spec implementable) and at 
least one other UA passing each test (giving us multiple implementations 
of each requirement, showing they're clear enough to be interoperability 
implemented).

As for what to do about features without tests, I think we nowadays 
should have a lot less of a problem getting tests authored as UAs 
implement the spec than CSS 2.1 has had over the past decade; the 
testing cultures are radically different now to ten years ago. Let's 
deal with this problem when we hit it.

Non-interoperable features should probably just be made informative and 
left in the spec. I can't see any better compromise between actually 
progressing forward and having undefined behaviour.

-- 
Geoffrey Sneddon — Opera Software
<http://gsnedders.com>
<http://opera.com>

Received on Wednesday, 18 May 2011 08:38:42 UTC