Prev: Question about constructor property vs. instanceof
Next: What browser doesn't support ajax ?
From: RobG on 11 Jan 2010 20:28
On Jan 12, 7:21 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> RobG wrote:
> > Since el will be a (live) collection in conforming browsers, and
> > probably an array where a native method has been substituted, you
> > probably want to enumerate its members and add the click listener to
> > each one:
>
> >   for (var i=0, len=el.length; i<len; i++) {
> >     el[i].addEventListener(...);
> >   }
>
> Or you could find the common ancestor (when in doubt, the BODY element), and
> add a listener that tests the className.  That would be a lot more
> efficient.

The criteria for "efficient" depend on the circumstance and how it is
measured. I assumed (perhaps incorrectly) that the OP was a small
example and not intended to be production code.

Using getElementsByClassName for a single element is certainly
inefficient compared to say getElementById, however it is sufficient
for an example.

Using event delegation might be more efficient in terms of requiring
fewer listeners and so saving processing time adding them, or less
efficient as the listener will likely be called far more often than if
it is placed only on the elements it relates to.


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

I don't know, but there are lots of browsers that I know little or
nothing about. Quirksmode[1] says that Konqueror 3.5.7 doesn't have
getElementsByClassname but it might be out of date as 4.3 is current
and 4.4 is in beta (Linux and Windows, the stable Mac OS X version is
3.5.9).


1. <URL: http://www.quirksmode.org/dom/w3c_core.html#fivemethods >

--
Rob
From: kangax on 12 Jan 2010 22:34
On 1/11/10 8:28 PM, RobG wrote:
> On Jan 12, 7:21 am, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
> 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?
>
> I don't know, but there are lots of browsers that I know little or
> nothing about. Quirksmode[1] says that Konqueror 3.5.7 doesn't have
> getElementsByClassname but it might be out of date as 4.3 is current
> and 4.4 is in beta (Linux and Windows, the stable Mac OS X version is
> 3.5.9).

There's `document.getElementsByClassName` in Konqueror 4.3.2. I haven't
checked how compliant that method is, though.

[...]

--
kangax
From: David Mark on 13 Jan 2010 10:47
On Jan 11, 4:21 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> RobG wrote:
> > Since el will be a (live) collection in conforming browsers, and
> > probably an array where a native method has been substituted, you
> > probably want to enumerate its members and add the click listener to
> > each one:
>
> > for (var i=0, len=el.length; i<len; i++) {
> > el[i].addEventListener(...);
> > }
>
> Or you could find the common ancestor (when in doubt, the BODY element), and
> add a listener that tests the className. That would be a lot more
> efficient.
>
> > 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 (and who knows how many off-
brand agents?) And what do CSS classes have to do with detecting
event-related features?

Also, though it is beside the point, typeof document.body.className ==
'string' in Opera 6 and CSS classes work in the static markup (of
course), but manipulating them programmatically has no effect.

Not sure of any general way to detect that oddball behavior, but a
couple of clues are that its (rather limited) inline style rule
properties actually compute styles and left, top, height and width
return numbers (rather than the usual strings). The last of those is
something I accounted for in My Library, but was never sure which
browser(s) were afflicted with the quirk.

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. Of course,
my addStyleRule (API method) is disallowed in that browser as well, so
I can't use that to add a test rule. Only thing I can think of is a
multiple object inference based on the screwy style properties, but
I'm not adding anything like that for Opera 6. IMO, they should not
have exposed the CLASS attribute as a className property if changing
it would have no effect.
From: Thomas 'PointedEars' Lahn on 13 Jan 2010 13:16
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?

> (and who knows how many off-brand agents?)

I do not know. What do you consider an "off-brand agent"?

> And what do CSS classes have to do with detecting event-related
> features?

Read the Subject.

> Also, though it is beside the point, typeof document.body.className ==
> 'string' in Opera 6 and CSS classes work in the static markup (of
> course), but manipulating them programmatically has no effect.

Thanks.

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

> [...]
> I'm not adding anything like that for Opera 6. IMO, they should not
> have exposed the CLASS attribute as a className property if changing
> it would have no effect.

ACK


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 process"or, or another network. -- Tim Berners-Lee
From: David Mark on 13 Jan 2010 13:29
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. Opera Mini is a the first one that
comes to mind. There's also some form of Opera in a Wii. Then there's
that POS in the PS3 (Netfront?) Knowing that my library makes a
graceful exit in Opera 6 gives me more confidence that it will deal
successfully with browsers that I haven't yet tested. Of course, some
scenarios (e.g. the lack of documentElement) can be simulated by
stubbing out methods.

>
>> And what do CSS classes have to do with detecting event-related
>> features?
>
> Read the Subject.

No help there. :)

>
>> Also, though it is beside the point, typeof document.body.className ==
>> 'string' in Opera 6 and CSS classes work in the static markup (of
>> course), but manipulating them programmatically has no effect.
>
> Thanks.

Yes, I thought you'd like that.

>
>> 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. ;)
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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Question about constructor property vs. instanceof
Next: What browser doesn't support ajax ?