Wouldn't this be better proposed to the DOM working group?
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)
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.
> 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...
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)
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');).
reporter agrees with the developers comments. verified wontfix