- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 22 Sep 2009 01:13:16 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Shane McCarron <shane@aptest.com>, Maciej Stachowiak <mjs@apple.com>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
On Tue, Sep 22, 2009 at 12:31 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Henri Sivonen wrote: >> >> On Sep 22, 2009, at 01:17, Shane McCarron wrote: >> >>> So my first reaction is "don't do that". >> >> >> By the HTML WG's Design Principles, error handling needs to be defined. >> It's not good enough to say that it's an error, so don't do that. > > The design principles also say "pave the cowpaths", yet HTML5 defines an > entirely new syntax. > > So citing the principles doesn't seem to be productive here. Isn't paving cowpaths *exactly* what we're doing here? HTML5 describes the syntax used for the billions of HTML documents browsed by people every day better than any other specification draft I've ever seen. And I've worked decently closely with the HTML parser in Gecko for many years now. For the first time ever there is actually a document which we can check our implementation against and fix bugs, rather than having to guess what most pages expect. If that's not paving a cowpath then I guess we have a different understanding of that principle. Additionally, I don't understand your logic that if we in some part of the spec had decided not to follow a principle (which I maintain isn't the case here), then we should throw out an entirely different principle in an entirely different context? / Jonas
Received on Tuesday, 22 September 2009 08:14:23 UTC