From: Thomas 'PointedEars' Lahn on
john wrote:

> Garrett Smith wrote:
>> john wrote:
>>> given the following javascript:
>>>
>>> var hour = new Date().getHours().toString();
>>> document.body.className = '_' + hour;
>>>
>>> is it safe to assume that any browser supporting javascript will be
>>> able to execute the code without error. in other words is it safe to
>>> assume the features exist and implementations will work as expected?
>>
>> Nothing is guaranteed 100%.
>
> which seems like one of the more interesting parts of browser scripting.

This phenomenon has nothing to do with "browser scripting". Instead, it
has to do with a group of languages that require a runtime environment to
be useful, that mostly serve as interfacing languages to control those
environments, and where both the languages and the runtime environments
have a rather long, vivid history, to say the least. Both client-side and
server-side.

>>> i have gathered a number of "ancient" browsers (MacIE 5.2.3, Opera
>>> 7.54, Firefox 1.0.7 etc.) to test with but my question is more
>>> concerned with finding a general principle for what and when to
>>> feature test.
>> That comes down to experience, unfortunately.
>
> fortunately this project is academic and for my own amusement so there
> is plenty of time to gain the necessary experience (and thanks to Thomas
> Lahn pointing out the evolt browser archive entirely possible).

And thanks to the ECMAScript Support Matrix, I hope. For it is the
ultimate target of that project to make such browser testing unnecessary,
at least for older features. (Should you take the time to make tests, your
support is appreciated.)

>> Object.prototype.hasOwnProperty fails in older browsers, such as Mac IE.
>>
>> The greatest divergence will be found in browser object models.
>
> could you recommend a reference for the browser object model?

As a result of the diversity of possible runtime environments, there is
_not_ *the* browser model.

> i searched with google but didn't find anything that looked
> authoritative. i read the following pages from the search results:
>
> - <http://msdn.microsoft.com/en-us/library/ms952643.aspx>

MSDN is a good starting point for learning about the object model of
MSHTML-based user agents, and about the JScript language supported by
MSHTML-based Web browsers (like Internet Explorer) and other Microsoftish
runtime environments (like ASP [.NET] on IIS).

> -
>
<http://javascript.about.com/od/browserobjectmodel/Browser_Object_Model.htm>

Without looking at it, that is probably not a good starting point.

> the MSDN article seems a bit sparse

It is not just one article, is it?

> and while thorough i'm not sure the accuracy of the about.com article.
> are there others that would be worth reading?

Yes. Read the FAQ.

>> Use w3c standards features an approaches first and do not expect
>> non-standard behavior from them.
>
> understood.

