实践

Mac下编辑JS文件, 如果是中文字符的行会警告: This character may get silently deleted by one or more browsers.

SublimeLinter 的官方文档http://goo.gl/VYzZ0, 里面也说的含糊不清, 只是告诉要装nodejs或设置sublimelinter_executable_map.
On Mac OS X, you must install Node.js if you plan to edit Javascript or CSS files that use non-ASCII characters in strings or comments, because JavaScriptCore is not Unicode-aware.
OS X默认的JavaScriptCore(jsc)不支持非ASCII字符, 所以会报上面的警告, 使用nodejs才行.

debug了下SublimeLinter的源码, 发现把Package Settings->SublimeLinter->Settings - User加上:
"sublimelinter_executable_map":
{
"javascript": "/Users/leon/.nvm/v0.10.8/bin/node" // which node
},
就OK了, 开始还以为要设置"node":"node path", 原来是设置"javascript"..

没安装nodejs到/usr/local/bin, 如果使用其他编辑器里的jshint/jslint应该也会遇到这个警告, 可以尝试修改node路径来解决.

以前弄scss只能在ruby下面, nodejs版less.js已经比较成熟, 而sass.js(1)不支持scss(后面作者又去开发Stylus了~), 后面出现的scss-js(2)已经错过时机(支持scss语法有限, 已很久没更新了).
这大概是导致目前less在国内爆发的一个原因吧. 排除环境依赖影响, 个人感觉sass比less好很多, 相信不少同学也这样认为~
对比了目前的4种css预处理语法: sass(scss)/less/stylus/closure-stylesheets, 还是更喜欢scss.

用nodejs写小工具蛮适合的, 但之前苦于sass在nodejs下没有比较好的package. 终于node-sass(3)出现, 目前npm里最好的sass package, 测试了一些scss文件基本都OK, 语法有误时也会返回错误信息.

基于node-sass写了个小工具, 监听项目目录, 当文件夹里的.scss文件被修改则立即编译成css文件, 使用:
1. sudo /path/scss.js # 载入已写好的配置, 侦听多个项目;
推荐这种方法, 把多个项目的配置信息写到 scssConfig.js中, 不需要额外的参数.
2. sudo /path/scss.js -build # 读取所有的.scss并编译成.css文件;
3. sudo /path/scss.js -clear # 清除错误日志(如果配置了 scssConfig.js里logDir的路径);
4. sudo /path/scss.js /path/project1/ /path/lib/ # 临时监听project1目录, lib为.scss里@import的path(无@import,可以省略);

源码放在: https://github.com/kairyou/f2e-tools/tree/master/scss

附送使用node-sass时遇到的问题以及解决方法:
1. error reading values after :
读取value出错, 可能是颜色错误不是6位或3位, 比如:color:#abcde;
2. .scss里面写: @charset "UTF-8"; 会报错: top-level blockless directive must be terminated by ';'
@see: https://github.com/andrew/node-sass/issues/23
3. error reading values after opacity / progid
使用: unquote("..."); @see: https://github.com/hcatlin/libsass/issues/72

文中提到的sass几个package的link:
1) sass: https://github.com/visionmedia/sass.js
2) scss: https://github.com/bmavity/scss-js
3) node-sass: https://github.com/andrew/node-sass

有了nodejs版, 其他语言(非ruby), 比如PHP的phpsass/scssphp等就可以忽略了~

更新
2015/03/02: 解决了Chrome/IE11下面的图片空白问题;

• 优先用二进制代替base64, 提升性能;
• before/always 参数, 针对很大的图(>=20M), 缩图时间较长时, 可以设置loading提示. 2013/08/01: 解决了后面遇到> 的bug: 图片被压扁(IOS6); 图片被旋转;
  整个源码放在: https://github.com/kairyou/html5-make-thumb

新方案需要后面实现的, 就是下面的旧版本里的功能(水印/是否强制拉伸以适应目标尺寸等功能).

w3ctech长沙站交流会, 里面分享的PPT: http://www.slideshare.net/99leon/html5-create-thumbnail

之前有bug的版本放在分支old里(不推荐使用), 请使用更新的方案~

2013/01/07:
11年做的公司的移动页面, 上传图片时缩略图是靠后端生成, 但是随着现在的手机越来越牛X(摄像头比数码相机还厉害~), 图片体积也越来越大.
一个几M的图, 也许我们只是用来生成一个100*100的小图, 上传到后端再生成缩略图就大大的浪费了, 而且提交表单的等待时间也非长久, 对用户体验也不好.
普通的web表单, 上传图片靠后端来生成缩略图很平常, 但有了HTML5, 针对移动Web开发可以考虑使用前端生成缩略图了.

写了个生成缩略图的jquery的插件, 主要参数:

width: 生成缩略图的宽; height: 生成缩略图的高;
fill: 图片小于缩略图尺寸时, 是否填充(false: 缩略图宽高自动缩放到适应图片, true: 缩略图尺寸不变)
background:生成图片填充背景(默认#fff, 设置null时, 背景透明)
type: 生成图片类型 ('image/jpeg' 或 'image/png')
size: 生成缩略图方式, 生成缩略图的效果主要参考了CSS3的background-size属性:
  contain: 等比缩放并拉伸, 图片全部显示;
  cover: 等比缩放并拉伸, 图片把容器完全覆盖;
  auto: 图片不拉伸, 居中显示.
mark: 水印
  文字水印: mark = {padding: 5, height: 18, text: 'test', color: '#000', font: '400 18px Arial'}
  图片水印: mark = {padding: 5, src: 'mark.png', width: 34, height: 45};
stretch: 小图是否强制拉伸以适应缩略图的尺寸(size = auto/contain时)
success: 生成缩略图后 callback

大体思路如下:
首先判断是否支持fileReader(支持fileReader, canvas就不在话下了)
不支持的话: 不做任何操作, 默认的input type="file"上传, 靠后端生成缩略图.
支持的情况: input change时, 判断选择的文件是图片, 就创建一个隐藏的canvas, 并把图片画到canvas里,
因为要生成缩略图, 所以在canvas里画图的时候, 控制剪切坐标和被剪切的宽高就OK了.
另外可以加上水印, 图片水印或者文字水印加到canvas上面也是比较方便的.
最后 canvas.toDataURL 转成base64, post到后端(先把input type="file"移除, 再生成个新的input type="hidden"储存图片数据), 后端接收后直接保存为图片就OK了.
主要用到: FileReader和canvas, 一个用来读取本地图片, 一个用来生成缩略图.

做移动网页开发的同学可以考虑下.

基于sublime的SimpleSync插件修改, 完善了原插件的一些缺陷, 比如: 不支持windows系统, 保存时会强制同步, 不支持快捷键调用, 修改配置需要重启sublime.
所以把源码大部分都修改了. 原版优秀的地方也都已保留, 比如: 执行同步时使用多线程来避免UI阻塞, 同时支持本地同步和同步到server.
已增加对ST3的支持.

下面把功能列一下:

1. 1. 把本地项目的文件同步到本地或server (比如可以用来: 同步到server端预览, 减少不停地commit-push-pull; 或本地编辑时备份到其他文件夹等)
   注: 同步本地用cp命令, 同步server用scp命令
2. 2. 支持多文件夹, 可以把所有项目的规则写到一起, 针对不同的文件夹执行不同的命令.
3. 3. 支持多规则, 可以把当前编辑的文件同时推到N个server或本地文件夹.
4. 4. 同步时的命令利用threading多线程执行, UI不会阻塞, 可以继续操作编辑器(否则sublime执行CMD等命令会卡住, 等命令结束才会响应)
5. 5. + 支持windows系统 (原版只支持MacOS and Linux)
6. 6. + 保存文件时是否自动同步, 可在配置里设置 ("autoSync": false)
7. 7. + 支持快捷键调用同步 (会自动保存当前文件, 再同步)
8. 8. + 同步前读取配置, 修改配置不需要重启sublime.

简单配置:

修改配置: Preferences > Package Settings > sublimeSimpleSync
增加快捷键: Preferences > Key Buildings - User, 添加一行, 比如:
{ "keys": ["alt+s"], "command": "sublime_simple_sync"},

项目地址: https://github.com/kairyou/SublimeSimpleSync

对于压缩工具前端攻城师最常见的就是雅虎的Yui Compressor / Google的Closure Compiler了。
对比其他压缩工具相对在JS和CSS压缩领域比较成熟，压缩率也比较好.
一般会选择结合ANT实现压缩并合并，效果也不错，但是比较偏向个人，团队协作每个人都部署java/ant有些麻烦。
对于个人开发使用ANT的方案也是相对不错的选择。对于团队，最好的解决办法是在服务端压缩，大家只需要登录并执行一个统一的脚本。

下面分享下大致的测试结果，和改用nodejs压缩合并js/css的原因。

js部分采用UglifyJS

1. 压缩jquery 1.8，253 KB：使用UglifyJS(以下简称UJ): 90.5 KB；使用Closure Compiler(以下简称CC): 91.1 KB。

2. 如果在闭包(function($, window, undefined) {...})(jQuery, window); 内的 unused function/variables
CC会被删除没使用的；UJ 默认全部保留，加上 pro.ast_lift_variables(ast) 才会删除未使用的函数/变量 (对象/数组 不会被删除)。
如果直接暴漏在window下的，两个基本差不多。

3. function c(){2}， CC 会警告，UJ不会
4. function c(){e()2}，都会抛出异常，显示行数，错误原因。CC提示列错误，UJ不会。
5. function c(){e();2}，都保留了2，CC 警告，UglifyJS 无信息
6. CC 一次显示JS里的全部错误(有些是前面的错误引起的, 所以部分是误报)，UJ每次只显示一个错误。

7. 0 = {}; CC会报错，而UJ不会。
8. if语句都可很好的优化。

9. CC喜欢把变量/函数(结构简单的)内的语句，直接插入到使用它们的地方，UJ维持原样。
如果函数内的内容较少, CC会把函数的内容直接插入到调用它的地方，比如：
function c(){xxxxxxx('12345678901234567');}
function c(){xxxxxx.yyyyy('12345678901234');}
function c(){xxxxxx.yyyyy.zzzz('12345678901');}
function c(){if (X){alert('1234')};alert('12');}
当其他函数里调用c()时，会把c()方法删除，然后把c()内的内容移动到这里
(当里面的字符串长度+1后，就会直接使用原函数c()，所以CC这里是根据字符长度)。

查看全文 »