web.Frontend

自定义复选框样式，推荐经典标准化专栏 snwebsite 版主的一篇帖子 《用图片模拟checkbox，简简单单》。

真是创意无限啊，想法真妙。

小道消息，呵呵

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011228.html

The W3C’s HTML working group today resolved to start from the current WHATWG work. Specifically, the group resolved to review our work, and will probably build on it.

They also resolved to call this work HTML5.

Thus, the “Web Applications 1.0″ spec is now officially named “HTML5″!

所谓顺天应人，嗯。

update:

刚又在 Junchen 那里看到了“大道消息”，:D

都和 layout 有关，记录一下

1. IE7 下 layout 元素会有鼠标光标问题，具体就是鼠标位于文字之外时，光标也会变成 I 型。演示页面，IE7 下观看，一个框有 layout，一个没有，注意鼠标光标在两个框中的不同形状。

   但是此 bug 有例外：
   当它有背景时（包括背景色和背景图像）、当它 float 时、当它绝对定位时、当它有一个 filter 时，当它被放置于一个 float 的祖先中时，不会出现这个bug，也许还有别的情况，以后发现了再补充。

   另外如果将其相对定位，只有一部分会显示 I 形光标，另外一部分是正常箭头状。箭头状范围不随字体和行距的大小改变，始终在顶部 15px 附近，这个现象有点灵异了 o_o。

   目前比较简单的解决办法是加背景，如果需要背景透明，就用一个透明 gif 代替，或者用一个不存在的 url 代替，或者使用 filter: alpha(opacity=100) 。

2. 具有 layout 的元素会裁切掉内部元素的默认 margin，但内部元素的自定义 marign 不受影响，演示页面可以参考经典论坛的这个帖子。比较奇怪，默认 margin 和自定 margin 难道还有不同的机制？不知道 IE 对于默认样式是什么处理的，IE6 和 IE7 都受影响。这 bug 由于一般都会写一个 *{margin: 0; padding: 0;} 的样式，所以平时不容易发觉。开始以为和 margin-collapsing 有关，结果似乎不是这个问题，margin-collapsing 和 layout 的相关 bug 可以参考 Bruno 的测试页面。

HTML 5 最近风头大起，争论不断，现在又来了一个 CSS 2.2

的确，CSS 3 拖的时间实在太长了…… Andy Budd 认为它之所以迟迟不能定稿是因为贪多嚼不烂（有 40 个模块），WEB 的变化越来越快，以前定下来的东西过了一段时间发现又需要修改，这样怎么改也改不完，何时是个尽头。总想让自己完美，总想尽可能考虑周全未来的种种状况，结果忽略了当前真正亟待解决的问题，这是 CSS 3 目前定稿最大的障碍。于是 Andy 提议将 CSS 3 中的部分急迫内容，或者说用来满足一些常见需求的内容加入 CSS 2.1 中，升级为 CSS 2.2 以促进新的 CSS 版本推出。

不过个人感觉，这个没有浏览器厂商的合作，就算 W3C 定了个 CSS 2.2 出来又能如何？Mozilla 和 Opera 倒是可以持乐观态度，但是 IE 呢？占浏览器市场份额最多的 IE 呢？且不说 IE7 的份额还很少，就是还在计划中的 IE 8 目前的目标也仅仅是完善对 CSS 2.1 的支持！CSS 2.2 出来了谁能保证它的命运不像 2.1 一样悲惨？

新技术总是会引发热潮和争论，特别是一项针对现有技术的竞争品的出现。微软推出了 Silverlight，针对的自然是 Flash，两者的比拼从 WPF/E 出现一开始就没有停止过。这有一篇来自 gskinner 的分析，A Flash of Silverlight? My Analysis，从技术潜力，runtime，开发工具和未来趋势四个方面比较了这两种技术，不过作为 Flash 界大牛，自然是偏向 Flash 喽 :)

摘一段结论：

Conclusion

