宋体 vs 微软雅黑——成见 vs 眼睛?

15 四月, 2011 (07:30) | Web技术及应用, “学术”研究 | By: Cutsin

[2011-01]

一、“为什么还在用难看的宋体方块字。”

1、宋体之所以被批评为“难看”,是因为它没有包含足够的hinting(字体的额外资讯,它告诉render该如何处理细节部分,使得在不同大小时能够好看), 所以当字号小于8pt(11px)或大于14pt(19px)时,会出现断裂、残缺、粗细不均的情况;

2、很多人以为从vista开始,windows的默认字体是微软雅黑,但他们也许不知道:xp的宋体版本为3.03,从vista开始已经完全改为 5.0,并且同时使用2种默认字体:在GUI界面、标题文字、帮助文档等重要的地方,使用微软雅黑;在正 文部分(如记事本的内容,默认没有指定字体的网页)、阅读区域,实际上使用的是宋体5.0;只不过,宋体5.0比3.03要“胖”一些、“圆”一些,所以用户不易区分它,甚至误以为是微软雅黑。

3、关于微软雅黑和宋体哪个更好,一般有2种看法:

  1. 多数人会说:这是个主观和习惯的问题;
  2. 有2个词:“易读性(legibility)“可读性(Readability)”;

宋体的笔画清晰,阅读轻松,容易识别,特别适用于正文这类 文字密集的地方,它能够沿袭一千多年不是没有道理的。

微软雅黑,它的出现主要是为了解决宋体的上述缺陷,即不可读问题,但后来大家慢慢发现它的易读性很糟糕:笔画高低不平、颜色较淡、边缘五彩斑斓……

从易读性角度看,有人把它比作“美术字”,而此类字体通常被认为是不适合长时间阅读的,很容易疲倦。

而这些缺陷的原因,除了由于雅黑本身的Hinting信 息仍不是那么精细外,另一个重要原因在于ClearType。ClearType提出的初衷是因为LCD没法很好的显示小字号的点阵字体,所以要亚像素去 填充锯齿,关于它的原理和缺陷这里有篇详尽的介绍:http://www.xieyidian.com/?p=1057
c. 然后是2种字体的阅读对比:
宋体14px:http://www.moonless.net/demo/27/
微软雅黑14px:http://www.moonless.net/demo/27/2.html

二、“某些网站的css支持雅黑”,“font-family: Arial,Helvetica,sans-serif;

这是个错误的写法。

它的初衷是想让macOS能够使用Helvetica字体,但写反了,Arial在macOS中同样普遍存在,这样 helvetica根本没有被使用到的机会。正确的写法至少是:font-family: Helvetica,Arial,sans-serif;

另外,如果不设定中文字体,浏览器会去寻找os的字符映射,但如果字符映射错了(比如 linux用户自行修改过),那么显示的既不是宋体,也不是雅黑。

三、“我突然发现有些网站也开始支持雅黑字体了”

有些用户使用了类似“火狐中国版”这样的浏览器,它们默认不允许站点使用 css指定的字体:

四、全文改成微软雅黑的技术问题

1、除了上面提到的易读性问题,IE拖动页面时,雅黑体抖动会更明显;
2、微软雅黑、宋体3.03、宋体5.0的x-height不同,垂直对齐文字中的icon、表单控件等行内元素很困难,如果找不到折中方案,无法区分它们

white-space processing model简介

15 四月, 2011 (07:06) | Web技术及应用 | By: Cutsin

[2009-07]

  1. 在html源码中,属性前后空白字符会被移除,一个或多个空白字符序列映射为单个词间空格(white-space)。
  2. 白空格合并规则html源码中的回车、换行、制表符、空格会根据包含元素的显示类型合并、忽略或转义,而根据white-space属性的不同设置(normal、nowrap、pre、pre-wrap等)表现又有所不同。
    通常情况下的white-space processing model执行步骤:

微博不是twitter——虚妄的140字

14 十二月, 2010 (13:36) | Web技术及应用, “学术”研究 | By: Cutsin

