Intent to Deprecate: HTMLImageElement.x/y

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the HTMLImageElement.x/y IDL attributes.

Motivation

These attributes are non-standard and not interoperably implemented.

Here's a demo comparing img.x/y to some other APIs:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3090

This is pretty simple, but Gecko and Blink still disagree.

Blink's x/y seem similar to getBoundingClientRect().left/top, except that they just return 0 if there's no renderer (try removing the initial offsetLeft access) and don't take zoom into consideration (try zooming and reloading). There may be additional quirks.

Gecko's x/y seem similar to offsetLeft/offsetTop and don't have the particular problems that Blink has, but there may be others I haven't found.

IE11 does not support the x/y IDL attributes at all.

Usage is low enough that removal is worth a shot before going the spec route, which would certainly require implementation changes as well.

Note that Firefox tried removal in 2012 and failed:

https://bugzilla.mozilla.org/show_bug.cgi?id=587021

However, usage may have shifted since then, or may be in engine-specific code paths.

Compatibility Risk

Medium. Usage is just below 0.03% and this API has been around for a long time.

Alternative implementation suggestion for web developers

Use getBoundingClientRect() for document coordinates and offsetLeft/offsetTop for containing block coordinates.

Usage information from UseCounter

http://www.chromestatus.com/metrics/feature/timeline/popularity/396

http://www.chromestatus.com/metrics/feature/timeline/popularity/397

Available in M36. Highest measurement yet is 0.0242%.

Entry on chromestatus.com, crbug.com, or MDN

None.

Requesting approval to remove too?

No. Deprecate for at least one release cycle.

[Elliott Sprehn]

On Tue, Jul 29, 2014 at 3:17 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the HTMLImageElement.x/y IDL attributes.

Motivation

These attributes are non-standard and not interoperably implemented.

Here's a demo comparing img.x/y to some other APIs:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3090

This is pretty simple, but Gecko and Blink still disagree.

Blink's x/y seem similar to getBoundingClientRect().left/top, except that they just return 0 if there's no renderer (try removing the initial offsetLeft access) and don't take zoom into consideration (try zooming and reloading). There may be additional quirks.

We fixed that recently, now x() and y() both cause a layout.

- E 

[Philip Jägenstedt]

Right you are, I was testing in a stable browser.

Philip

[Ian Hickson]

On Wed, 30 Jul 2014, Philip Jägenstedt wrote:
>
> These attributes are non-standard and not interoperably implemented.

> [...]

> Usage is low enough that removal is worth a shot before going the spec
> route, which would certainly require implementation changes as well.

They are specced, actually:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17844
http://dev.w3.org/csswg/cssom-view/#excensions-to-the-htmlimageelement-interface

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

[Philip Jägenstedt]

On Wed, Jul 30, 2014 at 4:29 AM, Ian Hickson <i...@hixie.ch> wrote:
>
> On Wed, 30 Jul 2014, Philip Jägenstedt wrote:
> >
> > These attributes are non-standard and not interoperably implemented.
> > [...]
> > Usage is low enough that removal is worth a shot before going the spec
> > route, which would certainly require implementation changes as well.
>
> They are specced, actually:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17844
> http://dev.w3.org/csswg/cssom-view/#excensions-to-the-htmlimageelement-interface

Ah, thanks! It's under "Extensions" in Blink's HTMLImageElement.idl
and I didn't think to look in CSSOM.

The spec seems to require document coordinates ignoring transforms,
which doesn't match Gecko or Blink/WebKit.

Gecko's x/y seem to mostly match offsetLeft/offsetTop, though they're
not implemented as aliases. Therefore, I would suggest adding use
counters to see how often x/y, when read, do not match
offsetLeft/offsetRight. With luck, x/y could be made simple aliases
and presumably everyone would be happy.

Does that sound like a plan?

Philip

[Philip Jägenstedt]

After looking a bit closer at the history I no longer think that's
worthwhile. The two attributes appeared first in Netscape 4, and the
implementations in both Gecko and WebKit were motivated by NS4 compat.

Gecko:
https://bugzilla.mozilla.org/show_bug.cgi?id=98292
https://bugzilla.mozilla.org/show_bug.cgi?id=116843
https://bugzilla.mozilla.org/show_bug.cgi?id=587021
https://bugzilla.mozilla.org/show_bug.cgi?id=731832
https://bugzilla.mozilla.org/show_bug.cgi?id=887660

WebKit:
http://trac.webkit.org/changeset/2905

Mentioned sites that I could still find were:
http://web.archive.org/web/20021202080711/http://online.wsj.com/public/us/
http://web.archive.org/web/20120107051245/http://www.crownhill.com/

Both sites have changed radically since then and neither of the
archive.org copies work in IE11. Both also break when zooming in
Chrome.

It won't work to alias x/y to offsetLeft/offsetTop for either site,
but implementing them as getBoundingClientRect().left/top does keep
these sites working.

The new plan is to fix the obviously-broken zoom behavior and then
determine if getBoundingClientRect().left/top would be equivalent
enough.

Philip