现在是2020年，我用的是图像地图

由。在“技术”项下发表。到2020年，DR图像地图仍然有用，只是用于注解而不是导航。我从一项任务开始：如何在注释图像的同时防止注释遮挡图像。由于我们希望为图像的某些部分使用可交互区域，因此问题归结为在图像中标记这些区域。当然，在HTML中没有合适的方式来做到这一点，对吗？

21世纪初，部分可点击的图像和图像驱动的导航栏的遥远记忆浮现在我的脑海中，但我很快就对此不屑一顾，认为这显然是你在2020年不会做的事情。然而，尽管SEO赔率很高，还是出现了一篇2004年关于使用图像地图进行注释的文章，这是对html图像注释的第一个搜索结果。

图像地图是有趣和早期HTML功能(如<；marquee>；和<；blink>；)中鲜为人知的兄弟。图像地图最初是由Mosaic Web Browser的作者在1996年使用此RFC进行标准化的，其目的是允许用户通过单击图像中的不同区域来访问不同的文档。

这篇文章引用了一句非常相关的话，如今(2004年！)我们已经在一定程度上远离了[Imagemaps]，文章继续展示了即使在当时，图像地图至少对于作者的注释库来说仍然是相关的。16年后，在这篇文章中，我们将再次同意这一假设，并重新实现我们自己的基于图像地图的图像注释。

让我们从语法开始吧。Imagemap语法在语法上漂亮吗？我既不同意也不反对，而是让你来评判，展示一个完整的支持矩形的图像地图是什么样子：

<；map name="；interface-map"；>；<；Area Title="；Top Controls"；Shape="；RECT"；cocords="；0，0,1024，84"；nohref="；nohref"；alt="；"；/>；<；Area Title="；资源库"；"；/>；<；区域标题="；编辑视图"；形状="；坐标="；280、80、744、349"；nohref="；nohref"；alt="；"；/>；<；区域标题="；预览视图和图层属性"；形状="；矩形。<；Area Title="；回放和时间线控件"；Shape="；RECT"；COCORDS="；0,350,1024,419&34；nohref="；nohref"；alt="；"；/>；<；Area Title="；Timeline Controls"；Shape="；RECT"；COCOLS=&#。当然，至少在某种程度上，从2004年的最先进技术发展而来，我们知道拥有不受W3C标记验证服务铁腕控制的特权，并且需要当时所有必要的属性(HTML5规范也发生了变化)。我们现在可以完全删除href属性，而不是在<；area>；标记中拥有nohref="；nohref&34；属性。非常出色!。

然而，我们并没有从和弦的优雅属性中解脱出来。在现代CSS中，采用四个坐标形成矩形的属性(最突出的是边距和填充)坐标是按照上|右|下|左的顺序描述的(这里希望我不是唯一一个必须不断查找这些内容的人)。相反，要声明一个图像地图矩形，您需要按左|上|右|下的顺序。

更令人兴奋的是，在CSS中绝对定位项目时，最后两个坐标可能不是您所期望的，右和下分别表示到右边缘和下边缘的距离。在图像地图中，这是站不住脚的。相反，水平坐标从左边缘开始计数，垂直坐标从顶部边缘开始计数。

为了找到不同顺序背后的原因，我尝试查看我能找到的第一批CSS规范草案，并将它们的日期与图像映射RFC进行比较。这份1995年底的CSS W3C草案指定了与现在Web浏览器上使用的CSS坐标顺序相同的CSS坐标顺序，并且早于1996年的图像映射RFC。我看不出图像映射实现使用不同顺序的明显原因。

在任何情况下，为现在事后看起来像是愚蠢的事情找理由对我的任务来说都是没有用的。往前走！

实施起来并不是很困难。(A)查询页面以查找具有usemap属性的现有图像，(B)绝对构建(但相对于图像大小，明白吗？)。定位覆盖注释，(C)使它们在悬停时显示，我们几乎重新实现了2004年的库！哦，等等，响应性设计呢？我们忘了带电话(见鬼)！

有了系统的(谢天谢地只有触摸设备)TouchStart事件，我们可以方便地为所有被触摸的注释添加一个额外的类。如果你想自己测试一下结果，可以在这里找到图片。

我们从这一切中学到了什么，从中受益了什么？除了从本质上重新实现遗留功能的乐趣之外，没什么。然而，如果谷歌搜索引擎排行部的某个人找到了他们2002年的旧动态HTML，我们可能只会看到图片搜索引擎优化(SEO)对其他图片地图用户的影响。至少从经验上发现，图像地图上的链接会被跟踪，尽管图像本身仍然被视为一个整体，而不是被切割成碎片。这真的会发生吗(或者我们至少会在谷歌图片结果中得到一些令人兴奋的图片模板形状剪切动作)，可能不会。

2020年的一位新的网络开发人员将不会在他们的互联网研究中学习图像地图，那么这仅仅是在没有充分理由的情况下滥用遗留的HTML3功能吗？嗯，不完全是。正如所确定的那样，图像地图在HTML5规范中仍然是一个完全受支持的特性(有一些修改和限制)，甚至MDN也没有提到该特性所谓的过时。当然，API看起来和感觉上有点过时，它的坐标与CSS标准不同，并且依赖于name属性，但另一方面，现代的hivemind似乎正走向语义HTML元素。带有特权<；map>；和<；area>；标记的图像地图就是一个很好的例子。

然而，就其预期目的而言，图像地图的时代可能即将结束。例如，调整图像大小会破坏图像地图，因为它们依赖于不随图像缩放的固定绝对坐标，并且HTML5规范甚至取消了将坐标指定为百分比的功能。然而，一旦那些自动调整图片大小的响应性网站过时了，我们就会重新审视这一观点。

还在这里？查看这个网站的视频编辑器，或者在Twitter上关注我们。或者离开，我想。