Intent to Remove Attr.isId, ownerElement, prefix setter & Deprecate Attr.specified

613 views
Skip to first unread message

Dominic Cooney

unread,
Jan 6, 2014, 9:07:54 PM1/6/14
to blink-dev

Primary eng (and PM) emails

domi...@chromium.org


Summary

Let's clean up the DOM Attr interface to better align with DOM4. This takes us part of the way there.


Motivation

Aligning Attrs with the spec (which is good in itself) will enable lots of cleanup and simplification of Blink DOM.


Usage information from UseCounter

I'm removing:


isId (0.00%)

ownerElement (0.00%)

prefix setter (0.00%)


I'm deprecating:


specified (0.04%)


Compatibility Risk

Low, because these properties are rarely used. In terms of some other popular UAs: This basically makes Blink line up with Firefox, except for ownerElement, which is present but deprecated in Firefox. I assume WebKit matches the status quo in Blink. IE10 has everything except isId.


For reference, here's the relevant part of the DOM spec: <http://dom.spec.whatwg.org/#interface-attr>


Row on feature dashboard?

No. This is in the gubbins of ancient DOM inherited from WebKit etc.


Requesting approval to remove too?

Removals noted above. I assume we can't remove Attr.specified at 0.04%. WDYT?


Dominic

Kenneth Rohde Christiansen

unread,
Jan 6, 2014, 10:53:53 PM1/6/14
to Dominic Cooney, blink-dev
lgtm
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.



--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆

TAMURA, Kent

unread,
Jan 7, 2014, 12:58:39 AM1/7/14
to Dominic Cooney, blink-dev
> isId (0.00%)
> ownerElement (0.00%)
> prefix setter (0.00%)
> specified (0.04%)

Does Chrome 31 stable have these counters?

--
TAMURA Kent
Software Engineer, Google


Dominic Cooney

unread,
Jan 7, 2014, 1:43:16 AM1/7/14
to TAMURA, Kent, blink-dev
They're in r159704 from Oct 16. So they're in beta but not stable yet.

Dominic

Ojan Vafai

unread,
Jan 7, 2014, 12:53:20 PM1/7/14
to Dominic Cooney, TAMURA, Kent, blink-dev
I can't seem to find prefix setter in the logs. I see it in the UseCounter.h enum. Do we have an off-by-one in our histogram mapping of enum to histogram name?

Also, what do you mean when you say you want to deprecate specified? Do you just mean logging a warning to the console? If so, can we make sure to log only the first time you use it in a page? Spamming the console is bad.

Dominic Cooney

unread,
Jan 7, 2014, 6:19:02 PM1/7/14
to Ojan Vafai, TAMURA, Kent, blink-dev
On Wed, Jan 8, 2014 at 2:53 AM, Ojan Vafai <oj...@chromium.org> wrote:
I can't seem to find prefix setter in the logs. I see it in the UseCounter.h enum. Do we have an off-by-one in our histogram mapping of enum to histogram name?

The counting code is at Attr.cpp:95. The mapping is in histograms.xml and looks fine to me, with the exception that recently five unrelated counters were added to UseCounter that need to be added to the mapping (four of which are showing up as counts for 219, 220, etc.)

Counts of zero aren't reported. We have 218 counters, but recently only counted 206 of them; and if you drill into more specific versions you'll see fewer and fewer counters (because more buckets have zero counts.)
 
Also, what do you mean when you say you want to deprecate specified? Do you just mean logging a warning to the console? If so, can we make sure to log only the first time you use it in a page? Spamming the console is bad.

I mean the usual "DeprecateAs", counting and logging mechanism. This only logs once per kind of message. If you pop open DevTools and call window.captureEvents(), and then call it again, you'll see the sort of behavior we'd get.

Dominic

Dominic Cooney

unread,
Jan 8, 2014, 7:23:01 PM1/8/14
to Ojan Vafai, TAMURA, Kent, blink-dev
This still needs a couple of LGTMs...

Ojan Vafai

unread,
Jan 9, 2014, 4:30:30 PM1/9/14
to Dominic Cooney, TAMURA, Kent, blink-dev
LGTM

Dimitri Glazkov

