Re: some technical thoughts about incremental improvements to forms

On Wed, 6 Sep 2006, Lachlan Hunt wrote:

> e.g. For unknown elements that aren't pseudo-XML, like this:
>
> <foo>content</foo>
>
> "FOO" and "/FOO" are both treated as distinct empty elements, 
> rather than the start- and end-tags for the same element.  The DOM 
> looks like this:
>
>  FOO
>  #text: content
>  /FOO

Yes, that is indeed annoying. The same work around applies which
is to insert the element into a namespace as part of a clean up
process initiated when the document gets the load event.

> IE's DOM is often significantly broken.  Well-formedness errors 
> are not fatal for pseudo-XML, they're treated similarly to the way 
> such errors are treated in HTML.
>
> With badly nested elements, it produces a DOM where a node doesn't 
> even appear in its parent's childNodes list.

When people generate malformed markup they are putting themselves at 
the mercy of the browser's error handling behavior (Caveat scriptor)

>> The original case is preserved if the element has a namespace, e.g.
>>
>>        <h:bind id="b1" name="fred"/>
>> 
>> where h has to have been bound to a namespace URI.
>
> It doesn't have to have been bound to a namespace for IE to treat 
> it as pseudo-XML, it just has to have a prefix.  Where the prefix 
> is not defined, it just generates a PI like this:
>
> <?xml:namespace prefix = h />

My tests showed that the prefix has to be bound to a namespace URI
for IE to allow CSS selectors to take effect on that element.

>> Firefox and Opera treat "/>" as if it was ">". Firefox also forces all 
>> elements to uppercase. Opera doesn't. It seems that browser developers 
>> aren't particularly thorough in reverse engineering IE's behavior in 
>> parsing well formed markup.
>
> Why should they copy IE in this case?  IE's pseudo-XML nonsense is 
> not widely used or *depended upon* for anything in the real world 
> (even though it sneaks into the garbage generated by MS Office) 
> and is not defined anywhere.

I agree that IE's processing instruction hack is a little eccentric
to say the least, but I don't see why browsers should ignore the />
syntax as that only makes it harder to deploy mixed markup 
documents.

>> My point is that if all browsers honored the /> syntax for non 
>> HTML elements delivered as text/html and preserved the case, it 
>> would make it that much easier to deploy mixed markup documents.
>
> My point is that the whole idea of embedding XML in HTML is 
> nonsense and should have no part in any transition from HTML to 
> XML.  I'll be explaining this last point more in a future post.

I look forward to that!

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

Received on Tuesday, 5 September 2006 16:01:43 UTC