Re: CR exit criteria and features at risk for HTML5

On Sun, 19 Aug 2012 23:44:59 +0200, Maciej Stachowiak <mjs@apple.com>
wrote:

> On Aug 19, 2012, at 4:00 AM, Chaals McCathieNevile <w3b@chaals.com>  
> wrote:
>>
>> I'm happy with this too - but I am not happy if the test boils down to  
>> "must work in two browsers". It must be possible to *create* HTML5 too,  
>> and manage it effectively for a large content provider. It must be  
>> possible for a small business to effectively use HTML5 without all  
>> hand-authoring their code. And it must be feasible for organisations to  
>> include HTML5 as a reference - for a Statement of Work, as a basis for  
>> testing a product, as something to be compatible with in developing a  
>> technology.
>>
>> I don't know if this adds to the CR timeline, but it means that there  
>> is more to proving HTML5 works than getting a lot of tests from a small  
>> handful of browser makers, and running their products through the  
>> collection.
>
> All three versions of proposed CR exit criteria that I've posted limit  
> the interoperability requirement to "Web browsers and other interactive  
> user agents". See here for the full list of conformance classes:  
> <http://dev.w3.org/html5/spec/single-page.html#conformance-classes>. Now  
> that I read closer, maybe it should actually be "Visual user agents that  
> support the suggested default rendering", since that is the strictest  
> set.

Although obviously that clearly renders anything that adapts content for  
accessibility irrelevant. I think that is a major mistake, since it  
effectively ignores large swathes of users who rely on something other  
than the default visual rendering, and in particular on assistive  
technology.

Likewise this fails to take into account browsers like Opera Mini that can  
adapt the default rendering for their tens of millions of users on devices  
where the default rendering isn't actually a very good experience.

> I personally do not think the other conformance classes need explicit CR  
> exit criteria for the following reasons:
>
> - Most (such as "Non-interactive presentation user agents") are  
> effectively subsets of the mainline browser criteria.
> - For the "Conformance checkers" conformance class, we're likely to have  
> only one serious implementation.

Then it would be an extremely sad state of affairs if that implementation  
couldn't actually usefully implement the specification. Perhaps rather  
than throwing our hands in the air and saying that there is no need to  
show you can make a validator, we should say there needs to be at least  
one that can actually work...

> - The criteria for "Data mining tools" are too vague to test.
> - For "Authoring tools and markup generators", the conformance criteria  
> are essentially that their output must pass a conformance checker. I  
> believe we already know this to be possible.

I disagree. Their output should pass a conformance check - in toto,  
including things that can't readily be tested except by a human. So it  
should be reasonably feasible to do the things the HTML spec says in such  
a tool. For real users, not just the more-or-less irrelevant subset of us  
who still write source code as happily as content.

The price of dumbing down the criteria too far is that we may ignore real  
use cases that are complex. Massive amounts of Web Content is managed as  
chunks in databases that are assembled "on-demand", enabling re-use of  
common components. If we make this unduly complex, we're doing the world a  
great disservice.

To illustrate this idea, if we adopt a pattern where the essential  
components of a piece of content is split over two parts of a document,  
then it is critical that all these systems manage that split. This was one  
of the strong arguments against namespaces, against the proposal to make  
video transcripts rely on a pointer to some link somewhere else on the  
page, and in various other cases. I am not interested here in discussing  
those issues, but if we refuse to test whether a given resolution to them  
has created a practical problem that has been outlined as a real risk, we  
are effectively basing our work on unsubstantiated belief.

> That said, it's ultimately up to the Working Group whether to consider  
> other conformance classes.

Indeed. Hence, as a WG member, I'm suggesting we should indeed consider  
other classes. And for that matter, consider something broader than "4  
american browsers and one from norway" as the conformance class  
"interative user agents" (just in case anyone still thought there were  
only 5 browsers around).

cheers

Chaals

-- 
Chaals - standards declaimer

Received on Tuesday, 21 August 2012 12:18:05 UTC