unread,
Jan 9, 2014, 4:31:19 PM1/9/14
to Ojan Vafai, Dominic Cooney, TAMURA, Kent, blink-dev
LGTM2

Ehsan Akhgari

unread,
Jan 13, 2014, 11:28:51 AM1/13/14
to Dimitri Glazkov, Ojan Vafai, Dominic Cooney, TAMURA, Kent, blink-dev
FWIW, I removed the Gecko implementation of Attr.ownerElement last week, but based on the UseCounter report here, we're not sure whether we can remove Attr.specified yet.  <https://bugzilla.mozilla.org/show_bug.cgi?id=957430> tracks that.

Cheers,
LGTM2

Alex Russell

unread,
Jan 13, 2014, 8:29:35 PM1/13/14
to Dimitri Glazkov, Ojan Vafai, Dominic Cooney, TAMURA, Kent, blink-dev
LGTM3


LGTM2

Dominic Cooney

unread,
Jan 13, 2014, 8:55:02 PM1/13/14
to Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
Thanks all. With the exception of Attr.prefix setter, which will die today, these are now gone (r164820, r164578.)

Eric Seidel

unread,
Jan 24, 2014, 4:15:09 PM1/24/14
to Dominic Cooney, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
lgtm4

Ehsan Akhgari

unread,
Mar 18, 2014, 6:43:46 PM3/18/14
to Eric Seidel, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
Gecko removed this attribute in Firefox 29 (currently on beta) but we're going to add it back to the platform, please see <https://bugzilla.mozilla.org/show_bug.cgi?id=957431>.

Cheers,

Dominic Cooney

unread,
Mar 18, 2014, 7:50:47 PM3/18/14
to Ehsan Akhgari, Eric Seidel, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
FWIW it looks like Anne just added this back to DOM4, too:


I'm skeptical DOM4 will produce an interesting subset if ownerElement makes the cut, but maybe that's just me.

Dominic

Philip Jägenstedt

unread,
Mar 19, 2014, 4:44:49 AM3/19/14
to Ehsan Akhgari, Eric Seidel, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
On Wed, Mar 19, 2014 at 5:43 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Gecko removed this attribute in Firefox 29 (currently on beta) but we're
> going to add it back to the platform, please see
> <https://bugzilla.mozilla.org/show_bug.cgi?id=957431>.

The reason given in that bug is
<http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0107.html>,
i.e. that its convenient with XPath. I don't think that's very
compelling unless it's also required for Web compat.

In the best of worlds, Attr could be amputated enough to map to the
internal representation of attributes. In Blink/WebKit, that's
Attribute, which is just a name and a value. It doesn't include a
pointer to the owner Element.

I'm not convinced that we live in the best of worlds, but it would be
nice to find out...

Philip

Anne van Kesteren

unread,
Mar 19, 2014, 6:18:38 AM3/19/14
to Dominic Cooney, Ehsan Akhgari, Eric Seidel, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
On Tue, Mar 18, 2014 at 11:50 PM, Dominic Cooney <domi...@chromium.org> wrote:
> FWIW it looks like Anne just added this back to DOM4, too:

Just DOM, please.


> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25086>
> <https://github.com/whatwg/dom/commit/db19f1c8de8fb78e2ef1218b45a7c967b6a5822d>
>
> I'm skeptical DOM4 will produce an interesting subset if ownerElement makes
> the cut, but maybe that's just me.

I backed that change out (i.e. DOM no longer has
Attr.prototype.ownerElement). It would be interesting to find out if
Attr.prototype.value can be made readonly first. What do you guys
think?


--
http://annevankesteren.nl/

Philip Jägenstedt

unread,
Mar 19, 2014, 6:52:02 AM3/19/14
to Anne van Kesteren, Dominic Cooney, Ehsan Akhgari, Eric Seidel, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
Given that Document.createAttribute
<http://www.chromestatus.com/metrics/feature/timeline/popularity/111>
is around 0.2% it seems likely that setting Attr.value is at least
that high, but finding out for sure seems like a good idea:

https://codereview.chromium.org/203193010/

Philip

Eric Seidel

unread,
Mar 21, 2014, 1:35:32 PM3/21/14
to Anne van Kesteren, Dominic Cooney, Ehsan Akhgari, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
Anne:

