随网之舞HTML & CSS http://dancewithnet.com WEB Design{HTML:CSS:Javascript:DOM:AJAX:PHP:Usability}/Viewpoint/Photo/Food/Mood Mon, 18 Jul 2011 02:45:29 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 HTML5@电子商务.com http://dancewithnet.com/2011/06/19/html5-at-e-commerce-com/ http://dancewithnet.com/2011/06/19/html5-at-e-commerce-com/#comments Sat, 18 Jun 2011 19:50:52 +0000 秦歌 http://dancewithnet.com/?p=1536 经过2009到2010年全球领先的互联网企业Google、Apple、Facebook等等在HTML5上的大力推进和应用，今年在国内业界开始真正地热起来，4.10 QConBeijing2011的12个专题之一就是HTML5开发平台，4.18 由W3CTech主办的“拥抱HTML5” 又是国内业界另一个顶级的HTML5大会，这次的HTML5 in China是今年第3个关于HTML5的国内业界顶级会议，还有即将到来的7.9 D2前端技术论坛 也将会有部分HTML5相关的内容。在这么短的时间内国内组织了这多次和HTML5相关的大规模顶级会议，几乎涉及到国内所有最领先的互联网企业，从中可以看出HTML5的热度。

HTML5引起业界如此重视这是好事，但短时间内过热反而说明了业界对于HTML5的理解程度不够，这点和2005年言必称标准和ajax非常类似，等大家真正对标准和ajax深刻理解并应用到生产实践的时候反而在谈论的是利用标准和ajax成就了某项产品而不仅仅是技术本身，HTML5也正经历这样一个过程。现在最热的讨论之一就是在移动平台上使用原生开发还是使用HTML5，如果只是讨论两者的技术优势这个问题估计永远没有答案，因为我们的目标真的不是那种技术更好，而是哪种技术更能适合我们用来快速的解决用户的需求，一个复杂游戏比如极品飞车当然用HTML5来做当然不是最佳的方案，但类似Google Reader之类数据展现性和简单交互的应用当然用HTML5开发比较好，其实如果你稍加留意就连Apple自己的App Store这个应用的本身就是用HTML5开发的。本次会议前面有两位同学介绍使用phoneGap + HTML5来重构新浪微博的iPad客户端，两个人利用一周的业余时间大致实现了这个iPad客户端的全平台覆盖（Web、Mobile Web、Android、iPhone和iPad），我想新浪微博的同学看到这个应该会有一些不一样的感触吧。

我把这次每张幻灯片要讲的内容都写到幻灯片的注释中，有兴趣的同学可以对照看会更明白一些，同时也在blog中列出每张幻灯片要讲的内容。另外，几乎每张幻灯片的后面都了一两个链接，这些链接很多都非常精彩，强烈推荐大家看看。


  1. HTML5@电子商务.com是我在这次HTML5 in China大会上讲的主题，之前有大量的业界同仁介绍了HTML5的意义和HTML5能够实现的各种很Cool的应用，特别是Mozilla的米嘉代讲的《HTML5 in the wild》让很多人都惊讶于HTML5所能实现的一切，但是可能也有不少人会感觉到这些玩意太炫了，不知道怎么才能和我们的实际结合上，所以会有人说那些酷酷的游戏是浮云，我发现大部分人留下来听非游戏部分也说明了HTML5在非游戏领域的应用是我们更多人面临的问题。我会把口碑和淘宝在HTML5上一些应用案例拿出来和大家交流，基于这些案例来聊聊我们对HTML5的认识和应用，最重要的如何思考落地的然后实现，当然这些经验不是只适合电子商务网站，也适合任何使用HTML5来解决业务问题的场景。
  2. 这页就是个人信息，欢迎就任何问题联系我。
  3. HTML5的应用的程度和浏览器的支持程度密切相关的，这个表列出目前主流浏览器各个版本在HTML5 Test得分，全球的占有率和淘宝的占有率。HTML5 Test的满分是400分，而目前得分最高的293，可见实现HTML5已定义的所有标准还需要较长的路要走。
  4. 从表中我们还可以从中看出更多很有意思的东西：

    1. IE6、IE7、IE8在HTML5标准上的支持的确太差劲了，是大规模应用HTML5的障碍，我们是应该主动推动用户升级了。全球范围内IE6低于3%，IE7低于9%，在美国和欧洲这个值应该更低，这就是为什么Google可以宣布在它的很多新兴业务不支持或有限支持IE6和IE7的原因，利用HTML5开发出优秀的产品，然后适时引导用户升级浏览器的最好方法。
    2. 我们更应该看到虽然HTML5是在2004由WHATWG开始孕育，2006年W3C正式启动，但2001年推出的IE6已经支持部分HTML5，这告诉我们HTML5并不是全部是所谓的新技术，它更考虑对现有HTML技术的继承和改进，而很多HTML5技术规范我们早已经在使用，比如HTML5的DTD声明<!doctype html>，所以我们很多人很早就在使用HTML5。
    3. 淘宝的IE6、IE7、IE8占有率超过80%，整个IE份额接近90%，这主要有两个原因导致淘宝IE份额非常高：

      1. XP操作系统在中国份额依旧80%以上
      2. 电子商务网站最重要的一个环节是支付，而现在的网银绝大部分是只支持IE的，包括和淘宝密切相关的支付宝，虽然已经支持了各大平台的，但其最重要的安全措施电子证书主要还是在IE上使用最多。
    4. 淘宝的IE6占有率已经低于40%，这绝对是一个好迹象，从我私下打听的几个数据判断国内IE6平均占有率应该在50%以上，后面会解释为什么会这样。
  5. 整个阿里的电子商务交易支付部分主要依赖支付宝，支付宝在不支持浏览器、安装证书等操作上会引导用户升级最新的版本，这非常值得国内的大站点学习。
  6. 支付宝在其教显著位置推荐使用IE、Firefox、Chrome、Safari等浏览器最新版本，并提示用户升级浏览器，这是一件非常有意义的事情，好的产品引导用户升级利企利民。 不过，这里支付宝可以有一个小改进，那就是不要对XP平台的同学也推荐IE9浏览器，幸好下载链接那边的微软做了判断。
  7. 开始学习和应用HTML5，首先会注意到新增了大量的语义化元素，比如<section>，这些元素的添加正是HTML5务实一种体现，它们都是来自对现实HTML组织形式的抽象提取，但遗憾的是IE6、IE7、IE8不支持这些标签，但开发者是很聪明的，于是有了两种解决方案：

    1. John Resig公布了利用JavaScript来实现让IE6-8支持的方法，这种方案比较简单，唯一的缺陷就是必须使用JavaScript，但浏览器可能不支持JavaScript
    2. 利用双层标签进行嵌套，这样就不需要考虑是否支持JavaScript了，但代码臃肿，基本上开发人员不太喜欢，所以大部分都使用上一种方案
  8. 但我们不能不面对一种现实，那就还是有大量的用户代理禁用JavaScript，当有上亿用户时，这个数量其实是我们无法忽视的。
  9. 为什么还有这么多用户禁用JavaScript呢？除了用户通过安全级别进行禁用、杀毒软件禁用之外，还有一个Firefox插件NoScript也需要值得我们注意，一方面它的下载量接近9000万，可见用户数量之大，另外一方面我们在百度上搜索NoScript时，你会发现第一页很多地方介绍NoScript时都提及安全，也就是说用户对JavaScript的恐惧和对安全的担忧才是我们存在大量禁用JavaScript的情况。
  10. 淘宝首页在年初升级时引入了HTML5的语义元素，当用户在IE6-8下禁用JavaScript会出现幻灯片上的提示，建议用户开启JavaScript或者访问一个专门定制的不使用HTML5新语义元素的页面，这个看起来是一个不错的解决方案，但就是成本太高。
  11. 所以为了避免成本太高， 淘宝彩票首页前不久也引入了HTML5语义化元素，就直接告诉禁用JavaScript的用户启用JavaScript，否则没法使用。
  12. 我们当然可以把不支持JavaScript的用户看成某个低版本的浏览器用户，比如是IE5.5的用户，我们也可以像强制用户升级一样去强制用户开启JavaScript，这是不同场景的不同选择，所以前面淘宝的选择也是一个可行的方案。在口碑的实践中，尽可能地让用户先用起来是我们的设计原则，所以口碑看重的是：

    1. 重点是语义的本身而不仅仅是语义元素，我们不会仅仅为了使用语义元素而引入JavaScript或嵌套标签，采用语义本身的含义来组织我们的代码是关键，所以我们可以更多的去参考HTML5的语义元素和http://schema.org/ 来规划我们的代码结构和命名，这样如果有一天你想转换成HTML5的也是非常简单的。
    2. 对JavaScript依赖性很强的项目，可以大胆的使用HTML5语义元素，同时需要对用户进行友好的提示，特别是在安全方面的提示。
    3. 不考虑NoScript并不能靠优雅降级一言蔽之，前端工程师有责任和义务去深入思考可访问性问题，虽然两者并不是同一件事。
  13. 电子商务网站经过多年的实践总结出主要的用户路径，这些路径的完成率直接关系到整个网站的交易额，所以提升每步的转化率对于电子商务网站来讲至关重要，实现每步之间的转化率就是要想办法提升用户的购买效率。这里面有很多事情可以做，比如按照应用购买力的因素来设计页面信息和购买步骤，尽量减少每两步之间的页面数、提升两步之间的速度、减少两步之间的干扰，在完成购买时形成新的购买循环。
  14. 在很多情况下，List页到Detail页有很多相似的地方，比如共同的头尾、侧边栏、购物车，如果我们用ajax来替换中间不一样的部分，会减少从List到Detail的时间，提升页面性能，从而提升交易额。Amazon的实践曾表明网站慢100毫秒有1%的人放弃交易 。 但采用ajax这样做的时候会遇到三个障碍：
    1. ajax请求的页面，比如detail页面，怎样定位这个页面的URL
    2. 浏览器前进后退的问题
    3. 传统页面的和可访问性和SEO问题
  15. 应用ajax的这些问题早已经有了比较完美的跨浏览器解决方案，很多JavaScript库或框架都有解决这些问题的组件，twitter就是这方面是个非常好的案例

    1. 利用url的hash标签来作为独立的URL，这样可以定位到每个具体页面
    2. 利用window.history.hash + iframe来实现浏览器的前进后退
    3. 提供强大的API，不存在传统的SEO问题

    但twitter的方案并不完全适合传统的页面的渐进增强，传统页面很多时候必须在页面本身考虑SEO问题，以及URL标准问题。比如访问 https://twitter.com/#!/kavenyan 你会看到loading，这是因为需要JavaScript要获取hash值之后才能再次获取对应数据，然后更新到页面上，如果是页面的核心主体内容采用这种方式一直看到loading并不是太友好的事情。

    HTML5对history提供了强大的API：histroy.pushState和histroy.replaceState，它们非常简单自然优雅地解决ajax应用遇到的前面两个问题。更重要的是URL不需要借助于URL的hash部分，是一个真正意义上完整的URL，这样就可以很自然地实现对可访问性和传统SEO的保留。所以，当你直接访问从List通过ajax生成的Detail的URL http://waimai.koubei.com/web/takeoutgoodsdetail.html?city=99&offerId=10211200000000191 时会直接出现Detail的主体部份，不会出现任何loading。

    这个API的缺点在于只有Chrome、Safari和Firefox4支持，这恰好形成了一个天然的ABTest，我们可以通过统计埋点看看这样做是不是实现了我们的目标增加了转化率。必须牢记，我们的目标不是为了使用某个HTML5技术，而是使用HTML5技术来解决用户的需求。最早使用这个API的知名网站是 http://github.com，在QConBeijing2011上hax提到了这个API，我们看到这个API恰好能解决我们的面临的问题就立即应用了。这个事情告诉我们，我们今天不仅仅是了解HTML5的那些最Cool的应用，还要找到那些适合我们能学以致用的技术，一旦发现我们应该快速的去实践拿出结果，否则再Cool的技术如果不能解决我们的问题，不能解决用户的需求是没有用的。

  16. 这里有一些我们已经使用和正在尝试使用的HTML5技术，每项技术的使用都是奔着能解决我们的问题去的，尽量避免为了技术而使用技术。

    HTML5和CSS3能够让我们实现很多很Cool的设计，比如圆角，比如倒影。但是有时候你可能会发现，视觉设计师通过PhotoShop之类软件设计的圆角和倒影你很难用HTML5 + CSS3实现，但HTML5 + CSS3 又能很高效的做出类似的事情，这是一个很尴尬的事情吧，所以让交互、让视觉，甚至让运营和产品了解HTML5能干什么非常重要，HTML5 + CSS3 + JavaScript + 浏览器性能的改进将会很快的改变我们的设计模式，为了让更多的上游理解HTML5和CSS3在设计上能做什么，我的同事开发了Chrome插件Code Cola，用它能够非常方便地通过可视化的方式在现在有的页面上实现各种HTML5效果，并能够方便地得到修改后的代码，或者把修改后的页面发给服务器以便其他人协作使用。这个插件本身就是用HTML5 + CSS3 + JavaScript来实现的，我们正在用HTML5来提高我们的效率。

  17. 这句话是Jeremy Keith在《HTML5设计原理》中讲的，4月份他也曾亲临W3CTech主办的拥抱HTML5大会向中国的开发者布道，这是一个我认为每个和HTML5应用相关的开发者都应该仔细去品味的演讲，从中我们可以深刻的理解HTML5为什么会变成这样，以后会是什么样，我们应该本着什么样的态度去实践HTML5。我们会使用HTML5不能叫我们创造价值，只有我们用HTML5解决了用户的需求才叫创造价值，这和HTML5的设计原则是一致的。从第1个例子考虑NoScript情况，到第2个例子针对不同浏览器实现不同效果，到第3个例子为设计师开发HTML5 + CSS3的可视化工具，都是在遵循这个原则基础上去实现的，实际上我们可以做的更多。
  18. 这些口碑在实践HTML5时的一些心得：
    1. 前端技术开发都是在渐进增强和优雅退化间做平衡，这不仅仅体现在某个具体的技术应用上，也体现在整个设计的思想和开发流程上，我所举的例子也都是在做这两者的平衡。
    2. HTML5并不是新兴的技术，但是由于各个浏览器支持的不同，我们必须面对残酷的现实，针对某个具体的问题的跨浏览器解决方案都很多种，比如探测浏览器是否支持HTML5某个属性的库 Modernizr上有个wiki页就收集了特别多的全球开发者解决HTML5跨浏览器问题的方案。我们完全可以站在全球开发者的肩上高效的使用HTML5来解决用户的需求，同时通过具体业务挖掘出新的解决方案贡献给社区。通常，应用HTML5并不仅仅是前端工程师的事情，需要整个设计和研发团队都所有了解，这样才能把技术利用到极致，为用户创造最大价值。
    3. Douglas Crockford曾说过ajax导致web page成为web application，实际上从2005年到现在虽然有这个趋势，但是还是不足够明显，随着HTML5的出现，从元素的规划到API的设计，都标志着Web App时代的带来，这恰好和手机App的时代同步。Web App的出现导致了我们需要更多的思考设计与技术的结合，单纯的先设计页面再开发页面的时代很快要过去了，我们需要把页面的设计和开发结合起来，这将会对我们的交互设计、视觉设计和前端开发带来很大的挑战和机遇，我们应该从现在探索，要知道如果按照运营、产品、交互、视觉、前端、后端、测试这种研发方式是不可能出现Google Maps、Gmail、Facebook、Twitter等等的。
    4. 我们面对大量基于HTML5新且Cool的应用，但是有时又会感觉离我们有点远，作为前端开发工程师应该理解业务，对业务的未来有所判断，那么我们就能够用HTML5来解决我们的用户问题，而不是为了使用HTML5来进行某些开发。我们必须用成功的案例来证明HTML5可以做什么？我们不仅仅应该出现的是技术热，更应该出现的是产品热，每个新的产品出现才是真正解决用户需求而具备非常大的意义。利用HTML5做出成功的产品是最好的布道方式。
  19. “一次编写，随处运行”曾经是Java的梦想，也是开发者的梦想，这样开发者可以把更多的时间放在解决用户的需求上，而不是机器和软件的兼容性上，现在HTML + CSS + JavaScript差不多快做到了，如果我们不能用这些技术满足用户的需求，让我们的用户感觉到Cool，那么满足开发者的梦想就会变得意义没有那么大了，这就是HTML5的设计思想，也应该是我们每个程序员的追求。

