- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Thu, 03 Apr 2008 14:00:56 +0200
- To: "Julian Reschke" <julian.reschke@gmx.de>, "Philip Taylor" <pjt47@cam.ac.uk>
- Cc: "Doug Schepers" <schepers@w3.org>, public-html@w3.org
On Tue, 01 Apr 2008 21:33:33 +0200, Julian Reschke <julian.reschke@gmx.de> wrote: >>> How about stating that any element with an attribute "xmlns", being >>> set to something different from "" or the XHTML namespace name, >>> implies <ext>? >> Lots of existing content uses attributes named "xmlns" -- see e.g. >> <http://philip.html5.org/data/xmlns.txt>. (Only 45 pages in the data >> set had XML content-types, so this is pretty much all text/html). It >> seems that compatibility requirements will make it impossible to base >> anything on the "xmlns" attribute. > Well, a similar argument can probably applied to *any* change in the > language, such as adding new elements. Certainly, but for a nugget of implementor experience to back up what Philip is saying: Opera at some point had some "support" for xmlns in text/html. It was removed because it broke pages when random sections or elements were no longer considered HTML markup. (I know without offering more hard facts like what exactly we "supported", how many pages we noticed breaking this is semi-anectdotal - I could look up those bugs if required). So we really can't imply <ext> when we see some xmlns - or at least not without extra magic that would "fall back" to un-implying <ext> if the "unknown" content looked like HTML after all (naturally, nobody wants to go down this route). -- Hallvord R. M. Steen Core QA JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Received on Thursday, 3 April 2008 12:01:37 UTC