Closed Bug 114538 Opened 23 years ago Closed 15 years ago

nsIContent needs a HasAttrValue method

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: hewitt, Unassigned)

Details

Opened this out of the discussion in bug 113562.  We need to implement
HasAttrValue(string attr, string value) on nsIContent so that we can check the
existence of an attr/value pair without having to do an extra string copy via
getAttribute() == "foo".
whoops, meant to assign to me when I filed it.
Assignee: jst → hewitt
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
sicking, what do you think?  This could take a fast codepath for string/nsIAtom
values (just compare) and ToString() the more complex value types....

This sounds like something we should do yeah. Though we probably need to add it
to more interfaces so that scripts can take advantage of it.
Assignee: hewitt → general
Status: ASSIGNED → NEW
QA Contact: gerardok → ian
Target Milestone: mozilla1.2alpha → ---
I'm not convinced we should clutter our scriptable APIs with this. If there are
significant performance savings from this, sure, but I seriously doubt there is.
Agreed, but the same goes for nsIContent, we shouldn't add anything there unless
it really improves performance. Though it is probably more likly that it does
there since then we could use it in the stylesystem.
To some degree the same goes for nsIContent, true, but not as much. Any changes
to nsIDOM* interfaces can potentially break existing scripts by adding to the JS
namespace that scripts run in, the same is not true for nsIContent. So if there
are performance *or* codesize benefits to adding more to nsIContent, I have
little problems with that, but the same can't be said for nsIDOM* :-)
Assignee: general → nobody
QA Contact: ian → general
This is fixed, IMO. nsIContent has AttrValueIs().
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.