使用 Date 构造一个指定日期,即可以传入毫秒单位的 UNIX 时间戳,也可以传入一定格式的字符串。

默认地,

1
new Date().toString()//Mon Mar 02 2015 16:49:10 GMT+0800 (CST)

返回的字符串即为默认支持的日期表示形式,该格式定义于 RFC2822,也是 HTTP Header 经常使用的格式。

ECMAScript 5.1 开始支持一种新的表示形式 – ISO

1
new Date().toISOString()//2015-03-02T08:57:08.865Z

该格式在 ECMAScript 中的定义位于 15.9.1.15,它与 HTML5 使用的 RFC3339类似,区别参考 stackoverflow

因此 “modern” 浏览器都支持这两种格式,ISO 格式会被首先尝试。

除此之外,各种 UA 可以继续实现其它格式的支持,比如 Firefox 支持

1
new Date('3/2/2015')

Chrome 不支持;Chrome 支持

1
new Date('2015-03-02 15:00')

Firefox 不支持。

应尽量使用标准的日期字符串表示形式,ISO 对代码更友好。

另外,在解析字符串格式日期时,假设的时区是不同的,ISO 是 UTC 时间,否则为当前时区。

参考

font-face 用于在 CSS 中设置字体,所以主流浏览器都支持,即便是 IE6,只不过所支持的字体格式不同。这里可以支持在不同字体格式之间转换并生成兼容的 CSS 代码。

对于一个隐藏元素应用 font-face 样式会立即下载字体文件么?

UA visibility:hidden display:none
Chrome Y N
Safari Y N
Firefox Y N
IE Y Y

可见除 IE 外都会针对 display:none 的元素进行字体文件的延迟下载,这样就会出现类似 FOUC 的行为,文字会以默认的字体渲染,待字体文件下载完成后再重绘。

测试见这里

从来没有哪种飞机的造型会比 XB-70 “女武神” 战略轰炸机更让人影响深刻的了。想到几年前第一次看到它照片的时候,确实让我震撼了好一会儿,不得不佩服美国人的智慧。

XB-70

修长的“脖子”,可变角度的机鼻,并排的六台引擎,可变的三角翼翼尖使得它与之前任何一架飞机都不同。虽然属于重型战略轰炸机,却依然可以飞到之前只有 SR-71 高空高速侦察机才能达到的3马赫极速。

XB-70

它为能取代 B-52 “同温层堡垒”而进行高空高速突防苏联领空而研发,但其费效比已不如当时已经发展起来的弹道导弹。同时,苏联也已经服役了 Mig-25 “狐蝠” 高速截击机,它以牺牲航程为代价使得全身70%不锈钢材料却依然能达到3马赫的极速。加上昂贵的造价与苏联“萨姆”防空导弹的发展,这些因素最终使得 XB-70 没能量产,试飞过程中与 F-104战斗机的相撞世故也使现今世上仅存一架放在空军博物馆做展示机。B-52 轰炸机也不得不服役至今,并将继续服役到2030年。

虽然 XB-70 项目下马了,但其超越时代的技术对后来的航空业产生了很大影响:其部分技术应用在了后来开发并服役的“协和号”超音速客机上,苏联窃取其技术制造了“图144”超音速客机。

刚发现苏联自己也曾尝试制造类似外形的苏霍伊 T-4 验证机:

T-4

冷战时期激烈的竞争确实很大程度上激发了双方的技术创新。苏联解体20余年,俄罗斯陆海军基本上在吃老本,空军的 T-50 五代歼击机仍在试飞中,不会比中国超前多少。西方世界,也仅仅有美国的 F22 “猛禽” 和 X-47B 无人机能称得上是亮点,B2 轰炸机应该仍属于冷战的产物。可见相比于冷战时期,近20年由于没了激烈的竞争,东西方都没有看到太多的技术革新,而科学技术一般都是由军用转民用。人类维持了世界和平,却也丧失了很多技术创新的动力。

没有竞争,你永远不知道人类智慧的上限。

继上次发现 Chrome 核的 text-decorationbug 后最近又发现了 Chrome 39 的开发者工具(DevTools)的一些故障,表现为不能显示某些 DOM 元素的样式,甚至 console 也会出现没有任何输出的情况,而这确和 URL 参数中含有特殊编码的值有关。虽然不知道故障的原因,但可以在 Linux/Mac 版的Chrome 39/Opera 26 上都100%重现,只是 Chrome 的 Dev/Canary Channel 都已经“意外修复”了该问题,所以也没有个结论,具体描述在这里。我觉得这样明显的问题出现在 stable 分支上,chromium 应该给个说法才是。

nodejs 的 0.11.x 分支也出现了诡异的问题url 模块的 parse 方法在第二个参数传入 true 时返回的对象中应始终存在一个非 nullquery 对象,但 0.11.x 版本却返回 null,导致了许多 crash。这会影响到一些 CI 系统在 0.11.x 版本下的构建(0.12还没有任何发布版)。

