- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 6 Nov 2009 11:49:20 +0200
- To: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Cc: Liam Quin <liam@w3.org>, HTML WG <public-html@w3.org>
On Nov 5, 2009, at 23:10, Aryeh Gregor wrote: > On Thu, Nov 5, 2009 at 2:26 PM, Henri Sivonen <hsivonen@iki.fi> wrote: >> How would this differ from what HTML5 specifies now? > > My impression is that for browsers, it would not differ. They would > use a hardcoded list of namespace mappings and treat unknown elements > just as they do now. [...] > In particular, I'm assuming that an ns.xml would be optional for all > users of automatic namespaces Making the semantics of the parser output depend on an optional feature is an incredibly bad idea. There already is a case study about this in the context of XML: Optional DTDs when DTD processing involves infoset augmentation. The recent entity thread shows how DTDs are a big FAIL. Authors can't use optional features reliably but implementors end up bearing the cost of having the optional features complicating the code base anyway. Optional features near enough the core of the system a lose-lose proposition. (Because, in a large project, it's really hard to maintain a policy that no one gets to commit patches that implement optional features of a standard, there's always a risk that someone commits an implementation of an optional feature and then you can't get rid of it. Or even if you have a no optional features policy, your competitor may be fooled into implementing an optional feature, so you do too. But authors can't reliably use it even then, because there's always another piece of software that doesn't support the feature.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 6 November 2009 09:49:57 UTC