Mikel

[转载]Web字体格式介绍及浏览器兼容性一览 – 梦想天空 – 博客园. 目前，文字信息仍是网站最主要的内容，随着CSS3技术的不断成熟，Web字体逐渐成为话题，这项让未来Web更加丰富多彩的技术拥有多种实现 方案，其中之一是通过@font-face属性在网页中嵌入自定义字体，主流的浏览器都支持这项技术，具体实现例子将在下一篇文章介绍，本文介绍主要的几 种Web字体格式及各浏览器兼容情况。 Web字体格式介绍 TrueType (.ttf) Windows和Mac系统最常用的字体格式，其最大的特点就是它是由一种数学模式来进行定义的基于轮廓技术的字体，这使得它们比基于矢量的字体更容易处理，保证了屏幕与打印输出的一致性。同时，这类字体和矢量字体一样可以随意缩放、旋转而不必担心会出现锯齿。 EOT – Embedded Open Type (.eot) 嵌入字体格式（EOT）是微软开发的一种技术，允许 OpenType 字体嵌入到网页并可以下载至浏览器渲染，浏览器根据 CSS 中 @font-face 的定义，下载，渲染这种 .EOT 后缀的字体文件。这些文件只在当前页活动的状态下，临时安装在用户的系统中。 OpenType (.otf) OpenType是一种可缩放字型（scalable font）电脑字体类型，采用PostScript格式，是美国微软公司与Adobe公司联合开发，用来替代TrueType字型的新字型。这类字体的文 件扩展名为.otf，类型代码是OTTO，现行标准为OpenType 1.4。OpenType最初发表于1996年，并在2000年之后出现大量字体。它源于微软公司的TrueType Open字型，TrueType Open字型又源于TrueType字型。OpenType font包括了Adobe CID-Keyed font技术。Adobe公司已经在2002年末将其字体库全部改用OpenType格式。 WOFF – Web Open Font Format (.woff) 相对于 TrueType 和 OpenType ，WOFF（Web开发字体格式）是一种专门为了 Web 而设计的字体格式标准，它并不复杂，实际上只是对于 TrueType / OpenType [...]

