knowing what and when to feature test

Discussion in 'Javascript' started by john, Jan 17, 2010.

  1. john

    john Guest

    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?

    checking <http://docs.sun.com/source/816-6408-10/> i see that `getHours`
    was implemented in JavaScript 1.0 while `className` and the `toString`
    method (on the Date object) were implemented in JavaScript 1.1.

    are there reasons to feature test for `getHours`, `toString` and
    `className`? if so would the following tests be adequate?

    if (Date.prototype.getHours && Date.prototype.toString &&
    typeof document.body.className !== 'undefined') {
    // above code here
    }

    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.

    is there any general advice on when it would be ok to assume a feature
    will be available? i've read the document at
    <http://jibbering.com/faq/faq_notes/not_browser_detect.html> but am
    still not sure where to draw the line.
     
    john, Jan 17, 2010
    #1
    1. Advertising

  2. 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?
    >
    > checking <http://docs.sun.com/source/816-6408-10/> i see that `getHours`
    > was implemented in JavaScript 1.0


    Yes, but that does not mean anything. First of all, that documentation is
    mostly outdated. You should use

    <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/>

    instead.

    Second, JavaScript is not the only ECMAScript implementation. 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.

    > while `className` and the `toString` method (on the Date object) were
    > implemented in JavaScript 1.1.


    You are mistaken. `className' is (clearly) _not_ a built-in property but a
    property of objects implementing the HTMLBodyElement interface of W3C DOM
    Level 2 HTML (as a shorthand to accessing the `class' attribute of the
    corresponding element); those are host objects, and even though they have
    an ECMAScript binding, the corresponding interface is language-independent.
    IOW, since you cannot assume the host environment provides that property,
    you should test whether that property exists before accessing it.

    Interestingly, though, the Client-side JavaScript 1.3 Reference says that
    the `toString' Date prototype method implemented in JavaScript 1.1 while
    the Core JavaScript 1.5 Reference at MDC says that it was implemented in
    JavaScript 1.0. The original Core JavaScript 1.5 Reference, too, still
    available e.g. from

    <http://ific.uv.es/informatica/manuales/CoreReferenceJS15/date.html#1206669>

    says "1.1" instead.

    I have observed in Netscape Navigator 2.02 (JavaScript 1.0) a few minutes
    ago (thanks to the evolt.org browser archive and Wine) that it supports

    var d = new Date();
    d.toString()

    but not any of

    new Date().toString()
    (new Date()).toString()

    or

    d.getHours().toString()

    The difference between the References can be attributed to the use of
    toString() without and with the `new' keyword in the same statement when
    testing. So apparently "1.1" was an error in the Reference that was
    corrected at MDC.

    That the last expression fails in Navigator 2.0 appears to be related to
    the fact that Number.prototype.toString() is not supported until JavaScript
    1.1 (Netscape 3.0; I have tested with Navigator 2.02 and 3.04). So you
    have to consider *all* components before you can make a correct
    compatibility judgement.

    > are there reasons to feature test for `getHours`, `toString` and


    No.

    > `className`?


    Yes.

    > 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.

    As for the `className' test, if you want to trust that implementors
    understood

    ,-[ECMAScript Language Specification, Edition 3 Final (2000), 11.4.3]
    |
    | 5. Return a string determined by Type(Result(4)) according to the
    | following table:

    as that `typeof' needs to result in a built-in String value, as clarified
    in

    ,-[ECMAScript Language Specification, Edition 5 (2009), section 11.4.3]
    |
    | 3. Return a String determined by Type(val) according to Table 20.

    then you can keep the strict comparison. If instead you subscribed to the
    idea that "With host objects, all bets are off."â„¢, you would use a type-
    converting comparison. I recommend doing to the latter as the potential
    decrease in efficiency is negligible as compared to the possible gain in
    compatibility.

    > 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.


    First of all, you need to understand that in most cases (i.e., on the Web)
    you are _not_ dealing with a *single* programming language but *several*
    *different* ECMAScript implementations:

    <http://jibbering.com/faq/#posting>
    <http://PointedEars.de/es-matrix>

    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 you desire further answers, please fix your From header as mandated
    by Internet standards, and sometimes provider's Acceptable Use Policies,
    and recommended by Netiquette guidelines. Violating foreign namespaces
    like using `nomail.com' for the domain part of an address header is _not_
    acceptable. (And to me, neither is preventing e-mail communication abusing
    top-level domains like .invalid, should you get that idea as a result of
    your research.)

    <http://tools.ietf.org/html/rfc1036>
    <http://tools.ietf.org/html/rfc1855>


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
     
    Thomas 'PointedEars' Lahn, Jan 17, 2010
    #2
    1. Advertising

  3. kangax wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> john wrote:
    >>> given the following javascript:
    >>>
    >>> var hour = new Date().getHours().toString();
    >>> document.body.className = '_' + hour;
    >>>
    >>> [...]
    >>> while `className` and the `toString` method (on the Date object) were
    >>> implemented in JavaScript 1.1.

    >>
    >> You are mistaken. `className' is (clearly) _not_ a built-in property
    >> but a property of objects implementing the HTMLBodyElement interface of
    >> W3C DOM

    >
    > No, the interface is HTMLElement
    > (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not
    > HTMLBodyElement.


    Yes, but if you check the IDL for HTMLElement, you can see that both
    statements are correct. I was referring to this property, therefore
    the more specific reference here.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jan 17, 2010
    #3
  4. Thomas 'PointedEars' Lahn wrote:
    > kangax wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> john wrote:
    >>>> given the following javascript:
    >>>>
    >>>> var hour = new Date().getHours().toString();
    >>>> document.body.className = '_' + hour;
    >>>>
    >>>> [...]
    >>>> while `className` and the `toString` method (on the Date object) were
    >>>> implemented in JavaScript 1.1.
    >>> You are mistaken. `className' is (clearly) _not_ a built-in property
    >>> but a property of objects implementing the HTMLBodyElement interface of
    >>> W3C DOM


    Right. I assumed Lahn had an editorial mistake.

    >> No, the interface is HTMLElement
    >> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not
    >> HTMLBodyElement.

    >


    Apparently I assumed incorrectly.

    > Yes, but if you check the IDL for HTMLElement, you can see that both
    > statements are correct. I was referring to this property, therefore
    > the more specific reference here.
    >


    http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62018039

    | interface HTMLBodyElement : HTMLElement {
    | attribute DOMString aLink;
    | attribute DOMString background;
    | attribute DOMString bgColor;
    | attribute DOMString link;
    | attribute DOMString text;
    | attribute DOMString vLink;
    | };

    I don't see `className` on that list.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Jan 17, 2010
    #4
  5. 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%.

    > checking <http://docs.sun.com/source/816-6408-10/> i see that `getHours`
    > was implemented in JavaScript 1.0 while `className` and the `toString`
    > method (on the Date object) were implemented in JavaScript 1.1.
    >
    > are there reasons to feature test for `getHours`, `toString` and
    > `className`? if so would the following tests be adequate?
    >
    > if (Date.prototype.getHours && Date.prototype.toString &&
    > typeof document.body.className !== 'undefined') {
    > // above code here
    > }
    >


    The test for Date.prototype.toString is irrelevant to your code:-

    new Date() // returns a Date,
    .getHours() // returns a number,
    . toString(); // calls toString on the *number*.

    That statement should be widely supported.

    > 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.
    Object.prototype.hasOwnProperty fails in older browsers, such as Mac IE.

    The greatest divergence will be found in browser object models.

    > is there any general advice on when it would be ok to assume a feature
    > will be available? i've read the document at
    > <http://jibbering.com/faq/faq_notes/not_browser_detect.html> but am
    > still not sure where to draw the line.


    More caution is needed with Host objects.

    In your case, document.body might be undefined in an XHTML DOM. That
    problem can be avoided by not using XHTML, of course.

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

    Nonstandard features tend to have more divergence in how they work.

    MSDN has provided many code examples that work only in IE. Sites that
    use have used those examples failed in other browsers.

    To make those the sites work, other browsers copied the feature, but
    usually with a variation.

    When the standard approach fails, check your code against the
    specification. Did you expect something that was not specified?

    Based on the failure, you might want to either rethink the problem,
    address the failure by making sure that the condition which triggers it
    does not occur.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Jan 17, 2010
    #5
  6. Garrett Smith wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> kangax wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> john wrote:
    >>>>> given the following javascript:
    >>>>>
    >>>>> var hour = new Date().getHours().toString();
    >>>>> document.body.className = '_' + hour;
    >>>>>
    >>>>> [...]
    >>>>> while `className` and the `toString` method (on the Date object) were
    >>>>> implemented in JavaScript 1.1.
    >>>> You are mistaken. `className' is (clearly) _not_ a built-in property
    >>>> but a property of objects implementing the HTMLBodyElement interface
    >>>> of W3C DOM

    >
    > Right. I assumed Lahn had an editorial mistake.


    So we are back to second name?

    >>> No, the interface is HTMLElement
    >>> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not
    >>> HTMLBodyElement.

    >
    > Apparently I assumed incorrectly.
    >
    >> Yes, but if you check the IDL for HTMLElement, you can see that both
    >> statements are correct. I was referring to this property, therefore
    >> the more specific reference here.

    >
    > http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62018039
    >
    > | interface HTMLBodyElement : HTMLElement {
    > | attribute DOMString aLink;
    > | attribute DOMString background;
    > | attribute DOMString bgColor;
    > | attribute DOMString link;
    > | attribute DOMString text;
    > | attribute DOMString vLink;
    > | };
    >
    > I don't see `className` on that list.


    Smith fails to see "HTMLElement" here.


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
     
    Thomas 'PointedEars' Lahn, Jan 17, 2010
    #6
  7. Garrett Smith wrote:

    > john wrote:
    >> is there any general advice on when it would be ok to assume a feature
    >> will be available? i've read the document at
    >> <http://jibbering.com/faq/faq_notes/not_browser_detect.html> but am
    >> still not sure where to draw the line.

    >
    > More caution is needed with Host objects.


    It's _host_ objects. Lowercase. *Really.*


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
     
    Thomas 'PointedEars' Lahn, Jan 17, 2010
    #7
  8. john

    john Guest

    On 17 Jan 7:33 AM, Thomas 'PointedEars' Lahn wrote:
    > john wrote:
    >
    >> checking<http://docs.sun.com/source/816-6408-10/> i see that `getHours`
    >> was implemented in JavaScript 1.0

    >
    > Yes, but that does not mean anything. First of all, that documentation is
    > mostly outdated. You should use
    >
    > <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/>
    >
    > instead.


    will do.

    > 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.


    > 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? are there more criteria
    i'm missing?

    >> 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.

    > `className' is (clearly) _not_ a built-in property but a
    > property of objects implementing the HTMLBodyElement interface of W3C DOM
    > Level 2 HTML (as a shorthand to accessing the `class' attribute of the
    > corresponding element); those are host objects, and even though they have
    > an ECMAScript binding, the corresponding interface is language-independent.


    i have started reading the DOM Level 2 HTML Specification.

    >> 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.

    >> `className`?

    >
    > Yes.


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

    >> 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 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.

    >
    > First of all, you need to understand that in most cases (i.e., on the Web)
    > you are _not_ dealing with a *single* programming language but *several*
    > *different* ECMAScript implementations:


    i think i understand that. i should have been more clear that i was not
    looking at the JavaScript reference as if it applied to all web browsers.

    i'm going through all of the links referred to at
    <http://jibbering.com/faq/#onlineResources> and just picked the one i
    had looked at most recently to reference.

    > <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? does it even matter?

    > Should you desire further answers, please fix your From header


    my apologies.
     
    john, Jan 17, 2010
    #8
  9. john

    john Guest

    On 17 Jan 1:05 PM, 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.

    >> 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).

    > 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? 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>
    -
    <http://javascript.about.com/od/browserobjectmodel/Browser_Object_Model.htm>

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

    >> is there any general advice on when it would be ok to assume a feature
    >> will be available? i've read the document at
    >> <http://jibbering.com/faq/faq_notes/not_browser_detect.html> but am
    >> still not sure where to draw the line.

    >
    > More caution is needed with Host objects.


    that was the impression i got from Thomas Lahn's initial response

    > In your case, document.body might be undefined in an XHTML DOM. That
    > problem can be avoided by not using XHTML, of course.


    of course; and since i'm interested in the very oldest dynamic browsers
    XHTML is not even an option as i guess none of them would know what to
    do with an XHTML mime-type.

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


    understood.

    > Nonstandard features tend to have more divergence in how they work.


    understood.
     
    john, Jan 17, 2010
    #9
  10. Thomas 'PointedEars' Lahn wrote:
    > Garrett Smith wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> kangax wrote:
    >>>> Thomas 'PointedEars' Lahn wrote:
    >>>>> john wrote:
    >>>>>> given the following javascript:


    [...]
    >>>> No, the interface is HTMLElement
    >>>> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not
    >>>> HTMLBodyElement.

    >> Apparently I assumed incorrectly.
    >>


    To say that className is a property of objects implementing
    HTMLBodyElement is as misleading because it is too narrow.

    className is a property of HTMLElement and HTMLBodyElement is an
    HTMLElement. That is exactly what kangax correctly pointed out.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Jan 17, 2010
    #10
  11. Garrett Smith wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Garrett Smith wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> kangax wrote:
    >>>>> No, the interface is HTMLElement
    >>>>> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not
    >>>>> HTMLBodyElement.
    >>> Apparently I assumed incorrectly.
    >>>

    >
    > To say that className is a property of objects implementing
    > HTMLBodyElement is as misleading because it is too narrow.


    Not for those with eyes to see.

    > className is a property of HTMLElement and HTMLBodyElement is an
    > HTMLElement.


    Nonsense.

    > That is exactly what kangax correctly pointed out.


    kangax, too, failed to see what I was specifically referring to,
    and the inheritance present in the W3C DOM API Specifications.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
     
    Thomas 'PointedEars' Lahn, Jan 18, 2010
    #11
  12. 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?

    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.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jan 18, 2010
    #12
  13. 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
     
    Thomas 'PointedEars' Lahn, Jan 18, 2010
    #13
  14. 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$>
     
    Thomas 'PointedEars' Lahn, Jan 18, 2010
    #14
  15. 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/
     
    Garrett Smith, Jan 18, 2010
    #15
  16. john

    john Guest

    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.
     
    john, Jan 18, 2010
    #16
  17. john

    john Guest

    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.
     
    john, Jan 18, 2010
    #17
  18. john wrote:
    > 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.


    I meant what I wrote: Don't expect nonstandard behavior from standard
    properties.

    Code that is expecting XHR to work over file: protocol is expecting
    nonstandard behavior (though technically XHR itself is nonstandard,
    though it is a w3c WD).

    Code that is expecting assignment to DOM domstring properties to be
    converted to string is expecting nonstandard behavior.

    Code that is expecting typeof document.images == "object" is expecting
    nonstandard behavior.

    Code that uses malformed, nonconformant HTML is expecting nonstandard
    behavior.

    When the code doesn't do what is expected of it, then it is necessary to
    understand why. For DOM related issues, this usually boils down to
    looking closely at the code and looking closely to what the specs say
    should happen.

    Regarding XHR working draft explicitly states that protocol other than
    http and https is outside of the scope of the spec (or
    implementation-dependent). The code that is expecting XHR to work over
    file: protocol is expecting nonstandard behavior.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Jan 18, 2010
    #18
  19. Garrett Smith wrote:

    > 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.


    So no longer of any concern. Thanks.

    >> 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


    You should know better than to cite Working Drafts as reference material.
    (How many times have I told you already?)


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jan 18, 2010
    #19
  20. Thomas 'PointedEars' Lahn wrote:
    > Garrett Smith wrote:
    >
    >> 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.

    >
    > So no longer of any concern. Thanks.
    >
    >>> 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.


    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Please read that again: "stopped at CR phase in 2007.

    "CR" Stands for "Candidate Recommendation".

    | Candidate Recommendation (CR)
    | A Candidate Recommendation is a document that W3C believes has been
    | widely reviewed and satisfies the Working Group's technical
    | requirements. W3C publishes a Candidate Recommendation to gather
    | implementation experience.

    A recommendation (REC) can be used as a normative reference.
    http://www.w3.org/2005/10/Process-20051014/tr.html#rec-track-doc

    >> http://www.w3.org/TR/WICDMobile/#dom

    >
    > You should know better than to cite Working Drafts as reference material.
    > (How many times have I told you already?)
    >

    If you look at the conclusion I wrote:-

    | 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.

    There is nothing proven here. A normative reference is not required and
    no normative reference was used.

    That document was not cited as a reference (normative or otherwise). I
    wonder what the rationale for omitting document.body was.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Jan 18, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Spencer
    Replies:
    2
    Views:
    459
    John Saunders
    Aug 6, 2003
  2. Skybuck Flying

    Call oddities: &Test() vs &Test vs Test

    Skybuck Flying, Oct 4, 2009, in forum: C Programming
    Replies:
    1
    Views:
    715
    Skybuck Flying
    Oct 4, 2009
  3. Simon Strandgaard

    test::unit caller stack feature request

    Simon Strandgaard, Feb 2, 2004, in forum: Ruby
    Replies:
    5
    Views:
    135
    Nathaniel Talbott
    Feb 2, 2004
  4. Simon Strandgaard
    Replies:
    14
    Views:
    185
    Nathaniel Talbott
    Aug 16, 2004
  5. Tim Down

    Feature test paste event

    Tim Down, Sep 18, 2009, in forum: Javascript
    Replies:
    6
    Views:
    151
    Tim Down
    Sep 28, 2009
Loading...

Share This Page