IE8以下 form 表单的 submit 事件、checkbox/radio 的 change 都不会冒泡到 document 中,jQuery 对它们进行了修复,使得在这些 DOM 元素的父节点上 delegate 这些事件得以实现。

submit

模拟 submit 事件冒泡的一个前提是表单由点击提交按钮或在输入框中敲击回车触发,这两个事件都是可以冒泡的,因此可以在监听到有表单输入元素(input、button)的clickkeypress时向包含这些元素的 form 表单元素注册一个 submit 事件,而 submit 事件一定是在 click 事件处理过后再触发的,因此不必担心错过时机。

change

radio、checkbox的 change 事件除了不能不能冒泡外,其在自身也有问题:失去焦点后才会触发,而不是选中状态变化后立即触发。所以这里的 fix 要分为两步。

IE 中存在 propertychange 这样一个事件,可以监听所有属性的变化,那么就以此代替 change 事件,只要处理event.propertyName === ‘checked’ 即可。这样,选中状态变化后不能立即触发 change 的问题得到了解决。

radio、checkbox的选中状态在变化前,在IE中会触发一个叫 beforeactivate 的事件,那么跟 submit 一样的原理,以此来解决 change 事件不能冒泡的问题。

focusin focusout mouseenter mouseleave

这4个事件是 jQuery 模拟的,支持冒泡。

顺便提一下当调用 jQuery.on 时发生了什么,jQuery 首先要判断应不应该在指定DOM 元素上绑定,一般都应该直接绑,不过像上面提到的 submitchange就不能直接绑,可能需要在子孙元素上绑定,也可能绑定其它替代事件。而像 focusinfocusout 这样模拟的事件就需要编程去实现冒泡了。

当调用 jQuery.trigger 时,jQuery 内部会尝试在 DOM 元素上调用与事件同名的方法,而不是用事件 API 去构造一个 event 对象。

参考

经常在 github 上看到很多 repo 的 readme 都会展示类似Bagde Demo这样的东西。它们的学名叫徽标(Badge),大多是使用 markdown 的图片语法嵌入的 svg,可以自动显示当前 repo 的各种状态。下面介绍几种提供徽标的服务。

NPM version

显示该repo发布在 NPM 上的版本,链接 http://img.shields.io/npm/v/{repo}.svg,如 NPM Version

NPM Download

显示在 NPM 上的阶段下载数,链接 http://img.shields.io/npm/dm/{repo}.svg,如 NPM Download

gratipay

需要登录,用于发起捐助。链接 http://img.shields.io/gittip/{user}.svg,如 Git tip

travis

需要登录并指定 repo ,用于自动显示构建状态。链接 http://img.shields.io/travis/{user}/{repo}.svg,如 Travis

coveralls

需要登录并指定 repo ,配合测试框架显示覆盖度。链接 http://img.shields.io/coveralls/{user}/{repo}/master.svg,如 Coveralls

appveyor

需要登录并指定 repo ,用于在 Windows 环境进行构建。链接 https://ci.appveyor.com/api/projects/status/{repo-id}?svg=true,如 Appveyor

codeship

类似于 travis ,同样用于自动构建,点此登录,如Build Status


其实这些服务大多都使用了同一种徽标生成服务:http://shields.io/。可以随意创建自己的徽标:yanni4night.com

http://yanni4night.github.io/badge.html 可快速生成所需徽标。

基于less 2.0 与 sass 3.5.7的官方文档对两者的功能和语法进行一些简单的比较.

Variable

两者都支持向_选择器名_、_属性名_、_属性值_和_字符串_中注入变量,并都支持数值变量的计算:

//sass
$left: left;
$variable: variable;
$num3px: 3px;
$num5: 5;

.#{$variable}{
    margin-#{$left}: $num3px + $num5;
    float: $left;
    content: "#{$variable}";
}
//less
@left:left;
@variable:variable;
@num3px: 3px;
@num5: 5;

.@{variable}{
    margin-@{left}: @num3px + @num5;
    float: @left;
    content: "@{variable}";
}

但只有sass支持字符串的连接:

$hel:"hel";
$lo:"lo";
$hello: $hel + $lp;

在sass中,变量更复杂的类型的,同时提供了如 !default!global 标记。

@import

两者的 @import 指令都默认引入同类型的.less/.scss 文件,同时也支持嵌套:

.mark{
    @import "item";
}

都输出:

.mark .item{}

如果要被引入的是一个 css 文件,sass 不执行任何操作,less 可以根据指令执行多种操作,例如,可以将 css 当做 less 处理:

@import (less) "common.css";

或者直接引入不执行任何处理操作:

@import (inline) "common.css";
@media

两者都支持媒体查询选择器提升:

.wrap{
    @media screen{
        .item{
            color: red;
        }
    }
}

输出:

@media screen {
    .wrap .item {
        color: red;
    }
}
Extend

两者都支持extend:

//less
.wrap{
    &:extend(.on);
}
.on{font-size:10px;}

//sass
.wrap{
    @extend .on;
}
.on{font-size:10px;}

输出:

