Last Comment Bug 92362 - [RFE] Include document.getElementsByAttrMatch()
: [RFE] Include document.getElementsByAttrMatch()
Status: VERIFIED WONTFIX
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: x86 Windows 95
: -- enhancement (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-25 19:09 PDT by Alex Vincent [:WeirdAl]
Modified: 2008-07-31 02:29 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Alex Vincent [:WeirdAl] 2001-07-25 19:09:06 PDT
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 
code:

<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") {
		throw DOM_SYNTAX_ERR
		}
// 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 Boris Zbarsky [:bz] (TPAC) 2001-07-25 21:41:41 PDT
Wouldn't this be better proposed to the DOM working group?
Comment 2 Alex Vincent [:WeirdAl] 2001-07-26 08:00:06 PDT
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 
specs.

Thanks for making me think, though... 8)
Comment 3 Alex Vincent [:WeirdAl] 2001-07-26 09:06:23 PDT
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
context.

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

Sounds like they kicked it back here.
Comment 4 Boris Zbarsky [:bz] (TPAC) 2001-07-26 11:19:16 PDT
> 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...
Comment 5 Alex Vincent [:WeirdAl] 2001-07-26 12:03:42 PDT
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 Johnny Stenback (:jst, jst@mozilla.com) 2001-07-27 00:04:13 PDT
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');).
Comment 7 Sivakiran Tummala 2001-10-12 12:54:45 PDT
reporter agrees with the developers comments. verified wontfix

Note You need to log in before you can comment on or make changes to this bug.