Re: CR exit criteria and features at risk for HTML5

On Fri, 17 Aug 2012 18:20:11 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 8/17/12 9:35 AM, Aryeh Gregor wrote:
>> On Fri, Aug 17, 2012 at 4:19 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>> Because if it's not planned to be released to users then the bar for  
>>> how
>>> much content it can break is much higher, not least because it hasn't  
>>> gotten
>>> as much user testing.
>>>
>>> And if implementing the spec requires breaking content that user-facing
>>> implementations are unwilling to break, then that's somewhat bad.
>>
>> I agree that the spec can't be deemed really stable until there's
>> enough web content out there that browsers can't change significantly.
>>   I don't think REC should be contingent on the spec being really
>> stable.
>
> I'm not sure what that has to do with what I said.
>
> The point of the two implementations requirement is to make sure the  
> spec is in fact implementable as written.
>
> If it's implementable standalone but not as part of the overall web  
> platform, that's not very helpful.
>
> So if you're going to have a two implementations requirement at all, the  
> only thing that makes sense is that they be good-faith implementations  
> of the full web platform.  At least in my opinion.

I sympathise with this idea. It certainly makes sense to ensure that  
"implementable" means "implementable in a real-world product that relies  
on the web". There is a certain difficulty in drawing the lines though.  
Does something work if it is only implemented for the US market? Is it  
necessary to demonstrate that you can build an authoring tool for HTML5 in  
chinese - or at least in some CJK language? Is a serious commercial  
project "experimental" if it is only working in Bogota? Is a community  
project in Kenya sufficiently serious?

In general I am in favour of permissive rules and strict ambitions - we  
should aim to ensure that HTML5 really can be implemented - not just by  
browsers, but by authoring and content management systems, in large-scale  
production environments, and around the world.

Against that, rather than holding back until we are sure every last bug is  
fixed we should be looking at releasing something that works better than  
HTML4, and doesn't have "glaring" bugs. (I won't bother defining them -  
most of us will know them when we see them, and not all of us will agree  
on how serious they are anyway - which is why the chairs are tasked with  
finding a working consensus rather than delivering perfection).

cheers

Chaals

-- 
Chaals - standards declaimer

Received on Friday, 17 August 2012 20:11:04 UTC