现在还拿这个说事已太out,权当自己温故知新……

一些应该知道的(以下文字中,1个汉字、1个英文或1个数字,均算作“1个字符”):

1、不少人常挂嘴边的是“1个汉字等于2个英文”,一定场景里,它是有道理的,但仅限于此:

  • 宋体字的设计,一个宋体汉字的宽度等于2个宋体英文的宽度;
  • GB2312、GBK、UCS-2编码对字符的存储方式是:将1个字符存为2个字节(Byte)

2:短信到底能发多少字?长短信是怎么回事?
目前短信常用的是PDU模式,它允许的用户内容最大是140字节(Byte);
而收发短信常用2种编码:7-bit和ucs-2,它们可以发送的最大字符数分别为160个、70个;
用支持中文的手机发短信时,默认是英文纯文本(7-bit),当输入汉字等unicode字符时,它们会自动帮你切换为ucs-2,就是这样……

对于长短信,它其实是由若干条短信连接组成,每条短信会被加上一段报文,不算这段报文,每条短信的最大字符数就变成了:153个、67个,如果长短信的组成被限制为12条,那最大字符数就是:1836个、804个

3、短信的160字是怎么来的?

时间倒流上世纪80年代,这天,在德国波恩的住所里,短信技术的主要发明人Friedhelm Hillebrand正坐在一台打字机面前,他在打字机上随意地打出几条字句组成的信息。当他完成打字并开始检查字句的字符数时,他发现这些信息每条都只 有1-2行的长度,而总字符数也总是小于160个。就这样,160成了对Hillebrand而言颇具魔力的数字。他根据这个数字确立了今天手机短信的字符数限制数。“这些字数足够使用了。”1985年,在他45岁的时候,Hillebrand决定将160个字符作为手机短信的长度上限。

4、twitter的140字是怎么来的?
除了技术原因,创始人循着短信的上限,为用户ID等留出20个字符,剩下的就是我们看到的140。

5、twitter的140字是怎么算的?
他们使用变长的utf-8,但同样把1个汉字、1个英文或1个数字,均视为1个字符;
这就造成了我们看到的中文往往要比英文长很多。

6、微博的140字是怎么来的?
-_,-

7、微博的140字是怎么算的?
他们把一个汉字视为1个字符,2个英文或数字视为1个字符;
这就造成了:

  • 我们看到的英文往往比中文长很多;
  • 总觉得自己超出了140字但实际没有
  • 总下意识地想:丫到底把我发出去的文字算成了几个?!

就算设计者是想让用户多发些内容(如url),但这个字数的计算,实在是滑稽之极;
那些自称很懂微博的xx,说xx不懂微博,其实本身也只是xx而已;

末了,翻了翻自己的博客,实足像个傻瓜,所幸吾日尚可三省,聊以慰藉……

以上。

参考资料:
http://www.52rd.com/Blog/Detail_RD.Blog_yxgnba_6436.html
http://www.linuxforum.net/books/UTF-8-Unicode.html
http://read.pudn.com/downloads108/doc/project/446877/Paper/pdf/y7201420015.pdf
http://wenku.baidu.com/view/26ada38a6529647d272852a3.html
http://localhost-8080.com/2010/07/why-140-characters/

Adjust my font size

7 十二月, 2010 (06:32) | Web技术及应用 | By: Cutsin

-webkit-text-size-adjust:auto(Initial)/none/percentage
很多人发现在chrome、safari以及一些apple设备中,无法将字体大小设为小于某个值(如12px),原因就是这个在iOS1.0 safari中出现的私有属性,它的作用是为了保持文本的可读性(防止太小不可辨认),默认取值为auto(iPad默认none),设置为none则不对文字大小进行调整。percentage在windows平台测试无效,从apple的演示来看,似乎更像是zoom -_-b

