This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 16842 as part of operation convergence. Originally filed: 2012-04-24 18:12:00 +0000 Original reporter: Ms2ger <Ms2ger@gmail.com> ================================================================================ #0 Ms2ger 2012-04-24 18:12:56 +0000 -------------------------------------------------------------------------------- I tried removing those attributes from Gecko, but failed. See https://bugzilla.mozilla.org/show_bug.cgi?id=587021 https://bugzilla.mozilla.org/show_bug.cgi?id=731832 ================================================================================
...what do they do?
(Maybe this should just be in CSSOM?)
ms2ger: ping
Looks like the position relative to the nearest positioned ancestor, in CSS pixels (in Gecko).
Glenn, do you agree that this belongs more in CSSOM than in HTML?
(In reply to comment #5) > Glenn, do you agree that this belongs more in CSSOM than in HTML? The greater question for me is whether it should be in either HTML or CSSOM... Is this is basically shorthand for HTMLImageElement.style.{top,left}?
I didn't understand your last comment.
(In reply to comment #6) > (In reply to comment #5) > > Glenn, do you agree that this belongs more in CSSOM than in HTML? > > The greater question for me is whether it should be in either HTML or > CSSOM... I'm asking why we should standardize this extension when it appears to be superfluous (with offset{Left,Top} -- see below). > Is this is basically shorthand for HTMLImageElement.style.{top,left}? I had meant getComputedStyle(img).{left,top}, but I see that HTMLElement.offset{Left,Top} seems to be the correct mapping, at least according to [1][2]. [1] http://hg.csswg.org/test/raw-file/tip/contributors/gadams/incoming/cssom-view/htmlimagelement-equivalence-xy-absolute.xht [2] http://hg.csswg.org/test/raw-file/tip/contributors/gadams/incoming/cssom-view/htmlimagelement-equivalence-xy-static.xht
Did you read the bug? These attributes are required for web compatibility.
(In reply to comment #9) > Did you read the bug? These attributes are required for web compatibility. yes I did; the mere existence of such usage does not mean these properties should be standardized, particularly when there appears to be an existing standard defined mechanism that already supports this function (unless offset{Left,Top} are somehow different behaviorally speaking) also, though I did test WK/OP/FF, i haven't checked IE to see if they are supported there; [FF also failed two tests] p.s. i suppose it would be possible to document x/y as obsoleted non-conforming features, such as is done in [1]; if this were done, then my preference would be to specify in HTML spec, and refer there to the normative CSSOM View properties (offset{Left,Top}). [1] http://dev.w3.org/html5/spec/single-page.html#non-conforming-features
Ms2ger: Are they in fact exactly equivalent to offsetLeft/offsetTop?
The implementations aren't trivially equivalent, at least not to my untrained eyes.
(In reply to comment #12) > The implementations aren't trivially equivalent, at least not to my > untrained eyes. to show they are different, we need a test that shows a difference in actual values, independent of the implementation; if they are different, that may be a bug as opposed to the intended behavior at first order, at least testing on 3 engines, they appear to be the same for both static and absolute positioned images
Ms2ger: Do you have a test showing how they're different? If they're the same, then it makes sense to define them in the "obsolete APIs" part of the HTML spec, deferring to the equivalents in CSSOM.
I know nothing about their implementation.
I don't really know this code but the implementation looks like x/y are the offset of the <img> border-box top-left to the top-left of the border-box of the nearest ancestor (excluding the <img>) that's positioned or not overflow:visible, ignoring transforms. (In reply to comment #10) > yes I did; the mere existence of such usage does not mean these properties > should be standardized It does, actually, unless we can find a way to eliminate the usage or treat it as insignificant.
And we accidentally removed them in Fx 20-21, and people started to rely on that too: https://bugzilla.mozilla.org/show_bug.cgi?id=887660
Comment 16 suggests this should be a CSSOM issue. zcorpan, do you want to take this, or if not, can you provide me with a hook to define this?
https://dvcs.w3.org/hg/csswg/rev/a65682fccc9b In Blink it appears to always be relative to the initial containing block, position and overflow on ancestors doesn't matter. This seems simpler, so unless Gecko's behavior better matches what Web content expects I think simpler wins. (In Presto position matters but overflow doesn't. IE10 doesn't support x/y.)
There's an ongoing blink-dev thread about HTMLImageElement.x/y: https://groups.google.com/a/chromium.org/d/msg/blink-dev/zpLuYu8tmdA/uA_7TQSQDzQJ