Web标准前途是否依赖浏览器技术
佚名
加快发展
我们已经有了一个版本目标的例子(Doctype转换). 当我用这种方法实现了, 我却陷入了混乱. 毕竟, 我是Doctype转换的推行者, 并且现在还在依赖它进行工作. 我应该憎恨这整个想法吗, 或者不?
就像在2000年的Doctype转换, 版本目标否定厂商的说法,怕破坏了现有的网站,现有的行为是不能改变的. 如果IE 8能够修正它对一些CSS属性或DOM方法的实现的话, 那在IE 9中的错误我们就可以在站点不被破坏的基础上修正了.
而且, 如果这一切就像标榜的那样, 那最终会让web开发更少的依赖于虚拟计算机. 如果你需要支持当前的浏览器,又要顾及之前版本的, 你只需要更改你的X-UA-Compatible值到一个较早的版本然后看看事情变得怎么样了 - 不需要VirtualPC的副本. 这不会立刻发生, 但是这是合理的最终结局. 新的嗅探测试
我们超越了浏览器嗅探, 不是吗? 没有人把这称为 "脆弱" 与 "弄巧成拙"?
我们知道的浏览器嗅探技术和版本目标器之间有至关重要的差别. 首先, "浏览器嗅探技术" 在现在意味着 "编写代码检查正在用什么浏览器, 然后对标签/CSS/JS/服务器端响应/任何东西进行相应的调整." 版本目标器完全相反, 它让 "浏览器自己检查页面是什么时候开发的, 并做出相应的调整." 换句话说, 版本目标把web开发者从嗅探中解放出来, 并把这个责任交给浏览器开发商.
这不是个能轻松讨论的改变. 浏览器的实现者们常用资源有限的借口来回绝我们, 但是却依然指挥着比我们之中的任何人能召集的还要多的资源和技术进行回退测试. 而且, 浏览器开发商对确保版本目标像承诺的那样不破坏旧站点比网站作者更新旧站点以支持新浏览器具有更大的既得利益. 后知后觉的好处
浏览器嗅探技术和版本目标器之间的第二个区别是浏览器嗅探技术是向未来看, 而版本目标器是向过去看. 向未来看是浏览器嗅探之所以脆弱的主要原因之一: 很难去预知未来. 举例来说: Safari在用户端的标识符中包含了"like Gecko"让很大一群嗅探脚本出错了 - 甚至是那些做得比较好的. 这些脚本的作者因为不能预知一个Apple的non-Gecko的浏览器会在用户端标识符中包含"Gecko"这个词而完全失败了.
现在, 我们的前景是浏览器自身会做浏览器嗅探了, 然后会向后看了, 这会有更多的稳定性: 过去的总是比预知未来更容易掌握.
此外, 我们已经为浏览器们写了足够的脚本和Hacks来适应他们, 是不是该是浏览器开始来适应我们的页面的时候了? 总而言之
我们知道向前兼容的研究工作. 更多的是, 虽然关于它的一切我们都知道了. 在互联网初始的时候, 除Doctype转换以外, 浏览器一直是以"所见即所得"为目标的. 开发者们在推测未来的浏览器要做什么的同时还要被迫保持和过去的浏览器一样的行为.
向前兼容的发展以及它的亲戚: 逐步加强是适合的,必须的, 因为这是我们的网站能在未来正常工作的唯一希望. 对向前兼容的歌颂在我们工作的世界中是必需的.
在另一个浏览器开始采用版本目标的世界里, 可能就是另一种选择了. 谁会知道会发生什么? 可能我们会发现向前兼容变得非常脆弱, 甚至相当可笑.
我们说向前兼容的发展是衡量一个专家的的标志, 因为我们的直接决定了这样. 版本目标的出现, 那种要求可能就会完全消失了, 呈现出来的不再出错,但是变得毫无意义. 虽然我根深蒂固的本能仍在抵抗这种结论, 但是我不得不进我最大的努力去看这个可能会发生的未来, 然后问自己, 这会不会比我们知道更好或是更坏?
这看起来更好.
在最后, 让我非常震惊的, 我原来并不讨厌这个想法. 版本目标使浏览器更容易开发新的功能, 并且在原有功能上修复错误和缺点, 这会潜在的加速web设计和发展, 单单这一个理由就就足够给它一个机会了. 是的, 但是...
当然, 我还是有所顾虑.
最大的顾虑是保真度. 会不会IE 8的向后兼容代码工作起来看起来还是像IE 8一样, 或者会不会有细微的改变但是还是破坏了旧的网站? 可能会这样, 但是我们不敢说, 新的缺陷会影响未来浏览器的向后兼容吗? 毕竟, 门会向两边摆: 厂商可能会让他们的"向后看"代码不是很严密, 就像开发者可能会让他们的 "向前看" 代码不是很严密一样. 讽刺一下.
另一个小小的顾虑是版本目标代码在浏览器程序上的大小问题. 这会让浏览器变成一个臃肿的程序吗? 一些人会认为 "谁在意啊? 现在的硬盘都很大了!" 但是我仍旧坚定的不同意"资源廉价"的观点. 不管它们如何的廉价, 那也都是人们努力出来的. 我真诚的希望未来的浏览器不会需要1或2G的存储空间, 它的历代版本Jacob Marley他过去的行为一样. 名词解释
我完全不是 "edge" 这个词的崇拜者. 原因是, 它的存在似乎使每个人都用自己的方法使用锁定机制, 比如 "IE=1024"或是其他更大的数字. 问题在于提供一个关键词当量创建一个官方赋予的氛围的事情, 我不认为microsoft会提供. 让所有人都使用这个机制是他们的利益所在, 这个关键字在希望取消它的人们面前充当着一个眼色,一个点头. 我完全赞同人们遵守这个锁定机制,如果他们希望的话 - 我能更好地完成这个工作, 但是这需要用到hacks, 而并不是官方的关键字.
Doctype作为版本目标
我想我会感到高兴, 如果页面在不使用任何版本目标信息也能被处理的话. 如果一个页面不包含任何版本目标信息, 那么Doctype就会充当版本目标的代理人. 比如说, 所有的HTML 4和XHTML 1的Doctype会在IE 7中作为默认锁定值. 在未来, HTML 5的Doctype会作为IE 9或IE 10的默认锁定值, 这取决于被打开的文件.
当然, 开发者可以提供一个明确的浏览器版本来忽略所有的: 一个 HTML 2的文档可以被IE9锁定, 一个HTML 6的文档可以被IE 7锁定. 但是在没有明确的版本目标信息时, Doctype要作为替身来连接到一个特定的版本. Microsoft的观点, 这是必需的: 如果没有这种方式, 没有目标的页面会被新版本的IE破坏. 我了解这点. 但是这意味着为了能像他们本来的样子那样处理页面, 随着浏览器的进步, 你就必须为目标机制作Hacks: 用一个很大的版本号数字 - 或者用edge关键字, 如果它没有被剔除的话.
最大的挑战, 似乎是, 他们必须确保版本目标在未来的浏览器中以这样的方式运作而要像Doctype转换那样的不会破坏网站功能. 换句话说, 我们还要确保它的向前兼容.
我想我的那些本能最后又出现在身边了.
我们已经有了一个版本目标的例子(Doctype转换). 当我用这种方法实现了, 我却陷入了混乱. 毕竟, 我是Doctype转换的推行者, 并且现在还在依赖它进行工作. 我应该憎恨这整个想法吗, 或者不?
就像在2000年的Doctype转换, 版本目标否定厂商的说法,怕破坏了现有的网站,现有的行为是不能改变的. 如果IE 8能够修正它对一些CSS属性或DOM方法的实现的话, 那在IE 9中的错误我们就可以在站点不被破坏的基础上修正了.
而且, 如果这一切就像标榜的那样, 那最终会让web开发更少的依赖于虚拟计算机. 如果你需要支持当前的浏览器,又要顾及之前版本的, 你只需要更改你的X-UA-Compatible值到一个较早的版本然后看看事情变得怎么样了 - 不需要VirtualPC的副本. 这不会立刻发生, 但是这是合理的最终结局. 新的嗅探测试
我们超越了浏览器嗅探, 不是吗? 没有人把这称为 "脆弱" 与 "弄巧成拙"?
我们知道的浏览器嗅探技术和版本目标器之间有至关重要的差别. 首先, "浏览器嗅探技术" 在现在意味着 "编写代码检查正在用什么浏览器, 然后对标签/CSS/JS/服务器端响应/任何东西进行相应的调整." 版本目标器完全相反, 它让 "浏览器自己检查页面是什么时候开发的, 并做出相应的调整." 换句话说, 版本目标把web开发者从嗅探中解放出来, 并把这个责任交给浏览器开发商.
这不是个能轻松讨论的改变. 浏览器的实现者们常用资源有限的借口来回绝我们, 但是却依然指挥着比我们之中的任何人能召集的还要多的资源和技术进行回退测试. 而且, 浏览器开发商对确保版本目标像承诺的那样不破坏旧站点比网站作者更新旧站点以支持新浏览器具有更大的既得利益. 后知后觉的好处
浏览器嗅探技术和版本目标器之间的第二个区别是浏览器嗅探技术是向未来看, 而版本目标器是向过去看. 向未来看是浏览器嗅探之所以脆弱的主要原因之一: 很难去预知未来. 举例来说: Safari在用户端的标识符中包含了"like Gecko"让很大一群嗅探脚本出错了 - 甚至是那些做得比较好的. 这些脚本的作者因为不能预知一个Apple的non-Gecko的浏览器会在用户端标识符中包含"Gecko"这个词而完全失败了.
现在, 我们的前景是浏览器自身会做浏览器嗅探了, 然后会向后看了, 这会有更多的稳定性: 过去的总是比预知未来更容易掌握.
此外, 我们已经为浏览器们写了足够的脚本和Hacks来适应他们, 是不是该是浏览器开始来适应我们的页面的时候了? 总而言之
我们知道向前兼容的研究工作. 更多的是, 虽然关于它的一切我们都知道了. 在互联网初始的时候, 除Doctype转换以外, 浏览器一直是以"所见即所得"为目标的. 开发者们在推测未来的浏览器要做什么的同时还要被迫保持和过去的浏览器一样的行为.
向前兼容的发展以及它的亲戚: 逐步加强是适合的,必须的, 因为这是我们的网站能在未来正常工作的唯一希望. 对向前兼容的歌颂在我们工作的世界中是必需的.
在另一个浏览器开始采用版本目标的世界里, 可能就是另一种选择了. 谁会知道会发生什么? 可能我们会发现向前兼容变得非常脆弱, 甚至相当可笑.
我们说向前兼容的发展是衡量一个专家的的标志, 因为我们的直接决定了这样. 版本目标的出现, 那种要求可能就会完全消失了, 呈现出来的不再出错,但是变得毫无意义. 虽然我根深蒂固的本能仍在抵抗这种结论, 但是我不得不进我最大的努力去看这个可能会发生的未来, 然后问自己, 这会不会比我们知道更好或是更坏?
这看起来更好.
在最后, 让我非常震惊的, 我原来并不讨厌这个想法. 版本目标使浏览器更容易开发新的功能, 并且在原有功能上修复错误和缺点, 这会潜在的加速web设计和发展, 单单这一个理由就就足够给它一个机会了. 是的, 但是...
当然, 我还是有所顾虑.
最大的顾虑是保真度. 会不会IE 8的向后兼容代码工作起来看起来还是像IE 8一样, 或者会不会有细微的改变但是还是破坏了旧的网站? 可能会这样, 但是我们不敢说, 新的缺陷会影响未来浏览器的向后兼容吗? 毕竟, 门会向两边摆: 厂商可能会让他们的"向后看"代码不是很严密, 就像开发者可能会让他们的 "向前看" 代码不是很严密一样. 讽刺一下.
另一个小小的顾虑是版本目标代码在浏览器程序上的大小问题. 这会让浏览器变成一个臃肿的程序吗? 一些人会认为 "谁在意啊? 现在的硬盘都很大了!" 但是我仍旧坚定的不同意"资源廉价"的观点. 不管它们如何的廉价, 那也都是人们努力出来的. 我真诚的希望未来的浏览器不会需要1或2G的存储空间, 它的历代版本Jacob Marley他过去的行为一样. 名词解释
我完全不是 "edge" 这个词的崇拜者. 原因是, 它的存在似乎使每个人都用自己的方法使用锁定机制, 比如 "IE=1024"或是其他更大的数字. 问题在于提供一个关键词当量创建一个官方赋予的氛围的事情, 我不认为microsoft会提供. 让所有人都使用这个机制是他们的利益所在, 这个关键字在希望取消它的人们面前充当着一个眼色,一个点头. 我完全赞同人们遵守这个锁定机制,如果他们希望的话 - 我能更好地完成这个工作, 但是这需要用到hacks, 而并不是官方的关键字.
Doctype作为版本目标
我想我会感到高兴, 如果页面在不使用任何版本目标信息也能被处理的话. 如果一个页面不包含任何版本目标信息, 那么Doctype就会充当版本目标的代理人. 比如说, 所有的HTML 4和XHTML 1的Doctype会在IE 7中作为默认锁定值. 在未来, HTML 5的Doctype会作为IE 9或IE 10的默认锁定值, 这取决于被打开的文件.
当然, 开发者可以提供一个明确的浏览器版本来忽略所有的: 一个 HTML 2的文档可以被IE9锁定, 一个HTML 6的文档可以被IE 7锁定. 但是在没有明确的版本目标信息时, Doctype要作为替身来连接到一个特定的版本. Microsoft的观点, 这是必需的: 如果没有这种方式, 没有目标的页面会被新版本的IE破坏. 我了解这点. 但是这意味着为了能像他们本来的样子那样处理页面, 随着浏览器的进步, 你就必须为目标机制作Hacks: 用一个很大的版本号数字 - 或者用edge关键字, 如果它没有被剔除的话.
最大的挑战, 似乎是, 他们必须确保版本目标在未来的浏览器中以这样的方式运作而要像Doctype转换那样的不会破坏网站功能. 换句话说, 我们还要确保它的向前兼容.
我想我的那些本能最后又出现在身边了.