font-size-adjust:/none(Initial)/inherit
这是个在css2中出现的属性,2.1被移除,在css3中又被重新定义,它的作用,简单来说,就是将字型的x-height设为近似大小,通过number指定的数值计算出一个比例,所有的字型按照这个比例缩放,公式为:比值=(属性值*x-height)/font-size,这里的x-height是取font-family指定的第一个字体,其他字体按照这个比值缩放,如果取不到x-height,会去取这个字体的ascent value,但从我的测试结果看,目前唯一支持的浏览器firefox,似乎总是使用一个固定的值而不是和字体相关……囧rz

它想要带来的是非常可喜的效果,但可惜的是目前仍不具备普适性……

CDATA、PCDATA

27 九月, 2010 (10:16) | Web技术及应用 | By: Cutsin

很多人喜欢把html放在<textarea>中,但实际上它被声明为#PCDATA,更好的方法也许是<div><![CDATA[搜狐微博]]></div>

大米,这样做更好吃?——一个门外汉眼中的用户体验与BCD

19 九月, 2010 (17:47) | “学术”研究 | By: Cutsin

Two Grades of Rice Milling

引子:

晚上做饭时发现米用光了,抖米袋时发现背面有行很大的字:“大米,这样做更好吃”,下面几张图详述了水的比例、蒸煮时间、临出锅的操作等等,但我直至扔掉它也不曾想要去看看厂家的名字。
联想到互联网行业,不禁生出几分慨叹:“战场上,能记住你的细致、进步与创新的,只有对手和模仿者,或许还有历史书。
——但这没用。

近几年被炒得很热的UED/UCD似乎变成了从业者的砝码,很多人(包括我)在弄不清楚怎么表达异议时就会冒出一句:“这么做用户体验不好”。

如果说用户体验设计无法量化,好,这可以理解,但更不幸的是,很多老板和leader也养成了类似习惯,于是杯具发生了…… BCD这个词也许是这么来的……

虽然事实上以人为中心的做事方法从古至今稀松平常,虽然我们可以例举如雅典极端民主的种种弊端,但,焦点只在于:这个借口怎么就变成了“用户体验”?

“用户体验”,很高端的术语,如果在火车上秀出这个词一定会招惹来很多的目光~
——大家都喜欢目光。

——各种各样的。

不过自觉羞愧的是:我脑子里总要闪现出两句很土气的话:“萝卜白菜各有所爱”、“众口难调”……

这本是一个无法界定对错的事情。

UCD/UED被赋予了太多、太模糊的涵义,有些不堪重负。

而真相也许是:它太可以作为很多事情的借口了,这个借口是什么?

  • 对闲人来说,可以让别人人明白:表面上看我在闲着,其实我是在考虑体验、设计思想,随便忽悠几个术语就能把人镇住的感觉真棒!
  • 对于boss来说:
    • 看着、用着不习惯,你们改了,我就爽了
    • 我觉得这样好,你们按照我说的改,不用怕出事,到时说体验没做好就成了
    • 我是个成功者,你们都是newbie,瞧瞧你们做的那些烂东西,这还能叫设计吗?需要改的地方太多了! 首先,咳咳,从用户体验开始吧……

玩笑……

也许用户体验真正的意义在于:它是一杆标尺,从它可以看出一个人是否足够细心、态度是否认真,这个是在做事还是在做产品,或者说是在做自己,还有可能,是自我实现。
一个产品成败的决定性因素不是它本身,质量只能算是一个必要因素而已,如果你在战略层面上去思考它,你就败了。

写上一段话的同时我想到了windows95和apple,回顾历史,各个时代过往的优秀产品其实相当的多,而他们的成功仅仅在于它的质量与体验吗?

笨拙的我所能想到的答案只有寥寥几个:

  • 洞察人们内心深层的需求(设计的本质在于产品而非外在形式)
  • windows、iTunes和app store模式
  • 抓住先机,聚气发力
  • 最吸引眼球的往往不是最盈利的

不过,究竟要做什么,在这趟浑水里,你是否能清晰地知晓了呢?

最后发句牢骚:UCD、UED、UCD,如果你要总拿它说事,那就是个很扯淡的事情。

IE中opacity与png图像alpha通道冲突2例及解决办法

