Quantcast

getElementsBy(attribute, value)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

getElementsBy(attribute, value)

Jörn Zaefferer-2

I'd like to propose a more useful DOM method then what
getElementsByClassName is supposed to provide (http://www.whatwg.org/
specs/web-apps/current-work/#getelementsbyclassname), replacing both
the need for getElementsByClassName and getElementsByName (http://
www.whatwg.org/specs/web-apps/current-work/#getelementsbyname), while
having a great performance potential when used directly or via
libraries.

Method signature would be:
getElementsBy(attribute: String, value: String, RegExp)

Usage examples:

function getElementsByName(name) {
  return document.getElementsBy("name", name);
}
function getElementsByClassName(className) {
  return document.getElementsBy("class", className);
}
function getElementsStartingWithId(id) {
  return document.getElementsBy("id", new RegExp("^" + id));
}

To actually be able to replace getElementsByClassName,
getElementsBy("class", className) would have to implement the special
case where the class attribute is split by whitespace and matched one
by one.

This makes much more sense to me then adding another
getElementsByAnotherAttribute every few years, especially considering
new attributes like required on input elements (http://www.whatwg.org/
specs/web-forms/current-work/#the-required).

I'd like to get the feedback of this group before trying to push this
out to a few blogs. Also ideas where to actually propose this are
welcome.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Chris Thatcher-3
Happy New Year Jorn,

This makes sense to me, and assuming the computational cost isnt significantly higher as a ratio to it's expected call count, I'd second your proposal for consideration.  I have to admit I was confused by signature usage of the term 'attribute' since we are talking about a DOM, but understood on second reading.  Would it serve the argument for generality of signature to use something like:

getElementsBy(props:{});

eg:

getElementsBy({
name:"a",
class:"myclass"
});

and just add to the list of supported properties over time?  Or does this affect performance or reduce to the same thing you propose?

Thanks
Chris Thatcher
(cell) 202 340 9685



On Jan 4, 2008, at 5:55 AM, Jörn Zaefferer wrote:


I'd like to propose a more useful DOM method then what
getElementsByClassName is supposed to provide (http://www.whatwg.org/
specs/web-apps/current-work/#getelementsbyclassname), replacing both
the need for getElementsByClassName and getElementsByName (http://
www.whatwg.org/specs/web-apps/current-work/#getelementsbyname), while
having a great performance potential when used directly or via
libraries.

Method signature would be:
getElementsBy(attribute: String, value: String, RegExp)

Usage examples:

function getElementsByName(name) {
  return document.getElementsBy("name", name);
}
function getElementsByClassName(className) {
  return document.getElementsBy("class", className);
}
function getElementsStartingWithId(id) {
  return document.getElementsBy("id", new RegExp("^" + id));
}

To actually be able to replace getElementsByClassName,
getElementsBy("class", className) would have to implement the special
case where the class attribute is split by whitespace and matched one
by one.

This makes much more sense to me then adding another
getElementsByAnotherAttribute every few years, especially considering
new attributes like required on input elements (http://www.whatwg.org/
specs/web-forms/current-work/#the-required).

I'd like to get the feedback of this group before trying to push this
out to a few blogs. Also ideas where to actually propose this are
welcome.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

dave.methvin
In reply to this post by Jörn Zaefferer-2


> To actually be able to replace getElementsByClassName,
> getElementsBy("class", className) would have to implement the special
> case where the class attribute is split by whitespace and matched one
> by one.

Since that is a special case, I would leave getElementsByClassName as
it is and propose your extension as
getElementsByAttribute(attributeName, [, valueOrRegexp]). If no value
is provided it would return all nodes that have the attribute
regardless of value. If a valueOrRegexp is provided then the node's
attribute value would need to equal the given value or match the given
regexp.

> This makes much more sense to me then adding another
> getElementsByAnotherAttribute every few years,

The W3C DOM2 tree traversal interface is the generalized way to solve
the problem, but it's relatively complex, not all browsers implement
the API, and it still leaves some implementation-specific wiggle room.
For example, Nodefilters can potentially modify nodes as they are
called during traversal but the spec seems hazy about whether that has
to be fully supported by the implementation.
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html

Your proposal is much easier to describe, implement, and integrate
into existing frameworks. Why, even Microsoft might be able to
impement it...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Jörn Zaefferer
In reply to this post by Chris Thatcher-3

Thanks Chris for your reply!

> [...]
>   Would it serve the argument for generality of signature to use
> something like:
>
> getElementsBy(props:{});
>
> eg:
>
> getElementsBy({
> name:"a",
> class:"myclass"
> });
>
> and just add to the list of supported properties over time?  Or does
> this affect performance or reduce to the same thing you propose?
That got me thinking quite a bit. Implementing CSS selectors is more
complicated then just getElementsBySomeStuff. For example, how would you
implement this one?
input[name=Peter]

Currently we do getElementsByTagName("input") and then filter the result
by name. With my proposal, we could do getElementsBy("name", "Peter"),
then filter by tagName. Nothing won so far.
With both available we could also execute both getXXX and then the
subset of both results (elements that are present in both lists).
Depending on the implementations, that may be more effective, but there
is hardly a guarantee.

Jörn

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Jörn Zaefferer
In reply to this post by dave.methvin

Thanks Dave, too :-)

>> To actually be able to replace getElementsByClassName,
>> getElementsBy("class", className) would have to implement the special
>> case where the class attribute is split by whitespace and matched one
>> by one.
>>    
> Since that is a special case, I would leave getElementsByClassName as
> it is and propose your extension as
> getElementsByAttribute(attributeName, [, valueOrRegexp]). If no value
> is provided it would return all nodes that have the attribute
> regardless of value. If a valueOrRegexp is provided then the node's
> attribute value would need to equal the given value or match the given
> regexp.
>  
Good point. getElementsByClassName is already out the door anyway, so is
there isn't much of a point of trying to replace that. Making the value
optional is also quite handy.

>> This makes much more sense to me then adding another
>> getElementsByAnotherAttribute every few years,
>>    
> The W3C DOM2 tree traversal interface is the generalized way to solve
> the problem, but it's relatively complex, not all browsers implement
> the API, and it still leaves some implementation-specific wiggle room.
> For example, Nodefilters can potentially modify nodes as they are
> called during traversal but the spec seems hazy about whether that has
> to be fully supported by the implementation.
> http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html
>
> Your proposal is much easier to describe, implement, and integrate
> into existing frameworks. Why, even Microsoft might be able to
> impement it...
Thanks for the link, that could definitely help to argument for a
simpler solution.

Though as mentioned in my reply to Chris, it still leaves the
select-and-filter hole open. I can do either getXXX or getYYY, but there
is no obvious way to combine both. So while its useful when working with
the DOM directly, the usefulness deacreases into an optimization option
for DOM libraries. A leveragable XPath implementation could enhance DOM
library performance way more.

On the other hand, both the DOM-level-2 traversal and XPath are quite
complex both in usage and in implementation. So with
getElementsByAttribute being much more realistic to be available some
time soon, the net gain could be way higher.

Other opinions?

Jörn

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Chris Thatcher-3
In reply to this post by Jörn Zaefferer
You points are well taken.  One thought, which may or may not be relevant, but I only mention because I've been using e4x lately:  What about distinguishing dom attribute nodes by requiring "@", so eg "@name".  Again this doesnt solve the bigger issue you raise but is just a passing thought.

getElementsBy({
name:"input",
"@name":"Peter"
});

Seems like you could construct a single boolean test that short-circuits on failure assuming the accepted properties had a hierarchical precedence defined.  Theres obviously a lot more to css as you said. I really need to study jquery.selector to understand whats going on now.  I'm assuming the function you are talking about would be internal (ie not exposed as a jQuery fn) to jquery.selector right?

I just read johns book and I'm am about to start karl and jonathons and my brain is hurting so I might have to let it rest before I try to think too much!  Thanks for your feed back, I always learn something.

Chris Thatcher
(cell) 202 340 9685



On Jan 8, 2008, at 1:02 PM, Jörn Zaefferer wrote:


Thanks Chris for your reply!
[...]
  Would it serve the argument for generality of signature to use 
something like:

getElementsBy(props:{});

eg:

getElementsBy({
name:"a",
class:"myclass"
});

and just add to the list of supported properties over time?  Or does 
this affect performance or reduce to the same thing you propose?
That got me thinking quite a bit. Implementing CSS selectors is more 
complicated then just getElementsBySomeStuff. For example, how would you 
implement this one?
input[name=Peter]

Currently we do getElementsByTagName("input") and then filter the result 
by name. With my proposal, we could do getElementsBy("name", "Peter"), 
then filter by tagName. Nothing won so far.
With both available we could also execute both getXXX and then the 
subset of both results (elements that are present in both lists). 
Depending on the implementations, that may be more effective, but there 
is hardly a guarantee.

Jörn




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Jörn Zaefferer

Chris Thatcher schrieb:
> Seems like you could construct a single boolean test that
> short-circuits on failure assuming the accepted properties had a
> hierarchical precedence defined.  Theres obviously a lot more to css
> as you said. I really need to study jquery.selector to understand
> whats going on now.  I'm assuming the function you are talking about
> would be internal (ie not exposed as a jQuery fn) to jquery.selector
> right?
Just to clarify: My proposal was meant to be eventually implemented by
browsers to enhance DOM library performance while also simplifying the
plain DOM API a lot.

Discussing something like that on this list first still seams like a
good idea to me :-)

Regards
Jörn

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

dave.methvin
In reply to this post by Jörn Zaefferer


> >   Would it serve the argument for generality of signature to use
> > something like:
>
> > getElementsBy(props:{});

A cautionary note about using objects as arguments: Since IE's DOM
implementation isn't native, it doesn't naturally handle any native
Javascript objects. I'm not sure they could implement having the
second argument be a native Javascript RegExp. It also has to work in
VBScript you know.  :)

> That got me thinking quite a bit. Implementing CSS selectors is more
> complicated then just getElementsBySomeStuff. For example, how would you
> implement this one?
> input[name=Peter]

document.getElementsBySelector("input[name=Peter]")

Each browser already has something similar it calls internally to
apply styles, so why shouldn't they expose it to scripts? It would
have to be an order of magnitude or more faster than our script
implementations. Even if jQuery had to take a pre-pass through the
selector string to implement shortcuts (e.g., s/:submit/
input[type=submit]/), or a post-pass on the resulting nodelist for
extensions like :has() that aren't in CSS,  it would still be faster
than slinging nodelists completely in script.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Jörn Zaefferer

Dave Methvin schrieb:

>  
>>>   Would it serve the argument for generality of signature to use
>>> something like:
>>>      
>>> getElementsBy(props:{});
>>>      
>
> A cautionary note about using objects as arguments: Since IE's DOM
> implementation isn't native, it doesn't naturally handle any native
> Javascript objects. I'm not sure they could implement having the
> second argument be a native Javascript RegExp. It also has to work in
> VBScript you know.  :)
>  
Ugh. So much about even IE implementing it...

>> That got me thinking quite a bit. Implementing CSS selectors is more
>> complicated then just getElementsBySomeStuff. For example, how would you
>> implement this one?
>> input[name=Peter]
>>    
>
> document.getElementsBySelector("input[name=Peter]")
>
> Each browser already has something similar it calls internally to
> apply styles, so why shouldn't they expose it to scripts?
Considering that the exposed DOM API is already quite messy when dealing
with "native" objects, exposing the CSS selector engine could be similar
messy. But anyway, thats the right way to go, everything else doesn't
get us far enough.

Of course that method should be on every DOM element, not only on
document :-)

Jörn

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Chris Thatcher-3
Just out of curiousity, assuming everyone supported e4x as well as firefox/rhino do now, would you be happy saying:

var whatiwant = html..input.(@name=='Peter');

Using e4x for serverside javascript, given a long history with xml to object binding love/hate relationships (in many languages), it's all leaving me wondering about the future of the browser dom in the case where xml becomes a first class object.  I don't really think the dom could go away, but would the developers prefer to work with the dom or the native xml object in most cases?

I'm trying to get jQuery to work with it a little, so I can use jq on the server (as an academic exercise) so you can render views and manipulate models before handing them to the client, eg jQuery(html..input.(@name=='Peter')) will do what you expect.  There's more to it than I expected but It's overall a very sexy way to get at an xml serialized data model.

Chris Thatcher
(cell) 202 340 9685



On Jan 9, 2008, at 4:09 PM, Jörn Zaefferer wrote:


Dave Methvin schrieb:

  Would it serve the argument for generality of signature to use
something like:

getElementsBy(props:{});


A cautionary note about using objects as arguments: Since IE's DOM
implementation isn't native, it doesn't naturally handle any native
Javascript objects. I'm not sure they could implement having the
second argument be a native Javascript RegExp. It also has to work in
VBScript you know.  :)

