I didn't think this through fully yet, but isn't this only a problem if we change the contents of the picture (e.g. Art direction) as opposed to reducing quality or pixel density?
If so, we could just declare that srcN doesn't support multiple usemap options, meaning you can only (successfully) use it if you're limiting your use of srcN to viewport and DPR switching.
Makes sense?
Cheers,
Guypo
Guy Podjarny | @guypod
On Nov 3, 2013, at 13:09, "Attiks" <attiks@gmail.com<mailto:attiks@gmail.com>> wrote:
I asked it, because the question was raised in the Drupal 8 issue queue, so I guess some people still use it.
For picture it might be possible by using a 'usemap' on the source element, but no idea how srcN will solve this
On Sun, Nov 3, 2013 at 4:39 PM, Aaron Gustafson <aaron@easy-designs.net<mailto:aaron@easy-designs.net>> wrote:
On Sunday, November 3, 2013 at 10:07 AM, Anselm Hannemann wrote:
I am not sure about this but I do think we cannot postpone this for an img attribute solution.
As usemap is an attribute referring to the img element’s source (in this case src-N) it should (must??) be supported by src-N.
For picture, as this is a completely new and different element, there is no need to support it though.
Agreed, we need to address it, but this is gonna be an interesting can of worms. For MQs I can’t see doing anything but supplying multiple maps (ick).
I realize its a bit of a cop-out, but would it be horrible to declare usemap incompatible with srcN?
Do we have #s on current use of client-side image maps? They are not a current best practice for numerous reasons (not the least of which is accessibility).
Cheers,
Aaron
--
Aaron Gustafson
@AaronGustafson
aaron-gustafson.com<http://aaron-gustafson.com>
-------
Aaron takes no responsibility for poor spelling in this message. It was pecked out by fat fingers on a tiny screen.