More Standards Documentation Available
Last month we published interoperability information for Internet Explorer 7 and Internet Explorer 8 focused on CSS and HTML4.01. Today we publish another set of documentation covering:
- Document Object Model (DOM) Level 1 (spec link)
- Document Object Model (DOM) Level 2 Core (spec link)
- Document Object Model (DOM) Level 2 Events (spec link)
- Document Object Model (DOM) Level 2 HTML (spec link)
- Document Object Model (DOM) Level 2 Style (spec link)
- Document Object Model (DOM) Level 2 Views (spec link)
- Document Object Model (DOM) Level 3 Core (spec link)
- Platform for Privacy Preferences (P3P) (spec link)
- PICS Label Distribution Label Syntax and Communication Protocols (spec link)
- PICS Rules (spec link)
- PICS Rating Services and Systems (spec link)
- Portable Network Graphics (PNG) (spec link)
- Ruby Annotation (spec link)
- Extensible Markup Language (XML) 1.0 (Fourth Edition) (spec link)
- XML Namespaces (spec link)
- XML Path Language (XPath) (spec link)
- XSL Transformations (XSLT) (spec link)
- ISO 10918-1 Image Compression and Encoding (JPEG) (spec link)
As before, these are drafts, and in the future we’ll talk about how we engineered these documents and will keep them up-to-date.
Thanks!
John Hrvatin
Lead Program Manager, Internet Explorer
Comments
Anonymous
January 01, 2003
Great information and direction for a standard!Anonymous
March 17, 2010
That helps a bit with IE 7/8. I've not looked through all of them, however, I find the use of 'equivalent' to be too strong when talking about attachEvent et al. Indeed, IE 8- support bubbling events on their 'DOM 2 Events' model, not capturing (that's only available with the legacy Netscape event model, which doesn't support bubbling, and the two don't mingle). Use of "partially equivalent" would be better here, as it's just impossible to emulate DOM 2 event methods with IE's event support with meaningful performance. Next, I've seen mention of the event handler function's scope a grand total of zero times - eventhough it radically changes from one model to the other: indeed,'this' in the handler function body refers to the event's target in DOM 2 Events, while it refers to the document in IE's: that means that each and every function needs to detect the event model used and depending on the model, use either 'this' or 'event.srcElement'.Anonymous
March 17, 2010
@Mitch: Which is why many people use some kind of 'addEvent' function to presumably handle all of this. Of course, that still doesn't make it right...Anonymous
March 17, 2010
Here's to all the documents one day looking like the ISO 10918-1 document!Anonymous
March 18, 2010
So the version of XML supported is 1.0, but the namespace support is for 1.1 (judging by the spec links)?Anonymous
March 18, 2010
@Roman - the versions number refer to the version of the spec not the version of XML. The only significant different between XMLNS 1.0 and 1.1 is some terminology changes for international resource identifiers.Anonymous
March 18, 2010
@Mitch - thanks for your feedback. We are documenting where we have variations from or extensions to the standards. IE7/8 doesn't support addEventListener (although IE9 will). We included the link to attachEvent, etc. as an informative reference. I agree with your point about the word equivalent and I am working with our documentation team to update the language based on your feedback. This will be changed in our next documentation refresh. Thanks again.Anonymous
March 18, 2010
Adrian, pursuant to Mitch's concern about the use of 'equivalent', I find it rather misleading that IE's highly divergent event API is glossed over as being a mere variation consistent with SHOULD/MAY language. While the spec does not explicitly state that implementations MUST implement the API theredefined in a manner consistent with what it layed out in the text, I think it's fair to say this requirement is implied, and I think the support document should make an effort to acknowledge that API holes such as the absence of addEventListener et al. are variations with severity at least on par with those of variations from MUST language. Still, it's an informative text, and I very much appreciate the effort that has gone into these. Review the HTML4 support text the other day reminded me of features I'd forgotten existed.Anonymous
March 18, 2010
@Adrian: thank you. I do realize that although the two are closely related, Javascript and DOM are actually two independent things (one can work on the DOM with a script language different than JS, or use JS on a document that has a different structure model) - this is why the documentation isn't wrong /per se/, but the use of the examples and citing the methods without specifying which ones are not implementation from the standard DOM methods, but have some form of equivalence (my current peeve: not perfect equivalence), those that are unique, those that are not implemented (that's actually rather well done currently), and those that are homonyms (exact same name, but different properties and/or scopes). would actually be the best use for these documents.Anonymous
March 18, 2010
@J. King - thanks for your thoughts. In general, the documentation is divided between variations (which we consider to be variations from MUSTs) and clarifications (where we explain what we did for a MAY or where the spec language isn't necessarily clear). This is a template we use across the Open Specifications node in MSDN. We haven't made subjective judgements about differing severity. That all depends upon what you're doing so you can make that judgement for your situation. @Mitch - we still have more documentation to come. Watch this space.Anonymous
March 19, 2010
@Adrian Bateman: > the versions number refer to the version of the spec not the version of XML. It doesn't seem so: 7 Conformance of Documents This specification applies to XML 1.1 documents. To conform to this specification, a document MUST be well-formed according to the XML 1.1 specification [XML 1.1]. > The only significant different between XMLNS 1.0 and 1.1 is some terminology changes for international resource identifiers. And the addition of a mechanism for undeclaring prefixes.Anonymous
March 19, 2010
@Adrian: Thanks for the clarification. I withdraw my objection, though I'll still maintain that information could be better organised for the document to serve as a decent reference. That's a matter of degrees, though, as the information is all there. Again, thanks for all the effort. :)Anonymous
March 20, 2010
@Roman - good catch. Thanks. I'll add a note. You can see the diff here: http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2Fxml-names%2F&doc2=http%3A%2F%2Fwww.w3.org%2FTR%2Fxml-names11%2F