RE: Testing default attributes in HTML DOM.

> RE: Testing default attributes in HTML DOM.
> My response:  We have the flexibility to add properties to our elements,

Pause for a moment. "Properties" are an ECMAScriptism, not
an XMLism. As I understand it,ECMAScript allows you to add
propreties to any object. That's completely independent of
adding Attributes to an element.

> If we make it so that only standardized properties can be used via
> setAttribute()

setAttribute() only knows about the DOM model's Attributes.
It isn't intended to access properties, and should not be
able to. If you want to make DOM Attributes appear as
Properties, that's fine, but Properties should not appear as
DOM Attributes.

If you want a method which does present both, you're free to
define one... but that strikes me as being well outside the
DOM's mission.

> 2) While I agree that the attributes collection shouldn't show things
> that don't have default values, I believe that the DOM test suite should
> test for DOM compliance, not HTML DTD compliance.

Speaking as an architectural purist:

If you're getting results from an HTML DOM that don't match
the HTML DTD, one of two things is happening:

1) You're using a nonstandard DTD. Quoting the DOM1 HTML
introduction, the HTML DOM relies "on the presence of a
predefined DTD. For DOM Level 1, the transitional and
frameset DTDs for HTML 4.0 are assumed." If you break that
assumption, you're departing from the HTML DOM spec as
written. You may be able to justify this to your users, but
you clearly aren't compliant with HTML DOM Level 1 and you
should _expect_ to fail a test which is written against this
spec. 

2) Or you're applying additional processing to the DOM
between parsing and presentation to the user. In other
words, you aren't implementing a straight HTML-to-DOM
parser. That too could be justified; after all, a CSS
processor may rn between parsing and presentation to the
user. But again, if you take this approach you're accepting
that the output of your parser won't match a straight DOM
representation of the HTML, and will fail the test. 

If you think your users really will prefer that you do one
or both of these, go ahead -- document what you're doing and
why you're doing it, and let the marketplace tell you
whether you're serving the right needs. If you don't like
the idea of having to explain divergence to your users, the
simplest answer is not to diverge.


The main point of the HTML DOM was to find a reliable common
set so code was reliably portable from browser to
browser.Yes, that means the HTML DOM was specifically
intended to be a least common denominator. You can extend
your models, but you should do so in a way that doesn't
alter the behavior seen through the DOM APIs.

Which brings me back to the earlier suggestion: Feel free to
add properties, but don't make them visible through
getAttributes.



Taking the architectural hat off for a moment: The main
problem I have with the business of adding magic attributes
is portability. Applications written against IE which rely
on these extensions may not run in other browsers, even
though they are using only the standard DOM API. I don't
consider that a particularly good situation; the goal was to
enhance portability in _both_ directions, not just to
enhance IE's ability to run scripts written elsewhere.

If we force the user to invoke a nonstandard method to get
access to these nonstandard values, then at least they've
been made aware of the fact that their code may run
differently elsewhere. So I really do consider that a
cleaner solution.


> I believe that IE's HTML DTD is not totally in line with the HTML 4.0
> DTD, however we should not be declared DOM non-compliant due to this.

If HTML4 wasn't written specifically into the DOM L1 spec,
I'd be inclined to agree. Unfortunately, it is.

Best suggestion I can offer is that you tell your users
"we're deliberately noncompliant on these specific points
because..." ... and work to accelerate development of the
(X)HTML DOM replacement for HTML DOM Level 1. Almost every
DOM has _some_ corner of known noncompliance -- a maximum
document size that will cause it to blow up, or something of
that sort -- perhaps you should simply admit that this is
yours.

Received on Thursday, 21 June 2001 10:29:18 UTC