最后，把这个幻灯片献给口碑网。

]]> http://dancewithnet.com/2011/06/19/html5-at-e-commerce-com/feed/ 11 默认Web字体样式 http://dancewithnet.com/2009/11/22/default-web-font-style/ http://dancewithnet.com/2009/11/22/default-web-font-style/#comments Sun, 22 Nov 2009 10:36:22 +0000 秦歌 http://dancewithnet.com/?p=1491 通常用户看到的页面的样式会受到三层控制，第一层是浏览器的默认样式，第二层是网页定义样式，第三层是用户自定义样式。和CSS一样，后面的优先级高于前面的，也就是说网页定义样式可以覆盖浏览器的默认样式，而用户自定义样式优先级最高。实际情况是虽然浏览器都或多或少提供了用户自定义样式的功能，但是极少数会有用户去自定义，一般用也是高级用户。而浏览器默认的样式往往在不同的浏览器、不同的语言版本甚至不同的系统版本都有不同的设置，这就导致如果直接利用默认样式的页面在各个浏览器下显示非常不一致，于是就有了类似YUI的reset之类用来尽量重写浏览器的默认设置保证各个浏览器样式一致性的做法。

拿字体来说，各个浏览器默认的字体种类、字体大小和字体行高都不一样，比如IE8的中文版在Windows XP下显示网页时默认字体是宋体，而英文版肯定不会如此。所以我们需要统一设置默认的字体样式，以便实现一致的显示效果来保证设计的一致性和提高开发效率。

以后准备使用如下默认字体样式：

body{
  font: 12px/1.5 arial;
}

字体：arial

我们页面的绝大部分内容字符都是中文，毫无疑问目前为止在网页上最常用也是最通用的显示中文的字体是宋体，但是宋体在显示英文、数字和英文符号时过于糟糕，比如©字符，所以我们一般期望通过CSS来实现用更好的字体样式来显示它们，然后用宋体来显示中文和中文符号。之所以选择arial是因为：

  1. Windows和Mac都预装了这款字体，应该是使用最广泛的网页字体了。它的潜在对手tahoma和helvetica就没有这么幸运了。
  2. 视觉设计的专业人士可能会认为在Windows中使用tahoma、在Mac中使用helvetica更好，比如淘宝的默认字体样式是font: 12px/1 Tahoma, Helvetica, Arial, "\5b8b\4f53", sans-serif;
    这是一个很不错的选择，但是你也会发现Google、YAHOO、Youtube、Bing甚至MSN的新版都使用arial作为第一默认字体。所以从美观和可读性上来讲arial应该是完全可以接受的。
  3. 一般情况下设置font-family都会在最后设置通用字体族以保证其安全性，比如Google的设置为font-family:arial,sans-serif;，但是至少在非中文版的Win7下当编码是GBK时，IE8会因sans-serif来渲染宋体，导致字体出现变形，这就是为什么淘宝需要在sans-serif前加上宋体而Google无需这样做的原因。
  4. 因为中文字体的选择非常有限，所以目前所有的主流浏览器都设置使用宋体来显示中文。Baidu的首页和搜索结果页使用font-family:arial;可以从侧面说明这样做的安全性。可能有人注意到Firefox中国版默认显示的中文字体是微软雅黑，这是因为谋智网络擅自修改了用户自定义样式，不允许网页的样式覆盖浏览器设置的样式。也是由于类似的情况，我们要弹性设计网页非常重要。

使用英文字体作为第一默认字体会导致的问题之一就是中英文以及符号混排时的对齐问题、通过设置行高和hasLayout能解决绝大部分情况，但是都不会很完美，如果把字体改成“宋体”能彻底的解决问题。很明显，这个问题只出现在IE上。所以，如果你的网站很少使用英文、数字和英文符号，那么直接设置{font-family:\5b8b\4f53;}也是很合理的选择。

