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

On Fri, 07 Nov 2014 19:26:12 +0100, Daniel Holbert <dholbert@mozilla.com>  
wrote:

> 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.

I agree with this analysis. Also note that image maps has not gained any  
new features or otherwise improved apart from better interop. For instance  
other shapes that are possible in canvas are not supported by image maps.  
It does not do anything differently for <picture>/srcset. It's considered  
a legacy feature.

Maybe inline SVG is a better choice for authors today?

-- 
Simon Pieters
Opera Software

Received on Monday, 10 November 2014 09:57:24 UTC