It is *really* bad advice, though. Instead, expect rather insane DOM
implementations: do not rely on any return value; especially, do not rely
on implementation assertions provided by the API (like
DOMImplementation::hasFeature()), and avoid the Element::*Attribute*()
methods where short-hand attribute properties suffice (we have discussed
this at length recently, I am surprised Garrett does not seem to remember.)


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on
john wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Second, JavaScript is not the only ECMAScript implementation.
>
> as in the following?
>
> JavaScript, JScript and the implementations in Opera and WebKit (and
> some browsers i've never heard of) are all unique; different versions of
> an implementation may vary widely; and the implementations from various
> vendors are bound to vary. additionally there are some implementations
> that run completely outside of a web browser.

Exactly; except that WebKit is not a browser (perhaps it is only poor
wording there), but a KHTML fork that consists of WebCore, the Mac OS-
influenced DOM implementation; JavaScriptCore (a KJS fork), the ECMAScript
language implementation; and probably other features.

You should quote properly, identifying all quotations as such (leading
pipes are customary on Usenet for third-party quotations), and providing a
citation, for example a Message-ID or the URI of a publicly accessible
resource. (See also <http://en.wikipedia.org/wiki/Citation>.)

>> What matters is that *some* of these features have been implemented
>> since JavaScript 1.0 *and* specified since ECMAScript Edition 1. For
>> historical reasons, it is therefore unlikely, though entirely possible,
>> that an implementation still usable today would not provide *those*
>> features or support them in that way.
>
> so what and when to test is a judgment call based on experience with
> implementations (of the browsers you are interested in supporting) and
> understanding of the relevant specifications?

Exactly, but browsers (clients) are still only one part of the equation.

> are there more criteria i'm missing?

Some language features are known not to be available in older
implementations that can still be considered to be in use. You can either
avoid those language features (e.g., using hasOwnProperty() is avoided by
using iterator prototype methods), apply emulations if necessary (e.g.,
define Array.prototype.map() if it is unavailable), use emulating wrappers
instead (e.g., jsx.object._hasOwnProperty() to call
Object.prototype.hasOwnProperty() if available, using alternatives
otherwise), or use (eval-based) wrappers so that those language features
are hidden from the compiler and do not trigger a syntax error (e.g,
jsx.tryThis() to hide try-catch). In all of those cases it is only
necessary to test the language feature once, if that.

>>> while `className` and the `toString` method (on the Date object) were
>>> implemented in JavaScript 1.1.
>>
>> You are mistaken.
>
> no doubt about that. i must not have been paying any attention when i
> looked up the `className` property. where it's mentioned in the
> JavaScript 1.3 reference it is clearly not what i was looking for.
>
> | className: The fully qualified name of a Java class in a package
> | other than `netscape`, `java`, or `sun` that is available to
> | JavaScript.

Ahh, I did not know *that*. The Matrix has you! :)

>>> are there reasons to feature test for `getHours`, `toString` and
>>
>> No.
>
> is that "No" because they are "old enough" features provided by the
> ECMAScript language and you have witnessed them working as expected?
> i.e. based on the relevant specifications and experience with
> implementations.

Yes. Date.prototype.getHours() is fully backwards-compatible, and I think
we can safely consider Netscape 2.0 and other runtime environments that
only support JavaScript 1.0 (which does not appear to implement
Number.prototype.toString()) to be extinct by now. It is not very
efficient (or not much fun, whatever term you prefer) to surf today's Web
with them anyway; BTDT (clicked away 43 script error *windows* on that
version's default homepage, redirected to <http://netscape.aol.com/>).

The problem with this is that it is a often circulus virtuosus, pretty much
a self-fulfilling prophecy: Incompetent people deprecate browsers because
they cannot cope with deviations, often mistakenly think they are no longer
in use, they use not backwards-compatible features and as a result users
are forced to use newer browsers (or go to the more compatible competition)
because the Web (site) had become unusable with what they were used to.

>>> `className`?
>>
>> Yes.
>
> is that "Yes" because it is a feature of the host environment and host
> environments should be assumed hostile?

Not hostile; the languages would not be of much use without them. But they
should be assumed to vary, and little if anything should be taken for
granted.

>>> if so would the following tests be adequate?
>>>
>>> if (Date.prototype.getHours&& Date.prototype.toString&&
>>> typeof document.body.className !== 'undefined') {
>>> // above code here
>>> }
>>
>> No. You are testing the true-ness of the first two built-in properties,
>> not their callability; if you think you need to test them, test whether
>> `typeof' results in "function" instead.
>
> now that i've spent some more time reading and testing i can see that
> those test are indeed inadequate. particularly if you don't want to
> throw script errors in very old browsers; which i gather could be
> considered unacceptable or unimportant under certain conditions.

I do not think any of these tests would throw exceptions, though. Indeed,
if you added the `typeof' test, the script would become incompatible to
JavaScript 1.0 as that operator requires at least JavaScript 1.1. But as I
said, that should no longer be a concern today.

In fact, I think language features supported from JavaScript 1.3 (Netscape
4.06) on are safe to use without feature test by now (that is, provided it
is specified or supported by known implementations; this assessment is
likely to be subject to change as more implementations and versions are
tested). The next release of the ECMAScript Support Matrix will reflect
that, providing further hints as to what needs to be feature-tested
according to (my) current level of knowledge.

>> <http://PointedEars.de/es-matrix>
>
> bookmarked.

:)

>> Second you need to understand the difference between built-in objects
>> like Date instances, and host objects (objects defined by the host
>> environment) like HTMLBodyElement implementations.
>>
>> <http://ecmascript.org/>
>
> should i begin with the 5th edition keeping in mind that some of the new
> language features will need feature testing or would it be better to
> become familiar with the 3rd edition first?

Yes. And you should use the Shift key of your keyboard where appropriate.

> does it even matter?

Edition 5 claims to specify behavior common to current implementations, so
you should be aware of the changes from Edition 3 which is more widely
implemented at this point.

However, I must say that Edition 5 is even less readable for beginners than
Edition 3 (OK, neither was ever meant to be, but there is nothing
comparable): the abstraction level in the algorithms of the new Edition is
quite extreme, to say the least¹; it is hard even for me (who claims to
know Edition 3 and its implementations fairly well) to wrap my brain around
it (if they even bothered to set some inline links ...) And I am not even
mentioning the new Strict Mode deviations.


PointedEars
___________
¹ Example: Property read access (omitting the quotation prefixes here)

The production MemberExpression : MemberExpression [ Expression ] is
evaluated as follows:

1. Let baseReference be the result of evaluating MemberExpression.
2. Let baseValue be GetValue(baseReference).
3. Let propertyNameReference be the result of evaluating Expression.
4. Let propertyNameValue be GetValue(propertyNameReference).
5. Call CheckObjectCoercible(baseValue).
6. Let propertyNameString be ToString(propertyNameValue).
7. If the syntactic production that is being evaluated is contained in
strict mode code, let strict be true, else let strict be false.
8. Return a value of type Reference whose base value is baseValue and whose
referenced name is propertyNameString, and whose strict mode flag is
strict.

~~~~~~~
8.7.1 GetValue (V)

1. If Type(V) is not Reference, return V.
2. Let base be the result of calling GetBase(V).
3. If IsUnresolvableReference(V), throw a ReferenceError exception.
4. If IsPropertyReference(V), then
a. If HasPrimitiveBase(V) is false, then let get be the [[Get]] internal
method of base, otherwise let get be the special [[Get]] internal
method defined below.
b. Return the result of calling the get internal method using base as
its this value, and passing GetReferencedName(V) for the argument.
5. Else, base must be an environment record.
a. Return the result of calling the GetBindingValue (see 10.2.1)
concrete method of base passing GetReferencedName(V) and
IsStrictReference(V) as arguments.

~~~~~~~
8 Types

Within this specification, the notation “Type(x)” is used as shorthand for
“the type of x” where “type” refers to the ECMAScript language and
specification types defined in this clause.

~~~~~~~
8.7 The Reference Specification Type

[...]
• GetBase(V). Returns the base value component of the reference V.
[...]
• HasPrimitiveBase(V). Returns true if the base value is a Boolean, String,
or Number.
• IsPropertyReference(V). Returns true if either the base value is an
object or HasPrimitiveBase(V) is true; otherwise returns false.
• IsUnresolvableReference(V). Returns true if the base value is undefined
and false otherwise.

(Still there? We're just taking off ;-))

~~~~~~~
8.12.2 [[GetProperty]] (P)

When the [[GetProperty]] internal method of O is called with property name
P, the following steps are taken:

1. Let prop be the result of calling the [[GetOwnProperty]] internal
method of O with property name P.
2. If prop is not undefined, return prop.
3. Let proto be the value of the [[Prototype]] internal property of O.
4. If proto is null, return undefined.
5. Return the result of calling the [[GetProperty]] internal method of
proto with argument P.

8.12.3 [[Get]] (P)

When the [[Get]] internal method of O is called with property name P, the
following steps are taken:

8. Let desc be the result of calling the [[GetProperty]] internal method
of O with property name P.
9. If desc is undefined, return undefined.
10. If IsDataDescriptor(desc) is true, return desc.[[Value]].
11. Otherwise, IsAccessorDescriptor(desc) must be true so, let getter be
desc.[[Get]].
12. If getter is undefined, return undefined.
13. Return the result calling the [[Call]] internal method of getter
providing O as the this value and providing no arguments.

~~~~~~~
8.10.2 IsDataDescriptor ( Desc )

When the abstract operation IsDataDescriptor is called with property
descriptor Desc, the following steps are taken:

1. If Desc is undefined, then return false.
2. If both Desc.[[Value]] and Desc.[[Writable]] are absent, then return
false.
3. Return true.

~~~~~~~
8.6.1 Property Attributes

Attribute Name | Value Domain | Description
---------------+----------------+------------------------------------------
[[Value]] | Any ECMAScript | The value retrieved by reading
| language type | the property.
---------------+----------------+------------------------------------------
[[Writable]] | Boolean | If false, attempts by ECMAScript code
| | to change the property's [[Value]]
| | attribute using [[Put]] will not succeed.
[...]

~~~~~~~
8.10.1 IsAccessorDescriptor ( Desc )

When the abstract operation IsAccessorDescriptor is called with property
descriptor Desc, the following steps are taken:

1. If Desc is undefined, then return false.
2. If both Desc.[[Get]] and Desc.[[Set]] are absent, then return false.
3. Return true.

~~~~~~~
13.2.1 [[Call]]

When the [[Call]] internal method for a Function object F is called with a
this value and a list of arguments, the following steps are taken:

1. Let funcCtx be the result of establishing a new execution context for
function code using the value of F's [[FormalParameters]] internal
property, the passed arguments List args, and the this value as
described in 10.4.3.
2. Let result be the result of evaluating the FunctionBody that is the
value of F's [[Code]] internal property. If does not have a [[Code]]
internal property or if its value is an empty FunctionBody, then result
is (normal, undefined, empty).
3. Exit the execution context funcCtx, restoring the previous execution
context.
4. If result.type is throw then throw result.value.
5. If result.type is return then return result.value.
6. Otherwise result.type must be normal. Return undefined.

~~~~~~~
8.6.2 Object Internal Properties and Methods

[...]
Internal Property | Value Type | Description
---------------------+-----------------+-----------------------------------
[...]
[[FormalParameters]] | List of Strings | A possibly empty List containing
| | the identifier Strings of a
| | Function's FormalParameterList.
| | Of the standard built-in
| | ECMAScript objects, only
| | Function objects implement
| | [[FormalParameterList]].
---------------------+-----------------+-----------------------------------
[[Code]] | ECMAScript code | The ECMAScript code of a function.
| | Of the standard built-in
| | ECMAScript objects, only
| | Function objects implement
| | [[Code]].
[...]

(etc. pp.)

~~~~~

(You did understand what was just said, didn't you? ;-))

--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Garrett Smith on
Thomas 'PointedEars' Lahn wrote:
> Garrett Smith wrote:
>
>> In your case, document.body might be undefined in an XHTML DOM.
>
> Where and under which circumstances? Are you considering that the W3C DOM
> Level 2 HTML Specification applies to XHTML 1.0 as well?
>

It was an old "bug" of mozilla where document.body was undefined. That
got fixed around 2003.

> IMHO, it is rather unlikely that, since the same parser and layout engine
> would be used as for XHTML 1.0 (when served declared as
> application/xhtml+xml or another triggering media type), `document.body'
> would not be available in XHTML (Basic) 1.1. Especially as XHTML (Basic)
> 1.1 defined the `body' element in the required Structure Module that all
> XHTML 1.1-compliant user agents MUST support.
>
There is "WICD Mobile 1.0" that suggests a subset of HTML DOM for mobile
devices. That subset does not include a body property.

Seems to have stopped at CR phase in 2007.
http://www.w3.org/TR/WICDMobile/#dom

http://www.w3.org/TR/WICDMobile/#dom-html-ref
| interface HTMLDocument : Document {
| NodeList getElementsByName(in DOMString elementName);
| };

I don't know what the rationale is for omitting document.body, nor do I
know which implementations actually do that. Anyone who is able to fix
that, please do.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: john on
On 17 Jan 9:04 PM, Thomas 'PointedEars' Lahn wrote:
> john wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Second, JavaScript is not the only ECMAScript implementation.
>>
>> as in the following?
>>
>> JavaScript, JScript and the implementations in Opera and WebKit (and
>> some browsers i've never heard of) are all unique; different versions of
>> an implementation may vary widely; and the implementations from various
>> vendors are bound to vary. additionally there are some implementations
>> that run completely outside of a web browser.
>
> Exactly; except that WebKit is not a browser (perhaps it is only poor
> wording there), but a KHTML fork that consists of WebCore, the Mac OS-
> influenced DOM implementation; JavaScriptCore (a KJS fork), the ECMAScript
> language implementation; and probably other features.

i didn't mean to imply that WebKit was a browser; merely that it
contained a distinct implementation of the ECMAScript language. so yes
it may have been a poor choice of words.

> You should quote properly, identifying all quotations as such (leading
> pipes are customary on Usenet for third-party quotations), and providing a
> citation, for example a Message-ID or the URI of a publicly accessible
> resource. (See also <http://en.wikipedia.org/wiki/Citation>.)

i don't understand what you mean (although i'd like not to get
sidetracked from the feature testing discussion which has been quite
enlightening thus far). in Thunderbird i see your text as properly
attributed to you and the rest attributed to me. i apologize if i've
given the impression that some portion of that text was mis-attributed
to you (or me) when that wasn't the case or if i'm misinterpreting your
statement. (honestly my day to day communication via email [i know
Usenet is not email but it seems the two are closely related; at least
when you use Thunderbird for both] is generally top posted corporate
correspondence so possibly i'm completely missing the point here).

>> are there more criteria i'm missing?
>
> Some language features are known not to be available in older
> implementations that can still be considered to be in use. You can either
> avoid those language features (e.g., using hasOwnProperty() is avoided by
> using iterator prototype methods), apply emulations if necessary (e.g.,
> define Array.prototype.map() if it is unavailable), use emulating wrappers
> instead (e.g., jsx.object._hasOwnProperty() to call
> Object.prototype.hasOwnProperty() if available, using alternatives
> otherwise), or use (eval-based) wrappers so that those language features
> are hidden from the compiler and do not trigger a syntax error (e.g,
> jsx.tryThis() to hide try-catch). In all of those cases it is only
> necessary to test the language feature once, if that.

i found the jibbering.com article on feature testing very informative
with regard to only testing a feature once as opposed to each time the
feature is used. granted at this point my application of such
information may be what an experienced developer would consider naive
i'm certainly trying to come to terms with the principle.

your scripts, David Mark's "My Library" and Garrett Smith's "APE
JavaScript library" are certainly helping in getting a feel for how an
experienced developer may apply those principles. so maybe my naive
attempts will eventually reach maturity.

from searching previous discussion on this list i think it's clear none
of the "brand name" (e.g. Prototype, jQuery, Dojo etc.) scripts have
much of anything to offer? are there any other scripts worth studying or
are there things in the "brand name" scripts worth looking at?

(by the way the JSDoc link in some of your scripts sends me to a 404
page; e.g. <http://pointedears.de/scripts/object.js>: "This document
contains JavaScriptDoc. See <http://pointedears.de/scripts/JSdoc/> for
details." the scripts are well documented inline so maybe whatever
should be at the 404 link is not essential. just thought you might like
to know.)

>>>> while `className` and the `toString` method (on the Date object) were
>>>> implemented in JavaScript 1.1.
>>>
>>> You are mistaken.
>>
>> no doubt about that. i must not have been paying any attention when i
>> looked up the `className` property. where it's mentioned in the
>> JavaScript 1.3 reference it is clearly not what i was looking for.
>>
>> | className: The fully qualified name of a Java class in a package
>> | other than `netscape`, `java`, or `sun` that is available to
>> | JavaScript.
>
> Ahh, I did not know *that*. The Matrix has you! :)

i'm glad my temporary lack of attention turned into a happy accident
instead of just me looking silly.

>>>> are there reasons to feature test for `getHours`, `toString` and
>>>
>>> No.
>>
>> is that "No" because they are "old enough" features provided by the
>> ECMAScript language and you have witnessed them working as expected?
>> i.e. based on the relevant specifications and experience with
>> implementations.
>
> Yes. Date.prototype.getHours() is fully backwards-compatible, and I think
> we can safely consider Netscape 2.0 and other runtime environments that
> only support JavaScript 1.0 (which does not appear to implement
> Number.prototype.toString()) to be extinct by now.

perhaps i'm particularly masochistic but regardless of extinction
Netscape Navigator 2 (and other dinosaurs) is just the sort of
environment i'm interested in. my interest is in determining if pages
can be made that work (and take advantage of) modern ECMAScript
implementations while not completely falling over (i.e. creating script
error windows) in even the oldest dynamic browsers. (last year i
undertook a similar "adventure" with the Ruby language and the various
contemporary and ancient implementations; next year who knows maybe Lisp.)

my tests with Netscape Navigator 2.0.2 seem to confirm your assertion
regarding `Number.prototype.toString()`.

> It is not very
> efficient (or not much fun, whatever term you prefer) to surf today's Web
> with them anyway; BTDT (clicked away 43 script error *windows* on that
> version's default homepage, redirected to<http://netscape.aol.com/>).

:)

as soon as i got your message pointing to the evolt browser archive the
next thing i did was download Netscape Navigator 2.0.2. except in my
case (a Windows XP virtual machine in VMWare) the default homepage
actually crashed the browser; it took a few tries to be fast enough to
hit the stop button before the crash. now that i have a blank homepage
it seems to be reliable enough for testing; although every single public
web page i've pointed it at since threw multiple script errors or worse
(e.g. <http://gmail.com/>).

>> now that i've spent some more time reading and testing i can see that
>> those test are indeed inadequate. particularly if you don't want to
>> throw script errors in very old browsers; which i gather could be
>> considered unacceptable or unimportant under certain conditions.
>
> I do not think any of these tests would throw exceptions, though. Indeed,
> if you added the `typeof' test, the script would become incompatible to
> JavaScript 1.0 as that operator requires at least JavaScript 1.1. But as I
> said, that should no longer be a concern today.

my interest is certainly less than practical and it was the `typeof`
test that i was referring to about throwing errors ("typeof is not
defined").

>> should i begin with the 5th edition keeping in mind that some of the new
>> language features will need feature testing or would it be better to
>> become familiar with the 3rd edition first?
>
> Yes.

"Yes" it would be better to start with the 3rd edition or "Yes" i should
begin with the 5th edition?

> And you should use the Shift key of your keyboard where appropriate.

sorry for the bad habit. perhaps we can just blame Herbert Bayer and/or
e.e. cummings? ;)

>> does it even matter?
>
> Edition 5 claims to specify behavior common to current implementations, so
> you should be aware of the changes from Edition 3 which is more widely
> implemented at this point.
>
> However, I must say that Edition 5 is even less readable for beginners than
> Edition 3 (OK, neither was ever meant to be, but there is nothing
> comparable): the abstraction level in the algorithms of the new Edition is
> quite extreme, to say the least¹; it is hard even for me (who claims to
> know Edition 3 and its implementations fairly well) to wrap my brain around
> it (if they even bothered to set some inline links ...) And I am not even
> mentioning the new Strict Mode deviations.

i've certainly had a heck of time with it so far (compared to reading
W3C specifications). which is probably why i've made more progress
getting through the implementers documentation so far.

> ¹ Example: Property read access (omitting the quotation prefixes here)
>
[example from ECMA-262 5th edition that are difficult for beginners]
>
> (You did understand what was just said, didn't you? ;-))

of course :)

thanks for your thoughtful and informative replies.
From: john on
On 17 Jan 7:12 PM, Thomas 'PointedEars' Lahn wrote:
> john wrote:
>
>> Garrett Smith wrote:
>>> Object.prototype.hasOwnProperty fails in older browsers, such as Mac IE.
>>>
>>> The greatest divergence will be found in browser object models.
>>
>> could you recommend a reference for the browser object model?
>
> As a result of the diversity of possible runtime environments, there is
> _not_ *the* browser model.

after my initial searching i thought that may be the case.

>> i searched with google but didn't find anything that looked
>> authoritative. i read the following pages from the search results:
>>
>>
<http://javascript.about.com/od/browserobjectmodel/Browser_Object_Model.htm>
>
> Without looking at it, that is probably not a good starting point.

after looking at it it certainly didn't feel authoritative. so i suspect
your suspicions are correct.

>> the MSDN article seems a bit sparse
>
> It is not just one article, is it?

i can't say for sure. it was the only page from MSDN that showed up on
the first page of google search results. perhaps tomorrow i'll have more
time to explore that site and turn up meatier pages.

>> and while thorough i'm not sure the accuracy of the about.com article.
>> are there others that would be worth reading?
>
> Yes. Read the FAQ.

i did search the FAQ and FAQ Notes but didn't see any mention of
"browser object model" or "BOM". do you happen to know which section or
page discusses this topic?

>>> Use w3c standards features an approaches first and do not expect
>>> non-standard behavior from them.
>>
>> understood.
>
> It is *really* bad advice, though. Instead, expect rather insane DOM
> implementations: do not rely on any return value; especially, do not rely
> on implementation assertions provided by the API (like
> DOMImplementation::hasFeature()), and avoid the Element::*Attribute*()
> methods where short-hand attribute properties suffice (we have discussed
> this at length recently, I am surprised Garrett does not seem to remember.)

i misread Garrett's response to say "do not expect _standard_ behavior
from them". after even my basic testing i'm pretty much ready to expect
non-standard behavior in even seemingly simple cases.