大小：12px

  1. 12px是宋体能显示的极限，虽然微软雅黑能显示更小的字体，但目前的应用环境尚未成熟。由于宋体基本上是目前显示中文唯一的通用Web字体，所以12px成为最常用的字体大小。我们当然可以依据产品的需要来修改这个默认值。
  2. 不用考虑基于字体大小（em）的设计。
  3. 在Chrome3.0之后的中文版中，字体大小最小值是12px，比如你设置最小字体为10px，最后也变成12px。

行高：1.5倍

  1. 这是一个经验值，不同的产品对这个值要求可能不同，但我们一般会设置最常用的为默认值。比如YUI的font中是font:13px/1.231 arial,helvetica,clean,sans-serif;即字体大小默认值是13px，行高是13*1.231=16.003px，默认的行高是默认字体的1.231倍。对于中文来说，常用的字体大小12px、14px、16px、18px等偶数大小，在IE6和IE7设置其行高也为偶数能解决一些特殊情况下的字体对其问题。
  2. 在IE6和IE7中，行高值必须大于字体的2px才能保证字体的完整显示或当其作为链接时能有效显示下划线。
  3. 设置line-height时，注意不要使用单位（包括%在内），因为子节点会继承经过运算后的line-height值，所以当使用单位后浏览器会把line-height计算成第一次定义的绝对值，而不会随着字体大小的变化而变化，而无单位的数值表示是所在容器的font-size的倍数，所以设置为无单位的数值是最佳选择。
  4. 深入CSS 行高非常有利于理解line-height，值得一读。

性能和效率

  1. 大部分平台都有arial，减少浏览器的查找时间。
  2. 代码最少，书写方便。arial基本上是名字最短的字体了，可以节约CSS的大小。
  3. 所有的字母都小写，目前Google就是这样做的，好处是既可以编写更快也能提升Gzip压缩的效率。
  4. 中文最好用unicode表示，比如使用宋体是{font-family:\5b8b\4f53;}，使用微软雅黑是{font-family:\5fae\8f6f\96c5\9ed1;}，这样的好处是避免编码问题，同时能得到所有的主流浏览器的支持。
  5. 使用正确的字体种类写法，避免使用引号，这样可以缩小CSS的大小。中文字体可以按上一条方式来编写。

未来

  1. 通过对中英文及符号混排的测试，我发现微软雅黑其实表现相当不错，包括英文数字和英文字符以及在IE6和IE7的显示效果上，但唯一的遗憾是在XP下如果安装了微软雅黑字体的用户没有打开“使用屏幕字体的边缘平滑”选项的话，在Firefox、Safari和Opera、特别是IE6下会非常模糊难以辨认。针对这个问题目前并没有很好的解决方案，所以只有等到IE6使用比率非常小的时候才可能正式的使用它。或许需要到2014年，XP死掉的时候。
  2. 虽然很早就有了@font-face，但是浏览器的支持、网速和商业问题，导致它很少被应用。最近关于字体的好消息是Firefox3.6将支持Web Open Font Forma。关于Web字体未来的相关信息可以看Web 字体的未来、关于 Web 字体：现状与未来和再谈 Web 字体的现状与未来。

最后推荐一下玉伯的《再谈 Web 默认字体》

]]> http://dancewithnet.com/2009/11/22/default-web-font-style/feed/ 45 IE中选择符的4095限制 http://dancewithnet.com/2009/09/10/ie-css-4095-limit/ http://dancewithnet.com/2009/09/10/ie-css-4095-limit/#comments Thu, 10 Sep 2009 15:42:42 +0000 秦歌 http://dancewithnet.com/?p=1471 去年曾总结了《IE对CSS样式表的限制和解决方案》中限制的第4条写道“一个CSS文件的不能超过288kb？”，这是一个疑问句，当时没有重现出来且参考来自Internet Explorer CSS File Size Limit。今天终于看到了IE在CSS上的另一个限制：IE中每个style标签或css文件的选择符个数不能超过4095。其实style属性也应该有这个限制，但是几乎不可能发生。这个限制在IE6、IE7和IE8中存在。请看IE关于4095个选择符限制的DEMO。

DEMO中的style.css有4913个选择符，大小为554kb，但在IE中却在4095个选择符之后失效，所以说明IE的CSS文件不存在不能超过288kb的限制。

所以在IE中对style标签使用addRule方法和cssText属性添加样式时都可能会碰到这个限制，比如使用addRule方法添加第4096个选择符时会报“Invalid Argument”的异常。

]]> http://dancewithnet.com/2009/09/10/ie-css-4095-limit/feed/ 21 CSS实现HTML元素透明的那些事 http://dancewithnet.com/2009/09/06/css-opacity/ http://dancewithnet.com/2009/09/06/css-opacity/#comments Sun, 06 Sep 2009 15:44:00 +0000 秦歌 http://dancewithnet.com/?p=1469 CSS3草案中定义了{opacity:<length> | inherit;}来声明元素的透明度，这已经得到了大多数现代浏览器的支持，而IE则很早通过特定的私有属性filter来实现的，所以HTML元素的透明效果已经无处不在了。首先看看A级浏览器所支持的用CSS实现元素透明的方案：

浏览器 最低
版本		 方案
Internet Explorer 4.0 filter: alpha(opacity=xx);
5.5 filter: progid:DXImageTransform.Microsoft.Alpha(opacity=xx);
8.0 filter: "alpha(opacity=xx)";
filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=xx)";
-ms-filter: "alpha(opacity=xx)";
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=30)";
Firefox (Gecko) 0.9 (1.7) opacity
Opera 9.0 opacity
Safari (WebKit) 1.2 (125) opacity

实际上在IE8中，-ms-filter是filter的别名，两者区别是-ms-filter的属相值必须被单引号或双引号包围，而filter中则不是必须，而在IE8之前的版本中，filter的属性值必须不被单引号或双引号包围。

IE中的HTML元素要实现透明，则其必须具备layout，这样的元素有仅可读的属性hasLayout，且其值为true。具体情况如下：

  1. body、img、table、tr、th、td等元素的hasLayout一直为true。
  2. type为text、button、file或select的input的hasLayout一直为true。
  3. 设置{position:absolute}的元素的hasLayout为true
  4. 设置{float:left|right}的元素的hasLayout为true
  5. 设置{display:inline-block}的元素的hasLayout为true
  6. 设置{height:xx}或{width:xx}的元素必须具体以下两个条件之一，其hasLayout才能为true：
    1. IE8兼容模式和IE8以前的浏览器中，在标准(strict)模式下其display的值是block，如demo3就不行。
    2. 元素在怪癖模式（compat mode）下。
  7. 设置了{zoom:xx}的元素在IE8的兼容模式或IE8之前的浏览器中其hasLayout为true，但在IE8的标准模式下则不会触发hasLayout。
  8. 设置了{writing-mode:tb-rl}的元素的hasLayout为true。
  9. 元素的contentEditable的属性值为true。
  10. 在IE8标准模式下设置了{display:block}的元素的hasLayout一直为true，如demo8。

关于hasLayout的更多详情可以看Exploring Internet Explorer “HasLayout” Overview和On having layout

从上面就可以看出IE实现HTML元素的透明如此混乱，为了向下兼容和自己的私有属性让IE上实现元素透明有多种方式，比如CSS Opacity实例中的demo1到demo8，虽然IE团队推荐实现透明的方式是：

{
  -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
  filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);
  opacity: .5;
}

而目前简单最好用的实现方式是如CSS Opacity中demo4这样：

{
    filter:alpha(opacity=30);
    opacity:.3;
}

实际上目前最流行的JavaScript框架的设置样式方法都是应用这种方式，并且针对IE设置了{zoom:1}来让元素的hasLayout为true，但在IE8的标准模式下zoom并不能触发hasLayout，所以利用它们设置hasLayout为false的元素的透明度时在IE8的标准模式下是失败的，这个bug在YUI（我已经给YUI团队提交了这个bug，他们会在下个版本修复，最新的2.8.0中依旧存在，期待2.9.0吧）、Prototype、jQuery和Mootools的最新版本中都存在，具体请在IE8标准模式下看demo9到demo11。同样由于在IE8中设置透明度的方式多种多样，所以利用JavaScript获取HTML元素的透明度值需要考虑多种情况，YUI完美解决了这个问题，Prototype比jQuery稍微周全一点，而Mootools直接是bug，具体可以在IE下看demo1到demo8的演示。从这个角度给4个框架来个排名的话，YUI第一、Prototype第二、jQuery第三、Mootools垫底。

我简单的实现了设置和获取Opacity的函数，可以避开上面框架存在的bug，请在IE8标准模式下看demo12：

//设置CSS opacity 属性的函数，解决IE8的问题
var setOpacity = function(el,i){
  if(window.getComputedStyle){// for non-IE
    el.style.opacity = i;
  }else if(document.documentElement.currentStyle){ // for IE
    if(!el.currentStyle.hasLayout){
      el.style.zoom = 1;
    }
    if(!el.currentStyle.hasLayout){ //在IE8中zoom不生效，所以再次设置inline-block
      el.style.display = 'inline-block';
    }
    try{
      //测试是否已有filter
      //http://msdn.microsoft.com/en-us/library/ms532847%28VS.85%29.aspx
      if(el.filters){
        if(el.filters('alpha')){
	  el.filters('alpha').opacity = i * 100;
	}else{
	  el.style.filter += 'alpha(opacity='+ i * 100 +')';
	 }
       }
    }catch(e){
      el.style.filter = 'alpha(opacity='+ i * 100 +')';
    }
  }
}

//获取CSS opacity 属性值的函数
//借鉴自http://developer.yahoel.com/yui/docs/YAHOO.util.Dom.html#method_getStyle
var getOpacity = function(el){
  var value;
  if(window.getComputedStyle){
    value = el.style.opacity;
    if(!value){
      value = el.ownerDocument.defaultView.getComputedStyle(el,null)['opacity'];
    }
    return value;
  }else if(document.documentElement.currentStyle){
    value = 100;
    try { // will error if no DXImageTransform
        value = el.filters['DXImageTransform.Microsoft.Alpha'].opacity;
    } catch(e) {
        try { // make sure its in the document
            value = el.filters('alpha').opacity;
        } catch(err) {
        }
    }
    return value / 100;
  }
}

不得不说，这些事都是IE整出来的……

]]> http://dancewithnet.com/2009/09/06/css-opacity/feed/ 36 Data URI 和 MHTML http://dancewithnet.com/2009/08/15/data-uri-mhtml/ http://dancewithnet.com/2009/08/15/data-uri-mhtml/#comments Fri, 14 Aug 2009 16:54:53 +0000 秦歌 http://dancewithnet.com/?p=1463 Data URI

