最近在补充一些HTML的书籍。我偶尔读这本书。这本书虽然是10年前的书了，但我还是提炼了一些有趣的知识点和观点。出来。标准制定与技术实施的冲突作者一开始就提出了一个Mozilla开发者关于标准与实施冲突的观点：一个技术规范和它的具体实施必须步调一致。在规范之前完成实现是不好的，因为人们开始依赖这些实现的细节，这将限制规范。但是，您也不希望在规范完成后有任何相关的具体实现和实践经验，因为那样规范将得不到任何反馈。如果有不可避免的冲突，我们需要硬着头皮克服它。其实对于前端开发来说，具体实现早于技术规范的制定已经是一种常态。但与其他领域不同的是：除非必要，新的前端标准不能破坏之前的实现。在这里，我可以举几个兼容性的例子：大家可能都用过String.prototype.includes来判断一个字符串是否包含在另一个字符串中。但实际上，在Firefox18-39中，这个方法的名称是contains()。由于Firefox17，一些使用MooTools1.2的网站会崩溃。当时，为了更方便地使用函数，各个框架都在自己的代码库中修改了内置对象的原型。同时，该框架还考虑到未来可能会实施标准。为了兼容未来的标准，他们对原型进行了判断，然后如果对象当前原型上没有函数实现，就使用当前自定义的函数。如果有函数实现，就使用浏览器提供的函数。尽管他们考虑了兼容的标准，但他们没有考虑到标准会发生变化。可能再过几年，标准实施后，功能会和现在有很大的不同。使用的代码出现错误。因此，无奈之下，该函数被重命名为includes()。其实我们可以看到contains的名字比includes好很多。最新的提议之一是在类中添加私有变量方法，标准将使用#符号来表示类的私有变量。类计数{#a=1;getCount(){returnthis.#a}}constcount1=newCount()count1.getCount()//1console.log(count1)//未捕获的语法错误：私有字段“#a”必须在封闭的类中声明。..，美丑必须自己辨别。正是因为前端没有所谓的私有变量，所以大家都会“认同”_是私有变量，但实际上，任何约定只会防君子而不防小人。必须有很多代码进行直接调用。一旦浏览器支持了，势必会影响到大量的网页。所以只能硬着头皮克服。受影响的不仅是JavaScript，还有Css。为了能够在Sass（变量使用$）和Less（变量使用@）中使用Css变量，它们也必须使用--。可以看出，这样定义css变量并不是那么美观。:root{--main-bg-color:brown;}赢家是交付一些东西的人。本书还讨论了![]()
元素标签存在的原因。为什么是img，而不是include，image（其实浏览器中好像也存在image元素标签，可以看看这篇博文Havingfunwith）？答案来源于1993年一群大佬的精彩对话，从中我们可以看到一些真知灼见，也可以看到一些前瞻性的言论。困难是不可避免的。很多时候，协议的制定本身并不是技术问题，很难说是对是错。但是为什么一定要是![]()
呢，答案很简单，因为提议者MarcAndreessen在对话之后直接贴出了处理这个元素的代码。这并不是说给出代码实现的就一定是赢家，但这是赢家的必要条件，不是吗？讨论固然重要，是一种思想的交流，但当我们不能理性地说服别人时，我们只能用其他的方案来表达我们的态度。太高级会死这本书还讨论了WHAT组和W3CHTML组对HTML开发的不同思考和观点。一开始，两组各行其是，根本不理会对方的存在。WHAT小组致力于Web表单和新功能，而另一个小组则忙于研究XHTML2.0，但是遗憾的是：没有浏览器为其提供实现。XHTML与HTML不兼容，这意味着不仅浏览器开发人员需要做很多工作，前端开发人员也需要一下子转向XML，并且完全编写好的规范——这是不可行的。相反，WHAT团队使用宽松的错误处理并专注于新功能。不管是概念还是互联网产品，过于超前的结局其实都不太好。当然，这也从侧面印证了一个道理，选择比努力更重要不是一句空话。难以消失的浏览器兼容技术最后，让我们谈谈技术。新功能已经到来，但我们要等到什么时候才能采用呢？这个问题不仅在10年前出现，现在也一样。优秀的开发人员总是希望使用最新的功能来改善用户体验。当然，我们现在可以依靠CanIuse来确定浏览器支持。很久以前，我们使用
