走在路上，想到明日依旧，于是微笑着耸耸肩搭上回家的公车。

一直在想，我应该是不会因为某些事情而抱有患得患失的情绪吧。我不想变得如他们所说的那样，但我也深深地担忧，担忧自己的坚持是否正确。比起两年前，我改变了一些。是的，学会了放下。

生活现在就是我的全部，家庭是最为重要，一切和这温暖相背的苦恼都要抛开。只要生命不息，未来就都还存在，一切都还是希望。并不是没有梦想，努力吧。

感谢吾妻，我爱你。

原文地址：CSS Selectors parsed right to left. Why?
中文翻译由 dengsa 独立完成，如若转载请注明。

Keep in mind that when a browser is doing selector matching it has one element (the one it’s trying to determine style for) and all your rules and their selectors and it needs to find which rules match the element. This is different from the usual jQuery thing, say, where you only have one selector and you need to find all the elements that match that selector.
记住，当浏览器在做选择器匹配时它会有一个元素（就是试图判定要样式化的那个）还有你所有的规则及选择器，浏览器需要找到哪条规则是和这个元素匹配的。这和 jQuery 之类的不同，嗯，你只有一个选择器然后你需要找出匹配它的所有元素。

If you only had one selector and only one element to compare against that selector, then left-to-right makes more sense in some cases. But that’s decidedly not the browser’s situation. The browser is trying to render Gmail or whatever and has the one it’s trying to style and the 10,000+ rules Gmail puts in its stylesheet (I’m not making that number up).
如果你只有单个选择器并且只有单个元素要和这个选择器比对，“从左至右”有时候是很能讲得通的。但那显然不适用于浏览器环境，浏览器正试图渲染 Gmail 或者其他什么的有一个要样式化的 和 Gmail 放入样式表的那 10,000+ 以上的规则（我并没有夸大这个数字）。

In particular, in the situation the browser is looking at most of the selectors it’s considering don’t match the element in question. So the problem becomes one of deciding that a selector doesn’t match as fast as possible; if that requires a bit of extra work in the cases that do match you still win due to all the work you save in the cases that don’t match.
详细说来，浏览器其实是在考虑大多数选择器并不匹配元素。所以问题就成了要尽快地确定一个选择器是不匹配的；如果那需要稍微更多一点的工作量，不匹配的方案节省的工作量也仍旧好过于匹配的方案。

If you start by just matching the rightmost part of the selector against your element, then chances are it won’t match and you’re done. If it does match, you have to do more work, but only proportional to your tree depth, which is not that big in most cases.
如果你从选择器最右侧部分开始比对你的元素，然后碰巧它不匹配然后就结束了。如果它匹配，你必须做更多的工作，但只和树的深度成比例，很多情况下它不会很大。

On the other hand, if you start by matching the leftmost part of the selector… what do you match it against? You have to start walking the DOM, looking for nodes that might match it. Just discovering that there’s nothing matching that leftmost part might take a while.
另一方面，如果你从选择器最左侧部分开始比对… 你会怎么匹配呢？你必须开始遍历 DOM，查找可能匹配的节点。只是会发现从最左侧部分匹配可能会耗费一点时间然后又一无所获。

So browsers match from the right; it gives an obvious starting point and lets you get rid of most of the candidate selectors very quickly. You can see some data at http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (though the notation is confusing), but the upshot is that for Gmail in particular two years ago, for 70% of the (rule, element) pairs you could decide that the rule does not match after just examining the tag/class/id parts of the rightmost selector for the rule. The corresponding number for Mozilla’s pageload performance test suite was 72%. So it’s really worth trying to get rid of those 2/3 of all rules as fast as you can and then only worry about matching the remaining 1/3.
所以浏览器从右侧开始匹配；它给出来一个显而易见的出发点并且让你非常快速地处理大量的候补选择器。你可以在 http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 看到一些数据（虽然表现形式有些乱），但要点是针对于两年前的 Gmail 来说，70% 的（规则和元素）搭配在刚检索到选择器最右侧规则的 tag/class/id 部分时你就能确定这个规则是不匹配的。相对应的 Mozilla 的 pageload performance test suite 的数字是72%。所以尝试越快去除这 2/3 的规则是相当值得的，然后只要操心剩下的 1/3。