Data URI是由RFC 2397定义的一种把小文件直接嵌入文档的方案。通过如下语法就可以把小文件变成指定编码直接嵌入到页面中：

data:[<MIME-type>][;base64],<data>
  1. MIME-type：指定嵌入数据的MIME。其形式是[type]/[subtype]; parameter，比如png图片对应的MIME是image/png。parameter可以用來指定附加的信息，更多情況下是用于指定text/plain和text/htm等的文字编码方式的charset参数。默认是text/plain;charset=US-ASCII。
  2. base64：声明后面的数据的编码是base64的，否则数据必须要用百分号编码（即对内容进行urlencode）。

在上个世纪HTML4.01引入了Data URI方案，到今天为止除了IE6和IE7之外，所有主流浏览器都支持，但IE8对Data URI的支持还是有限制的，只支持object（仅是图片时）、img、input type=image、link和CSS中的URL，且数据量不能大于32K。

优点：

  1. 减少HTTP请求数，没有了TCP连接消耗和同一域名下浏览器的并发数限制。
  2. 对于小文件会降低带宽。虽然编码后数据量会增加，但是却减少了http头，当http头的数据量大于文件编码的增量，那么就会降低带宽。
  3. 对于HTTPS站点，HTTPS和HTTP混用会有安全提示，而HTTPS相对于HTTP来讲开销要大更多，所以Data URI在这方面的优势更明显。
  4. 可以把整个多媒体页面保存为一个文件。

缺点：

  1. 无法被重复利用，同一个文档应用多次同一个内容，则需要重复多次，数据量大量增加，增加了下载时间。
  2. 无法被独自缓存，所以其包含文档重新加载时，它也要重新加载。
  3. 客户端需要重新解码和显示，增加了点消耗。
  4. 不支持数据压缩，base64编码会增加1/3大小，而urlencode后数据量会增加更多。
  5. 不利于安全软件的过滤，同时也存在一定的安全隐患。

MHTML

MHTML是MIME HTML (Multipurpose Internet Mail Extension HTML)的缩写，是由RFC 2557定义的把一个多媒体的页面所有内容都保存到同一个文档解决方案。这个方案是由微软提出从IE5.0开始支持，另外Opera9.0也开始支持，Safari可以把文件保存为.mht（MHTML文件的后缀）格式，但不支持显示它。

MHTML和Data URI还比较类似，有更强大的功能和更复杂的语法，并且没有Data URI中“无法被重复利用”的缺点，但MHTML使用起来不够灵活方便，比如对资源引用的URL在mht文件中可以是相对地址，否则必须是绝对地址。hedger在《Cross Browser Base64 Encoded Images Embedded in HTML》针对IE的解决方案使用的是相对路径就是因为声明了Content-type:message/rfc822使IE按照MHTML来解析，如果不修改Content-type则需要使用MHTML协议，这个时候必须使用绝对路径，如《MHTML – when you need data: URIs in IE7 and under》。

应用

Data URI和MHTML两者的配合可以完整的解决所有的主流浏览器，它们由于无法被缓存和重复利用的缺陷，所以并不适合直接在页面中使用，但在CSS和JavaScript文件中对图片适当地使用有非常大的优越性：

  1. 大大减少请求数，现在大型网站的CSS引用了大量的图片资源。
  2. CSS和JavaScript都可以被缓存，间接的实现了数据的缓存。
  3. 利用CSS可以解决Data URI的重复利用问题
  4. 告别CSS Sprites，CSS Sprites的出现是为了减少请求数，但它除了带来在不确定情况下的异常外，CSS Sprites还需要人为的图片合并，即使有合并工具也依旧必须人为地在如何有效的拼图上耗费大量的时间，并带来维护的困难。当你遵循一定的设计原则后，你就可以完全抛弃CSS Sprites来编写CSS，最后使用工具在上传到服务器环节把图片转换成Data URI和MHTML，如《利用data-uri合并样式表和图片》中用python实现的工具，这可以节约大量的时间。
  5. base64编码把图片文件增加了1/3，Data URI和MHTML同时使用相当于增加了2/3，但CSS和JavaScript可以使用gzip压缩，其可以节省2/3的数据量，所以使用gzip压缩后的最终数据量是(1 + 1/3) * 2 * (1/3) = 8/9，所以最终流量是减少的。

为了方便在CSS中实现Data URI和MHTML，我写了一个Data URI & MHTML 生成器，你可以看利用其生成Data URI & MHTML应用实例。

在CSS文件中使用应用MHTML时URL必须使用绝对路径，导致非常不灵活，所以可以考虑使用CSS expression来解决（DEMO），比如：

   /*

http://old9.blogsome.com/2008/10/26/css-expression-reloaded/

http://dancewithnet.com/2009/07/27/get-right-url-from-html/

   */
  *background-image:expression(function(ele){
    ele.style.backgroundImage = 'url(mhtml:' +
         document.getElementById('data-uri-css').getAttribute('href',4) +
         '!03114501408821761.gif)';
   }(this));
]]> http://dancewithnet.com/2009/08/15/data-uri-mhtml/feed/ 36 用doctype激活浏览器模式 http://dancewithnet.com/2009/06/14/activating-browser-modes-with-doctype/ http://dancewithnet.com/2009/06/14/activating-browser-modes-with-doctype/#comments Sun, 14 Jun 2009 07:19:36 +0000 秦歌 http://dancewithnet.com/?p=1457 为了处理根据Web标准创作的网页和根据在20世纪90年代末流行的陈旧实践创作的网页，现代的Web浏览器实现了各种不同的引擎模式。本文说明了那些模式是什么以及如何触发它们。

原文：Henri Sivonen的Activating Browser Modes with Doctype2009.05.19

文档范围

本文包括的模式转换（mode switching）适用于Firefox和其他基于Gecko的浏览器，Safari、Chrome和其他基于Webkit的浏览器，Opera、 Konqueror、Mac版Internet Explorer、Windows版Internet Explorer和内嵌IE的浏览器。避免提及浏览器引擎的名字，取而代之的是使用该引擎最知名浏览器的名字。

本文着重介绍模式的选择机制，而不是记录每个模式的确切行为。

模式

以下是各种不同的模式：

内容类型为text/html的模式

text/html内容的模式选择取决于doctype嗅探（doctype sniffing，本文后面有讨论）。在IE8中，模式也取决于其他因素。然而在IE8的默认情况下，那些不在微软提供黑名单上的非局域网（non- intranet）站点的模式取决于文档类型。

再怎么强调每个浏览器中模式精确行为的不同也是不过分的，即使本文中进行了统一的讨论。

怪癖模式（Quirks Mode）
怪癖模式中，为了避免“破坏”那些根据在20世纪90年代末流行的实践创作的页面，浏览器违反了现代的Web格式规范。不同的浏览器实现了不同的怪癖行为。Internet Explorer6、7和8中，怪癖模式有效地冻结在IE5.5 。其他浏览器中，怪癖模式是对准标准模式的少量偏移。
如果正在创作新网页，你应该符合相关的规范（特别是CSS2.1）且使用标准模式。
标准模式（Standards Mode）
标准模式中，浏览器尝试给符合标准的文档在规范上的正确处理达到在指定浏览器中的程度。
不同的浏览器遵循不同的阶段，所以标准模式也不是一个单一目标。
HTML5把这种模式叫“非怪癖模式（no quirks mode）”
准标准模式（Almost Standards Mode）
irefox、Safari、Chrome、Opera(从7.5开始)和IE8也有个叫“准标准模式”的模式，它按照传统的做法来实现表格单元格的垂直尺寸而不是严格的遵照CSS2规范。Mac IE5、Windows IE6和7、Opera7.5以前版本和Konqueror无需准标准模式，因为它们至少没有在各自的标准模式下严格遵循CSS2规范来实现表格单元格垂直尺寸。实际上，它们的标准模式更接近Mozilla的准标准模式而不是Mozilla的标准模式。
HTML5把这种模式叫着“受限怪癖模式(limited quirks mode)”。
IE7模式
IE8有个模式主要是冻结了IE7标准模式的副本。其他浏览器没有像这样的模式，且该模式也未被HTML5指定。

内容类型为application/xhtml+xml的模式（XML模式）

Firefox、Safari、Chrome和Opera中，application/xhtml+xml HTTP内容类型（不是meta元素也不是doctype!）会触发XML模式。在XML模式中，浏览器尝试给XML文档在规范上的正确处理达到在制定浏览器中的程度。

IE6、7和8不支持application/xhtml+xml，Mac IE5也如此。

基于WebKit的Nokia S60 浏览器中，application/xhtml+xml HTTP内容类型不能触发XML模式，因为在移动的围墙花园（mobile walled gardens）中关注点是对不规范内容的兼容性。（旧式的“移动浏览器”无法使用真正的XML解析器，因为不规范内容已被标记为XML。）

由于没有充分地测试Konqueror，我无法确切说出在这个浏览器中会发生什么。

非Web模式（Non-Web Modes）

某些引擎拥有的模式与Web内容无关。为了完整性，它们仅仅在这里被提到。Opera有个WML2.0模式。Leopard上的WebKit有个用于旧式Dashboard widgets的特定模式。

影响

以下是这些模式的主要影响：

布局

text/html的模式主要是影响CSS布局。例如，表格不继承样式是个怪癖。在某些浏览器的怪癖模式下，盒模型（box model）变成IE5.5的盒模型。本文档没有列举出所有的布局怪癖。

准标准模式（有这种模式的浏览器中）中，仅包含图片的表格单元格的高和标准模式中不同。

XML模式中，选择器有不同的区分大小写行为。此外，用于HTML body元素的特有规则不能应用在那些没有实现最新CSS2.1改变的较旧版本的浏览器。

解析

也有一些怪癖影响HTML和CSS的解析且会导致符合标准的网页被错误解析。怪癖布局决定了这些怪癖是否开启。无论如何，了解怪癖模式和标准模式在CSS布局和解析（非HTML解析）上的主要异同是非常重要的。

