- From: Chaals McCathieNevile <w3b@chaals.com>
- Date: Fri, 17 Aug 2012 22:10:37 +0200
- To: "Aryeh Gregor" <ayg@aryeh.name>, "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: public-html@w3.org
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