In summary, while I don’t entirely trust Microsoft’s intentions, I do think that Silverlight has potential, particularly in the short term while MS is still in “buying love” mode. Microsoft’s developer toolset is likely to be more robust, and have a much better integration story than anything Adobe can offer in the near future, but being Windows-only makes the tools inaccessible to many developers and a large portion of designers. I think the Silverlight plug-in will be an adequate runtime, but it will never pack the same punch per byte that the Flash player does, and it will never enjoy as large of an installed base.

一些其他的比较文章：

• Flash and WPF - My thoughts so far
• My take on WPF/E and the Future of Flash
• Silverlight Vs Flash 系列文章收集

以前用 Illustrator 的时候总觉得它的贝塞尔工具很不好用，经常误操作，比 photoshop 的差远了。原因在于 Illustrator 中选择和移动锚点/把手都需要十分精确的鼠标操作，箭头必须指在点上才能拖动，而那些点又十分小，所以误操作的几率太大了。最近画了一个 logo 让我深刻体会到，用 Illustrator 画贝赛尔真的会发疯。

装了 CS3 之后第一个看的就是贝塞尔曲线的几个工具有没有变化，试了试似乎的确是有了改观。

于是跑去设置里面翻，看到了多了这么一项：Selection & Anchor Display，里面可以设置锚点的敏感范围了！

默认是 3px，改到 5px，这下舒服多了……我想 CS3 之前的版本这个值估计是 0，简直无法想象那些复杂的曲线是怎么画出来的。

心情很沉重……为啥你就这么慢？

问题不复杂，移动一个图层文件夹，这个文件夹里面包含很多其他图层文件夹和图层，而且很多图层有复杂的图层效果。在PS CS3 中那速度简直可以用“不可理喻”来形容。箭头工具下 shift+↑，一个简单的移动动作，要卡十几秒，而且在这段时间内 CPU 占用率非常高……如果是用鼠标来拖动，那简直就是不可完成的任务。而同样的操作在我的 PS CS 里面，非常流畅……

Google 找 Baidu 搜，Adobe forum 去反映，试验了若干种方法，都没有解决问题，无奈，写篇 post 来求助下。

首先我不认为是我机器硬件太过时（P4 2.8, 1G RAM，Radeon 9600 pro 128M），就算过时，也不至于这么夸张吧，况且 CS 里面的效率很正常。我总觉得是软件或者操作系统或者其他设置的问题。更精确一点，我怀疑是和 CS3 的图片缓存机制有关——也就是说没有缓存这个图层文件夹的位图信息，而是在每次移动的时候都去重新计算各种图层效果。

我放了一个测试文件在这里：http://www.box.net/shared/f2h5q9yol7（新地址，先前的地址文件似乎已损坏）。试试用键盘移动或者鼠标拖动那个图层文件夹。如果你的 CS3 没有问题，麻烦留言说说机器配置和安装的字体数量……（字体数量是因为在一个 blog post 上看到有人减少字体数量，解决了 CS2 的效率问题。）

updated:Adobe 发布了一个 10.0.1 的升级包，release note 中第一条就是说改善了这个问题 : )，果然升级后效率提高很多，赞～

The Adobe® Photoshop® 10.0.1 update addresses a number of issues discovered after Adobe Photoshop CS3 and Photoshop CS3 Extended (10.0) software were released.

The most significant fixes in the Photoshop 10.0.1 update include the following:

• The speed of moving objects contained within multiple layer sets has been improved.
• Converting images to CMYK using certain profiles no longer results in black files.
• The Save for Web feature now includes an option to “Include XMP” (metadata) in the settings menu within the main Save for Web interface, making the existing capability easier to access.
• When using Save For Web with “Include XMP” enabled, all XMP data is now included in the optimized file.
• Print color matching has been improved.
• Images saved as DICOM and reopened in Photoshop CS3 are no longer corrupted on PowerPCﾮ based Mac computers.

过程很艰辛，小白鼠不是那么容易当的。再加上这个版本安装和卸载都出奇的慢，相当的慢，真是被郁闷死了。记录一下安装历程，希望可以帮到遇到同样问题的朋友。