28 四月, 2010 (06:40) | Web技术及应用 | By: Cutsin

1、
现象:在包含alpha通道的png图像/背景元素上应用alpha(opacity)滤镜,会将透明区域显示为黑色
涉及环境:IE6/7/8
解决办法:使用alphaimageloader载入png;
2、
现象:如果一个元素同时应用了alpha(opacity)滤镜、并使用alphaimageloader载入png,那么在此元素的实际显示区域中,所有元素的背景/背景色都会失效

涉及环境:IE6/7/8

解决办法:为被”吃掉”背景的元素增加alpha(opacity=100)

xhtml mp浅析

1 三月, 2010 (08:06) | Web技术及应用 | By: Cutsin

很早以前就想了解一下wml和wcss,借助春节假期的间隙,阅读了nokia xhtml指南和相关文献,感慨良多,这真是一次迟来的阅读。
网上的各种重复资料太多了,写一点自己的感想和总结:

一、基础概念
wap的发展基本上也是经过了一个从私有到规范的过程,目前的wap2.0应该说是从协议到描述语言,逐渐在向有线互联网靠拢,它终端的基本构成是xhtml mp和wcss,二者的关系就像html之于css;
xhtml mp基于xhtml basic的定义并扩展(包括支持wcss)、wcss则是css2的子集并进行私有扩展;
最大的优势是向规范靠拢,这样wap站点任何支持规范的终端都可以正常访问并应用。

二、xhtml mp
既然靠拢了规范,它势必摒弃了一些”不规范”的旧有特性,如:
1、deck、card、do、anchor、timer、等其他xhtml不允许的标签和应用逻辑
2、不支持非标准事件、变量、客户端脚本、锚点数据
3、必须要有xml声明,这一点不是很确定,从web得来的经验告诉我们:教条不可信,需要更多的测试和阅读。
总之,可以说xhtml mp是完全遵照w3对web的成熟定义,熟悉web开发的人可以很快上手,几乎不需要什么过渡过程,可能在不同终端的处理上尚需经验,但的确是门槛甚低。