一些人错误地把标准模式称为“严格解析模式（strict parsing mode）”，其让人误解了浏览器强制执行HTML语法规则和用浏览器评估标记的正确性。情况并非如此。即使当标准模式布局生效时，浏览器依旧会做标签杂烩汤（tag soup，http://en.wikipedia.org/wiki/Tag_soup）修正工作。（在2000年Netscape6发布前，Mozilla的确有用于强制执行HTML语法规则的解析模式。这些模式和现有的Web内容不兼容而被遗弃。）

另一个常见的误解是关于XHTML解析的。通常认为用XHTML doctype得到不同的解析。其实并非如此，内容类型是text/html的XHTML文档所用解析器和HTML文档的是同一个。目前浏览器在意的是文档类型为text/html的XHTML仅是“撒面包丁的标签杂烩汤（tag soup with croutons）”（到处是额外的斜线）。

仅当使用XML文档类型的文档（例如：application/xhtml+xml或xmapplication/）会触发XML模式来解析，这时的解析器完全不同于HTML解析器。

脚本

虽然怪癖模式主要是关于CSS的，但也有一些是关于脚本的。例如，Firefox的怪癖模式中，HTML id 属性像在IE一样建立了全局脚本作用域的对象引用。IE8中关于脚本的影响比其他浏览器更值得关注。

XML模式中，某些DOM API的行为彻底不同，因为XML的DOM API行为被定义时不兼容HTML的行为。

doctype嗅探（也叫doctype转换）

现代浏览器使用doctype嗅探来决定text/html文档的引擎模式。这意味着模式的选择是基于HTML文档开始的文档类型声明（或缺少）。（这不适于使用XML文档类型的文档。）

文档类型声明（doctype）是SGML的语法伪造，SGML是个旧式的标记框架，HTML5之前的HTML就是依据其定义的。HTML4.01规范中，文档类型声明描述的是HTML的版本信息。尽管名字叫“文档类型声明”且HTML 4.01规范所描述的是关于“版本信息”，文档类型声明并不适用把SGML或XML文档分类为特定类型的文档，即使它看起来像是（因为名字）。（更多内容在附录中）

HTML4.01规范和ISO 8879（SGML）都没有说关于使用文档类型声明作为引擎模式转换的任何事情。doctype嗅探是基于观察，在doctype嗅探被设计时，绝大部分的怪癖文档既没有文档类型声明也没有引用旧的DTD。HTML5接受这个事实，且定义了text/html中doctype作为唯一的模式转换。

典型的预HTML5（pre-HTML5）文档类型声明包含（被空白分开）“<!DOCTYPE”字符串，根元素（“html”）的通用标识符， “PUBLIC”字符串，处于引号中的DTD公共标识符，同一DTD的可能系统标识符（URL）和字符 “>”。文档类型声明位于文档的根元素开始标签之前。

选择doctype

text/html

下面是创建新的text/html文档时如何选择doctype的简单指南：

标准模式，最前沿的验证
<!DOCTYPE html>
如果想验证诸如<video>、<canvas>和ARIA这样的新特性，那么这样做是对的。注意，HTML5的有效定义依旧在变化中，请确保在Firefox、Safari、Chrome、Opera9或Opera10中测试图像对齐。在Internet Explorer中测试图像对齐是不足够的，无论如何请确保在IE8中也进行了测试。
标准模式，更稳定的验证目标
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
这个doctype也会触发标准模式，且10岁大的HTML4.01有效定义是稳定的。请确保在Firefox、Safari、Chrome、 Opera9或Opera10中测试图像对齐。在Internet Explorer中测试图像对齐是不足够的，无论如何请确保在IE8中也进行了测试。
要使用标准模式，但仍要验证不推荐标记或在表格布局中使用切片图像且不想去修复它们。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
它会触发准标准模式（和老掉牙的Mozilla中的完全标准模式full Standards mode）。请注意，如果以后移植到HTML5上，基于利用表格实现的切片图像的布局可能会被破坏（且完整标准模式也如此）。
故意要使用怪癖模式
没有doctype。
请别这样做。故意为怪癖模式所做的设计将会困扰你，在将来你的同事或继任者甚至没有人关心Windows IE6（Netscape4.x和IE5已经没有人关心了）。为怪癖模式设计是个坏主意。相信我。
如果你想依旧支持Windows IE6，对它做一个特别的hack使用条件注释比使其他浏览器退步到怪癖模式好。

我不推荐任何的XHTML doctype，因为XHTML被用作text/html被认为是有害的。无论如何，如果你选择使用XHTML doctype，请注意XML声明会使IE6（但不是IE7！）触发怪癖模式。

application/xhtml+xml

对application/xhtml+xml的简单指南是绝不使用doctype。该方式下的网页不是“严格一致”的XHMTL1.0，但这并不重要。（请看后面的附录）

IE8 并发症

A List Apart 曾介绍 ，IE8除doctype外会使用基于meta元素的模式转换作为模式选择的因素之一。（请看Ian Hickson、David Baron、David Baron again、Robert O’Callahan 和 Maciej Stachowiak的评论。）

IE8有4种模式：IE5.5怪癖模式、IE7标准模式、IE8 准标准模式 和IE8标准模式。模式的选择取决于来自几个方面的数据：doctype、meta元素、HTTP头、来自微软的定期下载数据、局域网域、用户所做设置、局域网管理员所做设置、父框架的模式（如果有）和地址栏兼容视图按钮被用户触发。（对于嵌入该引擎的其他应用，模式也取决于嵌入的应用。）

幸运的是如果出现下列情况，IE8大体上会像其他浏览器一样使用doctype嗅探：

  • 作者没有设置X-UA-Compatible HTTP头
  • 作者没有设置X-UA-Compatible meta标签
  • 微软没有在黑名单中放置该站点的域名
  • 局域网管理员没有把该站点放置到黑名单上
  • 用户没有按下兼容视图按钮（Compatibility View button） (或以其他方式添加到某个特定的用户黑名单中)
  • 该站点不在局域网域中
  • 用户没有选择在IE7中显示所有站点
  • 页面没有通过frame嵌入到兼容模式的页面中

上述除两个关于X-UA-Compatible的情况外，IE8像IE7一样执行doctype嗅探。IE7仿真（ IE7 emulation）叫兼容视图。

在 X-UA-Compatible 情况下，IE8的行为和其他浏览器完全不同。想看本页的附录或PDF和PNG格式的流程图。

不幸的是，没有 X-UA-Compatible的HTTP头或meta标签，即使使用了合适的doctype，IE8让用户无意间使页面从IE8的标准模式降到IE7模式，这是一种仿真的IE7标准模式。更糟糕的是，局域网管理员也可以这么做。微软也可以把你所用的所有域名到列入黑名单。

为了对付这些影响，doctype是不够的，你需要X-UA-Compatible HTTP头和meta标签。

下面的简单指南是针对已经有doctype在其他浏览器触发标准模式或者准标准模式的新的text/html文档如何选择X-UA-Compatible HTTP头或meta标签的：

你的域名没有在微软的黑名单上，你更关注是没有浏览器专属的令人讨厌的东西而不是确保用户无法回退去呈现IE7的行为。
你不需要包括X-UA-Compatible HTTP头或meta标签。
你的域名在微软的黑名单中，由于你域名中的其他作者破坏了站点或许导致用户对整个域启用了兼容视图，你担心Google或Digg用frame嵌入你的站点或你想确保用户无法使用兼容视图
首先，在你的页面包含后面的meta元素（它在HTML5中是非法的） <meta http-equiv="X-UA-Compatible" content="IE=Edge"> （在任何脚本元素前），或者设置后面的HTTP头：X-UA-Compatible: IE=Edge
你的站点在IE7中工作但在IE8中破坏
首先，在你的页面包含后面的meta元素（它在HTML5中是非法的）（在任何脚本元素前），或者设置后面的HTTP头： X-UA-Compatible: IE=EmulateIE7，然后修复你的站点不依赖非标准的IE7行为和迁移到IE=Edge。

相关链接

补遗：对XML的实现者和规范作者的恳求

请不要把doctype嗅探带到XML。

doctype嗅探是用签杂烩汤似的方法解决一个标签杂烩汤问题。doctype嗅探是在HTML4和CSS2规范发布后设计的一种试探方法，它从文档中区分出过时文档以符合其作者可能期望的行为。

偶尔有人建议在XML上使用doctype嗅探来调度不同的处理、识别正在使用的词汇表或激活特性。这是个坏主意。调度和词汇表识别应该是基于名字空间的，而特性激活应该是基于明确的处理指令或元素。

良构（well-formedness）的整个思想是介绍允许XML的无DTD解析，且推广无doctype文档。在正式情况下，两个XML文档有相同的规范形式且应用不同地处理它们（且不同之处并非因为没有选择处理外部实体），这个应用或许被破坏了。在实践情况下，如果两个XML文档导致同样的内容被报告（qnames忽略）给SAX2内容处理器且应用不同地处理文档，这个应用或者被破坏了。考虑到作为 Web作者无法相信每个人都会使用解决额外实体的XMLprocessor来解析其页面（即使一些浏览器看起来这样做，因为它们会映射一定公共的标识符到一个有删节的定义实体的DTD），插入doctype到XML中用于Web是毫无意义的且通常会导致货运崇拜（cargo cultish）习惯。(您仍然使用W3C验证器的DTD覆盖功能来对一个DTD进行验证，虽然W3C验证器会说结果仅仅是暂时有效。或更好的是，你可以用放宽NG验证，它不会污染模式引用的文档。)为了嗅探而要求doctype是非常愚蠢的，即使那是在HTML实践中的解决方法。

此外，当低级别的规范定义两个相等的东西时，高级别的规范不应该尝试给它们不同的含义。请考虑<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">。如果删除公共标识符，依旧指定了同样的DTD，因此doctype <!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">表示和前面的doctype一样。应该不同地嗅探它们么？可以进一步理论。假设复制给example.com一个叫foobar.dtd的DTD：<!DOCTYPE html SYSTEM "http://example.com/foobar.dtd">。这该如何嗅探？应该是同一个意思。甚至整个DTD可以贴在文档中。

换句话说，如果有#include “foo.h”，你不应该给名字foo.h绑定任何black magic，因为它应该允许复制foo.h的内容到文档中或复制foo.h到bar.h中且表示#include “bar.h”。