.wrap .on{font-size:10px;}

sass 实现了 !optional 标记用以屏蔽错误。

Mixins

两者都支持mixin:

//less
.fork(){font-size:20px;}
.banner{
    .fork;
}

//sass
@mixin fork(){font-size:20px;}
.banner{
    @include fork;
}

对于 sass,必须使用 @mixin 指令定义一个 mixin,个人感觉 less 更方便一些,直接写入选择器名,也不需要 @include 指令,特别是 mixin 本身去掉圆括号之后也可以作为一个合法的css选择器。

判断

都支持判断:

//less
@tick:1;
& when(@tick<5){
    .tick{
        & when(@tick<5){
            color:red;
        }
        font-size: 10px;
    }
}

//sass
$tick:1;
@if $tick < 5{
    .tick {
        @if $tick < 5{
            color:red;
        }
        font-size: 10px;
    }
}
循环

less 仰赖判断实现循环:

//less
.loop(@counter) when (@counter > 0) {
    .loop((@counter - 1));
    .item-@{counter}{
        left: (10px * @counter);
    }
}

.loop(5);

sass 实现了 @for 指令:

//sass
@for $counter from 1 through 5{
    .item-#{$counter}{
        left: #{$counter * 10px};
    }
}

除此之外,sass 还实现了功能强大的 @each@while 指令,这是 less 做不到的。

总结

less 与 sass 在常规功能上不相上下,less 可能稍稍略逊一点,不过书写上要相对简洁。一些 sass 的实现比如 @at-root 个人认为用处不大,使用反倒增加了阅读代码的难度。从环境部署上看,sass 需要 ruby 环境,而 less 基于 js,相对更容易在多种环境中使用。

CSS 预处理器的使用要以简化书写 CSS 和清晰展示选择符层次为重,从这点上来讲,并不需要太复杂的功能,我比较倾向于使用 less。

常见到一些代码或笔试题会出现针对旧浏览器(主要是IE6/7/8)的 getElementsByClassName 方法的 polyfill,我在面试一些初学者时也常常问起,不过回答差不多者寥寥。其实想完整的实现与原生相同的功能基本不可能,原因之一即是不管该方法返回的是 HTMLCollection 还是 NodeList,它们都必须是 alive 的,意即针对 DOM 树的任何改动都会实时反应到其中。因此,非瞬时地缓存集合的长度是危险的。同时由于不能构造一个 HTMLCollectionNodeList ,我们一般会以数组代之,因此集合是不可变的。

所有 getElements* 方法返回的集合都是 live 的,只有 querySelector 返回的 static 的。测试参见这里;

引用

CSS3 对 text-decoration 进行了扩展,新的语法为:

text-decoration: text-decoration-style text-decoration-color text-decoration-line;

目前只有 blink 内核对其进行了支持,但很不完善,或者说是一个bug。描述为:无法设置新的格式,但是却可以获取。例如:

<p id="p" style="text-decoration:underline"></p>
<script>
    var $p = document.querySelector('#p');
    console.log($p.style.textDecoration);//underline solid rgba(0,0,0)
    $p.style.textDecoration = "overline solid dashed #fff";
    console.log($p.style.textDecoration);//underline solid rgba(0,0,0)
</script>

该问题从Chrome 31开始出现,我提了 bug 给 chromium ,在后来的Chrome 37 中修复了一部分,不再返回 text-decoration-colortext-decoration-line,同时仍然无法设置。

这个 bug ,jQuery 拒绝修复,理由是 1.x 与 2.x 都仅保证支持 Chrome 的最近两个版本,同时这也不是个严重的问题,当前,Chrome 39 已经发布了。

昨天 GitHub 上捷克共和国一哥们提出几个 issues,讲我的某个石器时代土著插件不支持 Sublime Text Command 并且 Context Menu 缺失。其实这两个功能入口仅需要编辑两个配置文件就可以了,但前提是命令数量是有限的,这样才可以直接写死配置文件。

只是这个插件提供的主要功能即是无限扩展命令完成各种插入操作,默认提供了4种常见插入,此外可以无限配置插入种类,如果全部都要配置快捷键,确实不合理。

Sublime 插件配置文件分为几种:

  • sublime-menu,右键菜单和主菜单
  • sublime-commands,文本命令
  • sublime-keymap,快捷键定义
  • sublime-settings,插件主要配置文件

前三种格式全为数组,最后一个为对象,也只有最后一个 Sublime 单独提供了 API 供读写:

sublime.load_settings()
sublime.save_settings()

一般地,我们只需要读取就行了。

Text CommandContext Menu 需要修改 menucommands 配置文件,因为它们是数组格式,不能通过上面的 API 读写,所以不得不使用 python 的原生API进行写入操作。在每次插件加载时,动态更新这两个文件,编辑器本身也能立即得到通知。

settings 配置文件被修改时理应重新进行一次上面的操作,但是 Sublime API 的 Settings.add_on_change 似乎不怎么起作用,因此不得不强制要求编辑器重启来刷新设置。

引用
0%