W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: Choosing name for XML serialization (Was: Re: HTML5 differences from HTML4 editor's draft (XHTML5 and XHTML2))

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 22 Jun 2007 03:59:55 -0700
Message-Id: <266E364B-544D-4A83-9247-59BB93FCEF98@apple.com>
Cc: "Philip Taylor (Webmaster)" <P.Taylor@Rhul.Ac.Uk>, HTML WG <public-html@w3.org>
To: Jirka Kosek <jirka@kosek.cz>

On Jun 22, 2007, at 2:53 AM, Jirka Kosek wrote:

> Maciej Stachowiak wrote:
>> I read the message and I don't see how it has anything to do with  
>> what I
>> said. Please keep in mind that browser-hosted implementations allow
>> dynamic creation of elements and insertion in possibly foreign
>> namespaces. document.createElementNS("http://www.w3.org/1999/xhtml",
>> "input") can only have one result,
> Sure, on DOM level the result will be just one. But depending on
> stylesheets and behaviours loaded appearance and user interaction  
> could
> differ.

Consider these cases:

1) If you insert the element created above into an SVG document,  
would the XHTML1/XHTML5 or XHTML2 stylesheet and behaviors apply?
2) The element has to have a DOM API before it is even inserted into  
a document. Say you created it on an empty XML document. Does it have  
the API of an HTML <input> or an XForms <input>?

For another particularly crazy case, consider what would happen if in  
an XHTML2 document you do document.documentElement.setAttribute 
("version", "1").

Given cases like this, the whole idea of having elements that  
magically morph based on an attribute on the root element is  
fundamentally unworkable. The pair of namespace and local name have  
to be sufficient to determine the appearance, interaction behavior,  
API and events of a given element.

Even without the edge cases, it would be impractical and likely quite  
inefficient to make elements in the same namespace act differently  
based on a root element attribute.

>> In general, people commenting on what is or isn't doable in  
>> browsers may
>> wish to consider studying some browser code first.
> Thanks, I think that I can pretty well judge what is doable myself.

I admire your self-confidence. Historically I have found that people  
who lack knowledge of browser internals have a relatively poor  
ability to judge what is reasonably implementable without asking an  
expert. But perhaps you are one of the rare exceptions.

> But of course this doesn't always mean that it is easily doable within
> current browsers given the code base which was architected before such
> requirement was known.

Fortunately there is no requirement to support XHTML2, so this issue  
is mostly of academic interest.

Received on Friday, 22 June 2007 11:00:10 UTC

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