Ugh. So much about even IE implementing it...
That got me thinking quite a bit. Implementing CSS selectors is more
complicated then just getElementsBySomeStuff. For example, how would you
implement this one?
input[name=Peter]


document.getElementsBySelector("input[name=Peter]")

Each browser already has something similar it calls internally to
apply styles, so why shouldn't they expose it to scripts?
Considering that the exposed DOM API is already quite messy when dealing 
with "native" objects, exposing the CSS selector engine could be similar 
messy. But anyway, thats the right way to go, everything else doesn't 
get us far enough.

Of course that method should be on every DOM element, not only on 
document :-)

Jörn




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Jörn Zaefferer-2

Given enough support, e4x would be fine, too.

I've, too, played around with Rhino and jQuery on the serverside. If
you want to take a look at it, its all in SVN:
http://jqueryjs.googlecode.com/svn/branches/joern-dev/jQueryWeb/
Basically a Java web application where a servlet/portlet loads Rhino
and executes some scripts. The demo application is my blog (no DB) and
already supports posting comments, using the validation plugin on both
the client- and the serverside.

On Jan 10, 1:06 am, Chris Thatcher <[hidden email]>
wrote:

> Just out of curiousity, assuming everyone supported e4x as well as
> firefox/rhino do now, would you be happy saying:
>
> var whatiwant = html..input.(@name=='Peter');
>
> Using e4x for serverside javascript, given a long history with xml to
> object binding love/hate relationships (in many languages), it's all
> leaving me wondering about the future of the browser dom in the case
> where xml becomes a first class object.  I don't really think the dom
> could go away, but would the developers prefer to work with the dom
> or the native xml object in most cases?
>
> I'm trying to get jQuery to work with it a little, so I can use jq on
> the server (as an academic exercise) so you can render views and
> manipulate models before handing them to the client, eg jQuery
> (html..input.(@name=='Peter')) will do what you expect.  There's more
> to it than I expected but It's overall a very sexy way to get at an
> xml serialized data model.
>
> Chris Thatcher
> (cell) 202 340 9685
> [hidden email]
> [hidden email]
>
> On Jan 9, 2008, at 4:09 PM, Jörn Zaefferer wrote:
>
>
>
> > Dave Methvin schrieb:
>
> >>>>   Would it serve the argument for generality of signature to use
> >>>> something like:
>
> >>>> getElementsBy(props:{});
>
> >> A cautionary note about using objects as arguments: Since IE's DOM
> >> implementation isn't native, it doesn't naturally handle any native
> >> Javascript objects. I'm not sure they could implement having the
> >> second argument be a native Javascript RegExp. It also has to work in
> >> VBScript you know.  :)
>
> > Ugh. So much about even IE implementing it...
> >>> That got me thinking quite a bit. Implementing CSS selectors is more
> >>> complicated then just getElementsBySomeStuff. For example, how
> >>> would you
> >>> implement this one?
> >>> input[name=Peter]
>
> >> document.getElementsBySelector("input[name=Peter]")
>
> >> Each browser already has something similar it calls internally to
> >> apply styles, so why shouldn't they expose it to scripts?
> > Considering that the exposed DOM API is already quite messy when
> > dealing
> > with "native" objects, exposing the CSS selector engine could be
> > similar
> > messy. But anyway, thats the right way to go, everything else doesn't
> > get us far enough.
>
> > Of course that method should be on every DOM element, not only on
> > document :-)
>
> > Jörn
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getElementsBy(attribute, value)