I believe backing out this change was a mistake. Currently Chrome is
still planning to ship without Attr.ownerElement in M34 (stable early
april).

When we removed Attr.ownerElement, Dominic cited usage as 0.00%. I
went to look at the data again yesterday to confirm. I queried two
weeks of UseCounter data from 3/2/14-3/16/14 on Chrome Stable Windows
M33, and found that only 55 of every 1,000,000 loads used this
feature. Thats 0.000055 or 0.0055% of reported pageviews. If other
browsers have data to suggest higher usage, I would be very interested
to see it.

Backwards compatibility is a huge feature of the web platform, but we
also all have limited resources through which to maintain this
platform. Developers and users have voted with their feet [1] -- they
do not like Attr.ownerElement. We shouldn't penalize the 99.9945% of
views which do not use this feature with a worse Chrome by spending
resources on this long deprecated (2011, Gecko 7! [2]) feature.

You were right in the DOM spec that we should continue to work towards
removing Attr nodes from the platform. They needlessly complicate
lots of core DOM methods and add security risk [3]. Lets not back
away from that goal.

1. http://en.wikipedia.org/wiki/Foot_voting
2. https://developer.mozilla.org/en-US/docs/Web/API/Attr
3. https://code.google.com/p/chromium/issues/list?can=1&q=Attr+Type%3DBug-Security

Eric Seidel

unread,
Mar 21, 2014, 2:09:44 PM3/21/14
to Anne van Kesteren, Dominic Cooney, Ehsan Akhgari, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
I see. I realize now I misread your email. You re-removed
Attr.ownerElement with the spec:
https://github.com/whatwg/dom/commit/8b6168643a32d819758567d6f5fae6bd991783ed

So at least it seems you and I are in agreement? :)

Ehsan Akhgari

unread,
Mar 21, 2014, 4:10:54 PM3/21/14
to Eric Seidel, Anne van Kesteren, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
To close the loop here on the Gecko side, we decided that removing this attribute was a mistake.  I just backed out the removal patch from our trunk tree and requested the patch to be approved for our aurora and beta trees, which means that Gecko will not ship the removal of this API.

Cheers,

Ehsan Akhgari

unread,
Mar 21, 2014, 4:23:35 PM3/21/14
to Eric Seidel, Anne van Kesteren, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
On Fri, Mar 21, 2014 at 4:10 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
To close the loop here on the Gecko side, we decided that removing this attribute was a mistake.  I just backed out the removal patch from our trunk tree and requested the patch to be approved for our aurora and beta trees, which means that Gecko will not ship the removal of this API.

Just to be more clear, this is about Attr.ownerElement.

Cheers,
Ehsan

Eric Seidel

unread,
Mar 21, 2014, 4:36:57 PM3/21/14
to Ehsan Akhgari, Anne van Kesteren, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
Thank you. I've replied on your bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=957431

Anne van Kesteren

unread,
Mar 23, 2014, 3:48:55 PM3/23/14
to Eric Seidel, Dominic Cooney, Ehsan Akhgari, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
On Fri, Mar 21, 2014 at 6:09 PM, Eric Seidel <ese...@google.com> wrote:
> I see. I realize now I misread your email. You re-removed
> Attr.ownerElement with the spec:
> https://github.com/whatwg/dom/commit/8b6168643a32d819758567d6f5fae6bd991783ed
>
> So at least it seems you and I are in agreement? :)

Yes, in particular, if we can find a way to obsolete
Attr.prototype.value's setter I don't see any reason to revive
Attr.prototype.ownerElement. If we have to keep that setter, we might
as well expose the relationship between Attr and Element to script I
think, but I'm flexible.


--
http://annevankesteren.nl/

Eric Seidel

unread,
Mar 24, 2014, 5:57:17 PM3/24/14
to Anne van Kesteren, Dominic Cooney, Ehsan Akhgari, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
We'll have numbers for Attr.prototype.value's setter once M35 ships to stable:
http://blink.lc/blink/commit/?id=8d803f2925c11f7996fb8b2c98bf249fba9f5b10

We obviously still have to keep the ownerElement storage for now,
we're just not exposing it to the web any longer as of Chrome M34.
That may break as many as 55 of every 1,000,000 Chrome page loads, at
the cost of bringing us closer to removing this feature.

