The above blog entry suggests substituting $$ for getElementsByClassName as a work-around and I see that the Prototype documentation lists getElementsByClassName as "deprecated".
My problem is that I use the 'parentElement' option in Prototype's getElementsByClassName fairly often so $$ is not an effective substitution.
So, is there a variation on $$ that constrains the search to a specific node?
I have yet to hear a comment on this list regarding Safari 3.1's change and how it affects Prototype. Am I the only one feeling this pain. This broke our site in a few important ways...
Is there a short-term hack I can apply to Prototype to get it to allow me to use Safari's getElementsByClassName (which appears to support the parentElement option)?
On Mon, Mar 24, 2008 at 4:00 PM, Steve Upton <clang...@gmail.com> wrote: > So, is there a variation on $$ that constrains the search to a specific node?
> The above blog entry suggests substituting $$ for > getElementsByClassName as a work-around and I see that the Prototype > documentation lists getElementsByClassName as "deprecated".
> My problem is that I use the 'parentElement' option in Prototype's > getElementsByClassName fairly often so $$ is not an effective > substitution.
> So, is there a variation on $$ that constrains the search to a > specific node?
> I have yet to hear a comment on this list regarding Safari 3.1's > change and how it affects Prototype. Am I the only one feeling this > pain. This broke our site in a few important ways...
> Is there a short-term hack I can apply to Prototype to get it to > allow me to use Safari's getElementsByClassName (which appears to > support the parentElement option)?
> Is there something I'm missing here?
Just use $A(document.getElementsByClassName('foo')) instead of document.getElementsByClassName('foo') and you will have an array of extended elements, which is what you probably want. Simple workaround and haven't had any problems with it yet, both on Safari 3.1 and Firefox 3 beta (which also implements a native getElementsByClassName.
>Just use $A(document.getElementsByClassName('foo')) instead of document.getElementsByClassName('foo') and you will have an array of extended elements, which is what you probably want. Simple workaround and haven't had any problems with it yet, both on Safari 3.1 and Firefox 3 beta (which also implements a native getElementsByClassName.
This is a good thing to know but Safari 3.1's new implementation of getElementsByClassName does not seem to use the parentElement parameter so I get elements for the whole page... not what I needed.
At 4:03 PM -0600 3/24/08, Dan Dorman wrote:
>On Mon, Mar 24, 2008 at 4:02 PM, Dan Dorman <dan.dor...@gmail.com> wrote: >> $('node-id').select('class-name');
The $ is handy when the element isn't yet extended OR is an id and don't forget to put the '.' in front of the class name to make it a class selector.
Thanks for your help.
Regards,
Steve
________________________________________________________________________ o Steve Upton CHROMiX www.chromix.com o (hueman) 866.CHROMiX ________________________________________________________________________ --
On Mar 26, 3:53 am, Steve Upton <clang...@gmail.com> wrote:
> At 12:04 AM +0100 3/25/08, Peter De Berdt wrote:
> >Just use $A(document.getElementsByClassName('foo')) instead of document.getElementsByClassName('foo') and you will have an array of extended elements, which is what you probably want. Simple workaround and haven't had any problems with it yet, both on Safari 3.1 and Firefox 3 beta (which also implements a native getElementsByClassName.
> This is a good thing to know but Safari 3.1's new implementation of getElementsByClassName does not seem to use the parentElement parameter so I get elements for the whole page... not what I needed.
Read the doco - it doesn't need to, it's implemented as per the HTML 5
working draft on the HTMLElement interface, it is called as a method
of the "parentElement":
var liveNodeList = parentElement.getElementsByClassName('foo bar
tweedle dee ...');