<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>realazy</title>
	<link>http://chen.xianan.name/blog</link>
	<description>web 标准，前端开发，编程感悟，生活杂想</description>
	<lastBuildDate>Thu, 13 Aug 2009 15:30:19 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>How to detect double taps in UIWebView</title>
		<description><![CDATA[You can use this robust approach, or this smart method. But the first is using the UNDOCUMENTED (private)  API, and the second is not working for me (and for somebody according to the comments on that blog post). So this is my solution.
Subclass UIWebView and put these lines under your implementation:
- (UIView *)hitTest:(CGPoint)point
  [...]]]></description>
		<link>http://chen.xianan.name/blog/2009/08/13/how-to-detect-double-taps-in-uiwebview/</link>
			</item>
	<item>
		<title>《重构 HTML: 改善 Web 应用的设计》上市</title>
		<description><![CDATA[为给 HTML 5 让路，W3C 解散了 XHTML 2.0 工作组。这造成了对 XTHML 和 HTML 之间的很多误解，所以就有人画了漫画来解释（英文，中文）。为了避免更大的混乱，我就不多作评论了。
关于本书，可以参考一下我去年的书评。对于前端工程师来说，很多情况下都需要重新捡起以前的代码，不管是不是自己写的，都会面临抉择：重新来过还是基于现状？大部分情况下，后者是唯一选择。勿怨天尤人，重构是你的好朋友。即便是在全新的工作进程中，当你闻到坏坏味道时，也需要很多小型的重构。那么，到底什么是重构？这可不是前几年流行的《网站重构（Designing with Web Stardards）》那本书里说的“重构”，而是&#8221;Refactor&#8221;，编程术语上的“重构”……说到底，还是得买一本才能了解透彻的，哈哈。
随着网页的程序化（就是 Web Application 越来越多了），眼观六路，耳听八方，前端工程师跟浏览器打交道，除了在掌握浏览器在展示页面上的知识，还需要有浏览器跟后台交互的基本知识，本书涉猎 HTTP 的基本要点，虽不深入但亦可管中窥豹了。
作为第一本在 HTML 领域探讨重构的《重构 HTML: 改善 Web 应用的设计》终于上市了，各大网上书店均已铺货。
]]></description>
		<link>http://chen.xianan.name/blog/2009/08/04/refactoring-html-available/</link>
			</item>
	<item>
		<title>CHMate 上线</title>
		<description><![CDATA[拥有 MacBook 已经一年半了吧，有机会接触 Mac 的编程环境，兴趣盎然，一发不可收拾，经过一年的 C 和 Objective-C 语言入门，今年初即开始一些最基本的 Mac 编程，先后做了可可饭和饭否 iPhone 客户端。
有一天想用 iPhone 看一本只有 CHM 格式的电子书（Quartz 2D Graphics for Mac OS X&#8217;s Developers），发现 App Store 存在两款软件，试用其中一款，觉得非常不满意，甚至无法满足最基本的阅读需求，就产生了做一个更好的 CHM 阅读器的念头。满足自己的需求，也希望藉此赚点零花钱买个 iPhone 3GS.
于是有了 CHMate, 今天已经可在 App Store 安装，定价 $4.99. 如果有机会对比一下 CHMate 跟其他 iPhone CHM 阅读器，你会发现 $4.99 不会花得冤枉。根据我的老本行积攒的知识，我可以对 CHM 文件内的 HTML 做到最适合 iPhone 的屏幕阅读。CHMate 的优势是：对文档进行了重排，原来文档内的样式，除了那些依附在标签（tag）上的，基本上都被重写优化了，而且通过设置让你有控制样式的机会。当前尚未有同类产品有这个功能，这是我作为一个前端开发者所引以自豪的一件事情。
]]></description>
		<link>http://chen.xianan.name/blog/2009/07/31/chmate-available-on-app-store/</link>
			</item>
	<item>
		<title>工程师与科学家</title>
		<description><![CDATA[入行已久，做的领域也从浏览器扩展到桌面端甚至是手机端，对 Web 标准多少有些自己的看法，今日斗胆一说。
两种家
我们困惑不解、迷惑不安，很大程度上源于没有指导思想。要摆正自己的位置，我们究竟是想做科学家，还是想做工程师。简明扼要，科学家经常要问“为什么”，他们关心了解人类不懂的知识；工程师则利用科学家发现的知识，制造对人类有用的物体或工具。前者研究，后者实战。很明显，我们大多数人属于工程师，W3C 那一群才是科学家。端正自己的态度，很多疑问就会迎刃而解。
两种用法
HTML 生为标记语言，是组织文档的一种格式。随着技术和社会的不断进步，HTML 的用途也逐渐升级。今天它不仅出现在浏览器上（普通网页），它还出现在桌面程序上（Adobe AIR），出现在手机程序上（PalmPre WebOS）；它不仅用来展示网页，也用来构建程序的用户界面。Web 标准要求我们，HTML 必须有良好的语义化，对于展示内容的文档来说，这是毋庸置疑的，但对于只是作为构建用户界面的程序来说，强调语义是没有多大意义的。要注重语义的时候一定不能松懈，只是用户界面而已的话，怎么方便怎么来，利用最方便的手段做最适合的布局。
实用主义的前提
工程师信奉的是实用主义，但不等于可以放弃原则和规范。工程师关键任务是在遵守规范的前提下，发现、理解并结合实际的局限来达到满意的结果。作为一个流量巨大的网站，Google 对待 HTML 的态度是一个非常好的例子，省略&#60;/body&#62; 和 &#60;/html&#62; 的做法我们何曾想过呢？但这却是符合 HTML 4 规范的。详见： http://code.google.com/speed/articles/optimizing-html.html（需自行翻墙）。
]]></description>
		<link>http://chen.xianan.name/blog/2009/06/29/engineer-vs-scientist/</link>
			</item>
	<item>
		<title>CocoaFan alpha1</title>
		<description><![CDATA[最近总算有精力投入到 Cocoa 的学习了，做了一个饭否专用的客户端，名曰可可饭，倒腾了一个多月算是有了一个基本可用的版本：http://code.google.com/p/cocoafan/.
门还在入，欢迎各界人士多多指教。
]]></description>
		<link>http://chen.xianan.name/blog/2009/03/31/cocoafan-alpha1/</link>
			</item>
	<item>
		<title>Objective-C 学习笔记（一）——简介</title>
		<description><![CDATA[C 可能是世界上最简洁且功能强大的语言，同为 C 的超集（C++现在可能不认为自己是 C 的超集或者相反，我们姑且如此认为吧，至少历史上有过这样的共识），Objective-C 比 C++ 要简洁得多。Objective, 顾名思义，对象者也，为不提供面向对象编程基本功能的 C 添加面向对象的支持，但它不像 C++ 繁冗复杂，最大限度上保持 C 的简洁性。
Objective-C 不像 C 有国际标准，它和 C++ 一样不存在标准。目前主要是 Apple 在维护，最近衍生了 Objective-C   2.0. 使用 Objective-C 的大户也当属 Apple, 因此 Apple 提供的库属于准标准库了。对于开发 Mac 内在观感(native)的 UI 程序来说，使用的是 Cocoa 这个框架，包含 Foundation 和 Application Kit (AppKit). 
Objective-C 也使用头文件(header files)，后缀为 .h, 但使用 .m（即 message, 其他面向对象编程语言也叫 method），作为源文件的后缀。
Objective-C 引入了 [...]]]></description>
		<link>http://chen.xianan.name/blog/2009/02/02/objective-c-part-1-introduction/</link>
			</item>
	<item>
		<title>AIR 的尝试</title>
		<description><![CDATA[最近利用 Adobe AIR 做了一个饭否客户端：爱饭，并将之开源。使用 HTML, CSS 和 JavaScript 对着 API 文档照虎画猫，大概三个星期完工，有一些感想和总结。

AIR 的开发对 Web 开发者非常友好，基本上不需要额外的程序知识了，甚至可以使用已有的 JS 库，爱饭就使用了 YUI。但是生成的程序有一通病，那就是占用内存高（爱饭在 Windows 下占用 40m 左右），而且不存在优化之说。做严肃的应用 AIR 还是上不了台面。很多时候觉得，打开一个 AIR 程序，其实就是打开了一个浏览器。
absolute 的 CSS 布局方式非常灵活，对窗口缩放这种情况具有非常好的适应性。使用 webkit 引擎的 AIR 对 absolute 完全支持。如果是 IE 这种支持残缺的引擎，那得费非常多的 JS 代码。在 AIR 下写 CSS 有一种莫名的快感。正好 24ways 上发布了一篇关于 absolute 方式布局的文章，免却了我的罗嗦，见：Absolute Columns。
AIR 对 Linux 的支持还是存在缺失，比如无法给窗口加阴影，看来是 Linux 下的 Flash 支持跟不上。

完毕。
]]></description>
		<link>http://chen.xianan.name/blog/2009/01/11/ifan-on-air/</link>
			</item>
	<item>
		<title>使用 iframe 获取网页片段的一个好处</title>
		<description><![CDATA[异步操作数据的方式有两种常见的方式：XMLHttpRequest 和 iframe. 孰优孰劣在此我们不争论，只是想举一个例子说明在获取网片片段上，使用 iframe 有一个比 XMLHttpRequest 更易企及的好处。
Ajax 常见的一种使用方法是加载网页片段填充某个区域。假设我们要在网页 foo.com/index 上请求 foo.com/partial。我们假设 partial 就是 HTML，不涉及 JSON 或 XML 格式。在这种情况下：

使用 XMLHttpRequest 直接访问 partial，获取 responseText 后赋予 index 页面上某个元素的 innerHTML 即可完成。partial 必须是一个纯粹的 HTML 片段（基于以上假设）。
在页面上创建一个隐藏的 iframe, 使用 iframe 的 src 请求 partial, partial 可以作为一个完整的页面，里面包含 JavaScript，由 partial 里的 JS 完成替换 index 上页面片段替换。

第二种看起来更繁琐，但能给我们更多控制权。例如，假如用户直接访问 foo.com/partial（这种情况很容易发生，假设您是 unobtrusive 的拥护者，机会更大，例如需要点击网页上的链接更新某部分内容时，用户使用新窗口打开了改链接）, 你希望她看到的是什么内容呢？
在第一种情况中，用户看到的是代码片段，绝大部分下没有任何样式，也没有任何额外提示，导致用户体验的下降。因为只是一个 HTML 片段，你什么事都干不了。
但在第二种情况下，用户看到内容可能也只是 HTML 片段，但这却是一个完整的页面，一个可以执行 [...]]]></description>
		<link>http://chen.xianan.name/blog/2008/11/30/benifit-of-fecthing-page-via-iframe/</link>
			</item>
	<item>
		<title>Firebox 3 后退后按钮 diasabled 状态不恢复的一个解决方案</title>
		<description><![CDATA[Firefox 3 有一个很让人讨厌的bug：基于某种目的，在表单提交时 disable 掉提交按钮，通过后退键回到这个页面后，这个提交按钮的状态依旧保持为 disabled 的状态，重新载入（软硬刷新）也无法改变。
google 良久，从 https://developer.mozilla.org/En/Using_Firefox_1.5_caching 中发现一个 window.onpageshow 事件，window.onload 事件无法在后退的页面中出发，但这个可以，所以解决方案就是它了。

window.addEventListener('pageshow', function(e){
    // 重置你不需要 disabled 的按钮
}, false);

更新：网友岁月如歌的解决方案比我的方案简易和正宗多了：给提交按钮加上 autocomplete="off" 的属性。
]]></description>
		<link>http://chen.xianan.name/blog/2008/10/27/a-solution-to-firefox-back-button-disabled/</link>
			</item>
	<item>
		<title>AppKit 应用程序设计观</title>
		<description><![CDATA[原文来自  Application Design in AppKit.
This is a discussion of high-level application design in Cocoa that aims to explain the major class roles in an AppKit application and how they are connected. I&#8217;ll show you much more detail than simply &#8220;Model-View-Controller&#8221; and I also give a specific example of how all the concepts apply to [...]]]></description>
		<link>http://chen.xianan.name/blog/2008/10/10/application-design-in-appkit/</link>
			</item>
	<item>
		<title>form 元素内的字段 name 不要跟 form 属性名称一致</title>
		<description><![CDATA[长话短说，看这个 form 元素：
&#60;form method="post" action="_some_action_uri_" id="_form_id_"&#62;
&#60;input type="hidden" name="method" value="1" /&#62;
&#60;/form&#62;
试想一下，使用 document.getElementById('_form_id_').getAttribute('method') 会出现什么情况。Firefox 3, Safari 3, Opera 9.5 都会得到预期 &#8220;post&#8221;, 但是IE 6 和 7 就没有那么幸运了，得到的是一个 object: 其实就是 &#60;input type="hidden" name="method" value="1" /&#62; 这个元素。
因此，为避免混淆和挽救IE，最好是，as the title.
]]></description>
		<link>http://chen.xianan.name/blog/2008/10/08/do-not-use-filed-name-same-as-form-attribute-name/</link>
			</item>
	<item>
		<title>focus 进 textarea 元素后光标位置的修复</title>
		<description><![CDATA[问题
一个已经有内容的 textarea 元素，在执行该元素的 .focus() 方法后，不同的浏览器有不同表现。我们的预期是能够出现在内容后面，但只有 gecko 浏览器能做到。
修复
注意：这个函数不能直接运行，函数内的 isIE, isOpera 和 isWebkit 需要你的库提供或你编写，这并不难，对吧。
function fixTextareaFocusCursorPosition(elTextarea){
    if (isIE &#124;&#124; isOpera){
        var rng = elTextarea.createTextRange();
        rng.text = elTextarea.value;
        rng.collapse(false);
    } else if [...]]]></description>
		<link>http://chen.xianan.name/blog/2008/09/10/fix-cursor-position-in-focusing-textare/</link>
			</item>
	<item>
		<title>跨浏览器使用剪贴板</title>
		<description><![CDATA[一般情况下，访问或设置剪贴板，IE 只需使用 window.clipboardData 的 getData 或 setData 方法即可。Mozilla 家族的浏览器（如 Firefox）则比较麻烦，不仅开发者需要写一沱代码，用户也需要主动配合（就是需要设置允许访问剪贴板）才可以（参考 Using the Clipboard），以致几不可用。至于 Opera 则根本不提供剪贴板，Safari 可以在 onpaste 等非Dom 事件中访问剪贴板（参考 Using the Pasteboard From JavaScript）。
中国特色的网站上有一个很中国特色的应用就是，在一个输入框 focus 时自动帮你把内容复制到了剪贴板中。老实说访问剪贴板是个不安全的操作，因此即使是 IE, Windows 在后来的升级中都加入是否允许访问剪贴板的提醒。如果能够做到跨浏览器的“邪恶地悄无声息”地实现中国特色的剪贴板应用，确实是个不小的挑战。
遗憾的是老外在 2006 年就帮我们做到了：使用 Flash。参考 Clipboard Copy. 原版没有考虑不安转或禁止 Flash 的情况，我做了一个小改进：
function copy(inElement) {
    var get = function(id){
        return document.getElementById(id);
 [...]]]></description>
		<link>http://chen.xianan.name/blog/2008/09/01/using-clipboard-crossbrowsers/</link>
			</item>
	<item>
		<title>Web Forms 2.0</title>
		<description><![CDATA[Web Forms 2.0 是一个很有意思的东东，是 HTML 5 的组成部分。它的目标是提升表单的使用性 (usability)，基本上就是为 input 元素的 type 属性增加一些值，如 type="email"；还有一些新属性，如 required。根据 type 由浏览器实现各种功能。比如，&#60;input type="email" required="required" /&#62;，从字面上即可看出，这是一个必须填写，且格式是电子邮件的输入框。如果你用的是 Opera 9+, 猛击这个例子看看效果。
注意，这不需要任何 JavaScript，是浏览器内部实现的功能。很遗憾的是到目前为止只有 Opera 9+ 有部分实现，作为前端开发者，每天都在为表单验证、自动完成等提升表单用户体验的事情上拼了老命，重复发明轮子。好消息是，基本上这些都可以通过 JavaScript 来模拟实现，项目当然有人在做了：webforms2，不妨下载一试。
]]></description>
		<link>http://chen.xianan.name/blog/2008/07/22/web-forms-20/</link>
			</item>
	<item>
		<title>使用标准的表单字段名</title>
		<description><![CDATA[是不是很烦每次注册网站或填写相关资料时都要重来一遍？其实会有很多自动填写工具能代劳。比如使用 Mac, 在 Safari 的表单中，它可以足够聪明帮你从帐户资料中查找并填写一些相应的字段。Opera 也有相关功能，不过资料设置是在浏览器内。
当然，它们是根据表单的字段名称进行猜测与匹配的。如何给表单字段起个好名字，以方便自动填写工具的匹配，就变得有必要起来。
既然说“标准”，那名字肯定不是乱取的。RFC3106 据此而生。比方说，用户 ID 使用 Ecom_User_ID, 密码使用 Ecom_User_Password 等等，你可以访问该页面查看更多的对应实例。虽然商业气息比较浓重，但不妨碍我们的使用，以及给用户带来的便利。
]]></description>
		<link>http://chen.xianan.name/blog/2008/06/28/using-rfc3106-stardard-field-nam/</link>
			</item>
</channel>
</rss>