Chris Thatcher-3
Cool, I'll check that out today!  Thanks Jörn.

Chris Thatcher
(cell) 202 340 9685



On Jan 10, 2008, at 4:16 AM, Jörn Zaefferer wrote:


Given enough support, e4x would be fine, too.

I've, too, played around with Rhino and jQuery on the serverside. If
you want to take a look at it, its all in SVN:
Basically a Java web application where a servlet/portlet loads Rhino
and executes some scripts. The demo application is my blog (no DB) and
already supports posting comments, using the validation plugin on both
the client- and the serverside.

On Jan 10, 1:06 am, Chris Thatcher <[hidden email]>
wrote:
Just out of curiousity, assuming everyone supported e4x as well as
firefox/rhino do now, would you be happy saying:

var whatiwant = html..input.(@name=='Peter');

Using e4x for serverside javascript, given a long history with xml to
object binding love/hate relationships (in many languages), it's all
leaving me wondering about the future of the browser dom in the case
where xml becomes a first class object.  I don't really think the dom
could go away, but would the developers prefer to work with the dom
or the native xml object in most cases?

I'm trying to get jQuery to work with it a little, so I can use jq on
the server (as an academic exercise) so you can render views and
manipulate models before handing them to the client, eg jQuery
(html..input.(@name=='Peter')) will do what you expect.  There's more
to it than I expected but It's overall a very sexy way to get at an
xml serialized data model.

Chris Thatcher
(cell) 202 340 9685

On Jan 9, 2008, at 4:09 PM, Jörn Zaefferer wrote:



Dave Methvin schrieb:

  Would it serve the argument for generality of signature to use
something like:

getElementsBy(props:{});

A cautionary note about using objects as arguments: Since IE's DOM
implementation isn't native, it doesn't naturally handle any native
Javascript objects. I'm not sure they could implement having the
second argument be a native Javascript RegExp. It also has to work in
VBScript you know.  :)

Ugh. So much about even IE implementing it...
That got me thinking quite a bit. Implementing CSS selectors is more
complicated then just getElementsBySomeStuff. For example, how
would you
implement this one?
input[name=Peter]

document.getElementsBySelector("input[name=Peter]")

Each browser already has something similar it calls internally to
apply styles, so why shouldn't they expose it to scripts?
Considering that the exposed DOM API is already quite messy when
dealing
with "native" objects, exposing the CSS selector engine could be
similar
messy. But anyway, thats the right way to go, everything else doesn't
get us far enough.

Of course that method should be on every DOM element, not only on
document :-)

Jörn



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Loading...