Re: HTML WG Last Call Remarks to DOM 2 HTML

On Thu, 2002-04-18 at 04:23, Steven Pemberton wrote:
> [...]
> > The relations between the DTD of the document and its DOM representation
> > are not defined in the DOM API. In other world, neither the DOM Core API
> > or the DOM HTML API are defined to be validating API and therefore they
> > permit any kind of child insertion at any point. Validation is in the
> > scope of the DOM Level 3 Abstract Schemas specification. The sentence
> > "The text is parsed into the document's structure model" has been
> > removed from the document. We will encourage users to use the DOM Level
> > 3 Load and Save API in the future.
> 
> I'm not sure if our issue has been solved here. I will need to see the new
> text.

The following text was added on HTMLDocument.(write|writeln) :
"
Note that the function will produce a document which is not necessarely
driven by a DTD and therefore might be produce an invalid result in the
context of the document.
"

> [...]
> > > Doubtful Convenience
> > > We are not convinced that there is any convenience in certain methods:
> > > |HTMLDocument.anchors|: /all/ elements with an |id| are anchors in
> > > HTML 4 and XHTML; what is the convenience of only returning the |<a>|
> > > elements? Furthermore, since the |name| attribute has no semantics in
> > > XHTML, the returned set should /always/ be empty for XHTML documents.
> >
> > Even if the name attribute has no semantic in XHTML 1.0, it is still
> > part of this language. HTMLDocuments.anchors is kept in the DOM Level 2
> > HTML API for backward compatibility reason. We added the following
> > sentence:
> >
> > "The attribute name was deprecated in XHTML 1.0, therefore it is
> > recommend to not use this attribute for XHTML 1.0 documents. Users
> > should prefer the iterator mechanisms provided by DOM Level 2 Traversal
> > and Range instead."
> 
> Well, the problem isn't that it is deprecated. The problem is that if you
> use it, it has no effect. People *should* use the name attribute if their
> documents are to be compatible with HTML UAs. If the aim of the HTML DOM2 is
> to aid this compatibility, then this should be taken into account.

The text was modified as follows:
"
Note: For reasons of backward compatibility, the returned set of anchors
only contains those anchors created with the name attribute, not those
created with the id attribute. Note that in [XHTML 1.0], the name
attribute (see section 4.10) has no semantics and is only present for
legacy user agents: the id attribute is used instead. Users should
prefer the iterator mechanisms provided by [DOM Level 2 Traversal]
instead.
"

> > > Since |<object>| is the recommended method for including images in a
> > > document, what is the convenience of |HTMLDocument.images| only
> > > returning |<img>| elements?
> >
> > The reason is backward compatiblity since this attribute is supported by
> > both IE3.0 and NS3.0. However, since as the HTML WG mentioned, we was
> > added to the description:
> >
> > "Note: As suggested by [HTML4.0], to include images, authors may use the
> > OBJECT element or the IMG element. Therefore, it is recommended not to
> > use this attribute to find the images in the document but
> > getElementsByTagName with HTML 4.0 or getElementsByTagNameNS with XHTML
> > 1.0."
> 
> s/HTML4.0/HTML4.01/

fixed.

> s/attribute/method/ I suppose.

HTMLDocument.images is an attribute.

> It's not clear how the DOM2 HTML is aiding compatibility here if you have to
> use different calls for the same purpose.
> 
> > > Textual issue
> > > 1.6.2 suggests that there is some general naming technique applied,
> > > and yet it seems only to apply to |htmlFor|, and not, for instance, to
> > > |Element.className|, which according to 1.6.2 should be called
> > > |h||tmlClass|.
> >
> > Again, for backward compatibility with IE3 and NS3, the name cannot be
> > renamed.
> 
> OK, but then the text that says there is a general naming mechanism isn't
> true: you only use that mechanism for a single name. You may as well say
> that instead.

The text was modified as follows:
"
To avoid namespace conflicts, two attributes with the same name as a
keyword in one of our chosen binding languages were prefixed. The for
attribute of the LABEL and SCRIPT elements collides with loop construct
naming conventions and is renamed htmlFor. The class attribute of the
HTML elements collides with class definitions naming conventions and is
renamed className.
"

Philippe

Received on Thursday, 9 May 2002 17:50:12 UTC