Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > knowing what and when to feature test

Reply
Thread Tools

knowing what and when to feature test

 
 
Garrett Smith
Guest
Posts: n/a
 
      01-18-2010
Garrett Smith wrote:
> 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-20...#rec-track-doc
>

(in contrast to a CR, a REC can be a normative ref).
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-18-2010
Garrett Smith wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> 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".


<yawn> I know. </yawn> (You should also have known better than trying to
lecture me [of all people] about the W3C Process Document.)

> [...]
> A recommendation (REC) can be used as a normative reference.
> http://www.w3.org/2005/10/Process-20...#rec-track-doc


But a CR cannot.

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


Your conclusion is irrelevant. You should have never cited this document
in that manner in the first place (whom are you trying to fool here?):

| Status of this Document
|
| [...]
| Publication as a Candidate Recommendation does not imply endorsement by
| the W3C Membership. This is a draft document and may be updated, replaced
| or obsoleted by other documents at any time. It is inappropriate to cite
| this document as other than work in progress.


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
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      01-18-2010
Thomas 'PointedEars' Lahn wrote:
> Garrett Smith wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> 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".

>
> <yawn> I know. </yawn> (You should also have known better than trying to
> lecture me [of all people] about the W3C Process Document.)
>
>> [...]
>> A recommendation (REC) can be used as a normative reference.
>> http://www.w3.org/2005/10/Process-20...#rec-track-doc

>
> But a CR cannot.
>


Yes, that's a true statement, but beside the point.

The document linked was not used as a normative reference.

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

>
> Your conclusion is irrelevant. You should have never cited this document
> in that manner in the first place (whom are you trying to fool here?):
>


The only person that seems to be fooled is *you*. The CR is not a
normative reference, so arguing to say that I am wrong by using it as is
a normative reference seems to be on the wrong track.

I don't see where you're going with this (probably nowhere).

I want to know if any implementations are following that CR, and also
what the rationale for omitting document.body there. I do not expect you
to answer those questions although someone else might be able to.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-18-2010
Jake Jarvis wrote:
> Garrett Smith wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Garrett Smith wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> 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'


[...]

>> I want to know if any implementations are following that CR, and also
>> what the rationale for omitting document.body there. I do not expect you
>> to answer those questions although someone else might be able to.