• 试了若干个版本，先找到的是 SWAMP 的版本，自带 Crack，不过因为同时看到了 ZWT 的 Keygen，所以没用他的 Crack。
• 结果 Keygen 无法激活……无奈，保持未激活状态观望，Crack 我是不愿意用的，哼唧。
• 第二天 ZWT 发布了第二个 Keygen，这下可以激活。不过由于我开始不知道版本是和 Key 相关的，所以也没管那么多就用了这个 Key 激活了。后果很严重——不是 Extended 版本……
• 但我此时还没有怀疑到 Key，而是怀疑 ISO 的问题，于是卸载，继续观望。
• 发现了 ZWT 的 ISO，装了后问题依旧……还是 Standard 版，不同的是安装的时候没有问我要 Key。
• 开始怀疑版本和 key 有关，这时又发现了 SSG 的版本，不过没有贸然卸载重装，而是打算先尝试换一下 Key。
• 结果 deactivate 的时候总是出错……于是开始去网上找方案……这期间在水木社区发现了众多说法，也遇到了和我同样问题的人。有人建议试了这么多次了，也不在乎再多试一下 SSG 的版本，于是接受建议，开始卸载……
• 卸载期间经水木社区 Lostinl0ve 大仙提供的一个 URL，发现删除 c:\Program Files\Common Files\Adobe\Adobe PCD\cache\cache.db 可能可以清除激活信息。
• 卸载结束后马上删除了这个文件，开始安装 SSG 的版本……帅，再次出现了输入 Key 的对话框。
• 用了 SSG 的 Keygen（这个号称是 VLK 免激活的），成功变成 Extended。
• 结束。

总结一下，Standard 和 Extended 是和 Key 相关的，所以只要找对 Key，应该就没问题。SSG 的 Keygen 是 VLK 的 Extended 版，直接用他们的就可以了。至于 ZWT，出了两个 keygen，但不知道哪个是可以正常激活的 Extended 版本，所以如果你手上的是他们的 keygen，还是要观望一下。

CSS 有裸体节，JS 也有哦，看这里：http://www.scriptlessday.com/

CSS 裸体节的目的是号召 web 开发者注重自己 HTML 的结构和语义，同时体现 CSS 的强大功能，那JS 的裸体节目的是啥？

个人觉得目的应该是考验网站 bulletproof 的代码风格，unobtrusive 的编程习惯，从可访问性角度审核网站的水平。没有了 JS，你的网站还有多少可访问性？

不过发起人好像不是抱着这个目的……他们似乎想通过这个活动证明 JavaScript 在现代 web 应用中的重要性……什么意思？在失去 JavaScript 的痛苦中反思它的重要地位？……有点怪怪的。

瀚海用 Opera 回复帖子，如果标题有中文会变乱码，发表文章和同主题阅读就没有问题，非常恼人，不知怎么回事。今天研究了一下，发现似乎是 Opera 的 bug：

• Opera 似乎会通过 href 中是否有冒号（:）来选择不同的 URL encode 方式，没有冒号的使用当前页面编码，有冒号的使用 UTF8 编码。BBS 回复文章的时候会在标题前面加一个“Re: ”，所以出了问题。
• 取消了工具-> 首选项 -> 用 UTF-8 给国际语言网址编码复选框，问题依旧。（这个选项是不是干这个事的？）

bug 演示页面在此，鼠标划过两个不同的 link，注意状态栏，会发现两个 URL 采用的 encode 方式不同，而其他浏览器正常。记得以前 Opera 好像不会这样，自从版本 9（还是8？）以后开始有这个问题，今天更新了最新的 9.20 final 依旧如此。

所以初步判断是个 bug，已经提交到 Opera 的 bug report 系统 ，不知道什么时候能有回应。

updated发现将冒号先 encode 成 %3A 可以解决这个问题，不过目前还属于知其然不知其所以然，补习一下 RFC：http://www.faqs.org/rfcs/rfc1738.html

updatedOpera 9.5已经没有这个问题了，good~