我不担心HTML和SGML构造相同的参数的原因是Web浏览器不会使用真正的SGML解析器去解析HTML，所以我认为伪装成SGML进行处理是没有用的。无论如何，如果你还不相信，请看W. Eliot Kimber关于此事的文章 comp.text.sgml

附录：text/html中一些doctype的处理方式

下表中，怪癖模式、标准模式和准标准分别表示为Q、S和A。当浏览器仅有两种模式时，如果表格单元格的行高和Mozilla的标准模式表现一致时，标准模式标记为“S”，如果表格单元格的行高和Mozilla的准标准模式表现一致时，则标记为“A”。

请注意使用XML内容模型提供服务的XHTML在XML模式下渲染。

本表的目的并不是说表中所有的doctype都是新建页面的合理选择。本表的目的是为了展示我的推荐是依据什么样的数据。

下列的简写符号是用于列标题：

NS6
Mozilla 0.6…0.9.4 和 Netscape 6.0…6.2.3
Old Moz
Mozilla 0.9.5 到 1.1 alpha 和 Mozilla 1.0
Moz & Safari & Opera 10 & HTML5
Mozilla 1.0.1, Mozilla 1.1 beta和更高版本, Firefox 到 Netscape 7, Safari 0.9 到 Safari 4.0 beta, Opera 10, Chrome, Konqueror 3.5, HTML5指定的行为
Opera 9.0
Opera 9.0…9.20
IE 8 & Opera 9.5
无 X-UA-Compatible和兼容模式覆盖的默认IE8（该情况下“A”意味着IE8准标准模式）、 Opera 7.5…8.54 和 9.5…9.6
IE 7 & Opera 7.10
IE7、兼容模式且无X-UA-Compatible覆盖的IE8（这种情况下“A”意味IE7模式）和Opera 7.10…7.23
IE 6 & Opera 7.0
Windows IE 6 和 Opera 7.0…7.03
Mac IE 5
Mac IE 5.0…5.2.3
Konq 3.2
Konqueror 3.2.2…3.3 (也可能包括 3.1…3.2.1; 我尚未确定)
Doctype NS6 Old Moz Moz & Safari & Opera10 & HTML5 Opera9.0 IE8 & Opera9.5 IE7 & Opera7.10 IE6 & Opera7.0 Mac IE5 Konq3.2
None Q Q Q Q Q Q Q Q Q
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> 		Q Q Q Q Q Q Q Q Q
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> 		S S S S S A A A A
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> 		S S S S S A A Q A
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/html4/strict.dtd"> 		S S S S S A A A A
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> 		S S S S S A A A A
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 		Q Q Q Q Q Q Q Q Q
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 		Q Q Q Q Q Q Q Q Q
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"> 		S S A A A A A A Q
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

 Q S A A A A A A Q
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"> 		Q Q Q Q A A A A Q
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> S S S S S A A A A
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> S S S S S A A A A
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 		S S S S S A A A A
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 		S S A A A A A A Q
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> S S S S S A Q A Q
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> S S S S S A Q A Q
<?xml
version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 		S S S S S A Q A Q
<?xml
version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

 S S A A A A Q A Q
<!DOCTYPE
HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN"> 		Q S S Q Q Q Q Q Q
<!DOCTYPE
HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup
Language//EN"> 		Q S S S S A A A Q
<!DOCTYPE
HTML PUBLIC "ISO/IEC 15445:1999//DTD HTML//EN"> 		S S S Q Q Q Q Q Q
<!DOCTYPE
HTML PUBLIC "ISO/IEC 15445:1999//DTD HyperText Markup
Language//EN"> 		S S S S S A A A Q
<!DOCTYPE html> Q S S S S A A A

历史记录

Moziila的doctype嗅探代码在2000年10月、2001年9月和2002年6月有大幅度的修改。本文档描述的Mozilla（和 Netscape 6.x）建立的状态可以自2000.10.19起在ftp.mozilla.org上看到。本文档未涉及Mozilla M18（和Netscape 6.0 PR3）中的doctype嗅探的工作方式。Safari的doctype嗅探代码自第一个公开的测试版起也有大幅度的修改。本文档不包括比版本V73也叫0.9更早的行为。

Konqueror3.5之前的doctype嗅探代码似乎来自于Safari的很早的一个版本。Konqueror现在和Safari匹配，其doctype嗅探代码来自Mozilla。

从表中可见，Opera的doctype嗅探正由规律的从类似IE向类似Mozilla转变，虽然Opera9.5和9.6在倒退的路上。同时，Opera怪癖模式的布局行为已从仿效IE6的怪癖模式转换到Mozilla的怪癖模式。

附录：IE8的模式选择

开始：进入“X-UA-Compatible meta?”
X-UA-Compatible meta?
IE=7：使用IE7标准
IE=EmulateIE7: 进入“怪癖或无doctype?(兼容模式)”
IE=IE8 或 IE=IE7 或 IE=a 或 IE=EmulateIE8 或没有或首先出现 script：进入”X-UA-Compatible HTTP头?”
IE=8 或 IE=Edge 或 IE=99 或 IE=9.9：进入“准标准模式?”
IE=5：使用怪癖模式（IE5.5）
X-UA-Compatible HTTP头?
IE=7：使用IE7标准模式
IE=EmulateIE7：进入“怪癖或无doctype？（兼容模式）”
IE=IE8 或 IE=IE7 或 IE=a 或 IE=EmulateIE8 或没有：进入“显示所有站点…预设置？”
IE=8 或 IE=Edge 或 IE=99 或 IE=9.9：进入“准标准模式？”
IE=5：使用怪癖模式（IE5.5）
怪癖模式或无doctype?(兼容模式)
是：使用怪癖模式（IE5.5）
否：使用IE7标准模式
显示所有站点…预设置？
是：进入“怪癖模式或无doctype?(兼容模式)”
否：进入“显示局域网站点…预设置？”
显示局域网站点…预设置？
是：进入“站点位于局域网域？”
否：进入“域名在微软维护的名单上？”
域名在微软维护的名单上？
是：进入“怪癖模式或无doctype?(兼容模式)”
否：进入“被兼容模式页面用Frame嵌入？”
被兼容模式页面用Frame嵌入？
是：进入“怪癖模式或无doctype?(兼容模式)”
否：进入“按下了兼容模式按钮？”
按下了兼容模式按钮？
是：进入“怪癖模式或无doctype?(兼容模式)”
否：进入“怪癖模式或无doctype?(IE8)”
怪癖模式或无doctype?(IE8)
是：进入“使用怪癖模式（IE5.5）”
否：进入“准标准模式？”
准标准模式？
是：使用IE8准标准模式
否：使用IE8标准模式

这些步骤都可以通过PDF和PNG格式的流程图看到。

鸣谢

感谢Simon Pieters、Simon Pieters和Anne van Kesteren帮助我改正了各种Opera版本的模式表和他们的评论。感谢Simon Pieters制作了另一份IE8的流程图。

]]> http://dancewithnet.com/2009/06/14/activating-browser-modes-with-doctype/feed/ 39 border-radius与圆角 http://dancewithnet.com/2008/12/27/border-radius-and-rounded-corner/ http://dancewithnet.com/2008/12/27/border-radius-and-rounded-corner/#comments Sat, 27 Dec 2008 11:25:55 +0000 秦歌 http://dancewithnet.com/?p=1412 两年前发表的《The visual design of Web 2.0》中提到“Rounded everything”，圆角因使人感觉舒适的友好风格而变得无处不在。这个无处不在也让很多前端工程师累个半死，YAHOO Performance Research Engneer Team的Nicole在讲演《Designing Fast Websites》中用的副标题是don’t blame the rounded corners!，从侧面也说明了圆角给实现者带来的困扰：实现麻烦、兼容困难、性能不佳。而W3C早在2002年的CSS3草案中就加入了一个叫border-radius的属性，通过它可以直接来定义HTML元素的圆角。

CSS3的border-radius规范

最新草案中其主要信息如下：

  1. 属性：border-top-right-radius
    　　　border-bottom-right-radius
    　　　border-bottom-right-radius
    　　　border-bottom-right-radius
    值：<length> <length>?。它们分别是定义角形状的四分之一椭圆的两个半径。如图：
    border-radius

    1. 第一个值是水平半径。
    2. 如果第二个值省略，则它等于第一个值，这时这个角就是一个四分之一圆角。
    3. 如果任意一个值为0，则这个角是矩形，不会是圆的。
    4. 值不允许是负值。
  2. 属性：border-radius。它是上面四个属性值的简写。
    值：<length>{1,4} [ / <length>{1,4} ]?

    1. 如果斜线前后的值都存在，那么斜线前的值设置水平半径，且斜线后的值设置垂直半径。如果没有斜线，则水平半径和垂直半径相等。
    2. 四个值是按照top-left、top-right、 bottom-right、 bottom-left的顺序来设置的。如果bottom-left省略，那么它等于top-right。如果bottom-right省略，那么它等于top-left。如果top-right省略，那么它等于top-left。
  3. 应用范围：所有的元素，除了table的样式属性border-collapse是collapse时
  4. 内边半径等于外边半径减去对应边的厚度。当这个结果是负值时，内边半径是0。所以内外边曲线的圆心并不一定是一致的。
  5. border-radius也会导致该元素的背景也是圆的，即使border是none。如果background-clip是padding-box，则背景（background）会被曲线的内边裁剪。如果是border-box则被外边裁剪。border和padding定义的区域也一样会被曲线裁剪。
  6. 所有的边框样式（solid、dotted、inset等）都遵照角的曲线。如果设置了border-image，则曲线以外的部分会被裁剪掉。
  7. 如果角的两个相邻边有不同的宽度，那么这个角将会从宽的边平滑过度到窄的边。其中一条边甚至可以是0。
  8. 两条相邻边颜色和样式转变的中心点是在一个和两边宽度成正比的角上。比如，两条边宽度相同，这个点就是一个45°的角上，如果一条边是另外一条边的两倍，那么这个点就在一个30°的角上。界定这个转变的线就是连接在内外曲线上的两个点的直线
  9. 角不允许相互重叠，所以当相邻两个角半径的和大于所在矩形区域的大小时，用户代理（浏览器）比如缩小一个或多个角半径。运算法则如下：f = min(Li/Si)，i ∈ {top, right, bottom, left}，Ltop = Lbottom = 所在矩形区域的宽，Lleft = Lright = 所在矩形区域的高。如果f < 1，那么所有角半径都乘以f。