We're also counting XPath usage as of a week ago and should also have
good numbers as of M35 stable.

Avi Drissman

unread,
Mar 24, 2014, 6:04:12 PM3/24/14
to Eric Seidel, Anne van Kesteren, Dominic Cooney, Ehsan Akhgari, Alex Russell, Dimitri Glazkov, Ojan Vafai, TAMURA, Kent, blink-dev
FYI, xpath is used internally to Chrome separate from being exposed to the web. In a week when we kill automation, I will remove its internal use and that will give you the option to remove it if appropriate.

Avi

Mike Sherov

unread,
Mar 24, 2014, 8:48:07 PM3/24/14
to Avi Drissman, Anne van Kesteren, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Eric Seidel, Ehsan Akhgari
What is the replacement then for Attr.specified? Also, will the property be outright removed and detectable via an undefined check? Currently, jQuery uses this via getAttributeNode in its tabindex hook and I'd like to prepare future versions for this change.
Mike


Eric Seidel

unread,
Mar 24, 2014, 10:36:27 PM3/24/14
to Mike Sherov, Avi Drissman, Anne van Kesteren, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari

Eric Seidel

unread,
Mar 24, 2014, 10:38:25 PM3/24/14
to Mike Sherov, Avi Drissman, Anne van Kesteren, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari

Anne van Kesteren

unread,
Mar 25, 2014, 6:04:36 AM3/25/14
to Mike Sherov, Avi Drissman, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Eric Seidel, Ehsan Akhgari
On Tue, Mar 25, 2014 at 12:48 AM, Mike Sherov <mike....@gmail.com> wrote:
> What is the replacement then for Attr.specified? Also, will the property be
> outright removed and detectable via an undefined check? Currently, jQuery
> uses this via getAttributeNode in its tabindex hook and I'd like to prepare
> future versions for this change.

