Prev: Question about constructor property vs. instanceof
Next: What browser doesn't support ajax ?
From: Thomas 'PointedEars' Lahn on 13 Jan 2010 14:15
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> RobG wrote:
>>>>> Also, addEventListener is not available in some recent, and many
>>>>> older, browsers so you should also test for that and provide an
>>>>> alternative.
>>>> What other *recent* implementations except MSHTML that support CSS
>>>> classes do not support it?
>>> The addEventListener method? Opera 6
>> Thanks. Would you still consider it?
>
> Consider it what? I would consider it when testing degradation paths
> for unknown browsers. It's great for that. Gaps in logic are gaps in
> logic, whether they affect the latest browsers or not. ;)
>
>>> (and who knows how many off-brand agents?)
>> I do not know. What do you consider an "off-brand agent"?
>
> Mobile devices for one example. [more examples]

ACK

>>> And what do CSS classes have to do with detecting event-related
>>> features?
>>
>> Read the Subject.
>
> No help there. :)

In this example, if there would be no way to determine the elements that
have a certain class name, it would not matter if the environments to which
this applied would support addEventListener() as execution would/should
never reach that point. As it is possible, that changes the situation.

>>> So anyway, now that I think about it, if you set the className
>>> property to a class known to define a top rule, you could then check
>>> to see if the element's style.top is affected as expected.
>> I don't think so. The `top' "rule" (_declaration_, really) in a
>> document stylesheet does not affect the value of the `style.top'
>> property, and Opera 6 does not support getComputedStyle().
>
> You did not read carefully. Opera 6 does have a goofy
> quasi-computed-style capability. Just do a
> window.alert(document.body.style.color) and you'll see what I mean. ;)

Thanks. I tried that on <http://portal.opera.com/> (the default home page
for Opera 6.0.6) and it displayed nothing. To be precise, I checked type
and value: it was the empty string, unexpectedly.

I then found out that this must have been due to the empty `class'
attribute (which is invalid, BTW). The first child element with ID "opera-
websites" has a class attribute value of "clearfix", but the ID selector
has `color: #dddddd' which is what the `color' property yields.

This is probably what you meant by "goofy".

> Come to think of it, I could detect that silliness and infer that
> className won't work, but it's still too much of a stretch for my taste.

Which means in essence that you do not consider optimizing for this UA
anymore, does it not?


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: David Mark on 13 Jan 2010 14:33
Thomas 'PointedEars' Lahn wrote:
> David Mark wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> David Mark wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> RobG wrote:
>>>>>> Also, addEventListener is not available in some recent, and many
>>>>>> older, browsers so you should also test for that and provide an
>>>>>> alternative.
>>>>> What other *recent* implementations except MSHTML that support CSS
>>>>> classes do not support it?
>>>> The addEventListener method? Opera 6
>>> Thanks. Would you still consider it?
>> Consider it what? I would consider it when testing degradation paths
>> for unknown browsers. It's great for that. Gaps in logic are gaps in
>> logic, whether they affect the latest browsers or not. ;)
>>
>>>> (and who knows how many off-brand agents?)
>>> I do not know. What do you consider an "off-brand agent"?
>> Mobile devices for one example. [more examples]
>
> ACK
>
>>>> And what do CSS classes have to do with detecting event-related
>>>> features?
>>> Read the Subject.
>> No help there. :)
>
> In this example, if there would be no way to determine the elements that
> have a certain class name, it would not matter if the environments to which
> this applied would support addEventListener() as execution would/should
> never reach that point. As it is possible, that changes the situation.

That's what I was driving at.

>
>>>> So anyway, now that I think about it, if you set the className
>>>> property to a class known to define a top rule, you could then check
>>>> to see if the element's style.top is affected as expected.
>>> I don't think so. The `top' "rule" (_declaration_, really) in a
>>> document stylesheet does not affect the value of the `style.top'
>>> property, and Opera 6 does not support getComputedStyle().
>> You did not read carefully. Opera 6 does have a goofy
>> quasi-computed-style capability. Just do a
>> window.alert(document.body.style.color) and you'll see what I mean. ;)
>
> Thanks. I tried that on <http://portal.opera.com/> (the default home page
> for Opera 6.0.6) and it displayed nothing. To be precise, I checked type
> and value: it was the empty string, unexpectedly.

Then it had an empty class (or no color defined by the class).

>
> I then found out that this must have been due to the empty `class'
> attribute (which is invalid, BTW).

Not to mention clueless (and a waste of space). :)

> The first child element with ID "opera-
> websites" has a class attribute value of "clearfix", but the ID selector
> has `color: #dddddd' which is what the `color' property yields.
>
> This is probably what you meant by "goofy".

Yes.

>
>> Come to think of it, I could detect that silliness and infer that
>> className won't work, but it's still too much of a stretch for my taste.
>
> Which means in essence that you do not consider optimizing for this UA
> anymore, does it not?
>

No. I don't "optimize" for any specific browser. For example, this
browser has no way to get to the documentElement (literally none, even
gEBTN fails). There was a bad assumption in one of my module's feature
testing code, expecting that it would always be available one way or
another. That's simply a gap in logic and fixing it has nothing to do
with the browser that exposed the problem. Another gotcha with this
browser is that it has a bogus createElement method that invariably
returns the undefined value. (!) Luckily I was in the habit of testing
the result from that method (I never did trust it completely), so that
didn't pose an issue. About the only thing left to do for that one is
to find out why the mouse position stuff isn't working. That's
important for pruning the drag and drop methods (or actually making them
work). I suspect it is one of those browsers that used event.x and
event.y as I am pretty sure DnD was do-able in Opera 6.

One other interesting note with Opera < 9, is that it recalculates
offsetWidth/Height after evaluation, rather than before (at least in
some circumstances). It also seems to turn the usual hack-arounds into
noops. Example:-

(el.offsetWidth) // Force recalculation before reading--fails in Opera < 9

Changing that to an assignment or a test fixes the issue. I only did
that in the alert add-on, but ISTM the core should have a test for this
quirk (and use it in one or two places as well). FF1 had a similar
problem with the "shrink-wrapped" alert (fixed with the same hack).
First  |  Prev  | 
Pages: 1 2 3
Prev: Question about constructor property vs. instanceof
Next: What browser doesn't support ajax ?