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

lgtm
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].



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

lgtm4

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

Just DOM, please.
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/

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

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

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? :)

Thank you. I've replied on your bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=957431

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/

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.

Attr.specified always returns true in both Gecko and Blink:
https://developer.mozilla.org/en-US/docs/Web/API/Attr
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Attr.h&q=Attr.h&sq=package:chromium&l=48

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.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.idl&q=Element.idl&sq=package:chromium&type=cs&l=48
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.cpp&sq=package:chromium&type=cs&l=2166&rcl=1395670162

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/

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?

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/

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. `._.-(,_..'--(,_..'`-.;.'