711229 - xmlVersion method disabled or removed

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[John A. Bilicki III]

The xmlVersion method (window.document.xmlVersion) which is part of a live published specification was disabled or removed in bug 693162.

The LIVE PUBLISHED standard...
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations

Unless there is an updated alternative this needs to be reimplemented in to the browser.

My software is dependent on this method to allow users to verify the integrity of the page. In it's absence I am unable to allow verification using Gecko based browsers. This is equivalent to telling IE users their browser doesn't support WebGL.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

There is an updated alternative: <http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html>.

Comment 2

[John A. Bilicki III]

Then what is the equivalent to window.document.xmlVersion?

Comment 3

[Boris Zbarsky [:bzbarsky]]

The constant 1.0?  That's all it ever returned for XML documents.

Comment 4

[John A. Bilicki III]

I need to make sure that the page is being rendered as application/xhtml+xml and not text/html in certain cases.

Since this is apparently not possible the next best way to approach this is to determine which parser is being used: SGML or XML.

Creating a file from scratch and naming it with a file extension HTML makes Firefox render it as HTML (text/html) whereas using the .xhtml extension makes Firefox render it as XHTML (application/xhtml+xml).

Using Firefox 8 currently this works great as what it returns mirrors the mime/media type...

alert('window.document.xmlVersion = '+window.document.xmlVersion);

My goal is to prevent users from validating the page (through JavaScript/AJAX) with malformed XML by ensuring the SGML parser is NOT being used (the XML parser instead). The problem is that I do no want to have the site generate poor code that will trigger the HTML correction (e.g. in HTML5 the method to universally determine how to handle malformed code). By preventing submission of malformed code at the CLIENT it saves valuable server resources as well as the resources of say making a call to the W3C.

So I need to ensure that the XML parser is being used which I correlate to the mime / media type application/xhtml+xml. I do not trust XHTML served as text/html and frankly I don't care if any rendering engine uses the SGML parser for it instead.

Since there is a newer version (that has been suggested) I will use DOM detection and use it first and then fall back to xmlVersion method.

So if this correlates well enough to serve my purpose all I need to know is what the path is to the new method, e.g. window.document.xmlVersion.

The main issue at hand though is the approach to which Jonas is trying to implement things. I see no mention of the "new" methods in example in the bug reports and the MDN documentation isn't being updated. Lastly and I think most importantly is the lack of console errors clarifying what the "new" methods are other then what translates to "method you have used for 10 years no longer understood" which is confusing at best and ultimately useless if you're trying to write standards compliant code.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I need to make sure that the page is being rendered as application/xhtml+xml and not
> text/html in certain cases.

document.contentType should tell you that, no? 

You can also detect it trivially by seeing whether document.createElement("foo").tagName is "FOO" (in which case you're text/html) or "foo" (in which case you're some sort of XML, though maybe not application/xhtml+xml).

> Since this is apparently not possible

Except of course it is; see above.

> Since there is a newer version

Of the DOM specification.  And the new version of the spec removes the xmlVersion property, because in practice it wasn't interoperably implemented.

Comment 6

[Jean-Yves Perrier [:teoli]]

(In reply to John A. Bilicki III from comment #4)
> the MDN documentation isn't being updated. 

The MDN documentation, https://developer.mozilla.org/en/DOM/document.xmlVersion , has been updated on Nov 18th, almost one month before you open this bug.

I'm adding dev-doc-needed here as Comment 5 workarounds are worth to be added to the documention :-)

Comment 7

[Eric Shepherd [:sheppy]]

I've added that information to:

https://developer.mozilla.org/en/DOM/document.xmlVersion

Thanks!

Comment 8

[John A. Bilicki III]

Thanks to you both for the clarifications.

Boris, funny thing I came across your inquiry as to why someone would want to do this here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020369.html

The software I'm building has both basic XHTML generation and also allows advanced users to generate their own XHTML directly. To avoid having malformed XML make it to live (e.g. viewable by unregistered members, crawlable, etc) I require that the page successfully parse using XHTML served as application/xhtml+xml. The only validation error that I've encountered that is able to make it to a rendered page are duplicate ids (and I can scan the page for that using JavaScript). The page is validated by the user; essentially this is an automated quality control approach. Same valid XHTML should render the same across all the browsers or at least greatly reduce the chances of rendering issues especially these days. Opera 11.6 has thrown pages with malformed XML from the XML parser to the HTML parser though I haven't been able to figure out what exactly triggers it as one malformed XML error did and some others do not. This ensures that I can maximize the browsers that support validation of pages, that visitors will get quality code, the browser won't have to figure out how to handle malformed code, the server doesn't have to contact a validator and waste it's resources, etc; it's a win-win which is exceptionally rare these days.

document.contentType worked, I don't see it in the Ecmascript 5.1 (PDF) spec...have there been suggestions to implement it or something like it?

Jean, thanks for updating the documentation.

In general, I think one important issue that should be addressed is Jonas Sicking's approach to "updating" Firefox's specs. Titles including words such as "kill xyz" do NOT inspire confidence of interoperability with the lack of testing for backwards compatibility, alternative methods/properties/other objects, no useful messages in the error console, etc. I still have considerable numbers of Firefox 3.6 users (and even some more using even older versions) visiting my site. Firefox's development is moving way to fast as a user, a developer and a standards advocate. If the changes are actual improvements great, however the complete lack of communication about how to keep things working as a web designer/web developer and the documentation not being updated as quickly as these bugs are being worked on only serves to alienate Firefox. These things work against my trust with the developers working on the browser. Especially with the very hostile environment brewing over at Mozillazine (and I've even been personally threatened here for trying to resolve bugs) I think a lot of people need a reminder that the end goal isn't to make the browser standards compliant or to copy other browsers but to make the browser work using standards to reliably serve people; how these changes are communicated and implemented have unfortunately not been very successful in my opinion. Please keep these things in mind when certain people start swinging wrecking balls around at parts of the browser.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Boris, funny thing I came across your inquiry as to why someone would want to do this 

