This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21522 - AttrExodus: Restore hasAttributes()
Summary: AttrExodus: Restore hasAttributes()
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-02 14:45 UTC by Aryeh Gregor
Modified: 2014-08-18 13:31 UTC (History)
5 users (show)

See Also:

Attachments

Description Aryeh Gregor 2013-04-02 14:45:45 UTC 
Either on Node or on Element -- probably on Element for consistency, since .attributes is there (although I don't get why .attributes was moved from Node).

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=849661
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=113580

Do we have any data suggesting pages don't use this?  There was one occurrence in Gecko's codebase, and also in <https://developer.mozilla.org/en-US/docs/JXON>.

I don't see the value in getting rid of it.  Testing "el.attributes" does the same thing, but only if you actually have an Element, which is a dicey assumption in JavaScript -- "el.hasAttributes()" will throw if you don't really have an Element, which some authors might well prefer.

Are there any objections to restoring this to the spec?
Comment 1 Anne 2013-04-02 14:57:02 UTC 
.attributes was moved because it only returned something useful on Element.

.hasAttributes() was removed because you can check .attributes.length on Element.

The perceived value of moving things around was to make the DOM more JavaScript-y and less Java-prevent-casting-at-all-cost. If sicking wants this restored however I'm happy to put it back in.
Comment 2 Aryeh Gregor 2013-04-02 15:36:18 UTC 
Granted, now that you point it out, .attributes on non-Elements is really useless.  I'm not so sure about .hasAttributes(); I suppose moving it to Element forces things to be more explicit.  Anyway, bz WONTFIXed the Gecko bug, so I doubt anyone will actually remove this from implementations.
Comment 3 Anne 2013-04-15 09:46:18 UTC 
So WebKit/Blink just have it on Element. bz does not mind trying to remove it if we follow procedure as done elsewhere.

Several people have requested to keep it removed as it's useless.

I'm mostly *shrug* on this issue.
Comment 4 Anne 2013-09-06 15:23:06 UTC 
Arv, do you think we can remove hasAttributes() entirely or should we keep it on Element?
Comment 5 Erik Arvidsson 2013-09-06 15:29:13 UTC 
I'll add usage stats for this one too.
Comment 6 Anne 2014-05-22 13:53:45 UTC 
Erik, what can we conclude from http://www.chromestatus.com/metrics/feature/timeline/popularity/142 WONTFIX this bug?
Comment 7 Erik Arvidsson 2014-05-22 21:02:30 UTC 
(In reply to Anne from comment #6)
> Erik, what can we conclude from
> http://www.chromestatus.com/metrics/feature/timeline/popularity/142 WONTFIX
> this bug?

That our metrics had a hiccup?

We have previously said that the cuttof is somewhere around 0.02% and this is much lower than that.

At this point I'm not sure we care much about removing hasAttribute so if the spec adds it back I think we will just let this one rest.
Comment 8 Anne 2014-05-22 21:05:59 UTC 
I meant the opposite. Keep it out of the specification. Hmm.
Comment 9 Anne 2014-08-18 11:26:56 UTC 
Philip, care to remove hasAttributes() from Blink?
Comment 10 Philip Jägenstedt 2014-08-18 12:27:30 UTC 
The usage is fairly low, but it's also very low cost to support:

inline bool Element::hasAttributes() const
{
    return !attributes().isEmpty();
}

I do love removing things, but in this case I think spec'ing it might be better. Note that Node.hasChildNodes() is equally silly.