浏览器支持

实际中，目前没有任何一款浏览器支持这个属性，只有部分浏览器利用其私有属性支持部分实现：

  1. Firefox对border-radius的支持： 
    -moz-border-radius: <length>{1,4} | inherit
-moz-border-radius-bottomleft : <length> | inherit
-moz-border-radius-bottomright  : <length> | inherit
-moz-border-radius-topleft  : <length> | inherit
-moz-border-radius-topright : <length> | inherit
    1. 只对每个角设置一个半径，只支持实现四分之一圆角，并不支持椭圆形圆角。
    2. 具体每个角的命名规则也和W3C不一致，这个比较讨厌。
    3. Firefox3圆角已经相当圆滑了，Firefox2比较糟糕，好在它即将终结了。
  2. Safari和Chrome对border-radius的支持： 
    -webkit-border-radius: <length>{1,2} | inherit
-webkit-border-bottom-left-radius : <length>{1,2} | inherit
-webkit-border-bottom-right-radius : <length>{1,2} | inherit
-webkit-border-top-left-radius  : <length>{1,2} | inherit
-webkit-border-top-right-radius : <length>{1,2} | inherit
    1. 每个属性有1个或2个值，当有两个值时1个表示水平半径，一个表示垂直半径（当writing-mode改变也随之而变）。所以，Safari和Chrome中的圆角可以是椭圆角。
    2. webkit的实现方法和W3C的CSS3草案2005年版本非常一致，和当前的草案最大不同就是简写属性-webkit-border-radius的属性值也只有1个或2个值，意义和前面相同。
    3. Chrome中圆角锯齿比较严重，基本上和Firefox2是同一水平，或许是它的webkit版本较低造成的。
    4. 由于webkit出生于khtml，所以把 上面属性中的webkit换成khtml即会得到以khtml为核心的浏览器支持的属性了。
    5. 当相邻的角半径之和大于所在矩形区域的大小时，都会直接设置所有的角半径为0，即圆角失效，而不会像Firefox那样同比率缩小。
  3. Opera尚不支持border-radius，虽然Opera10 alpha拥有众多的CSS3改进，但是依旧看不到对其支持的希望。
  4. IE就不用说了，标准的不支持了。从MSDN的CSS Compatibility and Internet Explorer中可以看出IE8已经铁定不支持了。

实际应用

最简单的应用就是支持的用圆角，不支持的用方角。比如Wordpress2.7的后台、雅虎口碑UED的blog和今天你带伞了吗?。基础代码如下：


border-width: 1px;
border-style: solid;
-moz-border-radius: 11px;
-khtml-border-radius: 11px;
-webkit-border-radius: 11px;
border-radius: 11px;

实现请看演示实例。

利用VML可以实现从IE5-7的圆角，但是貌似IE8不支持VML了。组件DD_roundies就是综合以上解决方案的一个具体应用。说实话这样实现出来的圆角也比较粗糙了，我感觉还不如不要。

像VML一样，Canvas也能实现圆角，切除了IE外，所有的主流浏览器都支持。所以就有了两者结合实现的组件Cornerz。

如果上面的现实太痛苦，而又非要用圆角的话，要么一个像素一个像素去拼装，比如Chunky Borders；要么就老老实实用图片来实现吧，比如CSS Mojo的方式。

]]> http://dancewithnet.com/2008/12/27/border-radius-and-rounded-corner/feed/ 11 连续字符自动换行的解决方案 http://dancewithnet.com/2008/12/04/word-break-all/ http://dancewithnet.com/2008/12/04/word-break-all/#comments Wed, 03 Dec 2008 16:16:50 +0000 秦歌 http://dancewithnet.com/?p=1386 文本的排版依据语言的不同会有一些格式上的要求，比如简体中文中类似逗号、分号等标点符号不会出现在一行的开头，对于英文来讲就是一个完整单词不会在两行显示，浏览器会依据类似这样的原则来显示文本。但是由于网页有宽度限制的，连续的超长的字母、数字或标点符号超出其所在区域宽度的限制而导致影响页面视觉，如例1所示。这个问题在显示用户输入信息时尤为突出，这里就是要说如何解决这个问题。

在CSS3草案中，对文本的处理新增了两个新属性word-wrap和word-break来解决这个问题：

  1. {word-break:break-all;} ：依照亚洲语言和非亚洲语言的文本规则，允许在字内换行，且允许非亚洲语言文本行的任意字内断开
  2. {word-wrap:break-word;}： 内容将在边界内换行，如需要则词内换行（word-break）也行发生

下面是常见浏览器的支持情况：

IE6/7/8[1] Firefox2/3[2] Firefox3.5 Opera9+ Safari9.5+/Chrome
{word-wrap:break-word;} td元素需设置其宽度
见例4和例5		 不支持 不支持td元素
见例4和例5		 不支持 不支持td元素
见例4和例5
{word-break:break-all;} 不支持连续的符号
见例3		 不支持 不支持连续的符号
见例3		 不支持 支持
  • [1] 在MSDN的CSS Compatibility and Internet Explorer中可以看出，IE8会像IE6和IE7一样支持word-wrap和word-break这两个属性，但我在IE8beta2上测试来看却不支持这两项，由于IE8还处于beta阶段，且我相信IE8最终会支持的，所以在页头声明<meta content="IE=7" http-equiv="X-UA-Compatible" />使IE8按照IE7来解释页面是一个不错的办法。IE8正式版支持
  • [2] Firefox3.1将会支持word-wrap属性Firefox3.5beta4已经支持

由于{word-break:break-all;}导致英文和数字可读性严重下降且无法使连续符号换行，所以{word-wrap:break-word;}是一个相对较好的选择。需要注意的是各个浏览器中word-wrap在td上实现不一致，所以避免直接在td上使用。

但面对浏览器的如此糟糕支持，所以不能不借助JavaScript来解决这个问题，即当浏览器不支持CSS解决方案时，在连续字符串的适当位置插入&#8203;字符（当然还可以用<wbr />和&shy;，这三个字符在浏览器中的支持情况请看ppk的《The wbr tag》），这些字符写在浏览器中不会显示，却使长字符串换行。&#8203;和&shy;都会导致复制用其处理过的文本时有大量不可打印的字符，导致字符数急剧增大，更严重的是导致复制的链接字符串不可用，所以用<wbr />是比较好的方案，虽然<wbr />在IE8中不被支持且在Safari中有bug，但这些浏览器可以直接用CSS{word-wrap:break-word}来实现无需用<wbr />处理。Opera下要兼容<wbr />，需要设置CSS：wbr:after { content: "\00200B" }。

2009.05.28重写了实现方法，尽可能减少对浏览器探测的依赖，同时考虑对同一个页面多次执行该方法的效率，同时为了偷懒直接基于YUI。请看DEMO

具体实现代码如下：

function fnBreakWordAll(o){
var o = o || {},
  iWord = o.word || 13,
  iRe = o.re || '[a-zA-Z0-9]',
  bAll = o.all || false,
  sClassName = o.className || 'word-break-all',
  aEls = o.els || (function(){
    var aEls = [],
      aAllEls = document.getElementsByTagName('*'),
      re = new RegExp('(?:^|\\s+)' + sClassName + '(?:\\s+|$)');
    for(var i =0,iLen = aAllEls.length; i < iLen ; ++i){
      if(re.test(aAllEls[i].className)){
        aEls[aEls.length] = aAllEls[i];
      }
    }
    return aEls;
  })() || [],
  fnBreakWord = function(oEl){
    // 基于http://www.hedgerwow.com/360/dhtml/css-word-break.html修改
    if(!oEl || oEl.nodeType !== 1){
      return false;
    }else if(oEl.currentStyle && typeof oEl.currentStyle.wordWrap==='string'){
      breakWord = function(oEl){
        oEl.runtimeStyle.wordWrap = 'break-word';
        return true;
      }
      return breakWord(oEl);
    }else if(document.createTreeWalker){
      var trim = function  (str) {
        str = str.replace(/^\s\s*/, '');
        var ws = /\s/,
        i = str.length;
        while (ws.test(str.charAt(--i)));
        return str.slice(0, i + 1);
      }
      breakWord = function(oEl){
        var dWalker=document.createTreeWalker(oEl,NodeFilter.SHOW_TEXT,null,false);
        var node,s,c = String.fromCharCode('8203'),
          //re = /([a-zA-Z0-9]{0,13})/;
          re = new RegExp('('+ iRe +'{0,' + iWord + '})');
        while (dWalker.nextNode()){
          node = dWalker.currentNode;
          s = trim(node.nodeValue).split(re).join(c);
          node.nodeValue = s;
        }
        return true;
      }
      return breakWord(oEl);
    }
  };
for(var i=0,n=aEls.length; i<n; ++i){
  var sUa = navigator.userAgent,
    sTn = aEls[i].tagName.toLowerCase() ;
  if((/Opera/).test(sUa) || (/Firefox/).test(sUa) || ((/KHTML/).test(sUa) &&
  (sTn === 'td' || sTn === 'th')) || bAll){
    fnBreakWord(aEls[i]);
  }
}
}

具体应用请看演示实例

fnWordBreakAll函数提供一些定制参数，使用方法和参数含义如下：

fnWordBreakAll({word:15,re:'[\\w]',all:true});
参数 值 说明
word 正整数，默认是13 在这个字数内的单词不会被插入\u8203，印象中超过13个字母的单词不多，这可以保证绝大部分单词不会被打碎
re 正则表达式，默认[a-zA-Z0-9] 单词的正则表达式，用以确定一个单词是哪些字符组成，注意\的转义
all 布尔值，默认false 确定是否在所有的浏览器中执行，默认在Opera和Firefox，以及当class应用在th或td的Safari上执行，这个主要用在.word-break-all没有定义时，会对IE加上样式
className 合法class名，默认word-break-all 执行函数的元素对应属性名

