Re: [whatwg] How do CSS "object-position" & "object-fit" affect the coordinates used by image <map>/<area>?

On 11/07/2014 09:35 AM, L. David Baron wrote:
> On Thursday 2014-11-06 12:36 -0800, Daniel Holbert wrote:
>> Should these coordinates be relative to... (A) ...the top-left
>> corner of the <img> element itself? OR (B) ...the top-left corner
>> of the rectangle where the image's pixel data actually maps to?
>> (which may be inside or outside the bounds of the <img> element)
>> (Of course, parts outside the <img> won't render and shouldn't
>> receive clicks, but the rect is still there.)
> 
> I also think it should be (B), since the meaning of the
> coordinates in the imagemap shouldn't change as a result of CSS
> styling of the image.

I'm not sure I'd quite go that far (RE "the meaning of coordinates in
the imagemap shouldn't change as a result of CSS styling"). I agree in
an ideal world, but I don't think we can realistically honor that
requirement -- and after thinking about it a bit more, I think I've
shifted my opinion to favor (A). :)


Stepping back a bit -- I guess there are really two separate questions
here:
 (1) What should be the origin of the image-map pixels? (the
upper-left of the <img>, or the upper-left of the displayed image data?)

 (2) How big should an image-map pixel be? (Should it be 1px in the
<img> coordinate space (i.e. as wide as 1px of <img>-width), or should
it be in terms of the image's intrinsic-sizing coordinate-space?)

(I originally was just asking the first question, but it's probably
more sensible to consider both questions together, to fully define the
coordinate space.)

Focusing on question (2) for the moment: it seems to me that the spec
already forces the answer on this question to be "use the <img>'s CSS
pixel sizing", given the historical note about "width" & "height".
For example: given an 8px-by-8px square image, which is scaled up to
200px-by-100px using "width" and "height" properties, the spec
*already* requires that the imagemap coordinates for the center of the
image must be (100px,50px) -- not (4px,4px).   So, this means the
image-map pixels have to be sized according to the <img> element's
CSS-pixel coordinate-space.  I can't see a way to use any other
pixel-sizing behavior while still preserving this result.

So, given that the answer to question (2) is forced to be "use the
<img>'s CSS pixel sizing", I think my feelings on question (1) are
shifting to match that -- it seems like we should be consistent & use
the <img>'s coordinate-space for that, too. (So, I'm now favoring
option (A) from my original email here.)  This has the benefit of
making image-map coordinates reasonably easy to predict & reason
about, in display-space, at least.

If we could redesign imagemap from scratch, I think it'd be ideal to
let specific coordinates reliably map to specific places on the image,
regardless of what CSS is applied to the image.  But that's already
broken by the width/height historical requirement, as noted above; and
given that, I think the simplest thing is to just use the <img>'s
content-box coordinate-space.

Received on Friday, 7 November 2014 18:26:36 UTC