三、wcss
除了语法相同,它提供了可和web媲美的大多数属性(包括float和支持有限的position),并且提供不少相当有用的私有属性,这些属性和值以”-wap-”为前缀,例如:
1、-wap-accesskey:3(*、#、0-9),它使用规范的方式代替了之前的<do>
2、-wap-input-format 它可以定义输入格式
3、-wap-marquee 它可以按照相应的规则卷动元素
看起来这些属性并不和表现相关,仿佛违背了分离的思想,不过讽刺的是:css提供的这些属性,实际上是相当实用,而我们却只能通过className去模块化地使用它们。

四、兼容性
wap平台的浏览器对比pc更加杂乱,除了几大厂商五花八门的浏览器,还得考虑诸如MTK等山寨os的私有浏览器;
对前端而言最直接的影响就是:
1、font-family、font-style等字体属性显得无用,因为不少终端只有1-2种字体并且兼容性不好
2、各种布局属性(包括基本的width、height)的支持千差万别
3、js的支持比例一半一半
4、一切全靠测试、折腾…
复杂的终端导致我们只能从GUI设计阶段着手简化,用尽量简洁的设计生成尽量简洁的页面,以尽量小的容量提供给尽量小带宽的下载用户,这就引出此文的第五部分:

五:设计优化、可访问性、可用性
这套流程看起来很熟悉:
1、压缩xhtml、css,缩短各类明明,减小页面大小,这主要是因为终端的缓存限制,以MTK为例(我的山寨机就是),似乎超过20KB的页面就会导致报”下载页面过大”之类的错误,根本无法浏览;
2、图片压缩,尽可能采用jpg、gif、png-8,尺寸也不宜过大,在小屏幕终端上进行横向卷动是非常困难的事情;
3、屏幕尺寸以及导航的设计需要考量,尽量减少装饰性图片或背景;
4、灵活可变的布局,减少卷动
5、导航清晰、减少主要功能死角
总之,一切为了accessibility和usability

值得深思的是:nokia文档中有许多关于用户习惯、可用性、可访问性的描述,甚至包括许多类似”根据可用性研究,用户不太热衷于那些由于图像传输而中断 他们任务流的服务”的细节,而此文档的初稿时间是2002年7月,译文时间是2004年5月,04年同期事件是:国内web标准化的呼声刚刚崭露头角,而 当时国内的UCD研究亦处于起步阶段…

六、其他
1、关于css的放置
有不少资料建议将css放置在页面中,不要使用外部链接,理由是link会产生额外的请求,而且全站的css如果都在这一个文件中的话,文件会比较大,影响速度;
不过我觉得,如果每个页面都带有css,如果用户浏览了2、3页,那和使用link没什么区别,而且浏览得越多,下载的多余样式越多,而link一般会进入缓存;
再者,wap站点和web站点不同,它没有类似门面主页的存在,除非特别需要首页打开速度(比如资讯类等不需要登录的站点),选择将link放入页面相对较小的首页反倒是个不错的选择。

2、xhtml mp的未来及展望
xhtml诞生以来的最大意义就在于它提出的一种标准、一种强制规范,几乎不会有什么终端、设备会尝试以xml的方式读取xhtml,它的xml特性几乎 从未被我们所用到,html5的出现更是令xhtml非常尴尬,那未来的移动设备会采用什么方式呢?我觉得随着终端机能的增强和带宽的提高,除了xml源 及阅读器,仍然会是提供富交互的html和脚本,互联网跨平台的日子不远了……

3、关于builder、ria的必要性
从第五条关于设计的优化原则可以看出,根本不需要什么builder、js,所有的页面、逻辑都和程序环环相扣,3G时代又如何?我们不可能无视一半的用户比例,所以,在很长一段时间内,wap页都会长得大同小异,更丰富的无线应用,只能暂时在无线客户端中绽放……

X-UA-Compatible迷局

6 一月, 2010 (05:51) | Web技术及应用 | By: Cutsin

一般说IE流行着这几个版本:6、7、8以及未来的IE9,而事实上随着X-UA-Compatible的出现又增加了“IE8 as EmulateIE7”、“IE8 as Standard IE7”;

让人困扰的是:后2者仍然有着和纯IE7不同的表现,而微软总会用各种方法引诱你去打开兼容性视图:
1、让开发者们增加X-UA-Compatible强制指定
2、如图:

我们很难(不愿)通过hack再去区分它们,绝不能用错误的方式去解决错误的问题,还好微软同时提供了禁止兼容性视图的办法:
http://msdn.microsoft.com/zh-cn/library/cc817575.aspx
如果说IE8是IE向行业标准靠拢的里程碑,那没有理由不使用:
<meta http-equiv=”X-UA-Compatible” content=”IE=edge”>

如果原来使用Emulate有千百种理由,那么在新产品、新项目中不使用edge无异于自找麻烦,愚以为如此……

业内?业内……

11 十一月, 2009 (03:29) | 生活琐事 | By: Cutsin

今天花了不少时间看reader,从华尔街到枣报,又从枣报到业内博客……

然后就看到51js和蓝色的人在互喷,牵涉非常多的老版主、”业内名人”等等,主要是围绕一本书的推介,而关于主角”css8″,刚好我曾在蓝色web标准区多次遇到,对此人的技术和言语浅有了解,遂来了兴趣……
看这个文章可知始末:《炮轰<JavaScript征途>,兼批技术社区的吹捧之风》

然后有人发了篇文章《一些技术图书编写、推荐、出版人员需要自重》

最后,这是一个写书评的版主的补记(之所以记得这个蓝色的版主,只因他曾以”请言之有物”为理由删过我们几个朋友对另一个朋友大作的跟贴,而我看了看同一帖内剩余的跟贴却同样是言之无物,而区别仅仅是他们都是些有身份的人,如”荣誉管理团队”、”版主”等等,�~~,这就是所谓只许xxxx,不许xxxx)

老实说,看到这么混乱,我有一点兴奋。