Intent to Deprecate and Remove: Element.prefix setter
Philip Jägenstedt
Primary eng (and PM) emails
Summary
In Element.idl, make attribute DOMString prefix readonly.
Motivation
The attribute is readonly in the spec:
http://dom.spec.whatwg.org/#element
Ad-hoc testing shows that none of Firefox, IE or Presto support the setter:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3042
Compatibility Risk
Setting a readonly attribute is silently ignored, no exceptions will be thrown. Given the lack of support in non-WebKit/Blink browsers, the risk seems low.
Alternative implementation suggestion for web developers
Don't set the attribute, it won't do anything useful.
Usage information from UseCounter
http://www.chromestatus.com/metrics/feature/timeline/popularity/224
The peak value to date is 0.0008%.
Entry on chromestatus.com and/or MDN
None.
Requesting approval to remove too?
Yes, usage is so low that a deprecation period does not seem useful.Eric Seidel
risk of breaking enterprise.
Sounds like we're the odd man out.
LGTM.
Dimitri Glazkov
TAMURA, Kent
DOM Level 2 Core says Node::prefix is mutable.
> Ad-hoc testing shows that none of Firefox, IE or Presto support the setter:
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3042
TAMURA Kent
Software Engineer, Google
Boris Zbarsky
> DOM Level 2 Core says Node::prefix is mutable.
about 3 years ago). We have had no reports of resulting issues.
-Boris
Philip Jägenstedt
> DOM Level 2 Core says Node::prefix is mutable.
>
>
>> Ad-hoc testing shows that none of Firefox, IE or Presto support the
>> setter:
>
>> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3042
>
>
> The test looks incorrect. We should try to set a prefix associated to a
> namespace.
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-NodeNSPrefix
It doesn't say that the prefix needs to be known, but I tried changing
the test to use an element that has a prefix to begin with:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:a="http://example.com/a">
<head><title></title></head>
<body>
<a:element/>
<script>
var elm = document.querySelector("element");
elm.prefix = "b";
alert('prefix: ' + elm.prefix + ', nodeName: ' + elm.nodeName);
</script>
</body>
</html>
With this test, Gecko and Presto alert "prefix: a, nodeName:
a:element" while IE11 alerts "prefix: b, nodeName: b:element".
In other words, the setter does do something in IE11, but not when
prefix is initially null it seems. I haven't reverse engineered
further, but it doesn't exactly match what Blink/WebKit has
implemented.
I checked the history of Presto and it looks like it never supported
the setter, unlike Gecko which apparently once did.
In other words, risk is higher than I suggested, but still seems
pretty reasonable to me.
(I'm going to ignore the 2 LGTMs from Eric and Dimitri and await new feedback.)
Philip
Eric Seidel
we can ever remove support for displayed XML content" bucket. :)
How much does it help us to remove this setting code? Sufficient to
justify the risks to XHTML sites from the IE6 era which depend on this
feature? (or xhr.responseXML content which re-writes prefixes...)
Philip Jägenstedt
https://codereview.chromium.org/298063010
What I'm looking for is the path of least resistance towards having
the spec and all implementations actually agree. Every little
discrepancy is an opportunity for Web authors to write
non-interoperable code, after all. Asking the spec and Gecko to change
would be the alternative path.
I can understand the caution given the failed Attr-related removals.
Since this is an old and once-standard API, maybe a long-ish
deprecation period is in order, despite the low usage?
Philip
Ojan Vafai
Philip Jägenstedt
Thanks Ojan. If there are no objections in a couple of days I'll go with deprecation and revisit when that's been in stable for a few months.
Philip