What do you think Attr.prototype.specified does? I don't understand
why jQuery uses this. jQuery using it prevents us from removing it
though :-(


--
http://annevankesteren.nl/

Erik Arvidsson

unread,
Mar 25, 2014, 9:14:25 AM3/25/14
to Anne van Kesteren, blink-dev, Mike Sherov, Eric Seidel, Alex Russell, Dominic Cooney, Ojan Vafai, Dimitri Glazkov, Kent TAMURA, Ehsan Akhgari, Avi Drissman

.specified was needed in old IE where the attributes collection contained all the properties/webidl attributes. hasAttribute behaved the same way. .specified was the only way to detect if an attribute was present or not.

Mathias Bynens

unread,
Mar 25, 2014, 9:15:54 AM3/25/14
to Eric Seidel, Mike Sherov, Avi Drissman, Anne van Kesteren, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari
On 25 Mar 2014, at 03:38, Eric Seidel <ese...@google.com> wrote:

> You can detect if attributes are removed by asking
> node.hasAttribute("foo"). They'll return "false" if they're removed
> while "true" if they're just empty.

I suppose jQuery uses `Attr#specified` for old versions of Internet Explorer, where `element.attributes` returns all possible attributes, and you must check `.specified` to find out which ones were actually specified. `hasAttribute` is not supported in those IEs.

@Mike, can you confirm or deny if jQuery relies on `specified` even in modern browsers?

Mike Sherov

unread,
Mar 26, 2014, 9:51:18 AM3/26/14
to Mathias Bynens, Eric Seidel, Avi Drissman, Anne van Kesteren, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari
exactly right. And at the time, .specified looked like a stable thing that was present in all browsers. jQuery carries around a lot of hacks and feature detects, and we're eager to remove them when they aren't necessary, as was the thought with .specified.


@Mike, can you confirm or deny if jQuery relies on `specified` even in modern browsers?


jQuery 2.x: no reliance on .specified, relies on elem.hasAttribute instead.
jQuey 1.x latest: no reliance on .specified, relies on sizzle's implementation which only uses .specified in <IE9
jQuery 1.4.X -> 1.9.X: relies on .specified for the tabindex hook.
jQuery < 1.3.X: no reliance on specified

The only issue is when a user calls $(elem).prop('tabindex') or .attr('tabindex'), in which if Attr#specified is false or Elem#getAttributeNode returns undefined, jquery will fudge a tabindex of 0 if the element is focusable or clickable, otherwise return undefined. This likely does not "break the web". 

There are a few courses of action:
1. have .specified always return true like Gecko. jQuery will then "do the right thing".
2. remove .specified and then jQuery will mostly do the right thing as described above, and we'll tell users to upgrade as a cantfix if they complain, or provide a code snippet that will patch tabindex to do the right thing... jQuery has a hook for .attr() and .prop() that makes it easy to "fix" this.

I'm in favor of #2. Honestly, the use counter numbers for .specified should guide you more than the fact that it's in a jQuery codepath. The 0.004% usage indicates just how likely someone is to hit that codepath. The answer is "unlikely", and we have a strategy with which to mitigate its effects.



--
Mike Sherov

Anne van Kesteren

unread,
Mar 26, 2014, 9:56:08 AM3/26/14
to Mike Sherov, Mathias Bynens, Eric Seidel, Avi Drissman, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari
On Wed, Mar 26, 2014 at 1:51 PM, Mike Sherov <mike....@gmail.com> wrote:
> I'm in favor of #2. Honestly, the use counter numbers for .specified should
> guide you more than the fact that it's in a jQuery codepath. The 0.004%
> usage indicates just how likely someone is to hit that codepath. The answer
> is "unlikely", and we have a strategy with which to mitigate its effects.

It's a lot higher than that unfortunately, which is why we added it to
the DOM as a useless attribute that always returns true. See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25001 for history.


--
http://annevankesteren.nl/

Mike Sherov

unread,
Mar 26, 2014, 2:17:18 PM3/26/14
to Anne van Kesteren, Mathias Bynens, Eric Seidel, Avi Drissman, Ojan Vafai, blink-dev, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari
My mistake, I was reading the original intent, which says: I'm deprecating: specified (0.04%).
 


--
http://annevankesteren.nl/



--
Mike Sherov

bed...@technicalpursuit.com

unread,
Apr 10, 2014, 4:49:41 PM4/10/14
to blin...@chromium.org, Anne van Kesteren, Mathias Bynens, Eric Seidel, Avi Drissman, Ojan Vafai, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari
Removal of 'Attribute.ownerElement' badly broke some code that I was relying on. I petitioned the W3C folks to add it back in and they did so:


My rationale is stated on that bug for why ownerElement is useful (TL;DR; The fact that attributes are no longer nodes is irrelevant to the fact that they do, indeed, have an owning Element and it is useful to know what that is).

I was able to patch my current code by executing an XPath with the Attribute node as the context and using '..', but this is hacky.

Cheers,

- Bill

Ian Hickson

unread,
Apr 10, 2014, 4:54:06 PM4/10/14
to bed...@technicalpursuit.com, blin...@chromium.org, Anne van Kesteren, Mathias Bynens, Eric Seidel, Avi Drissman, Ojan Vafai, Kent TAMURA, Dominic Cooney, Alex Russell, Dimitri Glazkov, Ehsan Akhgari
On Thu, 10 Apr 2014, bed...@technicalpursuit.com wrote:
>
> Removal of 'Attribute.ownerElement' badly broke some code that I was
> relying on. I petitioned the W3C folks to add it back in and they did so:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25021

The relevant spec here is the WHATWG DOM spec, not the W3C fork:

http://dom.spec.whatwg.org/

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

johnso...@gmail.com

unread,
Sep 5, 2014, 1:34:40 PM9/5/14
to blin...@chromium.org, bed...@technicalpursuit.com, ann...@annevk.nl, math...@opera.com, ese...@google.com, a...@chromium.org, oj...@chromium.org, tk...@chromium.org, domi...@chromium.org, sligh...@google.com, dgla...@chromium.org, ehsan....@gmail.com
I am currently implementing an algorithm that traverses the DOM tree and detects the differences of two DOM trees. *1

The data model of the algorithm treats attribute nodes as "child nodes" of element nodes.

It is a bottom-up algorithm so that I need to access the ownerElement of attribute nodes; thus ownerElement is essential to me.

Furthermore, in the latest whatwg spec (4 September 2014) the ownerElement is still there.

[*1] the algorithm is the combination of Valiente's bottom-up algorithm and diffx.
Reply all
Reply to author
Forward
0 new messages