...

View Full Version : good stuff on namespaces and the DOM



beetle
03-22-2003, 02:02 AM
Note: This thread was originally split from this (http://www.codingforums.com/showthread.php?s=&postid=82941) one.

Your friendly supermoderator,
jkd





Originally posted by Alex Vincent
Fortunately, you shouldn't use the namespaced-attribute methods as well.Pardon my ignorance, but I'm not quite sure what you're saying here....

Oh, and other than "it's what's right", how does using the namespace affect the code/result/whatever

jkd
03-22-2003, 02:24 AM
Originally posted by beetle
Pardon my ignorance, but I'm not quite sure what you're saying here....

Oh, and other than "it's what's right", how does using the namespace affect the code/result/whatever

HTML documents don't need to (can't) deal with namespaces. However, in an XML document, such as XHTML, elements MUST be namespaced. createElement by default returns a non-namespaced element. Therefore, you need to use createElementNS.

As for namespaced attributes, with the exception of XLink and RDF, it seems every common XML Application published by the W3C uses non-namespaced attributes. I'm not entirely sure if that is a good idea, but whatever.

beetle
03-22-2003, 03:00 AM
Yes, I understand all that, but why "must they"? What I mean is, if they must, there must also be consequences for not doing so.

It's the consequences that I don't know. All my test-pages are XHTML Trans. Must I be using Strict to see some sort of adverse effect?

jkd
03-22-2003, 03:48 AM
Originally posted by beetle
t's the consequences that I don't know. All my test-pages are XHTML Trans. Must I be using Strict to see some sort of adverse effect?

No, I can almost guarantee your pages are tagsoup. Documents served as text/html are just that, HTML, even if you pretend it is XHTML. Unless you serve the page as text/xml, application/xml, or application/xhtml+xml (or anything that invokes an XML parser), the page is being interpretted as HTML, regardless of any XML formity.

beetle
03-22-2003, 05:01 AM
Okay, I think that's what I was looking for. So this script would just plain not work if the page was served as text/xml etc?

Remember jkd, I'm an application guy, not a theory guy ;)

jkd
03-22-2003, 06:53 PM
Originally posted by beetle
Okay, I think that's what I was looking for. So this script would just plain not work if the page was served as text/xml etc?

Probably not.

And I'm telling you, theory is soooo much nicer. Especially when you can bypass the application with nice browsers like Mozilla :p.

liorean
03-22-2003, 09:46 PM
When it comes to the DOM, theory is like childrens game against application.

But, the theory can get maze-like when you're taking version differences, MIME-types and namespaces into account.

DOM1 has no namespace functions, but you *should* be able to use it on xml-files.

DOM2 provides namespace functions, but here you have another difference: createElement and createElementNS without a namespace aren't entirely alike. createElement only works in environments without namespace handling, while createElementNS must be used in namespaced environments, even if the namespace is the default one.

brothercake
03-22-2003, 10:57 PM
Originally posted by beetle
So this script would just plain not work if the page was served as text/xml etc?

I just tried using createElement('name') on a page served as application/xhtml+xml. It's what jkd said - it doesn't work at all. But how do you add an object created using createElementNS? I tried to append it to document.body but 'document.body is not an object'?

As for theory vs application - well, theory is what we'd like things to be; application is what they actually are. 95% of the time I don't have a choice - application has to win or I don't get paid :(

jkd
03-23-2003, 12:32 AM
The reason you didn't get document.body is that Mozilla doesn't create an HTML DOM unless it has the text/html mime-type. application/xhtml+xml is basically treated like text/xml, and so it uses the Document constructor, not the HTMLDocument constructor.

One can argue that the HTML DOM should be applied to an XHTML document, but one can also argue that since an XHTML document can contain lots of funky things, it may not be a good idea to throw application-specific DOM's in the mix.

Either way, that's basically a long way of saying that there is no document.body when you serve the document as something other than text/html, at least in Gecko. :)

brothercake
03-23-2003, 12:45 AM
Right ... so at this point we're dealing with the XML DOM and not the HTML DOM ... so what are the major differences?

jkd
03-23-2003, 12:51 AM
Originally posted by brothercake
Right ... so at this point we're dealing with the XML DOM and not the HTML DOM ... so what are the major differences?

Primarily things to do with document. Remember, document is now an instance of XMLDocument, not HTMLDocument, so you lose an application-specific properties and methods, like document.body, document.getElementsByName(), the document collections (forms, links, etc).

Element-level things are still the same, as those constructors remain the same.

http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26809268

You basically just lose those properties and methods. (note that document.write() is no more)

liorean
03-23-2003, 01:20 AM
For xhtml served as 'text/xml', 'application/xhtml+xml' or 'application/xml'; the document is essentially DOM Core, not DOM HTML. Since moz has an "extensive knowledge" of the xhtml namespace, though, it knows what semantics and functionality should be added to xhtml elements.

In iew, it's worse - that browser brings no knowledge of the xhtml namespace into it's xml parser, and it doesn't have the namespaced DOM functions.

Op7 also gets tricky - that browser knows xml - all right - and it does have some knowledge of the xhtml namespace, but it doesn't parse script tags and it doesn't support the namespaced functions in DOM.

I have no knowledge of how saf/konq handles xhtml as xml, but I'd say it's a fair bet that mozilla is the only browser that really brings some good support.

