From: Hans-Georg Michna on
On Sun, 17 Jan 2010 17:23:51 -0600, john wrote:

>On 17 Jan 5:30 AM, Hans-Georg Michna wrote:

>> On Sat, 16 Jan 2010 23:10:29 -0600, john wrote:

>>> is there any general advice on when it would be ok to assume a feature
>>> will be available?

>> The question is equivalent to asking for a list of features for
>> each of the browsers in question.

>that's not at all what i was asking for. perhaps i phrased it poorly.
>
>i was wondering what criteria experienced javascript programmers use to
>decide when a feature test is necessary and when it's ok to skip it.

I thought it was obvious that a feature test is needed when one
cannot rely on the feature being available in all of the
targetted browsers. Therefore the question is equivalent to
asking which features are available in which browsers.

Hans-Georg
From: Garrett Smith on
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-20051014/tr.html#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/
From: Jake Jarvis on
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'
>>>>>> 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-20051014/tr.html#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.

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

--
Jake Jarvis
From: Garrett Smith on
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/
From: Thomas 'PointedEars' Lahn on
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