No, that was an inquiry as to why someone would want to know what the server said, as opposed to what the browser _thinks_ the server said.

> document.contentType worked,

Worked to do _what_?

Comment 10

[John A. Bilicki III]

Boris, my situation is not dependent on what the browser _thinks_, it's dependent on what the browser _does_, the _what_ was clarified in my last post: reducing resources used to only allow well-formed code to make it to live environments and thus ensure better cross-browser interoperability and improved performance from not wasting resources on error-correction. Thank you for your help and input.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> it's dependent on what the browser _does_

Right.  And what matters for that is what MIME type the browser used for the document, not what MIME type the server told the browser to use.  The discussion you linked to was about the latter, and my question in that discussion is why anyone in practice (outside a debugging tool) cares what the server told the browser to do as opposed to what the browser is actually doing.

In any case, I misread part of comment 8.  It sounds like you're now using .contentType to detect XML instead of using .xmlVersion, right?  If so, great.  Should work in a lot more browsers!

Comment 12

[John A. Bilicki III]

I won't be using .xmlVersion though if .contentType isn't implemented then using it first before testing element.tagName wouldn't make sense client/load wise (all the other browsers would have to process the first condition, ignore it and try the second when all the browsers can reference the case of element.tagName) however if .contentType is implemented in the specs officially then yes I would use that before element.tagName as eventually the other browsers would implement it and therefore performance would improve with decreasing numbers of browsers having to process the second if condition.

Comment 13

[Masatoshi Kimura [:emk]]

Currently document.contentType is in the spec.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-contenttype
But I'm not sure it will not be removed in future just like document.xmlVersion especially because only Firefox implements it at present and document.charset has been removed from DOM4 despite that it was supported by all other browsers.

Comment 14

[John A. Bilicki III]

Thank you Masatoshi.

That brings up an important concern then. I am aware that there are political disagreements in regards to DOM4 (merely a vague observation a couple years ago) so the standard has been delayed because of disagreements and thus the specification isn't yet a stable recommendation so the issue becomes this: all the DOM 1/2/3 features currently being removed in Firefox in order to become DOM4 compliant could actually be reimplemented in to DOM4 that aren't currently in the specification. That would mean that in the event something such as xmlVersion or isSameNode are removed in say Firefox 9 and then reimplemented in Firefox 11 that Firefox 10 is now not interoperable.

This begs the question: why are stable features in a stable version of the DOM specification being removed before the next version is becomes stable?

DOM level 3 currently supersedes DOM level 4 as DOM level 3 is finalized and stable while DOM level 4 is not. _Adding_ DOM level 4 features is agreeable because if they are not present in previous versions they can be tested and their presence does not yet infer permanent implementation. However since DOM level 4 is not yet a stable specification removing features however much can be argued that they will be dropped sets off a lot of red flags as the specification _can_ be changed and therefore lead to major regressions. In example the best approach would be to throw warnings in the console in regards to xmlVersion and isSameNode until DOM level 4 reaches it's stable release and then commit those finalized patches where such features are removed in the _stable_ release of DOM level 4.

Comment 15

[Anne (:annevk)]

DOM3 is not stable. It reached Recommendation while many features were not implemented in browsers. Whenever that happens it's a sure sign it wasn't ready.

Comment 16

[Masatoshi Kimura [:emk]]

Then we should not recommend document.contentType as an alternative to document.xmlVersion because it is far from "stable" until it is widely implemented.

Comment 17

[Eric Shepherd [:sheppy]]

Then what should we recommend?

Comment 18

[Boris Zbarsky [:bzbarsky]]

The one reliable cross-browser way of telling apart HTML and XML is whether .tagName for HTML tags is forced to uppercase (HTML) or not (XML).

Comment 19

[Eric Shepherd [:sheppy]]

Updated https://developer.mozilla.org/en/DOM/document.xmlVersion again.