- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 18 Feb 2009 14:42:34 +0100
- To: Robert J Burns <rob@robburns.com>
- Cc: HTML WG <public-html@w3.org>
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()'> <script> function test () { var img = document.createElementNS('http://www.w3.org/1999/xhtml' , 'img'); img.setAttributeNS(null, 'alt', 'Dahut Numero Uno'); img.textContent = 'Alternative Dahut'; document.getElementById('fo').appendChild(img); } </script> <foreignObject id='fo'/> </svg> 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