[转载]由web程序出现乱码开始挖掘(Bom头、字符集与乱码） – 沉于思考，默默学习！ – 博客园. 从第一次开始写web程序，自己还有身边同事开发出现乱码情况基本都没有消停过。估计以后还会一样继续。 这么些年，不断修修改改，也总结也归纳。程序从asp,ASP.NET,jsp,php，服务器从windows到linux，数据库也从 SQLServer,mySQL到oracle；它还是偶尔会出现。 好了，我总结下我与它较量的一些收获吧。乱码都与字符集有关系，一切都从它开始说。 什么是字符集，什么是字符编码，它做什么用？ 字符（Charcter）是文字与符号的总称，包括文字、图形符号、数学符号等。而字符集是一组抽象的字符组合的集合。如：英文字符集，中文字符集，日文字符集等 什么是字符编码? 计算机只能存储0,1之类2进制数字，怎么样让它表示那么多各种各样的字符呢？就需要对各种字符指定一个数值的编码代号它就是字符编码。如：a这个 字符，在ascii字符集编码表中对应的编号是97，而“中”在gb2312字符集中对应的编号是：16进制是D6D0 10进制是54992 。通过编号就可以找到计算机对应字符。不用将那么复杂的字符保存在计算机中，只需要保存它代号就好。字符集只是指定了一个集合中有哪些字符，而字符编码，是为这个集合中所有字符定义个编号，这就是字符集与编码区别所在。 如果我告诉别人，我这个字符是：gb2312字符集中编号是：54992或者是D6D0 ，无论那个程序都知道是”中”，如果有人听错了，把它弄成日文JIS字符集，然后他也去找编号是：54992对应的字符，却找到的是：”面“。 打了这个比方，相信大家找到原因了，同样如果把54992拿到ascii 码表找，就会得到对应：�� 两个不能打印字符了。 从上面看，当你拿到本来是gb2312编号，在不是它的字符集里面找就出现这样问题了。 其它，程序出现乱码也都是这个原因，找错了字符集表了. 字符在计算机是怎么样存储的呢？ 看了上面介绍，我想大家一定会说，如果所有文本的字符，都用它的符号存储在计算机里面，不就什么问题都么有吗？ 以前也这么想，后来一想啊，如果都存在计算机中，各种各样，怎么样表示呢？计算机处理01之类数字该多方便呢。 我们可以通过winhex实际来检查下，下面在简体中文下，将”中按照gb2312字符集编码保存。 以gb2312编码保存中文“中”，实际存储在计算机中是：D6D0，是“中”在字符集gb2312中的编号啦！ 计算机中只保存字符在某字符集中对应的字符编号值，计算机只需要维持一份字符集清单，当读到这种编号值（编码），就在对应字符清单中找出该字符显示出来即可。字符大小颜色都是程序按照字符样式绘制而成的。 看个图： 计算机中只保存该字符在某字符集中对应的字符编号（也叫字符编码） 怎么样读取文件并正确显示文件内容？ 从上面例子知道字符实际以该字符在某字符集中字符编码存储与计算机磁盘中。 下面以“中国”为例(中文简体windows)： “中国” 保存编码 存储内容 记事本打开 ANSI D6D0 B9FA 正常 gb2312 D6D0 B9FA 正常 utf-8+BOM EFBBBF E4B8AD E59BBD 正常 utf-8 E4B8AD E59BBD 正常 [...]

[转载]Web前端设计模式–制作漂亮的弹出层… – 翁智华 – 博客园. 设计场景： Ben最近在负责一个购书网站，在网站的首页上，有一个叫做“最新上架”的板块，板块的内容比较简单，只有书籍名称，作者姓名和上架时间（如图），当初设计的时候并i没有过于丰富的构思… 现在问题来了，这个版块不大，更新频率却很高，每天都有十数条最新的信息上去，浏览网站的会员对于最新图书的了解和需求越来越大，因此需要对这个板块进行 改良，以满足会员的需求，会员的主要要求有以下几个方面：显示该最新上架的图书的封面缩略图，该图书的名称和作者名称，以及该书部分内容的介绍和作者的简 介… 这下把Ben给愁坏掉了，首页上根本就没有多余的空间，怎么来呈现封面缩略图甚至是内容简介，如果去掉别的板块空间来实现这一板块的扩张，无异于在一家公司以牺牲一个部门来壮大另外一个部门，这是万万不可取的… 于是Ben想到了以弹出层的方式来显示每条信息的详细内容… 设计目标: 在不改变页面结构的情况下，以弹出层（用Dom重构的方式来实现元素的追加append和移除remove）的方式提高页面信息量… 解决方案： 首先，我们设计一个Div，样式如下： 代码 .TipDiv { width:500px; height:120px; padding:8px; border-top:solid 5px #a6c9e2; border-bottom:solid 5px #a6c9e2; border-left:solid 1px #a6c9e2; border-right:solid 1px #a6c9e2; background:#ffffff; z-index:10;/*z-index很重要，它决定了Div框在页面上的叠加顺序*/ position:absolute;/*绝对定位，它决定了该元素可以根据top 和 left 叠在其他元素上*/ } .TipDiv img { width:110px; height:110px; margin-right:36px; margin-left:10px; float:left; } .TipDiv span { /*×*/ width:340px; [...]

[转载]有关网站UI实现的几种方式的讨论 – LoveCherry – 博客园. 抛砖引玉，提出一些知道的做法，欢迎大家提出更多做法。 对于网站来说，UI最终的形式无非是（X）HTML + 脚本 + 样式，现在的问题是怎么样生成这些前端的元素，在以下几个方面达到平衡： （假设有开发和前端两种角色，前端负责表现逻辑和表现，而开发负责业务逻辑和业务数据） 1） 开发人员的工作量，工作难度 2） 前端开发人员（后面省略为前端）的工作量，工作难度 3） 产品（假设前端属于产品部）对UI的改动需求能否快速落实（能否只依靠前端实现） 4） 服务端的压力（客户端的性能问题暂时不考虑） （怎么发现自从翻译了《微软应用架构指南》之后，写什么都是翻译的口气了） 第一种方式：XML + XSLT 数据源是XML，由开发人员提供，XSL可以一开始由开发人员写，以后由前端参与开发和维护。 T的过程可以在服务端进行，优点是搜索引擎友好，缺点是服务端压力大。 T的过程也可以在客户端进行，和服务端进行的优缺点互反。 这种方式比较适用访问量大（特别是客户端进行T）、交互简单的系统，比如论坛，因为服务端只需要提供数据源，而XSL则是静态资源可以在客户端缓存。 这种方式的优点是，如果前端直接维护XSL，那么在开发不介入的情况下可以直接对页面布局等进行调整，并且可以做到最好的性能。 而缺点则是，学习成本比较大，如果在客户端进行转换那么搜索引擎支持会不好，而且XSL相对比较难以维护，实现复杂逻辑成本比较大。 第二种方式：ASP.NET Webform 最常见的方式，基于控件，由控件生成HTML，开发也可以直接操作服务端控件。这是一种开发人员主导的方式。 这是一种普适的方式，什么应用都可以支持。缺点是不太利于实现UI快速改动，前端很难参与aspx的维护，因为很多UI都是由控件进行，开发人员很可能在后端操作控件进行一些UI的修改。 第三种方式：纯粹的JavaScript + 服务端数据源 所有和呈现相关的逻辑，都由JavaScript来写（可以依赖JQuery,jtemplate等组件），以AJAX方式从服务端获取数据进行数据的填充和一些业务逻辑的实现。 这是一种前端主导的方式，会写大量的脚本来实现逻辑，需要的数据从服务端获取。 这种方式比较适合前端互动比较丰富的应用，比如网页游戏。 优点是，前端对页面的布局、行为有很大的自主权，并且服务端的压力也比较小。 缺点是，需要写大量的脚本代码，难度大并且容易出错，并且容易出现安全问题。 第四种方式：模板引擎 模板引擎通过基于HTML的模板加上各种预定义的占位符来实现数据的动态填充。在保证了UI灵活性的同时也保证了非常高的性能。 这种方式对于需要有多界面的新闻系统、博客系统，甚至每一个版块布局都不同的论坛系统来说很适用。 虽然足够灵活，但是前端和开发的配合还是双向的，也就是前端还是需要知道开发提供的数据结构。 并且，对于交互比较复杂的应用来说，可能需要用模板引擎预定义的脚本来写很多逻辑，造成难以维护。 第五种方式：ASP.NET MVC 这同样是一种普适的方式，只不过更适用于面向互联网的网站,而不是面向局域网的内部应用。 虽然MVC已经在UI和UI逻辑方面实现了很好的分离，但是我觉得还是很难在开发没有介入的情况下直接对页面的布局等进行调整。 第六种方式：在服务端为HTML的适当位置动态注入数据 这是一种比较新颖的方式，在服务端加载HTML作为模板文件，然后写代码修改HTML中的dom元素，为元素填充数据。 比如一个a.html配合a.shtml，a.shtml（httphandler）加载a.html然后解析HTML文档，从数据库加在数据填充到HTML中，输出这个HTML。 前端提供的HTML文件可以直接使用，不需要加任何模板标签，不需要加任何控件，所有数据由代码填充进去。 [...]

[转载]Web 2.0应用客户端性能问题十大根源 – 心 涯 – 博客园. Web 2.0应用的推广为用户带来了全新的体验，同时也让开发人员更加关注客户端性能问题。最近，资深Web性能诊断专家、知名工具dynatrace的创始人之一Andreas Grabner根据自己的工作经验，总结了Web 2.0应用客户端性能问题十大根源，InfoQ中文站将这十个问题做了概括整理，供Web开发人员借鉴和思考。 1. IE中的CSS选择器（selector）运行缓慢 Web开发人员通常使用JavaScript框架（如JQuery）提供的CSS选择器来实现查找功能，如var element = $(“.shoppingcart”)，但是IE 6和7没有提供这种查找方法的原生实现。所以，JavaScript框架不得不通过遍历整个DOM树来达到目的。这种方式花费的时间比在其他浏览器中的消 耗要多得多，而且严重依赖于DOM树的规模。IE 8对CSS查找提供了较好的支持，所以Web人员最好升级相应的JavaScript框架版本以利用这些新特性。 2.针对相同对象重复进行CSS查找 正如第一点所说，单个CSS查找代价高昂，在这种情况下，如果还要对相同的对象进行多次重复查找，那性能问题就可想而知了。下图是一个典型的Web页面中CSS查找功能调用统计结果： （引自dynatrace博客，中间一列为查找函数总执行时间，单位毫秒，最后一列为函数调用次数） 对于这种问题，Andreas Grabner建议将第一次查找的结果保存到变量中，在以后需要的时候重用即可，不必再重复进行查找。 3.XHR调用太多 JavaScript和XmlHttpRequest是AJAX技术的基础，很多JavaScript框架都提供了非常方便的使用方法，Web开发人员会充分利用其异步通信优势来实现诸如分页加载等效果，避免对整个页面的操作。 Andreas Grabner根据自己的经验指出，他发现这种方式被滥用了——过多的信息通过过多的调用来动态访问。例如，在一个显示10种商品的页面中，开发人员可能 想分别加载每种商品的详细信息。这意味着，你需要和服务器端进行10次交流才能得到全部信息，也会对后台系统产生压力。他建议，在这种情况下，把10次调 用合并成1次来减少通信压力。 4.代价高昂的DOM操作 操作DOM是网页交互性的必要技术。拿添加DOM元素来说，存在多种实现方式，每种方式因为不同的浏览器类型和元素数量大小带来的性能影响也各不相同。建议大家仔细分析比较不同的方法，采用适合自身情况的技术。 5.JavaScript文件过多 Andreas Grabner说，对于一个典型的网站来说，存在超过40个单独的JavaScript文件并不少见。他指出，JavaScript文件过多带来两个问 题：一是浏览器在加载这些文件时需要通过JavaScript引擎切换上下文运行环境，二是因为下载文件而带来额外的网络通信。解决方法是：减少 JavaScript文件数量！ 6.DOM规模庞大 DOM规模对页面性能影响很大，具体表现在： 占用的内存 从根节点到子节点的style变化所花费的开销 IE中CSS查找的性能问题 DOM遍历操作的性能问题 所以，警惕你的DOM树！ 7.事件处理函数绑定过多 对于Web开发人员来说，绑定事件处理函数是日常工作之一。Andreas Grabner提醒大家关注其对性能的影响： 绑定操作本身消耗时间（如查找对象、注册事件管理器等）。 当事件被触发时，事件管理器需要查找注册该事件的元素，并调用正确的事件处理函数。 在切换页面时，要记住对事件解绑，避免DOM相关的内存泄露问题。 8.外部服务执行缓慢 很多网页都嵌入了外部内容（如广告栏等）或者调用外部服务，Web开发人员通常需要在页面中包含由第三方提供商发布的JavaScript文件，而通常这些文件中就存在前面所提到的性能问题，我们需要擦亮眼睛，如果有问题要反馈给第三方供应商让其修改优化。 9.滥用视觉效果 很多JavaScript框架都提供了绚丽的视觉特效，如动态弹出表单等，一些方法在示例代码中运行良好，但是在实际的页面中特别是DOM [...]