Re: CR exit criteria and features at risk for HTML5

On Thu, 16 Aug 2012 17:50:39 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 8/16/12 8:21 AM, Benjamin Hawkes-Lewis wrote:
>> Some other audiences that needs consideration, but aren't mentioned in
>> your feedback, are authors, people writing guidance for authors, and
>> other spec writers (EPUB etc.).
>
> For all of these, an out-of-date and known-buggy REC seems worse than a  
> more up-to-date spec.

Right.

> The only benefit of a REC for such groups is if the REC doesn't get  
> changed, but an unchanging REC is even more likely to not match  
> implementation reality.

There are a lot of groups who accept that a REC is not quite perfect  
(there are still real security peoplewho accept XP on the basis that  
unlike windows 8 they are confident that they know what they need to do to  
cover security holes).

The relatively slow update cycle, and the time taken in the final  
polishing towards REC, gives them time to figure out what they are really  
getting, as the target stabilises.

> It's a hard problem, I agree.  I'm not quite sure how to solve it well.

More information (test suites, caniuse/coremob/whatever) help people  
understand and make more informed decisions. Expecting everyone to work to  
the editor's version, or everyone to wait for the REC, or any other  
one-size-fits-all solution is probably wishful thinking and a waste of  
time.

> For authors, per-feature stability annotations may be the way to go. For  
> something like EPUB, I don't really know how to proceed.

stability and implementation info is useful for them too. They often  
implement software (or work with people who do) and understand the gap  
between perfection and stuff you can actually use to get work done...

>> Information about the interoperable
>> implementation status of features is critical for that audience.
>
> I agree, but that information is not captured in a REC.

Sure. THe point of a REC is to snapshot stuff against which that  
information can be written without having it shift all the time.

>> These audiences likely naively assume that features in RECs should work.
>
> I think this assumption is false to a greater or lesser extent....  I  
> believe that's what you're saying also?

I think a lot of key audiences are aware that things might or might not  
work (people who have lived with HTML 4 for a decade might have actually  
tried their products...). But sometimes they value stability over  
perfection. And if you are trying to show some text, some pictures, let  
people hand over a form-page full of info and follow them around with a  
cookie, then maybe there is a good reason to accept the current state  
rather than waiting for a few years.

>> HTML-Next/Living Standard and the linter need to do a better job at
>> highlighting implementation status. I agree adoption of a common test
>> format could help provide better information here. Does Mozilla have a
>> test harness for running the HTML test suite?
>
> Apparently, yes, as of recently.  So I'll see what we can do about  
> mirroring tests back and forth.

YAY! (I understand that this, like most participation in standards,  
doesn't come free. I believe it helps those who do it, and it is also  
greatly appreciated by the rest of us).

cheers

Chaals

-- 
Chaals - standards declaimer

Received on Thursday, 16 August 2012 23:20:04 UTC