>
> It might just seem that you quoted that CR as an argument and support
> for "document.body might be undefined" (when it's not a bug).
>


What part of "Seems to have stopped at CR phase in 2007" sounds like an
argument?

Or is the argument in 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.

I don't see it.

Does any browser implement WICD Mobile 1.0 and use the DOM Level 2 HTML
Subset?

What do you think the reason for omitting document.body from that draft is?

Don't have answers? Join the club.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-20-2010
Garrett Smith wrote:

> john wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> john wrote:
>>>> Garrett Smith wrote:
>>>>> 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.


Nonsense. Obviously you have not paid attention to previous discussions.
Does setAttribute()/getAttribute() ring a bell?

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


Nonsense. There is _nothing_ that says XHR must not be used for `file:'.
One should be aware, though, that certain conditions must apply for this
to work. For example, in MSXML it requires the use of ActiveXObject().

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


Nonsense. The API Specification does not say how implementations should
behave there. While there is indication that it would be unwise to rely on
implicit type conversion, that is certainly not based on an expectation of
nonstandard behavior.

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


Nonsense. `document.images' is a reference to a host object. Host objects
are free to implement whatever `TypeOf' algorithm they want per ES3F, with
any possible string value as a result. While ES5 limits that to not
include "object" (and other values), there are more implementations that
implement ES3F than ES5 (of which it is not entirely clear what it is its
current status). That is, it is certainly not safe to have the
aforementioned expectation, but it is also NOT an expectation of non-
standard behavior.

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


Nonsense. The HTML standard makes recommendations as to how parsers are
supposed to handle invalid markup. But again, it is not wise to rely on
that as those are only recommendations.

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


You don't get it, do you? Working drafts are NOT to be cited as reference
material, as something else than "work in progress". They are NOT
standards. While that already follows from the W3C Process Document and
common sense, the very text of the Working Draft you are referring to
explicitly says so in its "Status of this Document" section.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigat-or.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-20-2010
On Jan 18, 1:26 am, Garrett Smith <(E-Mail Removed)> 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.
>
> > 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.


What does it matter? Just use a wrapper that tries document.body
first, then gEBTN, etc. You need it for some browsers and parse modes
(e.g. XML). Return null if all fails. Substitute a simpler wrapper
when the context allows:-

function getBodyElement(doc) {
return (doc || document).body;
}

var body = getBodyElement();

if (body) { // Needs a reference to BODY to work
...
}
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-20-2010
On Jan 18, 1:28 am, john <(E-Mail Removed)> wrote:

[...]

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


Thanks for the mention. My Library was just a lark, but it only took
a week or so to turn it into a condender. It's the only JS library or
framework that allows for progressive enhancement and certainly the
only major one (in terms of scope, not marketing efforts) that is free
of browser sniffing. From recent testimg, it has been shown to
degrade gracefully in browsers that were released before the turn of
the century. It's quite capable on dinosaurs like IE5 and NN1. Less
so with Opera < 7, but then it degrades in a way that cues calling
apps to avoid hazards. Try that with jQuery or the like and you'll
see immediately why they "deprecate" all but the latest versions of
major browsers (it's all they have time to keep up with as they have
to keep changing their code due to past unfortunate inferences).

The ES end of it is fairly trivial as most browsers are using an old
and established standard. The DOM stuff was chaos for the first five
years of the past decade and then settled down (just in time for JS
library authors to come along and introduce their own misconceptions
and mixups). The My Library test page demonstrates this quite nicely
(with companion features showing how the libraries of each era managed
to foul everything up).

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


The "brand name" scripts (AKA "major") are simply names from the
past. No, they don't have anything to offer. They wouldn't have been
acceptable in 2005 (around when most were conceived). It's been half
a decade of demonstrable futility since then.

[...]

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


People ask me why I bother to test ancient Opera browsers, handhelds,
Mozilla, etc. It's because ancient browsers have degradation paths
too. Virtually any old browser is a good test and can expose flaws in
the feature detection that might adversely affect other browsers (e.g.
lesser browsers in mobile devices, gaming consoles, etc). The only
people who will tell you to test just in the latest (or modern)
browsers are people are hiding from the fact that their scripts are
bunk. If you can't support the past, what hope is there for the
future?

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


You bet. My Library is a clinic on that.

[...]

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


In reality, NS2 (and IE3) are too old to be practical tests. NN4 is
pretty screwy too. But there's no excuse for a Website that blows up
in IE5.5 or Opera 7. The currently popular libraries (which are only
popular among people who have no idea what they are doing) are lucky
to support IE8 by itself (most can't). For years, jQuery blew up in
IE when ActiveX was disabled (despite the public outcry). To this
day, jQuery is compeletely oblivious to quirks and compatibility
modes. I know it sounds crazy, but the people who "design" Websites
don't test for ****. They want to "drop" IE6/7 because they could
never really do their jobs with them in use. Yes, these are the same
people who "argue" endlessly that they are dealing with "Real World"
issues (where nobody uses IE ever I guess).

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

>
>


Yes, Operas "Portal" throws several errors in Opera 6, which is pretty
ludicrous considering they wrote both the browser and the
documents.

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


That can happen too. Modularity helps as it allows removing a piece
at a time until the crash goes away.

> it took a few tries to be fast enough to
> hit the stop button before the crash.


LOL. The home page URI (and everything else) is in the Registry.

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


Doubled-over LOL. Gmail? If My Library can be considered a good
example of cross-browser scripting (call it an 8 at this point), GMail
is a colossal embarassment to anyone who ever worked on it (I can't
imagine anyone would admit to it). Call it minus about a million.
And no, I'm not exaggerating for effect. That site is the poster
child for browser scripting futility, with only other Google apps in
serious competition. So I suggest you test something other than
Google-authored sites.

Here's one I use as a yardstick for older (but not too ancient)
browsers:-

http://www.hartkelaw.net/

As mentioned, the My Library builder and test page are also useful for
this.
 
Reply With Quote
 
John G Harris
Guest
Posts: n/a
 
      01-20-2010
On Wed, 20 Jan 2010 at 13:49:01, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

<snip>
>Nonsense. The HTML standard makes recommendations as to how parsers are
>supposed to handle invalid markup. But again, it is not wise to rely on
>that as those are only recommendations.

<snip>

Which HTML standard is that ? The current standard makes no such
recommendations.

John
--
John Harris
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-20-2010
John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Nonsense. The HTML standard makes recommendations as to how parsers are
>> supposed to handle invalid markup. But again, it is not wise to rely on
>> that as those are only recommendations.

>
> Which HTML standard is that ? The current standard makes no such
> recommendations.


You are mistaken: <http://www.w3.org/TR/html4/appendix/notes.html#h-B.1>


PointedEars
--
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$(E-Mail Removed)>
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-20-2010
On Jan 20, 2:35 pm, Hans-Georg Michna <hans-
(E-Mail Removed)> wrote:
> On Wed, 20 Jan 2010 13:49:01 +0100, Thomas 'PointedEars' Lahn
> wrote:
>
> >... There is _nothing_ that says XHR must not be used for `file:'.
> >One should be aware, though, that certain conditions must apply for this
> >to work. For example, in MSXML it requires the use of ActiveXObject().

>
> I had wanted to ask about that already. I keep reading that the
> particular problem here is only the XMLHttpRequest in Internet
> Explorer 7, which exists and works fine, but refuses to touch
> any URL that begins with "file:".


Right.

>
> If yes, then it would be one of the rare examples where browser
> version sniffing is appropriate, as you cannot elegantly
> feature-test this. (Firing off an Ajax request just for the
> purpose of feature-testing is out of the question, I suppose.)


Not version sniffing, but an object inference is in order. As we know
that all ActiveX versions support file:, we can support file: if we
can create an ActiveX XHR object. See createXmlHttpRequest in My
Library.

>
> What most people seem to do is cruder. They check the URL for
> the file: prefix and the browser for the presence of MSXML, and
> if both are present, they use MSXML even in browsers where
> XMLHttpRequest is perfectly usable, like in Internet Explorer 8.


They do what?

>
> Do I see things correctly? The example below is an example for
> the crude method without browser sniffing.


Not exactly.

[...]

>
> // Constructor for universal XMLHttpRequest:
> function XHR() {
> // For support of IE before version 6 add "Msxml2.XMLHTTP":
> var modes = ["Msxml2.XMLHTTP.6.0", "Msxml2.XMLHTTP.3.0"];


Oh, this is what you meant by MSXML. These are programmatic ID's for
ActiveX components. You can be sure that XMLHttpRequest uses the same
components behind the scenes.

> // If working with the local file system, try Msxml2
> // first, because IE7 also has an XMLHttpRequest,
> // which, however, fails with the local file system:


Right.

> if (location.protocol === "file:" && ActiveXObject)


Poor feature detection. Use isHostMethod or the like.

> for (var i = 0; i < modes.length; i++)
> try {
> return new ActiveXObject(modes[i]);
> } catch (ignore) {}
> else if (XMLHttpRequest) return new XMLHttpRequest();


Same and missing try-catch (this constructor can be disabled by the
user, just like ActiveXObject). I wonder if jQuery remembered to wrap
that one too.

> else for (var i = 0; i < modes.length; i++)
> try {
> return new ActiveXObject(modes[i]);
> } catch (ignore) {}


A bit redundant.

> return;
>


I don't like that it runs these tests every time through, but the
basic ideas are sound. Checking the UA string would be far more
crude, not to mention disaster-prone.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
test test test richard Computer Support 3 01-24-2007 05:18 AM
TEST TEST Test...Blah Blah Blah generalbatguano@pacbell.net Computer Support 2 09-15-2006 03:47 AM
TEST TEST Test...Blah Blah Blah Generalbatguano@pacbell.net Computer Support 6 09-13-2006 01:53 AM
TEST TEST TEST Gazwad Computer Support 2 09-05-2003 07:32 PM
test test test test test test test Computer Support 2 07-02-2003 06:02 PM



Advertisments