Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[RFE] Include document.getElementsByAttrMatch()




DOM: Core & HTML
16 years ago
9 years ago


(Reporter: WeirdAl, Assigned: jst)


Windows 95

Firefox Tracking Flags

(Not tracked)




16 years ago
A common practice of HTML documents is using the same name or id attribute 
value across multiple elements to create arrays for JavaScript or server-side 

<input name="myInput[]" />
<input name="myInput[]" />

XML 1.0 and XHTML 1.0 disallow this, by the Document Type Definition.  So 
there's no direct way to grab a specifically limited set of the desired 
elements without coding in a special function.  In any case, I would love the 
ability native in Mozilla's DOM to find elements by attribute names in general, 
matched to a regular expression.  This would allow us to select a group of 
elements much more specifically than DOM Level 1 (and 2) methods allow.

I'm not saying there's no easy workaround if you decide to mark this bug 
INVALID.  Here is a JavaScript function which may closely approximate what 
would be needed to enable this.

document.getElementsByAttrMatch = function(attrName, attrMatch) {
	attrName = attrName.valueOf()
	attrMatch = attrMatch.valueOf()
// in case the user passes String() and RegExp() objects

	if ((typeof attrName != "string")||(typeof attrMatch != "regexp") {
// arguments must be correct

	var response = new NodeList(), elementList = 
document.getElementsByTagName("*"), loop=0
// set up basic parameters

	for (loop=0; loop < elist.length; loop++) {
		if (attrMatch.test(elementList[loop].getAttribute(attrName))) {
// if the attribute named has its value match the regular expression to check 
for, add it to the array
			response[response.length] = elementList[loop]
	return response

As an extra, since we like to get elements by id as well, I would suggest this:

document.getElementsByIdMatch = function(idMatch) {
	return document.getElementsByAttrMatch('id', idMatch)

I regret I'm not able to immediately provide namespace-enabled  equivalents to 
these functions.  Opinions?

Comment 1

16 years ago
Wouldn't this be better proposed to the DOM working group?

Comment 2

16 years ago
I'm not sure.  I'm for standardization, but you will recall how the DOM WG had 
to define a DOMString interface, just to hold strings?  Regular expressions are 
hugely complex.  If the DOM WG had to implement a DOMRegularExpression 
interface, what would that do to the specs, or for that matter, to browsers 
trying to follow them?  

Regular expressions are not a laughing matter for their sheer complexity.  How 
many different implementations are there of regular expressions?  It's the 
minor differences which could make things difficult.  XML Schemas RE's differ 
from Perl RE's a little.  ECMAScript RE's differ from Perl RE's a little.  PHP 
supports two different kinds of regular expression.

It might be simpler to start by adding an ECMAScript-based regular expression 
system, while simultaneously encouraging the DOM WG to respond to this issue.  
Which I think I will write them an e-mail about right now, including my 
original post to this thread, and referring them to this bug.

To my knowledge, DOM allows us to add extra functions above and beyond the DOM 

Thanks for making me think, though... 8)

Comment 3

16 years ago
Rather interesting reply they gave me:

This can be done today in a Level 2 DOM, by writing an appropriate
NodeFilter and using either NodeIterator or TreeWalker... which is actually
a very general solution, and probably makes a lot more sense than adding a
bunch of individual methods matching on various aspects of the node and its

If that doesn't address your needs, tell us why not ...
Joe Kesselman  / IBM Research

Sounds like they kicked it back here.

Comment 4

16 years ago
> It might be simpler to start by adding an ECMAScript-based regular expression
> system,

er... Mozilla uses ECMAScript to interface with the DOM.  So we _do_ have ECMA
regular expressions available.

> Sounds like they kicked it back here.

No, sounds like they told you how to create a library function that will do what
you want... there is really no good reason to have this be part of the browser's
DOM since it can just be implemented by a developer who needs it.

Setting status to new, but recommending wontfix...
Ever confirmed: true

Comment 5

16 years ago
Looks like this bug is invalid anyway.  I looked in DOM-2 Core, and they told 
me I could do it by DOM-2 Traversal.

Does the Bugzilla cafeteria serve crow?  Because I think I need a plate of it 
(don't forget the Heinz 57 sauce)

Comment 6

16 years ago
Yeah, this is a WONTFIX, there will be nice ways of doing things like this once
we support document traversal and XPath (i.e. document.selectNodes('xpath expr');).
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 7

16 years ago
reporter agrees with the developers comments. verified wontfix


9 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.