W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: ISSUE-4: Versioning, namespace URIs and MIME types

From: Robin Berjon <robin@berjon.com>
Date: Wed, 18 Feb 2009 14:42:34 +0100
Cc: HTML WG <public-html@w3.org>
Message-Id: <A479B560-DAE8-47EC-AECE-C74FC99037E1@berjon.com>
To: Robert J Burns <rob@robburns.com>
On Feb 17, 2009, at 20:12 , Robert J Burns wrote:
> On Feb 17, 2009, at 3:31 AM, Ian Hickson wrote:
>> On Tue, 17 Feb 2009, Robert J Burns wrote:
>>> On Feb 16, 2009, at 9:35 PM, Ian Hickson wrote:
>>>> Given the following function in a script:
>>>> function test(imp) {
>>>>  // imp is a DOMImplementation object
>>>>  var doc = imp.createDocument(null, null, null);
>>>>  var e = doc.createElementNS('http://www.w3.org/1999/xhtml',  
>>>> 'img');
>>>>  return e;
>>>> }
>>>> ...browsers are required, for compatibility with legacy content,  
>>>> XHTML1,
>>>> DOM2 HTML, and DOM2 Core, to return an element that, when  
>>>> inserted into a
>>>> document, displays either an image as indicated by its "src"  
>>>> attribute, or
>>>> text as indicated by its "alt" attribute.
>>> But that element has neither value set. I'm not following your  
>>> example.
>> The element has to be an element that acts as above for any  
>> subsequent
>> value set, changed, or removed for those attributes.
> So the script is a total distraction. You're simply saying that an  
> 'img' element has to behave in a way that conforms to the  
> implementation conformance criteria of HTML5. OK, fine we all knew  
> that. For XHTML2 it would have to behave in a way conformant to the  
> XHTML2 implementation criteria.

That's not what was said. The point here is that HTML5 has a  
requirement that code such as the above, which works today in HTML4  
and XHTML1, keeps working as is and producing the same result. Since  
there is no way above to tell whether the img element is an XHTML1 or  
XHTML2 object if XHTML2 takes over the namespace, there is no way in  
which a browser could guess which behaviour to use.

If you don't understand this from the short and abstract example  
above, consider a more concrete if longer one:

<svg xmlns='http://www.w3.org/2000/svg' width='320px' height='480px'  
viewport='0 0 320 480' onload='test()'>
     function test () {
         var img = document.createElementNS('http://www.w3.org/1999/xhtml' 
, 'img');
         img.setAttributeNS(null, 'alt', 'Dahut Numero Uno');
         img.textContent = 'Alternative Dahut';
   <foreignObject id='fo'/>

Today that shows "Dahut Numero Uno". If the UA suddenly supports  
XHTML2 instead of XHTML1, then it'll display "Alternative Dahut"  
instead. All of a sudden, my content is broken. If the application  
supports both, it has no way of guessing (and the only safe strategy  
for an implementer here is to default to XHTML1).

Because of this, if XHTML2 wishes to use same namespace as XHTML1 then  
is MUST be 100% compatible and not cause content to break. If it  
really intends to be a rethink of XHTML that starts off from a new,  
purportedly saner base, then it really MUST use a new namespace lest  
it break content (and incur both wrath and abandon).

You'll note that this has nothing to do with HTML5. Reusing the same  
namespace for incompatible content is a really, really terrible idea  
irrespective of whether HTML5 exists, or is being worked on, or uses  
that same namespace.

The reason HTML5 gets to use the namespace is because its absolutely  
core design orientation is that it will be backwards compatible, no  
matter how distasteful some corners of the specification need be.

Furthermore, if the XHTML2 WG has had a change of heart and wishes to  
be backwards compatible, then it needs to rethink its charter, and  
rather than duplicate the work that was chartered to be done here,  
either merge into this group, or focus on specifying how XForms, XML  
Events, etc. can integrate into an (X)HTML5 based framework (thereby  
inheriting work on making BC possible).

To put it in a nutshell:

   - if XHTML2 uses the same namespace
     then it needs to be backwards compatible to not break content

   - if XHTML2 is backwards compatible
     it is duplicating the work being done here, and another  
arrangement or merger should happen

   - if, on the other hand, XHTML2 is starting from scratch and not BC
     then it has no reason whatsoever to use the same namespace, and  
good reasons not to

Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Wednesday, 18 February 2009 13:43:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC