> My first thought was to embed anchors into the external map SVG: […]
> This approach is problematic. Those anchors are only active when SVG is inline and don’t work with an <img> element.
No, this approach is fine: you just need to use <object data=…> instead of <img src=…>. <object> is the correct choice for embedding interactive SVG.
But you probably do want the SVG to be inline anyway, because it will load faster and is in this case actively the content of the page; which is the technical decision he ended up at, though perhaps for partly the wrong reason.
If you're looking at any web page with ads or tracking, it has many iframe elements. The javascript that loads them usually creates an iframe and the ad appears there. A typical newspaper site could have 5-50 iframes on each page.
Really? I'd say image maps was the name I haven't heard in a long time... As in I read a couple of paragraphs before it dawned on me that it was _that_ type of image maps that post was about - I first thought it was something regarding rasterized maps (like OpenStreetMap or something)
<object>. It’s a better choice than <iframe> because it ensures the PDF will be rendered, and you can control the fallback content if the user agent can’t render it.
There is no way to defeat the evil dragon Hrathogwar. View the page sources to more easily traverse the URL graph, and confirm there is no escape. You can wander back and forth forever, but if you try to progress, to make Hrothgar happy, you get stuck.
for those of you using something like their technique of opacity animating a clip-path region from one look to another upon ~click ...
if you wish to be visually kind to safari users you can eliminate the default gray selection indication flash animation safari does upon a tap activation with just a tiny bit of webkit-only css , for example ...
> Anchors positioned absolutely over my map wouldn’t solve the pixel-based positioning problem or give me the irregular-shaped clickable areas I wanted. Anchors within an external SVG wouldn’t work either.
If you're trying something like this and irregular-shaped clickable areas are not a concern (like if only the numbered circles from the article's example would be clickable) then absolutely positioned anchors can be made to work. The trick is to use js to apply a css scale transformation to a relatively positioned parent container whenever the underlying image changes size.
My thought when reading that in the article was (in cases where, as you said, irregular-shaped clickable areas are not a concern): why do we need pixel-based positioning? What's wrong with percentage-based positioning and sizing? I did exactly that a couple of years ago, and it worked as expected.
> Image maps date all the way back to HTML 3.2, where, first, server-side maps and then client-side maps defined clickable regions over an image using map and area elements.
Server-side image maps were specified in HTML 2.0, in section 7.6 of RFC1866.
TFA takes us on this journey and then at the end, "Image maps ended up not working for us" without telling us what they did. My money is on JavaScript for that "expressive" aspect of the hover.
> My first thought was to embed anchors into the external map SVG: […]
> This approach is problematic. Those anchors are only active when SVG is inline and don’t work with an <img> element.
No, this approach is fine: you just need to use <object data=…> instead of <img src=…>. <object> is the correct choice for embedding interactive SVG.
But you probably do want the SVG to be inline anyway, because it will load faster and is in this case actively the content of the page; which is the technical decision he ended up at, though perhaps for partly the wrong reason.
(There’s also <iframe>.)
> There’s also <iframe>
Now that's a name I've not heard in a long time...a long time.
Perhaps you confused it with the frameset and frame?
frameset: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
frame: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
iframe: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
If you're looking at any web page with ads or tracking, it has many iframe elements. The javascript that loads them usually creates an iframe and the ad appears there. A typical newspaper site could have 5-50 iframes on each page.
Really? I'd say image maps was the name I haven't heard in a long time... As in I read a couple of paragraphs before it dawned on me that it was _that_ type of image maps that post was about - I first thought it was something regarding rasterized maps (like OpenStreetMap or something)
How would you embed a pdf view in a page?
<object>. It’s a better choice than <iframe> because it ensures the PDF will be rendered, and you can control the fallback content if the user agent can’t render it.
wow, I used to make so many games with image maps back when I first learned HTML. One still survives: https://andrew.fi/beowulf/game/
I feel like you were ahead of the trend with the visual style in this game.
I don't like the way Hrothgar's looking at me.
Thanks for posting this.
I met the dragon and died I think.
There is no way to defeat the evil dragon Hrathogwar. View the page sources to more easily traverse the URL graph, and confirm there is no escape. You can wander back and forth forever, but if you try to progress, to make Hrothgar happy, you get stuck.
for those of you using something like their technique of opacity animating a clip-path region from one look to another upon ~click ...
if you wish to be visually kind to safari users you can eliminate the default gray selection indication flash animation safari does upon a tap activation with just a tiny bit of webkit-only css , for example ...
#links { -webkit-tap-highlight-color : transparent ; }
added to the css of their codepen fixes it (without causing any issues for other/std browsers afaik)
> Anchors positioned absolutely over my map wouldn’t solve the pixel-based positioning problem or give me the irregular-shaped clickable areas I wanted. Anchors within an external SVG wouldn’t work either.
If you're trying something like this and irregular-shaped clickable areas are not a concern (like if only the numbered circles from the article's example would be clickable) then absolutely positioned anchors can be made to work. The trick is to use js to apply a css scale transformation to a relatively positioned parent container whenever the underlying image changes size.
My thought when reading that in the article was (in cases where, as you said, irregular-shaped clickable areas are not a concern): why do we need pixel-based positioning? What's wrong with percentage-based positioning and sizing? I did exactly that a couple of years ago, and it worked as expected.
> Image maps date all the way back to HTML 3.2, where, first, server-side maps and then client-side maps defined clickable regions over an image using map and area elements.
Server-side image maps were specified in HTML 2.0, in section 7.6 of RFC1866.
I've spent five minutes now, to no avail, trying to find a link to this website.
I think I read somewhere else that it is not publicly launched yet, but should be very soon.
This is all because of web standards playing catch-up with implementations instead of the other way around.
[dead]
[dead]
[dead]
TFA takes us on this journey and then at the end, "Image maps ended up not working for us" without telling us what they did. My money is on JavaScript for that "expressive" aspect of the hover.
The last third describes exactly what he did.