原文标题：《Functions as Namespaces, and How to Peek Inside》
原文地址：http://www.davidflanagan.com/2009/11/functions-as-na.html
很精彩的技巧，通过闭包和eval()的使用，达到标题中的功能。
var value = (function() { // Wrapper function creates a local scope…
Archive for the ‘翻译’ Category
同事发来了一篇《Clever JPEG Optimization Techniques》，文中提到的部分技术很细致，分享下。
大部分人在考虑图像压缩优化的时候，还只停留在设置图像处理软件的保存选项上。另外我们也有一些常用的优化工具，诸如OptiPNG和jpegtran。但是还有一些鲜为人知的方法，比如即将介绍的“8像素格优化方法”，它的原理是基于图像数据存储的格式上的。
8像素格
众所周知，jpeg图像存储是以8像素格为基本单位的，看下图示例：
32×32 pixels, Quality: 10 (in Photoshop), 396 bytes.
两个白色块大小均为8×8像素，图像保存质量为低。可以看出，左上角的方块很清晰，右下角却出现了杂色，这是为什么呢？让我们放大图片并画出参考线格：
可以看出，左上角的方块恰好在8×8格子里面（占据4个），而右下角的却横跨了9个格子，除了中间部分占满一个格子外，周围8个都只占据一部分。
由于jpeg存储算法中，每8×8个像素格是单独进行优化的，算法会寻找这个基本单位格中的均色（jpeg是以颜色正弦波编码）。因此，图像处理时应该尽可能考虑到这点，使得元素的位置靠近每个8×8的像素格。
这个方法使用起来很简单，比如下面这个例子：
13.51 KB
12.65 KB
第一张图片中，微波炉的位置是随意放的，而第二张却经过了细微的调整。两者存储的质量相同，都是55。让我们放大点看，红线是参考线：
可以看到，在略微移动了几个像素之后，图像减少了大约1 KB，并且也更清晰了一点。
颜色优化
这部分主要介绍不常用的图片存储格式，它主要应用在电视上面，暂不介绍。
常见的JPEG优化方法
这里介绍一些常用的优化方法。
JPEG算法很严格，唯一的压缩准则是图像软件设置里的质量选项。你可能在Photoshop中存质量为55～60的图片，但是在其它软件中存80质量才拥有同样的尺寸和外观。
一定不要用100的质量来保存图片！这其实并不是最高的质量值，因为这只是个数学理论上限，如果你非要质量很高的图片的话，一般存到95就够了，5点的质量丢失几乎没有区别。
注意Photoshop中低于50质量的图片保存。因为在50之下的时候，jpeg优化会启动一个附加的算法——color down-sampling——它将均衡相邻的8×8像素格的颜色。
48×48 pixels, Quality: 50…
NCZ在他的同名博客《Feature detection is not browser detection》中，讲述了一直以来前端开发中的一个热门技术——检测用户的浏览器平台，并详细地叙说历史发展以及各种办法的优缺点。我大致翻译了部分文章，可能有理解错误的地方，敬请指正。值得一提的是，评论部分的争论亦值得一看。
特性检测
起初前端工程师们就极力反对浏览器检测，他们认为类似user-agent嗅探的方法是很不好的，理由是它并不是一种面向未来的代码，无法适应新版的浏览器。更好的做法是使用特性检测，就像这样：
if (navigator.userAgent.indexOf(“MSIE 7″) > -1){
//do something
}
而更好的做法是这样：
if(document.all){
//do something
}
这两种方式并不相同。前者是检测浏览器的特殊名称和版本；后者却是检测浏览器的特性。UA嗅探能够精确得到浏览器的类型和版本（至少能得知浏览器类型），而特性检测却是去确定浏览器是否拥有某个对象或者支持某个方法。注意这两者是完全不同的。
因为特性检测依赖于哪些浏览器支持，当出现新版本浏览器的时候需要繁琐的确认工作。例如DOM标准刚出现的时候，并不是所有浏览器都支持getElementById()方法，所以一开始代码可能是这样：
if(document.getElementById){…
和我同住的某人开始把翻译好的《Project Darkstar》中文文档上传至Blog了，在这里宣传转一下。
地址：http://www.david0446.com/?p=6
原文标题：《Rich HTML editing in the browser: part 2》
原文地址：http://dev.opera.com/articles/view/rich-html-editing-in-the-browser-part-2/
介绍
在本系列文章的第一篇中，我详细阐述了如何利用javascript语言在设计模式（designMode）和可编辑内容（contentEditable）中创建html富文本编辑器的理论知识。这些文档对象模型（DOM）已经成为HTML5标准的一部分，并且现代主流浏览器也陆续地开始支持。本篇文章作为第二部分，我将化理论为实践，带你走进制作一款简单而跨浏览器的在线文本编辑器的世界。
你可以在这里看到在线完成的版本，点这里能下载它的源码。下面列出的将是代码中最重要的部分，我们将详细地来叙说它，其余乏味的地方就被省略了。
所有代码被分割为3个文件：
editor.js：主要的应用程序结构
editlib.js：一个修改选区的方法集合
util.js：一些有用的方法
框架
我们将使用一个空白的内嵌（IFrame）页面作为画布：
<iframe id=”editorFrame” src=”blank.html”></iframe>
我们可能会这样用：清除源文件中的代码从而得到一个body里完全没有任何元素的空白页，但是我更倾向于创造一个自定义“空白页”，里面放入一个空的段落，就像：
<title></title>
<body><p></p></body>
这样做自然有它可取之处，因为使用p元素作为开始来包含内容的话，Mozilla便能够和其它浏览器兼容了。（倘若不这样做，Mozilla将直接进入body元素的内容区。）使用可编辑内容属性（contentEditable attribute），我们能够避免使用框架而直接在页面上创建一个可编辑的div区域，但是Firefox 2并不支持，所以为了兼容性最好还是以内嵌页面（IFrame）为基础来制作跨浏览器的编辑器。
激活编辑模式
当页面加载完成时，我们使用下面的方法来激活编辑模式（editor.js中）。
function createEditor() {
var editFrame = document.getElementById(“editorFrame”);
…
原文标题：《Rich HTML editing in the browser: part 1》
原文地址：http://dev.opera.com/articles/view/rich-html-editing-in-the-browser-part-1/
介绍
时光倒流。在世界上最早的浏览器——提姆·伯纳·李（Tim Berners-Lee）发布于1990年——诞生的时候，我们可以直接在所见即所得模式下编辑网页的内容，那时的网页被构思为一种可读可写的媒介。后来经过一段时间的发展，浏览器基本上变得只读了，除了只能在form控件中输入一些纯文本而已。
Internate Explorer 5的发布将浏览器的所见即所得编辑特性带回了主流：新的设计模式（designMode）属性允许用户编辑整个文档（document）。一开始这一特性显得多少有些疏忽，因为它最初是Windows操作系统下IE专有的。
近些年来，另一些可以和IE抗衡的浏览器——Mozilla、Safari和Opera——跟随并实现了这一IE独有的特性。排版引擎比较组织（WHATWG-group）也致力于编辑系统标准的建立——HTML5中设计模式和可编辑内容文档对象模型属性（contentEditable DOM properties）的介绍。看起来在浏览器中，所见即所得编辑最终将成为网页整体的一部分。
这篇文章利用HTML5的可编辑特性来评审现今浏览器的基本概念和挑战。这些科目包括：
不同的可编辑模式
编辑命令
编辑产生的HTML代码
和DOM的配合
这篇文章是两篇系列文章的第一篇，第二篇内容将覆盖到一个详细的例子来实现一个编辑器。
注意：我只考虑到最近的主流浏览器所支持的特性：Opera 9.5、Firefox 2+和Safari 3，较旧的版本有太多的bug和不稳定的地方了。IE中的实现直到5.5版本才有了明显的变化。
可编辑系统预览
可编辑系统允许用户编辑页面或者页面中的一部分，它有如下几个方面：
光标（caret）标识当前的插入点。用户可以输入、删除等。使用键盘或鼠标可以移动光标或者选区。
一些浏览器提供UI组件用户缩放重定位图片、表格和其它可重定位的元素（elements）。
内置了一系列独立的编辑命令：粗体、斜体、插入链接、粘贴、撤消等。这些可以被快捷键、脚本命令接口（script command API）调用。使用API可以轻易实现一个编辑器的工具栏（toolbar）。
使用范围和选区接口（range and selection…
http://jqueryvsmootools.com/#mottos
今天开了个小会，讲解了mootools的navative实现，最后也提到目前前端用mootools、技术部用jquery的事情。我是比较喜欢mootools的，于是从javaeye的mootools圈子里找了篇经典分析文章。原文很长，上面是链接，我就翻译了一段看看。
格言反应了一切
如果你打开jquery首页，页面顶部是这样说的：
jquery是一个快速的、简单的javascript库，它为快速web开发者们简化了遍历html的document、事件句柄、动画、ajax接口。jquery的设计目的就是改变你书写javascript的方式。
而如果你进入mootools的网站，则会发现这句话：
mootools是一个健壮的、模块化、面向对象的javascript库，它是为中高级javascript程序员设计的。借以其优雅的设计、良好的文档、清晰的API，它能让你书写出强健的、灵活的、跨浏览器的代码。
我想这是一个真实的总结。如果你问我（你正在读这篇文章，所以在这里假设你问我），并且问的并不是孰优孰劣，而是哪个对你而言更适合？答案是：这两个框架并不是尝试做相同的事情。虽然在功能方面它们有相同之处，但它们做的事情却完全不同。
jquery描述自己时提到了HTML、事件、动画、ajax和web开发者，mootools则谈到了面向对象以及编写强健、灵活的代码。jquery期望改变你书写javascript的方式，mootools则为中高级javascript程序员而设计。
一定程度上考虑一个javascript库的方法是将其与工具箱作比较。mootools尝试将javascript语言本身变得更加理想（根据mootools作者所说），提供的API就像是javascript语言本身具有的或者增强的，并不仅仅限于DOM。jquery则是个让你轻松地使用独立的集合方法来友好控制DOM的工具箱。大部分人在写javascript程序时都将主要精力放在DOM上，所以在很多情况下，jquery正是你想要的。
当你用mootools写代码时，大部分情况下你感觉你就是在写javascript。如果你对javascript作为一门语言来说不感兴趣，那么学习mootools就是件很吃力的事情。反之若觉得javascript是门有趣、强健、富有表现力的语言，那么我的个人意见是，mootools则是更好的选择。
本博客所有文章均采用