Note also that there are other optimizations browsers already do to avoid even trying to match rules that definitely won’t match. For example, if the rightmost selector has an id and that id doesn’t match the element’s id, then there will be no attempt to match that selector against that element at all in Gecko: the set of “selectors with IDs” that are attempted comes from a hashtable lookup on the element’s ID. So this is 70% of the rules which have a pretty good chance of matching that still don’t match after considering just the tag/class/id of the rightmost selector.
另外有其他一些优化过的浏览器已经做到了避免明显不合的规则匹配。举个例子，如果最右侧选择符有一个 id 并且这个 id 不匹配元素的 id，然后在 Gecko 中就再也不会尝试给这个选择器匹配元素了：“含有 ID 的选择器”集合是来自于一张检视元素 id 的哈希表。所以这就是 70% 的规则看似很有机会匹配上但是在仅考虑到选择器最右侧的 tag/class/id 之后就仍旧不会匹配的原因了。

Long time no see…

之前写过一篇《Firefox下获取图片文件的Base64编码字串》，主要是用来获取各网站的 favicon.ico 以供 Custom Buttons 2 扩展玩耍…

最近为 iOS 的应用书写内置页面，会比较频繁地获取所需图片的 Base64 编码直接内嵌写进页面代码中，写过一个 PHP 的小脚本但还是感觉不够便捷，于是想到要用 HTML5 的文件拖拽才好些…

实现原理为：使用 HTML5 拖拽 读取图片属性，然后交给 FileReader 获取编码。

blackhole.ondrop = function(e){
	e.stopPropagation();
	e.preventDefault();

	var files = e.dataTransfer.files,
		filter = /^(image\/bmp|image\/cis-cod|image\/gif|image\/ief|image\/jpeg|image\/jpeg|image\/jpeg|image\/pipeg|image\/png|image\/svg\+xml|image\/tiff|image\/x-cmu-raster|image\/x-cmx|image\/x-icon|image\/x-portable-anymap|image\/x-portable-bitmap|image\/x-portable-graymap|image\/x-portable-pixmap|image\/x-rgb|image\/x-xbitmap|image\/x-xpixmap|image\/x-xwindowdump)$/i;
	for (var i=0,j=files.length;i<j;i++){
		if (!filter.test(files[i].type)){
			console.log('not image');
			return;
		}
		(function(i){
			var reader = new FileReader();
			reader.onload = function(event){
				document.getElementById('parallel').innerHTML += '<textarea onfocus="this.select()" style="background:url(data:'+ files[i].type +';base64,'+ btoa(event.target.result) +') no-repeat;">data:'+ files[i].type +';base64,'+ btoa(event.target.result) +'</textarea>';
			};
			reader.readAsBinaryString(files[i]);
			return false;
		})(i);
	}
};

DOM 操作可忽略，读取 file.type 进行图片类型过滤，使用闭包立即执行当前 file 操作。17 行为 FileReader 指定读取类型为二进制，由此才能把正确的编码赋给 event.target.result 转交给 btoa 函数进行 Base64 编码。

参考文档：
Selecting files using drag and drop
HTML 5 Demos and Examples

1. HTML5
HTML5Rocks！20thingsilearned！Wait，这些不是HTML5？HTML5到底是个啥？纯标记语言还是一个概念集合？HTML5 presentation、[学习]HTML5 js APIs，HTML5 Security Cheatsheet。

2. CSS Reset
Eric Meyer 又又又又谈 CSS Reset！！！萝卜白菜自己挑，为项目选择正确的 reset.css 才是正经事。这里有CSS Reset编年史，还有关于css reset中list-style:none的一些想法，另外还有关于*{margin:0;padding:0}的争议。

3. 开会
O’Reilly Velocity China 2010 & 5th D2

GReader 和 RIL 上面都囤了超多的标星未读项…

1. ejohn 和 NCZ 的辩论
射雕的评论，里面提到了豆瓣的基于 jQuery 的 Do 框架。被“闻味”的时候问有没有写过框架，内心小纠结了一下。称职的前端都应该写好 js，我还不称职…

2. twitter 的 URL hash
Making AJAX Applications Crawlable，定义一个特殊标记给 googlebot 抓取 AJAX 内容。话说 #! 也不见得比 _escaped_fragment_ 有多 pretty…

3. 正则优化
jQuery Regular Expressions Review、复杂的正则表达式应该如何构造，[正则优化] CSS选择符匹配。正则开销很大，如何优化才能做到又快又好又全，有时候越写越繁也是很有必要的。回家好好啃猫头鹰书去…

不定期，记录下随意想到的东西，老婆大人亦有重大贡献！

1. 关系：
朋友、爱人、情人甚至是讨厌的人，邀请身边的人加入虾米，知道他们在听什么，心情怎样，“SNS”。

