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 dholb...@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
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
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 tend to think B is the correct answer, but I'm not 100% sure, and I'd like a sanity-check. 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. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron dba...@dbaron.org wrote: 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. Note that as Daniel pointed out it for legacy reasons already does. img height/width and CSS height/width are the same. Not perpetuating that further makes sense though. -- https://annevankesteren.nl/
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.
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On 11/07/2014 09:42 AM, Anne van Kesteren wrote: On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron dba...@dbaron.org wrote: 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. Note that as Daniel pointed out it for legacy reasons already does. img height/width and CSS height/width are the same. Not perpetuating that further makes sense though. I'm actually not so sure I agree (about not perpetuating that further). The width height legacy requirement basically ends up meaning that imagemap coordinates use the img's content-box as their coordinate space. In a More Perfect World, it'd arguably be more useful for specific imagemap coordinates to reliably to map to specific places in the image data (regardless of height/width), but it seems we've already lost that possibility. So, for now, we just have one useful assumption that we can make about these coordinates: they use the img's content-box as their coordinate space. I don't think we should let object-fit/object-position break that assumption, or else we risk making these coordinates completely incomprehensible / unusable. So, I'm now favoring option (A) from my original email. (See my reply to David for more thoughts on this.) ~Daniel
[whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
Hi whatwg, I'm working on implementing the object-fit object-position CSS properties in Gecko (which allow authors to adjust the scaling/positioning behavior of image data inside of an img element), and I'm wondering how these properties should affect the coordinate space that's used by the map area elements. Spec reference for map and area: https://html.spec.whatwg.org/multipage/embedded-content.html#processing-model-2 QUESTION: The processing model's step 8 says to interpret coordinates as CSS pixels from the left [or top] edge of the image. i.e. coordinates are relative to the top-left corner of the image. But, what does that mean, for an image that's being rendered under the influence of object-fit / object-position? 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 tend to think B is the correct answer, but I'm not 100% sure, and I'd like a sanity-check. (Chrome is the only implementation that I've tested on this, and it appears to choose (A), which seems wrong to me. I'm not sure this was a conscious choice on the part of the developers, though, since this admittedly an obscure use-case, and easy to miss.) Also, FWIW: at the bottom of that same section, the spec says: # For historical reasons, the coordinates must # be interpreted relative to the displayed image # after any stretching caused by the CSS 'width' # and 'height' properties. # # Note: [...] transforms applied using CSS or SVG # do not affect the coordinates. That seems relevant, but it still leaves things vague for me. Thanks! Daniel Holbert Mozilla P.S. For reference, object-fit/object-position are specced here: http://dev.w3.org/csswg/css-images-3/#propdef-object-position