这个函数的核心部分修改自Hedger Wang 整理了一个JavaScript解决方案《Cross Browser Word Breaker》，其利用document.createTreeWalker和split方法给非IE浏览器的每个字符间加入了&#8203;，它用在纯中文文本基本上没有什么问题，但是如果你仔细观察他给出的例子就会发现文本中有英文或数字时，虽然解决了换行问题，但是使文本难以阅读，且增大了字符间的间距，所以我在此基础上做了上面的改进。

]]> http://dancewithnet.com/2008/12/04/word-break-all/feed/ 18 CSS Hacks http://dancewithnet.com/2008/07/12/css-hacks/ http://dancewithnet.com/2008/07/12/css-hacks/#comments Fri, 11 Jul 2008 19:05:48 +0000 秦歌 http://dancewithnet.com/?p=1347 Java一直标榜一句老话叫“编写一次，到处运行(Write Once,Run Anywhere)”，CSS也差一点点做到了。但就是为了差的一点点往往需要大量的工作，虽然这并不是CSS的错。基本上别妄想兼容所有的解析器了，仅仅是为了让网页在YUI中列举的A级浏览器呈现一致就不是一件特别容易的事情。虽然通过精心的组织HTML结构加上使用最合适最通用的CSS代码可能实现多浏览器呈现一致，但当在视觉的过度设计、精确到像素的规定和前端快速实现的要求的前提下，可能你不得不为不同的浏览器写不同的CSS代码，这就是CSS Hacks了。我们的目标是保持CSS简洁和没有CSS Hacks，但即使多年以前就呼吁Keep CSS simple的PPK也不得不在他的网站中使用CSS Hacks，即便如此其站点在所有的A级浏览器中也无法保持一致的呈现。所以，下面这个我常用的CSS Hacks列表或许有些用：

IE6 IE7 Firefox2+ Firefox3+ Opera9.5+ Safari3.1+
选择符{
  *属性:值;
}[1]		 √ √ × × × ×
选择符{
  _属性:值;
}		 √ ×[2] × × × ×
选择符,x:-moz-any-link{
  属性:值;
}		 × √ √ √ × ×
选择符,x:-moz-any-link,x:default{
  属性:值;
}		 × √ × √ × ×
@media all and (min-width:0){
  选择符{属性:值;}
}[3] 		× × × × √ √
@media all and (-webkit-min-device-pixel-ratio:0){
  选择符{属性:值;}
}[4] 		× × × × × √

这里有一个上述CSS Hacks的应用的例子可以看看。

  • [1] 此处的*号其实也可以是.号、>号、+号和#号。但它们都不属于CSS2.1规范合法属性名的一部分，所以不能通过验证。
  • [2] 当IE7为quriks mode时和IE6为quriks mode解析相同，所以此时这个表达式在IE7中也能生效。这个hack已经应用了很久了，下划线_作为属性名的前缀是符合CSS2.1规范语法的，但不存在于其属性名列表中，所以依旧不能通过标准语法验证。对于多个IE的CSS Hacks，条件注释是一个很值得考虑的解决方案。另外对于IE8可以关注其新功能和变化，但现在考虑其CSS Hacks问题有点过早，真的有需求可以通过增加<meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE7″ />来解决。
  • [3] 如果把表达式中的and和(中间的空白去掉变成@media all and(min-width:0){选择符{属性:值;}}，那么Safari3+将无法识别，Opera9.5+则可以。
  • [4] 这个表达式Opera9.0是支持的。

上面这些CSS Hacks仅仅是沧海一粟，是一些简单的通用的CSS Hacks。这个世界上还存在很多很知名很经典的CSS Hacks，更多的CSS Hacks可以看这里：

  1. Browser CSS hacks
  2. CSS Browser Hacks For Firefox, Opera, Safari & Internet Explorer
  3. CSS Hacks for Different Versions of Firefox
  4. CSS hacks
  5. CSS Hack
  6. Will the browser apply the rule(s)?
  7. Tricking Browsers and Hiding Styles
  8. 与臭虫为友——浏览器补救办法，臭虫以及解决方案（第二部分）
  9. CSS Hackz Series: Targeting and Filtering Internet Explorer 7
  10. Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs—中文版
  11. CSS让你的IE浏览器崩溃
  12. Internet Explorer CSS Bugs—中文版
  13. 【IE6的疯狂系列】IE6 BUG大全
]]> http://dancewithnet.com/2008/07/12/css-hacks/feed/ 17 是时候不用考虑基于字体大小（em）的设计了 http://dancewithnet.com/2008/06/17/it-is-time-to-discard-font-size-adjustments/ http://dancewithnet.com/2008/06/17/it-is-time-to-discard-font-size-adjustments/#comments Mon, 16 Jun 2008 18:23:35 +0000 秦歌 http://dancewithnet.com/?p=1344 今天是Firefox3的2008下载日(貌似北京时间是6.18的凌晨1:00)，这就意味着Firefox3正式发布了。Firefox3有众多的改进和新功能，我最关注的功能之一是“全页面缩放（Full page zoom）”。这就意味着Firefox3和Opera以及IE7+都可以让用户“完全控制显示内容的大小同时自动调整页面布局和结构”，说白了就是可以让整个页面直接放大或缩小却不会乱掉。这就意味着我们不用再考虑为了可访问性而整个页面是基于字体大小（em）的设计了。

在CSS中，有两种单位。一种是绝对长度单位，包括英寸(in)、厘米(cm)、毫米(mm)、点(pt)和派卡(pc)。另一种是相对长度单位，包括em、ex和像素(px)。ex由于在实际应用中需要获取x大小，因浏览器对此处理方式非常粗糙而被抛弃(更多内容可以参考Eric A. Meyer的《CSS权威指南》)，所以现在的网页设计中对大小距离的控制使用的单位是em和px（当然还有百分数值，但它必须是相对于另外一个值的）。

在css中，1个“em”定义为一种给定字体的font-size值。所以1em可能随元素的不同而不同，它会相对于父元素字体大小而改变。在常见浏览器下，默认字体的大小为16px。常见有两种方法来进行网页设计：

  1. 设置默认字体大小为10px： 
    body{font-size:62.5%;}
#wrapper{width:97.4em;}

    这便于依次计算出其他元素的长宽值，比如某个容器#wrapper的宽度是974px，CSS中定义为97.4em。本站随网之舞就是依据这种方式来实现的。

  2. 设计默认字体大小为网页中最常用字体的大小，比如最常用字体的大小是12px： 
    body{font-size:75%;}
#wrapper{width:81.1667em;}

    这样虽然省去了设置默认字体的大小，但是偶尔却为严格尺寸设计带来麻烦，比如你要设置那个宽为974px的容器#wrapper就会遇到此类麻烦。其实第一种方法也会遇到类似麻烦，只不过比第二种少些。

基于字体大小的设计好处很明显，当用户调整浏览器默认字体的大小时，字体和页面会随之缩放，能够满足挺这种方法的人常说的一个优点就是弱视的人可以通过放大字体来看清楚页面内容，增强了页面的可访问性。

每个屏幕都有分辨率，比如1280×1024分辨率时屏幕就有1280×1024个点，这每个点就是一个像素(px)。所以利用px来设计网页，不存在em那种相对于父元素字体大小变化而变化的问题。而实际上绝大部分的站点设计都是基于px设计的。在Windows平台下IE7之前都无法通过调整浏览器中的“字体大小”来调整文本大小，非IE浏览器可以，但实际上是一般基于px的页面，一旦仅仅调整了文本大小页面就会乱掉（在Firefox 2下观看除中国雅虎外的门户网站，调整一下字体大小就了解了）。

为了IE下不能调整以px为单位的字体大小，而非IE下可以的问题，YUI CSS Tools采用了如下代码来设置默认1em的大小，支持用户的字体大小调整：

body {font:13px/1.231 arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}

为此IE默认情况下，1em的大小是13.3333px，所以你会看到YUI CSS Grids里面那些诸如width:73.076em;这样的值。

所以，基于字体大小（em）的设计和基于px的设计相比而言：

  1. 基于字体大小(em)的设计页面带来的缩放效果有限，最早基于字体大小设计的门户网站应该就是Yahoo和MSN了，而实际上它们也仅仅是保证了上下缩放三级而已，再多就乱掉了。
  2. 现在的站点越来越多的图文混排，图像的高度和宽度本身就是像素数。除非你通过CSS来把图片的大小设置为相应的em值，就像本站的Logo这样，否则图片是不会随着文字变化而变化的。但是如果采用的是背景图片，那就基本上无计可施了。所以实际上基于字体大小来做图文混排设计的网页需要对图像的设计是有相当严格的要求的，即使如此仍无法完美解决，但复杂度却上升不少。
  3. 基于字体大小的网页设计，将使长度变得的非常的不直观，导致设置一个宽度变得非常麻烦，YUI CSS Grids中说明了这点。并且由于em会相对于父元素字体大小变化而变化的问题，导致图文混排的复杂设计时非常麻烦。特别是在盛行过度设计和精确到像素的这个浮躁时代。其实连Google和百度这种非常简单的首页都或多或少的利用px来布局。

现在主流浏览器都支持了“全网页缩放”功能，Safari尚未支持这个功能（Google的新推出的Chrome和Safari的基于同一个核心，很遗憾也不支持这个功能），而是像Firefox2一样支持文本缩放，但是具有讽刺意味的是Apple页面基本上都是基于px的，所以一缩放就乱掉，我深信Safari支持这个功能仅仅是时间问题（Safari和Chrome共同核心引擎Webkit已经有计划了）Chrome2和Safari4都已经支持这个功能。两年前有篇《95%的中国网站需要重写CSS》很流行，虽然保证用户的可访问性是应该的，但是应该找到其最佳实现的方法，毫无疑问浏览器的“全页面缩放”功能是最佳选择。从现在开始，基于px的设计不用再过于背负违背可用性的恶名了，基于em（文字大小）的设计不能给我们带来太多的好处，反而有可能耗费太多的精力挣扎于如何精确保护视觉设计上，设计师的精力应该更多的放在内容的理解、快速呈现、语义化、对屏幕阅读器的支持等等方面上。

全球范围内IE6已经不到40%了，中国用户比率应该高些，但趋势是一样的，毕竟IE8都出Beta了，IE6会很快成为历史的。如果你是偏执狂，需要考虑Firefox2和Safari的话，或许设置body{font-size:10px;}再基于em进行设计是一个不错的办法，中国雅虎的首页就是利用类似原理。总之，是时候不用考虑基于字体大小（em）的设计了，特别是针对IE6的解决方案。

]]> http://dancewithnet.com/2008/06/17/it-is-time-to-discard-font-size-adjustments/feed/ 51