2. 心情：
记录用户心情和正在听的歌曲，后期统计数据提炼出心情电台，“心情抱抱团”。

3. 纪念曲：
朋友情人之间的小秘密，记录这首歌的纪念意义来历和故事，“有故事的歌”：可以是歌曲的制作背景，也可以是网友的故事。

4. KTV：
自己的保留曲目、必点歌曲、“一人一首成名曲”，唱K前温习一下，相同曲风推荐新歌练习，看当下流行唱什么歌，歌词很重要，“歌友会”：以歌会友，线下邀约活动。

5. 新人指引：
“新手任务”，弱化虾币机制，鼓励用户听歌打分，把低端用户吸收进来再分流转化。

6. 粉丝团：
“fans签名墙”，专辑纪念品门票优惠券团购，明星动态新闻八卦。

7. 工具包：
“婚礼用曲库”，风格分类包、懒人包、排行榜包，打包出售。

8. 点歌台：
给身边的人点一首歌，或者是特殊的日子或者是随性，回访邮件也可以点歌邀请收听。

*** 媒体合作，增加知名度；统一页面样式，放低姿态，改进内容推荐平民化，简化使用流程和板块子功能。

• 如果没有人分享，那快乐也便没有意义。
• 最近早上几乎都是瞬间醒来的，觉得有什么压在胸口。难受，脑子在挣扎，然后便猛地睁眼起床了。有在想装修的事，也有在想自己和她的事，都是些巨大的石头。
• 老狗说我心态有问题，才导致生活起了变化。
• 精神胜利是我思想的全部，我讨厌我自己。
• 闷。

1. favicon.ico 404

2. 静态资源未使用不发送COOKIE域名

3. 页面存在多种图片文件调用写法
图片文件路径过深且意义与子域名重复
未分割图片服务器以缓解请求数

<img src=”http://img.xiami.com/./images/album/img90/199890/h22856a2u80_3.jpg” width=”55″ height=”55″ alt=”The Invisible Deck” />
<img src=”http://img.xiami.com/images/album/img26/16226/142982_3.jpg” width=”55″ height=”55″ alt=”Mechanical Resonance” />

4. 页面相关静态资源调用零散

