On 03.11.2013, at 21:13, David Newton <david@davidnewton.ca> wrote:
> On Nov 3, 2013, at 3:03 PM, Anselm Hannemann <info@anselm-hannemann.com> wrote:
>
>>> What about just letting usemap take a list of IDs in the same order as src-n?
>>>
>>> <img usemap=“#map1, #map” src-1=“(max-width: 400px) img1.png” src-2=“(max-width: 1000px) img2.png” alt=“whatever” />
>>
>> This is not possible for the very same reason we couldn’t extend the src-attribute. We would need to create a new attribute usemap-n="".
>> I find this an ugly solution. Still, not supporting usemaps attribute when a src-n attribute exists is also ugly.
>
> What are those reasons specifically? Not saying you’re wrong, but just wondering if the less frequent usage of usemap could make the problems easier to tackle than they were with src. That said, even though usemap-N isn’t ideal, the infrequency with which it would be needed makes it not a terrible compromise IMO.
It’s that browsers first wouldn’t understand a multi-value usemap attribute and will fail on that.
This is the reason why a new one has to be created. Not the most elegant solution.
Also your proposal would differ in the syntax of both attributes which is not great. On the other hand, a multi-attribute usemap-n solution now really messes up / blows up the img element syntax. :/
That, by the way, are reasons why I still prefer the picture-element.
> Can someone find out if it would be possible to drop this attribute at all? There are enough better solutions like working with SVG for such maps.
>> I also think we should ensure every img attribute is somehow supported by src-N. Otherwise it’s not a good webstandard-solution. Partial support doesn’t sound bullet-proof which a webstandard spec should be IMO.
>
> Other attributes to consider: ismap, crossorigin. Crossorigin should be fine; ismap poses similar problems to usemap.
crossorigin should be fine, yes.