- 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