<img src=”res/img/default/rss2.0.gif” width=”16″ height=”16″ alt=”Rss订阅” />
<link type=”text/css” href=”http://st.xiami.com/res/css/default/main15.css” charset=”utf-8″ media=”screen” rel=”stylesheet” />
background:url(http://img.xiami.com/res/img/default/mbg.jpg) top repeat-x #fff;

5. sprites拼接不完全
页面相关图片未压缩

http://img.xiami.com/res/img/default/navi_mbg.png

http://img.xiami.com/res/img/default/bg_sprit2.gif

6. DOM结构过深
CSS选择器层级过深且未优化
未压缩CSS文件

7. 一次性请求隐藏区块图片
行内脚本写法欠妥

<a href=”javascript:;” class=”selected” id=”tablink1″ onmouseover=”easytabs(’1′, ’1′);” onfocus=”easytabs(’1′, ’1′);” onmousedown=”return false;”>发布</a>

P.S. 以上观点纯 Page Speed 及 YSlow 分析结果背书~~

豆瓣链接：《Web界面设计》

在学校图书馆翻着粗看了一遍，此书例举了许多优秀的页面设计来提取观点。个人感觉有些专用名词翻译成中文味道变得怪怪的，还好书籍中保留了标题名词的英文。摘了几点自己感觉有用的文字，记录如下：

• 在用户按下鼠标并拖动了3像素或按住鼠标超过0.5秒时启动拖动。
• 如果上下文工具涉及邀请用户执行非常重要的操作，则应该保持其始终可见。
• 不要让用户为了搞清楚工具的含义而悬停鼠标。
• Web应用程序越像桌面应用程序，就越容易利用用户已有的桌面应用程序操作经验。
• 单击左箭头应该从左往右滚动内容，单击右箭头应该从右往左滚动内容。
• 从视觉效果看，扩展比加亮／减暗更容易吸引眼球（因为移动与轻微的颜色变化更显而易见）。
• 为避免过分强化加亮效果或计时变换，应该把效果的值减少一半。
• 自动完成绝对不应该让用户滚动下拉列表去选择已经选中的项！按Tab键应该就可以输入匹配项。
• 使用渐进展现把较为复杂的过程变得更为轻巧。

原文地址：A Nice Little CSS Positioning Technique
英文版权归 Greg 所有，中文翻译由 dengsa 独立完成，如若转载请注明。

A Nice Little CSS Positioning Technique
小而美的CSS布局技巧

==============================

Our Phil (finish your site mate!) asked me to pop this up here, it’s a neat little CSS positioning technique I use all the time. It’s not particularly difficult, nor is it massively new and revolutionary, but I see a lot of people achieving similar results in spectacularly longwinded ways.
我们的Phil（完成你的站点兄弟！）要我把文章在这儿发出来，这是我一直在使用的一个很工整小巧的CSS布局技术。它既没有高难度，也不新潮亦非革命性，但我看到很多人为了达到相同的目的使用了巨啰嗦的方法。

There are a loads of instances where this little technique could be employed, but I’ve used a list as an example because it’s one of the most common. Here we have a basic unordered list (<ul>), with floated-left images where the text doesn’t wrap under the images. Told you it was simple.
有超多实例可以用来例证这个小技巧，但我只用一个最普通的列表示例。这儿有一个基本的无序列表（<ul>），有左浮动图片并且文字没有包围着图片。说了这很简单吧。

Ignore the extraneous styling I’ve used in this example (I can’t help it!), I’ll be dealing with just the layout of the list in the CSS. Also the example images aren’t accurate in terms of dimensions, they’re shown here merely to assist.
忽略我用在这个例子上的无关紧要的样式（哥情不自禁啊！），我只处理CSS中的列表布局部分。并且这个例图在尺寸方面并不是很精确，它们只不过是帮助展示而已。

Now I’ve seen loads of people use two divisions in this situation, one for the image and one containing everything else, floated left and right respectively. It’s really not necessary and can be a pain in the arse dealing with all those pesky floats. The HTML for this method is as follows:
目前我看过超多人在这种情形下使用到了2个块级元素，一个给图片另一个包含其他所有东西，左右各自浮动。这真的不必要而且处理所有这些恼人的浮动太痛苦了。接下来是这个方法的HTML结构：

<ul>
    <li>
        <img src="image1.jpg" alt="" />
        <h3>A heading</h3>
        <p>A nice little paragraph, Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
    </li>
    <li>
        <img src="image2.jpg" alt="" />
        <h3>Another heading</h3>
        <p>A nice little paragraph, Lorem ipsum dolor sit amet.</p>
    </li>
    <li>
        <img src="image3.jpg" alt="" />
        <h3>Final heading</h3>
        <p>A nice little paragraph, Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Pellentesque congue ante et sem. Cras consequat magna nec elit. Maecenas imperdiet augue nec libero mattis faucibus.</p>
    </li>
</ul>

Well simple. Next, we’ll use some classic CSS that I’m sure you all use everyday (as I mentioned earlier, I’m ignoring all the extraneous styling that would have to happen to realise the examples; the green, the type, spacing, etc):
很简单吧。接下来，我们要使用一些你天天用的传统的CSS（正如我前面提到的，我忽略了所有实现样例的无关样式；绿色，文字，间隔等等）:

ul li { padding-left:70px; overflow:hidden; }
ul li img { float:left; }

This will leave you with a nice floated image and some padding where the image will sit. The overflow: hidden; clears the contents of the list-item, meaning you don’t have to worry about clearing floats.
这将给你一个浮动的图片并且图片占据了一些间隔。overflow: hidden; 清理了列表项目的内容，意味着你不必担心要清除浮动。

Next we need to get that image where it belongs:
接下来我们要让图片到它该去的地方：

ul li img { float:left; position:relative; left:-70px; }

This will give us something like this. Because we’re using position: relative;, the image is still in it’s place in the flow of the HTML document, hence the gap, but our positioning has simply pulled it over to the left.
我们将看到这样的效果。因为我们用了 position: relative;，图片依旧在HTML文档流中它的位置上，有了间隔，不过我们的位置被轻易地拉过到了左边。

Now to closed up that gap:
现在来靠拢那个间隔：

ul li img { float:left; position:relative; left:-70px; margin-right:-60px; }

Job done. I know that this can be done using absolute positioning on the image, and min-height on the list-item (to make sure the list-item doesn’t cut off the bottom off the absolutely positioned image), but this method caters for images of varying heights, and plays nicer with IE6.
做完啦。我知道这能使用图片绝对定位，还有列表项目的最小高度（确保列表项目不会裁掉绝对定位图片的底部）来做到，但是这种方法很契合高度变化的图片，并且在IE6下表现美极了。

Apologies if this insulted everyone’s intelligence; blame the Swan^[1].
如果这侮辱了所有人的智商那我要说抱歉了；要怪就怪Swan吧。

==============================

[1] Swan就是Phil