(BTW, as xml contains no way of including a script in a page, opera might very well be the browser that does the right thing - it's likely that people will have to either append scripts by xlink or run them from the opener application.)


The reason for not creating an HTMLDocument instead of a plain Document, is a few compatibility issues xhtml has with other xml languages. They are roughly the same as those given for explanation why mozilla isn't an xhtml user agent, but an html user agent and an xml user agent with extensive knowledge of the xhtml namespace.



The difference between HTMLDocument and Document (HTMLDocument carries pver all properties and methods of Document, so these are only the additional ones for HTMLDocument):

properties:
title, referrer, domain, URL, body, images, applets, links, forms, anchors, cookie
methods:
open, close, write, writeln, getElementsByName

brothercake
03-23-2003, 01:37 AM
Originally posted by liorean
properties:
title, referrer, domain, URL, body, images, applets, links, forms, anchors, cookie
methods:
open, close, write, writeln, getElementsByName
Doesn't look like anything I'll miss; nothing useful that can't be done some other way (unless you count being able to open windows as useful, which I don't)

But a couple of things sprang into my mind that might be problems -

- how do you refer to a cookie? Can you not refer to cookies in XML DOM?

- how do you deal with radio controls if there's no name? You can't, surely, have multiple radios with the same ID??

brothercake
03-23-2003, 01:48 AM
Originally posted by liorean
I have no knowledge of how saf/konq handles xhtml as xml

It handles .xhtml pages served as application/xhtml+xml :) I don't know after that.

liorean
03-23-2003, 02:07 AM
Originally posted by brothercake
Doesn't look like anything I'll miss; nothing useful that can't be done some other way (unless you count being able to open windows as useful, which I don't)

This is document.open, not window.open. This means you still can open windows, but you can't open a stream for writing sourcecode to the document.



But a couple of things sprang into my mind that might be problems -

- how do you refer to a cookie? Can you not refer to cookies in XML DOM?

W3C felt like cookies weren't really part of the document. Browsers can handle them any way they wish, which includes adding the cookies property to the Document interface.



- how do you deal with radio controls if there's no name? You can't, surely, have multiple radios with the same ID??
You'll have to filter out the name attributes, like you'll have to sort out the type attributes, by regular DOM methods. As xml doesn't specify either a specific CLASS, NAME or ID type of attribute you'll simply have to check the elements for them. Same goes for #id and .class in css. Besides, getElementsByName was so inconsistent across browsers that you couldn't use it anyway.

brothercake
03-23-2003, 03:07 AM
Originally posted by liorean
W3C felt like cookies weren't really part of the document

Oooookay ... so they just leave it for each vendor to implement a non-standardised property? if they feel like it? :rolleyes:


Originally posted by liorean
You'll have to filter out the name attributes, like you'll have to sort out the type attributes, by regular DOM methods.

I was thinking more in terms of form submission - you send the value of a radio control as name=value - but if there's no name, how do they become collections?

liorean
03-23-2003, 03:23 AM
Well, it's got to do with what the spec is supposed to cover. DOM should cover the document and necessary mechanisms for modifying it, nothing else. The rest is just there for compatibility with DOM0. Xml doesn't need DOM0 compatibility, so they dropped it. ECMAScript describes only the base language, not the host objects, so you'll not get any spec over this from there either. I guess you'll have to trust that MS wants to keep their browser compatible with NS's javascript, and nowadays the other way around as well. And that others follow suit and implement the union or more. There were never more than a de facto standard covering host objects such as window, document, navigator, location, screen, history etc. before the DOM arrived, and that's the way it'll probably stay.
Noone wants to create a spec for pure host objects.



Have a look at [XFORMS] (http://www.w3.org/TR/2002/CR-xforms-20021112/). That's the way you do forms in xml. An xml user agent with knowledge of the xhtml namespace would probably handle html forms as well.

Alex Vincent
03-23-2003, 03:46 AM
I didn't mean to create that big of a firestorm with my comment... :eek:

jkd
03-23-2003, 04:31 AM
Originally posted by brothercake
I was thinking more in terms of form submission - you send the value of a radio control as name=value - but if there's no name, how do they become collections?

But there is a name attribute. ;)
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_extformsmodule

Check it out. At least, XHTML 1.1 says there is, and that it is CDATA.

brothercake
03-23-2003, 04:35 AM
Originally posted by Alex Vincent
I didn't mean to create that big of a firestorm with my comment... :eek:
I'm glad you did - this has turned into a fascinating, if slightly bewildering, discussion :cool:

ahosang
03-24-2003, 12:54 PM
also in Mozilla, when using .xhtml extension, be aware that the <body> only goes physically as far as the content. So, if your body had just one line of text, say, and a styleheet applied:
body {
background-color:green;
height:100%;
}
The green wouldn't cover the whole window, but just be a one line of green. To cover this, put html tag in there as well:
body,html {
background-color:green;
height:100%;
}

brothercake
03-24-2003, 01:57 PM
that's true for any XHTML/ standards mode page - whatever the mime-type or file extension - BODY no longer represents the whole canvas, but HTML does.


Is there any easy object test for XML DOM? I was thinking

if(typeof document.createElementNS!="undefined")
{
...
}
else
{
...
}


But maybe there's something easier - a global var that could be set to avoid lots of individual object or features tests?

liorean
03-24-2003, 02:58 PM
If you wish to determine whether the document is parsed as html or xml, try simply checking for the existence of document.body. It won't exist in xml documents.

If you want to check for strict/quirks rendering modes, test document.compatMode for /^backcompat|quirksmode$/i. Note that in ie, xml is alwas handled as 'BackCompat', while moz and op7 uses doctype switching for determining appropriate rendering mode.

If you on the other hand want to determine whether the browser can use namespaced DOM functions or just the non-namespaced, determine whether document.createElementNS exists. (Must be combined with an xml/html check to be useful in any way.)



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum