HTML 一直是咱们编译的目标 – 咱们能够解决好它吗?

HTML 一直是咱们编译的目标 – 咱们能够解决好它吗?

每隔几周,Web 开发者的 Twitter 圈都会由于糟糕的 HTML 代码而吵到疯狂。但 HTML 只是一些带有各类各样属性的 div 和 span 而已。有些 HTML 不只缺少任何可见的接口,例如锚点或按钮,也缺少任何结构,例如头部和列表。啊,这就是非语义的 HTML,不可读的 HTML。html

HTML 的定义很清晰,因为它的语法有着很高的容错率,它也很健壮。在XHTML时代,咱们试图让HTML下降容错率,可是网络环境不容许咱们这样作。开发者犯下的错不该让用户背锅,而应该让浏览器宽容 HTML 同时在渲染时自动修复错误。这个问题应让咱们产生担心:咱们被迫忍受多年来浏览器的糟糕决定。这就是为何 HTML 不像其它语言那样(进步得很快)—— 由于浏览器太臃肿和缓慢了。前端

HTML 容许咱们犯错

首先,HTML 的高容错率帮助了 web 世界存活下来。它确保了现代浏览器也能够显示很老的内容,而无需进行更改。不少年的 Flash 内容如今都没法使用了,这件事证实在网络这样波动很大的环境中,容错率高是一件正确的事情。android

可是, 这确实意味着对非语义 HTML 没有可感知到的错误。用 div、span 来实现 table 布局仍然能够正常工做(说的就是这个网站:hackernewsios

展现给咱们全部内容的浏览器让咱们感到担忧,由于它让“干净整洁“和“语义化”的 HTML 变成了一种少数人拥有的特殊技能。HTML 做为网络创做的文字,其书法千千万,其中有大多数的内容都像是随意涂写的涂鸦。git

语义化的 HTML 是很棒的,咱们能够确保它没有问题。你能够从语义化的 HTML 中获得不少显而易见的好处。它每每表现得更好,它一般也意味着没有第三方依赖,也容易阅读和理解。咱们中的不少人学习 web 知识是经过阅读其余 web 站点的源码,这个方法已通过时了,我几个月前写了这篇文章github

如今是时候开始在更成熟的层面上处理这个问题,而不是每隔几个月就重复一样的抱怨了。web

HTML 一直都是一个编译目标。“手写 HTML” 的玩法仅仅适用于一小部分吵闹的爱好者。后端

我是那些吵闹的爱好者中的一员,至今我已经写了 14 年博客了。我热爱这个对全部人都开放的 web 世界。你只须要一个编辑器,一些(工具的)使用文档就能够在 web 世界上发布你的做品。浏览器

手写的 HTML 是稀有品,它应该是收藏品

大约20年前,当我开始成为一名 web 开发者的时候,(用工具编译 HTML)并非人们的工做方式。那个时候没有什么特别大的 web 产品被创造出来——事实上,一个职位需求中没有要求“手写 HTML/CSS/JS 的能力“都是很反常的。那时关注 HTML 规范化的是一个精英汇聚、兴趣浓厚的团体。若是你可让 web 世界变得更加清晰,更加语义化,那么你就是一个很棒的人。可是咱们到底要改变什么呢?服务器

web 世界的大部分都是基于除了 HTML 之外的其余技术:

  • 服务端基础(记得 .shtml 页面吗)
  • CGI/Perl 模版引擎
  • 用内容管理系统和咱们自定义的模版语言来生成 HTML
  • 用来生成一些相似于 HTML 的 WYSIWYG(所见即所得)编辑器
  • 模版语言,例如 PHP、ColdFusion、Template Toolkit、ASP 以及其它
  • 在线编辑器和页面生成器,例如 Geocities
  • 论坛和博客编辑器有时拥有本身的语言(还记得 BBCode 吗?)(译者注:BBCode 是一类标记语言,相似于 Markdown。wiki:zh.wikipedia.org/wiki/BBCode…

这些技术没有一件是在 web 上发布产品所必需的。但在我工做过的一些大型公司中,他们的内容管理系统是及其复杂和庞大的,但人们却选择用它。由于它提供了一个更简单、更明确、更清晰的 web 内容发布途径。他们解决的是开发人员和产品经理之间的问题, 而不是最终用户体验。Geocities 及相似的服务让人们在网络上发布做品更加容易,由于这些服务使得人们甚至不须要编写任何代码。

你在浏览器里看到的几乎不会是源代码。若是你想去提升代码质量,你须要去追溯到代码的源头。

即便咱们选择看网页的源代码,那也不是某我的写的代码,而是由服务端代码处理各类数据甚至是优化后返回给浏览器的代码。

这样作是有其道理的。有不少不一样的公共组件容许人们同时使用它们。通常状况下,你的网站导航是全球性的,甚至是由其余部门或公司编写和维护的。你甚至没法修改 HTML,若是幸运的话,你能够解决网站 CSS 的一些问题。

HTML 是一个编译目标

咱们回到如今。HTML 并非一个很酷的东西,各种模版语言(例如 Markdown Pug、Jade 以及其它)层出不穷。这些模版语言都但愿能让咱们从 HTML 在不一样环境下的可靠性和兼容性问题中解脱出来。

HTML 有一个在某处可用,却不能确保其它地方可用的坏名声。比起只能确保兼容老旧技术的框架,一个能提供更强功能且与时俱进的框架会更加使人兴奋。

web 世界不该该受到咱们的控制,可是咱们须要去知足用户的需求。对于他们来讲,在规定时间内给出了被需求的接口才是他们的任务。咱们应该改变这个现状!

HTML 看起来不是咱们所须要担忧的东西——它在一个容错率高的环境中运行。它一般被看做是更好地利用你的时间来学习更高的抽象。人们不但愿创建一个单纯意义上的网站,而是想构建一个应用程序。尽管大多数状况下,他们并不须要一个应用。咱们在保证 HTML 的趣味性上犯错误了。咱们但愿网络能给咱们更多的功能,让其能够与手机上的原生代码并驾齐驱。但这老是致使咱们的应用有更高的复杂度。构建可扩展 web 的宣言 基本证实了网络上的发布者须要有比实体的做家或出版商更多的开发者思惟。咱们想要控制,咱们想要负责。如今咱们是这样作了。

这样作让咱们剩下了什么?首先,咱们须要去兼容如今 web 世界中现有的由服务器处理过的代码。查看最终结果、感叹其代码质量是没有意义的。没有人写过这些代码,意味着它是不可读的。

我不会放弃语义化 HTML 及其优势,但我明白,咱们不会经过告诉开发者他们的产品是可怕的来讲服他们。咱们须要与框架开发人员合做,这些开发人员是组件的建立者。咱们须要帮助模板源代码,这些模板源代码是框架渲染器。咱们须要确保转换阶段产生良好的 HTML 代码——而不是简单的 HTML。

同时咱们须要和工具开发者合做来确保人们了解语义化的价值。集成在编辑器内的代码 Lint 和自动化有很大的发展潜力。如今咱们有了更多的工具可供选择,以确保开发人员作正确的事情,而没必要考虑它。我喜欢这个主意,它让咱们从源头上解决问题,而不是抱怨症状。

若是发现译文存在错误或其余须要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。


掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 AndroidiOS前端后端区块链产品设计人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划官方微博知乎专栏