当前位置: 首页 > 图文教程 > 网页制作 > CSS样式表 > Web标准前途是否依赖浏览器技术

CSS样式表
css 块状元素和内联元素
CSS 盒模型、块状元素与内联元素、CSS选择器
css 浮动 理解Float的含义
CSS 清除浮动Clear
CSS 制作网页导航条(上)
CSS 制作网页导航条(下)
css 浮动(float)页面布局
css 浮动(float)页面布局(下)
css position 定位
css 定位应用实例
CSS Hack 有关浏览器兼容方面
css 单图片按钮实例(css 图片变换)
使用X-UA-Compatible来设置IE浏览器兼容模式
div overflow 超出隐藏属性使用说明
CSS 使用规则总结
div+CSS 兼容小摘
CSS的inherit与auto使用分析
如何组织和注释CSS文件
CSS样式按整洁易懂的结构组织
CSS Prism 查看和编辑CSS中用到的颜色

CSS样式表 中的 Web标准前途是否依赖浏览器技术


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-09-11   浏览: 136 ::
收藏到网摘: n/a


原文:http://www.alistapart.com/articles/fromswitchestotargets
作者:Eric Meyer
当我读了一遍Aaron Gustafson的Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 后,我心里的第一反应就是深深的否定这种观点. Aaron描述的version-targeting机制是完全错误的, 是完全倒退的, 是和我们应该做的事情完全相反的. 在web开发领域浸淫了十多年的我的每条神经都在反对.
为什么我会如此的抗拒? 部分原因是目标转换器像是"浏览器嗅探"技术的复仇. 真的, 在众多浏览器正确的支持标准前, 嗅探器是应付它们之间不兼容情况的必需的方法, 但是到最后它都没有起到作用. 在你上传你的脚本之后没多久, 一个浏览器的新版本就出现了, 并且又破坏了它. 浏览器嗅探技术脆弱的,弄巧成拙的本性是将标准带给我们的浏览器的理想背后的反抗力量. 如果从浏览器的代码层把它合法化, 那他又将成为一种破坏标准之路的力量了.
首先, 我为目标转换器感到烦扰, 因为它这样做和向前兼容的发展背道而驰. 这曾经是我们的行业多年来的最优方法, 是在浏览器战争中艰难的发现的生存方式. 我们着眼于未来的开发, 大部分使用普及的稳定的功能来实现, 然后使用一些不影响我们网站正常使用的 "尖端技术" - 这逐渐就成为了 "逐步加强". 这种方法的一个例子是在"Go To Print"中描述过的技术, 这种技术可以让进步的浏览器在需要打印的页面上显示出链接的URL,但是又不会破坏不具备这项功能的浏览器的打印的效果.
对于目标转换器而言,什么为未来作出规划, 什么前瞻性, 都几乎被摧毁殆尽了. 浏览器会承诺总是向后兼容. 对于浏览器来说目标转换器就像是个时间机器, 它的想法是当用IE 10来装载IE 7的页面时, IE 10要让自己像IE 7一样的工作, 不管在这些年里发生过什么.
从而, 作为一个开发者, 没有必要追求超现实状态的浏览器. 我甚至可以假设, 浏览器们始终会支持我做的东西, 甚至是那些目光短浅的, 特定浏览器的, 无论如何都需要标准的. 至于浏览器预期将支持的方向: CSS或者JavaScript又或是HTML5...谁又在意呢? 现实调查
那么, 谁在意呢? A List Apart 的读者们, 的确, 以及我们中的大部分. 但是在调查分析后显示, 大多数的网页内容都没有很重视基于标准,向前兼容的原则.
是的, 我们已经取得了长足的发展. 对开发者进行的教育也结出了一些果实. 尽管如此, 我们必须正确的对待这些. 我们没有(标准)到达所有的人, 或许永远都不会. 一些网站是根据当前浏览器能做什么进行开发的, 而从不管对照规范是否错误, 或者其他浏览器中的行为是否正确.
这让浏览器厂商在面对他们的缺陷时处于一个进退两难的境地: 修正它或是保留它? 最经典的一个例子是 "Internet Explorer的原始width和height" , 这是对CSS规范的错误执行. IE 团队在发布IE 3后不久就意识到这个问题了...但是一直到了IE 6才真正修复, 这样的延误减慢了CSS的应用, 并引发了所有的JavaScript嗅探和CSS Hacks.
Doctype的转换确实拯救了它们, 允许IE 6在"quirks mode"保留旧的(错误的)行为, 在"standards mode"下进行正确的解析 - Mac版本的IE5引进的一个机制, 也很快被其他浏览器采用了.
让我们想一想, 通过Doctype的转换, 浏览器有效的认可了两种状态: 老的和正确的. 这是在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转换那样的不会破坏网站功能. 换句话说, 我们还要确保它的向前兼容.
我想我的那些本能最后又出现在身边了.