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.
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.
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 .
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.
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
Last edited by brothercake; 03-22-2003 at 11:01 PM..
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.
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.
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):
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??
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.
Quote:
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.
Quote:
- 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.
Before you post, read our: 
.
