17844 2012-07-18 07:01:32 +0000 Spec img.x/y 2014-07-30 08:40:36 +0000 1 1 1 Unclassified CSS CSSOM View unspecified Other other RESOLVED FIXED P3 normal --- 1 contributor zcorpan annevk glenn ian mike Ms2ger philipj roc zcorpan public-css-bugzilla oldest_to_newest 70158 0 contributor 2012-07-18 07:01:32 +0000 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 ================================================================================ 72658 1 ian 2012-08-23 21:57:43 +0000 ...what do they do? 72659 2 ian 2012-08-23 21:58:55 +0000 (Maybe this should just be in CSSOM?) 77359 3 ian 2012-10-29 23:48:49 +0000 ms2ger: ping 77374 4 Ms2ger 2012-10-30 07:52:31 +0000 Looks like the position relative to the nearest positioned ancestor, in CSS pixels (in Gecko). 77553 5 ian 2012-10-31 19:58:31 +0000 Glenn, do you agree that this belongs more in CSSOM than in HTML? 77584 6 glenn 2012-10-31 21:41:41 +0000 (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}? 77605 7 ian 2012-10-31 22:44:16 +0000 I didn't understand your last comment. 77643 8 glenn 2012-11-01 09:10:40 +0000 (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 77648 9 Ms2ger 2012-11-01 10:39:11 +0000 Did you read the bug? These attributes are required for web compatibility. 77649 10 glenn 2012-11-01 10:48:33 +0000 (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 77715 11 ian 2012-11-01 22:29:51 +0000 Ms2ger: Are they in fact exactly equivalent to offsetLeft/offsetTop? 77735 12 Ms2ger 2012-11-02 08:14:37 +0000 The implementations aren't trivially equivalent, at least not to my untrained eyes. 77740 13 glenn 2012-11-02 08:32:59 +0000 (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 77776 14 ian 2012-11-02 21:17:14 +0000 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. 84872 15 Ms2ger 2013-03-22 18:38:16 +0000 I know nothing about their implementation. 84882 16 roc 2013-03-23 06:00:48 +0000 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. 89948 17 Ms2ger 2013-06-27 11:59:09 +0000 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 95253 18 ian 2013-10-23 20:42:44 +0000 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? 95313 19 zcorpan 2013-10-24 14:51:33 +0000 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.) 109556 20 philipj 2014-07-30 08:40:36 +0000 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