Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X

收集slidershare高质量的ppt

http://www.slideshare.net/rainoxu/javascript-5464018  javascript性能优化

http://www.slideshare.net/fool2fish/js-12953769 js高级技巧 demo在http://fool2fish.aliapp.com/js-senior-skill/index.html

http://www.slideshare.net/iddcn/ss-12153414 高粒度模块化前端开发

http://www.slideshare.net/kejun/ss-9015786 前端开发理论热点面对面

http://www.slideshare.net/firt/mobile-web-high-performance 高性能移动端开发(E文)

http://www.slideshare.net/nzakas/writing-efficient-javascript 高效率书写javascript

 教主的ES5演讲

http://v.youku.com/v_playlist/f15769239o1p4.html

http://v.youku.com/v_playlist/f15769239o1p5.html

http://v.youku.com/v_playlist/f15769239o1p6.html

 

 Real-Time Web实时信息流推送

http://www.docin.com/p-467150624.html

阿里巴巴adc  http://adc.alibabatech.org/  内有大量ppt

 

2012 年 6 月 11 日 5 条评论 Short URL

git如何处理别人的pull request及解决冲突

出过两次了，每次都查很多资料，太蛋疼，记录在此。

 

当你的项目比较牛逼的时候，有人给你贡献代码，但他修改的地方恰恰你前阵子也修改了，这样在github中就不能够自动merge了。

因此你需要手动去解决冲突。首先要在本机安装好命令行工具gitbash，之后用clone拉下你的项目，之后

按照以下命令输入

这时候命令行会提示你有冲突，冲突文件是啥，那如何解决冲突呢，很简单

在同步代码的过程中，git会自动检查冲突，并尝试进行**自动合并**。最好的情况应该是大家同时修改一个文件，但是大家修改的地方不同了。在这样的情况下，git会进行非冲突合并，这时，在调用 git pull 的时候，git会尝试进行非冲突合并。
而在合并过程中有冲突的时候， git 会把修改记录直接保存在文件中，让开发者判断文件如何解决合并。例如，在一个描述文件中同时修改了一句话，在合并的时候，git会这么做：

即把两个更改都写在文件上，但是用=======来区别发生冲突的位置，在=======以上是 HEAD，即本地的代码；而=======以下则是来自远程的更改了。这个时候，你可以选择保留远程或本地的修改或者都不要（简单地说，把不需要的内容删除即可）。

 

也就是说我们把文件修改好后，把增加的那几行head >>><<<之类删掉就ok啦。之后冲突修改完毕，我们继续输入

 

还要记着一点，本地修改代码前一定要先pull一下看看，记得慎用github的在线编辑功能

 

2014 年 3 月 6 日 没有评论 Short URL

node-sass的介绍及使用(官方文档)

其实我很少写第三方库的介绍的，主要是node-sass确实蛮好用，而且我对ruby缺乏好感。。

 

 

node-sass

Build Status NPM version Dependency Status devDependency Status Coverage Status

Node-sass is a library that provides binding for Node.js to libsass, the C version of the popular stylesheet preprocessor, Sass.

It allows you to natively compile .scss files to css at incredible speed and automatically via a connect middleware.

node-sass提供了一个nodejs到libsass的桥梁.libsass是广受欢迎的css预处理器sass的c版本.

这个东东提供了难以想象的效率来本地编译sass到css文件，甚至可以通过中间件的方式自动编译。

Find it on npm: https://npmjs.org/package/node-sass

Install 安装

Usage 使用

Options 选项（这里仔细看）

The API for using node-sass has changed, so that now there is only one variable – an options hash. Some of these options are optional, and in some circumstances some are mandatory.

node-sass的api已经变化，只需要一个参数-options对象。有些选项是可选的，有些选项在某种环境下是必须的。

file

file is a String of the path to an scss file for libsass to render. One of this or data options are required, for both render and renderSync.

file表示libsass需要编译的文件，以字符串表示。这个选项或者data选项必须在render或者renderSync中指定

data

data is a String containing the scss to be rendered by libsass. One of this or file options are required, for both render and renderSync. It is recommended that you use the includePaths option in conjunction with this, as otherwise libsass may have trouble finding files imported via the @import directive.

data表示scss字符串.这个选项或file选项必须在在render或者renderSync中指定.我们建议你使用includePaths选项来为@import(sass中的import命令)指定来源,不然有些时候libsass在寻找@import引入的文件时会出错

success

success is a Function to be called upon successful rendering of the scss to css. This option is required but only for the render function. If provided to renderSync it will be ignored.

当scss被编译为css后,success指定的函数被调用.这个选项在render函数中是必须的,但renderSync会忽略

error

error is a Function to be called upon occurance of an error when rendering the scss to css. This option is optional, and only applies to the render function. If provided to renderSync it will be ignored.

当scss被编译为css的过程中出错,error指定的函数被调用.这个选项在render函数中是可选的,但renderSync会忽略

includePaths

includePaths is an Array of path Strings to look for any @imported files. It is recommended that you use this option if you are using the data option and have any @import directives, as otherwise libsass may not find your depended-on files.

includePaths是一个由字符串组成的数组,表示路径,来表明任何@imported所引入的文件在哪。如果你使用了data选项,且包含@import,建议你使用这个选项,否则libsass可能找不到依赖文件。

imagePath

imagePath is a String that represents the public image path. When using the image-url() function in a stylesheet, this path will be prepended to the path you supply. eg. Given an imagePath of /path/to/images, background-image: image-url('image.png') will compile to background-image: url("/path/to/images/image.png")

imagePath 表示图片路径. 当在样式表中使用 image-url() 函数时, 这个函数将会载入你用imagePath指定的图片路径比如说你设置了imagePath为/path/to/images，样式表中写的是background-image: image-url(‘image.png’)，将会被编译为 background-image: url("/path/to/images/image.png")

outputStyle

outputStyle is a String to determine how the final CSS should be rendered. Its value should be one of 'nested', 'expanded', 'compact', 'compressed'. [Important: currently the argument outputStyle has some problem which may cause the output css becomes nothing because of the libsass, so you should not use it now!]

outputStyle是一个字符串，表示最终的CSS是什么样的。它的值应该是下列值其中一个：“nested”,“expanded”,“compact”,“compressed”。(重要:目前outputStyle有一些问题,libsass的缘故可能会导致不输出css,所以建议现在不应该使用!)

 

sourceComments

sourceComments is a String to determine what debug information is included in the output file. Its value should be one of 'none', 'normal', 'map'. The default is 'none'. The map option will create the source map file in your CSS destination. [Important: souceComments is only supported when using the file option, and does nothing when using data flag.]

sourceMap

If your sourceComments option is set to map, sourceMap allows setting a new path context for the referenced Sass files. The source map describes a path from your CSS file location, into the the folder where the Sass files are located. In most occasions this will work out-of-the-box but, in some cases, you may need to set a different output.

Examples

Edge-case behaviours

  • In the case that both file and data options are set, node-sass will only attempt to honour the filedirective.
  • 当file跟data选项都设置了，node-sass只会以file选项为准

Connect/Express middleware

connect跟express的中间件

Recompile .scss files automatically for connect and express based http servers

下面的例子可以让node-sass变为express/connect的中间件，来自动编译scss文件

Heavily inspired by https://github.com/LearnBoost/stylus

DocPad Plugin docpad的插件

@jking90 wrote a DocPad plugin that compiles .scss files using node-sass:https://github.com/jking90/docpad-plugin-nodesass

Grunt extension  grunt的插件(grunt的sass插件就是基于这货)

@sindresorhus has created a set of grunt tasks based on node-sass: https://github.com/sindresorhus/grunt-sass

Gulp extension gulp的插件

@dlmanning has created a gulp sass plugin based on node-sass: https://github.com/dlmanning/gulp-sass

Harp

@sintaxi’s Harp web server implicitly compiles .scss files using node-sass: https://github.com/sintaxi/harp

Meteor plugin

@fourseven has created a meteor plugin based on node-sass: https://github.com/fourseven/meteor-scss

Mimosa module

@dbashford has created a Mimosa module for sass which includes node-sass:https://github.com/dbashford/mimosa-sass

Example App

There is also an example connect app here: https://github.com/andrew/node-sass-example

Rebuilding binaries

Node-sass includes pre-compiled binaries for popular platforms, to add a binary for your platform follow these steps:

Check out the project:

Replace the prebuild binary with your newly generated one

Command Line Interface

The interface for command-line usage is fairly simplistic at this stage, as seen in the following usage section.

Output will be saved with the same name as input SASS file into the current working directory if it’s omitted.

使用命令行接口是相当简单的,见以下使用部分。
若不指定输出文件，输出文件名将与输入的SASS文件名相同，且保存到当前工作目录。

 

Usage

node-sass [options] <input.scss> [<output.css>]

Options:

Post-install Build

Install runs a series of Mocha tests to see if your machine can use the pre-built libsass which will save some time during install. If any tests fail it will build from source.

If you know the pre-built version will work and do not want to wait for the tests to run you can skip the tests by setting the environment variable SKIP_NODE_SASS_TESTS to true.

Contributors

Special thanks to the following people for submitting patches:

Dean Mao Brett Wilkins litek gonghao Dylan Greene

Note on Patches/Pull Requests

  • Fork the project.
  • Make your feature addition or bug fix.
  • Add documentation if necessary.
  • Add tests for it. This is important so I don’t break it in a future version unintentionally.
  • Send a pull request. Bonus points for topic branches.

Copyright

Copyright (c) 2013 Andrew Nesbitt. See LICENSE for details.

2014 年 3 月 4 日 没有评论 Short URL

转发 viewport双城记

    • about：
      • 原文：http://www.quirksmode.org/mobile/viewports.html
      • 作者简介：
        • Peter-Paul Koch — mobile platform strategist, consultant, and trainer
        • 详细描述
      • 搬运人员：
        • 翻译：承风
        • 较稿：鬼道
      • 名词说明：
        • 本文所有的缩小、放大、缩放都指zoom操作。而非改变浏览器窗口的大小。
  • viewport 双城记（part1）
    • 在这个迷你系列的文章里，我将解释viewports和多种重要的HTML标签元素的宽度是如何工作的，例如<html>标签。同样也会解释window和screen的宽度问题。
    • 第一部分主要关于桌面（pc）浏览器，基本目的在于为移动端（mobile）浏览器上，本话题的讨论创建舞台。绝大多数web开发人员已经对pc的概念有了直观的认识。mobile拥有相同的概念，但是更加复杂。如你所知，一个友好的预热将极大的帮助你理解mobile浏览器。
    • 概念：设备的pixels和CSS的pixels
      • 首先你应当理解CSS的pixels，以及它和设备的pixels的区别
      • 我们姑且认定设备的pixels为正确（标准）的pixels宽度。这些pixels决定了你工作所用的那些设备上正式的分辨率。在大多数情况下，能够从screen.width/height上取出具体值。
      • 如果你为某个HTML元素赋值width:128px,你的显示器是1024px宽且你最大化了浏览器窗口。忽略后续所言的麻烦的部分，粗略的计算下，该显示器上能横排容纳（1024/128 = 8）个这种元素。
      • 如果用户缩放（zoom）了浏览器，当然必须改变计算方式。例如用户缩放了200%，上诉显示器只能横排容纳4个上诉元素了。
      • 现代浏览器上的缩放，是基于“伸展”pixels。结果是，html元素上的宽度并没有因为缩放200%而由128pix变成256px，而是真实的pixels的被计算成了双倍。html元素在形式上依然是128CSS的pixels，即便它占用了256设备的pixels
      • 换言之，缩放200%将一个单位的CSS的pixels变成了4倍的设备的pixels那么大，即宽度 * 2、高度 * 2，面积扩大了2 * 2.
      • 下列图片将清楚的解释这个概念。如图1-1.有4个1像素，缩放为100%的html元素，CSS的pixels完整的和设备的pixels重叠
      • image 图1-1
      • 当我们缩小浏览器时，CSS的pixels开始收缩，导致1单位的设备的pixels上重叠了多个CSS的pixels，如图1-2
      • image 图1-2
      • 同理，放大浏览器时，相反的事情发生了，CSS的pixels开始扩大，导致1单位的CSS的pixels上重叠了多个设备的pixels，如图1-3
      • image 图1-3
      • 总体而言，你只需要关注CSS的pixels，这些pixels指定你的样式被如何渲染
      • 设备的pixels几乎对你毫无用处。但对用户而言却不是这样。用户会缩放页面，直到他能舒服的阅读内容。但是你不需关心这些缩放级别。浏览器会自动的保证你的CSS的pixels会被伸展还是收缩。
      • 100% 缩放
      • 本例设定缩放级别为100%。现在我们更严谨的定义，如下：

      在缩放级别为100%时，1单位的CSS的pixel是严格相等于1单位的设备pixel

      • 100%缩放的概念非常有利于表述接下来的内容，但你不必在日常工作中过度担忧这个问题。在桌面系统上，你通常会在100%缩放级别下测试你的网站，但即便用户缩放，CSS的pixels的魔法依然能保证你网站外观保存相同的比例
      • 屏幕尺寸 Screen size

      screen.width/height

      • 含义：用户的屏幕的完整大小
      • 度量：设备的pixels
      • 兼容性问题：IE8里，不管使用IE7模式还是IE8模式，都以CSS的pixels来度量
        • 我们先了解一些特殊的尺寸：screen.width 和 screen.height。这两个属性包含了用户屏幕的完整宽度高度。这些尺寸使用设备的pixels来定义，他们的值不会因为缩放而改变：他们是显示器的特征，而不是浏览器。如图1-4所示。
        • image 图1-4
        • 很有趣吧？但是我们拿来何用呢？
        • 简单的说，木有用！用户的显示器宽度对我们而言不重要 – 除非你想要用他们做网络统计数据
        • 浏览器尺寸 Window size

        window.innerWidth/Height

      • 含义：包含滚动条尺寸的浏览器完整尺寸
      • 度量：CSS的pixels
      • 兼容性问题：IE不支持，Opera用设备pixels来度量
        • 相反的，你想要知道的浏览器的内部尺寸。它定义了当前用户有多大区域，可供你的CSS布局占用。你可以通过window.innerWidth 和 window.innerHeight来获取。如图1-5
        • image 图1-5
        • 显然，窗口的内部宽度使用CSS的pixels.你需要知道多少你自己定义的元素能塞入浏览器窗口，而这些数量会随着用户放大浏览器而减少（如图1-6）。所以当用户放大显示时，你能获取的浏览器窗口可用空间会减少，window.innerWidth/Height就是缩小的比例

      Opera浏览器在这个问题上是一朵奇葩，当用户放大浏览器显示时不少。
      所以当用户放大显示时，你能获取的浏览器窗口可用空间会减少。
      window.innerWidth/Height 却并不会减小。
      在桌面浏览器上，这个特性很烦人，但在移动设备浏览器上简直是致命的，后面我们会讨论

      • image 图1-6
      • 注意，窗口内部宽度和高度的尺寸，包含了滚动条的尺寸。（这主要是来至于历史原因）
      • 滚动移位 Scrolling offset

      window.pageX/YOffset

      • 含义：页面的移位
      • 度量：CSS的pixels
      • 兼容性问题：pageXOffset 和 pageYOffset 在 IE 8 及之前版本的IE不支持, 使用”document.body.scrollLeft” and “document.body.scrollTop” 来取代
        • window.pageXOffset 和 window.pageYOffset，定义了页面(document)的相对于窗口原点的水平、垂直位移。因此你能够定位用户滚动了多少的滚动条距离。如图1-7
        • image 图1-7
        • 该属性也以CSS的pixels来度量.同上面的问题，你想要知道在用户放大窗口的情况下，用户向上滚动了多少的滚动条。
        • 原理上来说，在用户放大浏览器时，向上滚动了页面，window.pageX/YOffset会改变。但当用户放大页面时，浏览器会尝试着保存用户当前可见的页面的元素依然在可见位置。虽然该特性表现得不如预期，但它意味着：在理论上 该情况下 window.pageX/YOffset并没有改变，被用户滚出屏幕的CSS的pixels几乎保存不变。如图1-8。
        • image 图1-8
    • 概念：视窗 viewport
      • 在我们继续讨论更多的JavaScript的特性properties之前，先介绍另外一个概念：viewport
      • viewport的功能在于控制你网站的最高块状（block）容器：<html>元素.
      • 听起来有点玄乎，举个例子~假设你定义了一个可变尺寸的布局（liquid layout），且你定义一个侧边栏的宽度为width: 10%。当你改变浏览器窗口大小时，该侧边栏会自动扩张和收缩。这是什么原理呢？
      • 技术上讲，原理是侧边栏的宽度为它父元素宽度的10%，我们设它的父元素是<body>且你未指定宽度。那么问题就变为了<body>的宽度到底是多少？
      • 通常，一个块级元素占有起父元素的100%的宽度（这里有异常情况，暂时忽略）。所以<body>的宽度就是其父元素<html>的宽度。
      • 那么<html>元素到底有多宽？因为它的宽度恰好为浏览器的宽度。所以你的侧边栏宽度width: 10%会占用10%的浏览器宽度。所以的web开发人员都直观的知道和使用该特性了。
      • 但是你也许不知道原理。在原理上，<html>的宽度受viewport所限制，<html>元素为viewport宽度的100%。
      • 反过来，viewport是严格的等于浏览器的窗口：定义就是如此。viewport不是一个HTML的概念，所以你不能通过CSS修改它。它就是为浏览器窗口的宽度高度 – 在桌面浏览器上如此，移动设备浏览器上有点复杂。
      • 影响 Consequences
      • 缩放事件有一些奇怪的影响，你可以在本站上实验（http://www.quirksmode.org/mobile/viewports.html）。页面滚动到最上面，放大浏览器2-3倍，网站的宽度会超过浏览器窗口。再将页面滚动到最右边，你会发现网站最上面的蓝色栏目不再对齐了。如图2-1
      • image 图2-1（作者还在玩IE6!）
      • 这个效果反应了viewport是如何被定义的。我定义了最上面蓝色栏目的宽度为width: 100%。什么的100%？当然是<html>的宽度，同样是viewport的宽度，同样是浏览器窗口的宽度。
      • 重点：缩放比例100%的情况下很正常，现在我们放大浏览器，viewport变得比网站的总宽度更小。对viewport无影响，但页面的内容溢出了<html>元素，但它却有属性overflow: visible。意味着溢出的部分依然会被显示。
      • 但蓝色栏目却不会溢出。我定义了它宽度为width: 100%，结果浏览器为他赋值宽度为viewport的宽度。浏览器不会在乎这个栏目的宽度是不是过窄了。如图2-2
      • image 图2-2
      • 页面宽度 document width ?
      • 我真正想要知道的是页面内容的总大小，包括超出浏览器窗口的部分。到目前为止，据我所知并没有办法找到这个值（当然，除非你计算页面所有部分的宽度包括所有元素的margin，但是这种计算很容易出错）
      • 我开始相信我们需要一个JavaScript特性对(property pair)来标示我所谓的页面宽度 document width(当然，以CSS的pixels来度量)。如图2-3
      • image 图2-3
      • 如果我们真的感觉对这事儿很烦躁：为什么不在CSS中揭露这些值？我期望定义width: 100%来控制页面蓝色栏目的宽度，它基于页面的宽度而不是<html>元素的宽度。这似乎很棘手(This is bound to be tricky）,如果这成功的被实现我也不会感倒惊讶
      • 度量viewport Measuring the view port

        document. documentElement. clientWidth/Height

        • 含义：viewport的尺寸
        • 度量：CSS的pixels
        • 兼容性问题：无
      • 你也许想要知道viewport的尺寸，他们可以通过document. documentElement. clientWidth/Height来获取。如图2-4
      • image 图2-4
      • 如果你熟悉DOM，你会知道document.documentElement实际上就是<html>元素：HTML文档的根元素。然而viewport是比<html>更高级别的元素，打个比喻，它是容纳<html>元素的元素。那会和你是否给<html>元素赋值width相关（我不建议这么做，但是却是可行的）
      • 在那种情况下document. documentElement. clientWidth/Height依然给出了viewport的尺寸，而不是<html>元素。（这是特殊的规则只针对这个特殊的元素针对这个特性对。在其余任何情况下元素使用实际的宽度）如图2-5。为<html>元素赋值25%。但document. documentElement. clientWidth/Height的值不变。它虽然貌似从<html>元素取值，但实际描述的确是viewport的尺寸。
      • image 图2-5
      • 所以document. documentElement. clientWidth/Height只会给出viewport的尺寸，而不管<html>元素尺寸如何改变
      • 两个特性对 two property pairs
      • 但是viewport的尺寸不是也通过window.innerWidth/Height来描述的么？嗯，是，也不是。
      • 这两个特性对有严格的区别，几乎算是吹毛求疵了
        • window.innerWidth/Height包含滚动条
        • document. documentElement. clientWidth/Height不包含
      • 我们能获取这两个特性对是因为他们是浏览器大战的残留。过去Netscape只支持window.innerWidth/Height，IE 只支持document. documentElement. clientWidth/Height。从那时候开始所有其余浏览器都支持这两个特性。但IE一直未支持window.innerWidth/Height
      • 在桌面系统中，拥有这两个特性对只是一点小麻烦，但在移动设备中却变成了一种祝福。后面我们会看到
      • 度量<html>元素 measuring the <html> element

        document. documentElement. offsetWidth/Height

        • 含义：<html>的尺寸
        • 度量：CSS的pixels
        • 兼容性问题：IE用这个值标示viewport的尺寸而非<html>
      • 如果clientWidth/Height一直用以标示viewport的尺寸，我们该如何去获取<html>元素的尺寸呢？— document.documentElement.offsetWidth/Height。如图2-6
      • image 图2-6
      • 这个特性对真实的让你访问块级元素<html>元素，如果你为<html>元素赋值了宽度，offsetWidth会真实的反应出来。如图2-7
      • image 图2-7
      • 事件坐标 Event coordinates

        pageX/Y, clientX/Y, screenX/Y

        • 含义：见下文
        • 度量：见下文
        • 兼容性问题：IE不支持pageX/Y,IE使用CSSpixels来度量screanX/Y
      • 详细描述
        • pageX/Y：从<html>原点到事件触发点的CSS的 pixels
        • clientX/Y：从viewport原点（浏览器窗口）到事件触发点的CSS的 pixels
        • screenX/Y：从用户显示器窗口原点到事件触发点的设备 的 pixels。
      • 如图2-8、2-9和2-10
      • image 图2-8
      • image 图2-9
      • image 图2-10
      • 9成可能你会用到pageX/Y而1成左右会使用clientX/Y,screenX/Y基本没啥用
      • Media查询 media queries

        mediaqueries

        • 含义：见下文
        • 度量：见下文
        • 兼容性问题：IE不支持.
      • 最后一点文字关于@media的css属性。出发点很简单：你可以根据页面的特定宽度来定义特殊的CSS规则。举个例子。

        div.sidebar {

        width: 300px;

        }

        @media all and (max-width: 400px) {

        // styles assigned when width is smaller than 400px;

        div.sidebar {

        width: 300px;
        }

        }

      • 如果宽度大于400px，那么sidebar宽度为300px。反之，sidebar宽度为100px
      • 有两个相关的media查询：width/height 和 device-width/device-height。如图2-11
        • device-width/height使用screen.width/height来做为的判定值。该值以设备的pixels来度量
        • width/height使用documentElement.clientWidth/Height即viewport的值。该值以CSS的pixels来度量
      • image 图2-11
      • 到底该使用那个呢？一个很无脑的结果：width。web开发中不需要对设备的宽度感兴趣，而width却使按照浏览器窗口的大小计算的
      • 所以在桌面浏览器中使用width而忘记device-width。接下来我们会看到在移动设备中有点凌乱
    • 总结
      • 在此结束对桌面浏览器的特性的简短讨论，第二部分主要涉及移动设备和其与桌面浏览器的重要区别
  • viewport 双城记（part2）
    • 在这个迷你系列的文章里，我将解释viewports和多种重要的HTML标签元素的宽度是如何工作的，例如<html>标签。同样也会解释window和screen的宽度问题。
    • 本页我们将讨论移动设备的浏览器。如果你是移动开发的纯菜，建议先阅读第一部分：关于pc浏览器，以建立基本的概念
    • 移动设备浏览器的问题
    • 设备的宽度是移动设备浏览器和桌面浏览器的最大区别。移动设备的显示通常比桌面浏览器显示同一网站的内容要少。或者缩放浏览器变小导致文字无法阅读，或者只显示网站适合设备大小的部分内容。
    • 移动设备的屏幕宽度比桌面浏览器小，经常最大就400px宽，而且通常会更小。（有些手机号称大宽度，但他们确是在说谎 – 或起嘛给了我们一些无用的信息）
    • 一些中间宽度的pad设备(table device)如iPad或传说中HP的webOS设备填补了桌面和移动设备的缺口，但却没有解决根本的问题。网站还是必须在移动设备上工作，我们不得不让她们在小屏幕上显示得表现良好。
    • 问题的风暴中心在于CSS，特别是viewport的尺寸。如果我们只是拷贝桌面的样式到移动设备，我们的CSS会丑得崩溃
    • （假设移动设备的宽度400px）我们回到width: 10%的侧边栏。如果在移动设备上同理处理，会显示出40px宽，实在太窄了。你的可变布局看起来被可怕的压扁了。
    • 其中一个解决方式是为移动设备重新建设一个特殊的网站。即使跳开这些基本的问题：你到底该怎么处理，现实的问题是只有很少的站长准备好了加入迎合移动设备而做的改变。
    • 移动设备浏览器供应商期望他们的客户端提供最好的可能性体验，即现在意味着“尽可能的像桌面浏览器”。因此许多处理手段是必须的。
    • 两种viewport
    • 因此viewport太窄，不能很好为你的基本CSS布局服务了。最显然的解决方式是让viewport更宽。因此这个需求分为了2个方面：虚拟的viewportvisualviewport和布局的viewportlayoutviewport。
    • George Cummins在Stack Overflow上解释了这个基本概念，猛击

    想象下layoutviewport是一张大的不能改变大小和角度的图片。现在你有个更小的框来观看这张大图片，这个框被不透明的材料包围，因而你只能看到大图片的一部分。你通过这个框子看到的大图片的部分被称为虚拟viewport(visual viewport)。你能拿着这个框站得离大图片远点（用户的缩小页面功能），以一次性看到这个大图片。或者你能站得近点（用户的放大页面功能）以看到一部分。你能改变这个框子的方向，但这张大图片的大小和形状都不会改变。

    • 你可以参见解释详情by Chris
    • visualviewport是当前显示在屏幕上的部分页面。用户会滚动页面来改变可见部分，或者缩放浏览器来改变visualviewport的尺寸。见图1-1.
    • image 图1-1
    • 但是CSS 布局，特别是感性的宽度（percentual widths）通常是按照layoutviewport来定义，而比visualviewport宽很多
    • 然而<html>元素的宽度继承于layoutviewport，你的CSS应预先准备着需要处理的屏幕(layoutviewport)是不是远远超过手机屏幕宽度。这用以保证你的网站外观特性而恰如在桌面浏览器上一样
    • layoutviewport到底有多宽？每个浏览器都不同。iPhone上的Safari使用980px、Opera 850px，安卓的Webkit核心800px，IE974px。
    • 一些浏览器有特别的特性

    • 缩放 Zooming
    • 两种viewports都以CSS的 pixels来度量。当你通过缩放改变visualviewport时，layoutviewport保存不变。
    • 理解layout viewport
    • 为了理解layoutviewport的尺寸，我们先看下页面完全缩小时发生了什么。许多移动设备浏览器在初始默认打开以最小缩放模式打开网站。（即在手机屏幕上展示完整宽度的页面）。如图1-2.
    • 重点：浏览器已经选择好他们的layoutviewport的尺寸，它完整的覆盖了最小缩放模式下的移动浏览器的屏幕。
    • image 图1-2
    • 这时候layoutviewport的宽度高度和最小缩放模式下能在页面上显示的内容的宽度高度一致。即便用户缩放，它依然保存不变。如图1-3
    • image 图1-3
    • layoutviewport宽度通常保存不变。如果你旋转你的手机，visualviewport改变，但浏览器会缩放页面以自适应，以达到layoutviewport再次和visualviewport同样宽。如图1-4。
    • image 图1-4
    • 这影响到了layoutviewport的高度，它突然变得比竖着模式更小（portrait model肖像模式），但web开发者并不关心高度，只在乎宽度。如图1-5.
    • image 图1-5
    • 度量layout viewviewport

      document. documentElement. clientWidth/Height

      • 含义：layoutviewport尺寸
      • 度量：CSS的pixels
      • 完整支持：Opera, iPhone, Android, Symbian, Bolt, MicroB, Skyfire, Obigo
      • 问题：在Iris上它标示visualvieport
        • 三星的Webkit核心浏览器，仅当在页面上写入<meta viewport>标签，才正确表示。否则就代表着<html>的尺寸
        • FireFox以设备的pixels来度量
        • IE返回1024 x 768 px，而准确的尺寸保存在document.body.clientWidth/Height
        • NetFront仅当100%缩放时候才正确
        • 塞班的Webkit1(在S60v3设备)不支持这些属性
      • 不支持：黑莓
    • 很幸运浏览器由于浏览器大战而遗留给我们2个特性对来度量这两种viewport
    • document.documentElement.clientWidth/Height传递layoutviewport的尺寸，如图1-6
    • image图1-6
    • 旋转只关系到高度，而不是宽度。如图1-7

    *image图1-7

    • 度量visual viewport

      window.innerWidth/Height

      • 含义：visualviewport尺寸
      • 度量：CSS的pixels
      • 完整支持：iPhone, Symbian, BlackBerry
      • 问题：
        • FireFox和Opera以设备的pixels返回该数值
        • Android, Bolt, MicroB, 和 NetFront 以CSS的pixels返回该数值，且为layoutviewport的值
      • 不支持：
        • IE，它使用document. documentElement. offsetWidh/Height来表示
        • 三星的Webkit核心浏览器，仅当在页面上写入<meta viewport>标签，才正确表示。否则就代表着<html>的尺寸
      • 混乱：Iris, Skyfire, Obigo返回的值不知所云
    • 我们使用window.innerWidth/Height来度量visualviewport。显然，随着用户缩放浏览器，这值会改变，更多、更少的CSS pixels放进了屏幕。如图1-8
    • image图1-8
    • 很不幸这是一个待完善的部分，许多浏览器依然没有支持对visualviewport的度量。到现在为止，没有浏览器将该度量存储在其他地方，我猜测window.innerWidth/Height会成为标准，albeit是最强力的支持者
    • 屏幕 Screen

      screen.width and screen.height

      • 含义：屏幕尺寸
      • 度量：设备的pixels
      • 完整支持：Opera Mini, Android, Symbian, Iris, Firefox, MicroB, IE, BlackBerry
      • 问题：
        • Opera在Windows Mobile下只给出横向尺寸(landscape size)。在S60上工作正确
        • 三星的Webkit核心浏览器，仅当在页面上写入<meta viewport>标签，才正确表示。否则就代表着<html>的尺寸
        • iPhone和Obigo仅给出竖直尺寸(portrait sizes)
        • Android, Bolt, MicroB, 和 NetFront 以CSS的pixels返回该数值，且为layoutviewport的值
      • 不支持：
        • IE，它使用document. documentElement. offsetWidh/Height来表示
        • 三星的Webkit核心浏览器，仅当在页面上写入<meta viewport>标签，才正确表示。否则就代表着<html>的尺寸
      • 混乱：Iris, Skyfire, Obigo返回的值不知所云
    • 和pc浏览器一样，screen.width/height标示了设备屏幕的尺寸，以设备的pixels度量。和pc浏览器一样，作为web开发人员你永远不需要这些信息。你不关心屏幕的物理宽度，而关心当前有多少CSS的pixels能供你使用。如图1-8
    • image 图1-8
    • 缩放等级 Zoom level
    • 无法直接获取缩放等级，但可以使用screen.width除以window.innerWidth来计算。当然，只有这两个特性被完美支持时才能使用。
    • 幸运的是，缩放等级并不重要。你只需要知道当前有多少CSS的pixels能供你使用。你可以从window.innerWidth获取这些信息 – 如果当前浏览器支持。
    • 滚动位移 scrolling offset

      window.pageX/YOffset

      • 含义：见描述
      • 度量：CSS的pixels
      • 完整支持：iPhone, Android, Symbian, Iris, MicroB, Skyfire, Obigo
      • 问题：
        • Opera, Bolt, Firefox, and NetFront 总是返回 0.
        • 三星的Webkit核心浏览器，仅当在页面上写入<meta viewport>标签，才正确表示。
      • 不支持：

        * IE，它使用document. scrollLeft/Top来表示

    • 你同意需要知道当前visualviewport相对于layoutviewport的距离。这就是滚动位移，如同在桌面浏览器一样，使用window.pageX/YOffset存储。如图1-9
    • image 图1-9
    • <html>元素

      document. documentElement. offsetWidth / Height

      • 含义：html元素的整体尺寸
      • 度量：CSS的pixels
      • 完整支持：Opera, iPhone, Android, Symbian, Samsung, Iris, Bolt, Firefox, MicroB, Skyfire, BlackBerry, Obigo
      • 问题：
        • NetFront只在100%缩放时返回正确的值.

        * IE，使用这个特性对来表示visualviewport的尺寸。它使用document. body. clientWidth/Height来表示

        • 和在桌面系统一样,document.documentElement.offsetWidth/Height给出了<html>元素以CSS的pixels度量的尺寸。如图1-10
        • image 图1-10
        • Media查询 media queries

        Mediaqueries

      • 含义：以CSS的pixels度量<html>元素或以设备 的pixels度量设备
      • 完整支持：Opera, iPhone, Android, Symbian, Samsung, Iris, Bolt, Firefox, MicroB.
      • 不支持：Skyfire, IE, BlackBerry, NetFront, Obigo
      • 备注：

        * 我只测试了浏览器是否从正确的特性对里提取这些值。而特性对里的值是否正确并不在这里进行详细测试。

        • media查询如同桌面系统一样。width/height使用以CSS的pixels度量的layoutviewport，device-width/height使用以设备的pixels度量的设备屏幕（device screen）
        • 换句话说，width/height 反映document. documentElement. clientWidth/Height的值, device-width/height 反映screen.width/height. (所有浏览器遵循同样原理，即使取值是错误的)。如图1-11.
        • image 图1-11
        • 哪个度量对web开发人员更有用呢？我也不知道。
        • 我起初认为device-width更重要，因为它给予了设备的信息，我们也许可以使用。例如，你能根据设备的宽度改变网站的外观。但是你同样可以使用<meta viewport>标签做到这些。因此使用device-width并不是必须的。
        • 那么width就更有用了么？也许是。浏览器的制造商认为他们给出了一些对网站有用的宽度的细节。但这些内容却含糊（混乱），因而width media 查询并不真正给出其余信息。
        • 所以我没有做决定。现在我认为media查询在标识网站处于桌面浏览器、pad浏览器或手机浏览器方面很重要，而在区别不同pad和手机设备方面并不有用
        • 事件坐标 Event coordinates

        Eventcoordinates

      • 含义：见下文
      • 度量：见下文
      • 完整支持：Symbian, Iris
      • 问题：
        • Opera 只有pageX/Y，但滚动页面过远时这个值会出错。
        • 在iPhone, Firefox, 和 BlackBerry 上clientX/Y 和pageX/Y相等
        • 在 Android 和 MicroB screenX/Y和clientX/Y相等，也就是它们以CSS的pixels度量屏幕尺寸
        • 在FireFox里screenX/Y值不正确
        • IE, BlackBerry, 和 Obigo 不支持 pageX/Y.
        • NetFront 所以三个值都是screenX/Y.
        • Obigo clientX/Y是screenX/Y.
        • Samsung WebKit 总是返回pageX/Y.

      • 未测试：Opera Mini,Bolt,Skyfire

        • 事件坐标在桌面浏览器上多多少少是支持的。不幸的是，移动设备上在所测试的12个主流浏览器中只有Symbian WebKit 和 Iris完全正确的支持这3个坐标特性。其余浏览器多多少少都存在问题。
        • pageX/Y,该特性依然是基于页面的CSSpixels度量的值，如图在桌面浏览器一样，它是三个特性里面最有用的。如图1-12
        • image 图1-12
        • clientX/Y是基于visualviewport的，以CSSpixels度量的值. 这样做比较靠谱，虽然我不是很确信这样计算的好处。
        • screenX/Y基于设备屏幕以设备的pixels度量的值。显然，它使用和clientX/Y同样的参考，而设备的pixels没什么用。所以我们不需要在意screenX/Y,同在桌面浏览器一样，每个bit都是没用的。如图1-13.
        • image 图1-13
        • viewport的meta标签 meta viewport

        Metaviewport

      • 含义：设置layoutviewport的宽度
      • 度量：CSS的pixels
      • 完整支持：Opera Mobile, iPhone, Android, Iris, IE, BlackBerry, Obigo
      • 不支持：Opera Mini, Symbian, Bolt, Firefox, MicroB, NetFront
      • 问题：
        • Skyfire 不能处理我的测试页面。
        • 在三星的wibkit浏览器下，出现<meta viewport>会改变一些特性对的值。

        * Opera Mobile, iPhone, Samsung, and BlackBerry 不允许用户在设置viewport后再进行缩小操作（do not allow the user to zoom out.）

        • 最后我们讨论<meta name="viewport" content="width=320">；最初这是Apple的一个html扩展标签，但被许多浏览器复用，意义是设置layoutviewport的宽度。为了理解它的含义，我们退一步看看基础。
        • 假设你创建一个页面，并不为它赋值width。那么它会伸展开来占据100%的viewlayout的宽度。绝大多数浏览器缩小这个页面以在一屏的宽度上显示这个layoutviewport。我们获得如下效果。图2-1.
        • image 图2-1
        • 用户会立马放大页面，虽然会起到效果，但绝大多数浏览器会保存元素完整的宽度（保持元素定位的不变），而导致阅读困难（文字超过屏幕），如图2-2
        • image 图2-2
        • (唯一不同的是Android下的Webkit核心浏览器，他会剪短长串文字的html元素，以让他们适应屏幕。这简直太有才了，我觉得其余所有浏览器都应该复用这个特性。我会在再以后全面的写这方面内容)
        • 现在你可以尝试着设置htm{width: 320px}。现在<html>元素收缩，随之所有的会计元素都占有100%的<html>宽度：320px。当用户放大浏览器显示时这样做工作得挺好，但在最初加载时的缩小显示下，用户感觉很糟糕，因为页面几乎没内容。如图2-3.
        • image 图2-3
        • 为了解决这个问题，Apple引入了metaviewport。当你设置<meta name="viewport" content="width=320">,你网站的layoutviewport变成了320px。页面的初始状态就很正确了。如图2-4
        • image 图2-4
        • 你能任意设置layoutwidth的宽度，甚至包括device-width。device-width由以设备的pixels度量screen.width来设置。
        • 在这里有个钩子（There’s a catch here）。有时严格的screen.width一点意义都没有，因为pixels的值太大了。例如，Nexus One上的严格宽度是480px，但Google的工程师觉得在用户设置device-width时，将layoutviewport设置为480太大了。他们砍成了2/3，提供320px，和iPhone上一致。
        • 加入，像传言中，新的iPhone将提供一个巨大的pixel值（并不等于一个巨大的屏幕，只是分辨率），如果他们沿用这个特性：device-width为320，我一点都不会惊讶。或许最终device-width会直接意味着320px。
        • 相关研究
        • 许多相关研究将会在以后展开：
      • position: fixed。一个固定位置的元素，如我们所知，定位于viewport。但到底是哪个viewport？我的研究结果如下：猛击
      • 其余media 查询：dpi, orientation, 特别是dpi是个灾难性的区域，不仅仅因为所以浏览器都返回96dpi（通常这个值是错误的），而且因为我们不知道web开发人员到底对哪部分感兴趣。[一个相关问题](http://stackoverflow.com/questions/11722442/is-there-a-way-to-use-dpi-in-css-media-queries-instead-of-px）
        • 当我们的元素大于layoutviewport或<html>时会发生什么？如果我们在layoutvwport为320px的页插入了一个1500p元素，如果我们为<html>设置了overflow: visible时，它会超出。是否意味着实际的viewport能比layoutviewport更宽？此外，这种情况发生时一个旧的Android设备（Nexus One）扩大HTML元素。这是个好主意么？
2014 年 2 月 20 日 没有评论 Short URL

点击链接不发送referer的方法

我们在从一个网站点击链接进入另一个页面时，浏览器会在header里加上Referer值，来标识这次访问的来源页面。但是这种标识有可能会泄漏用户的隐私，有时候我不想让其他人知道我是从哪里点击进来的，能否有手段可以让浏览器不要发送Referer呢？

基于HTML标准，可以在a标签内使用rel="noreferrer"来达到这一目的。
目前大部分基于Webkit的浏览器已经支持。
提供跨浏览器支持的更好的办法是使用一个第三方的库noreferrer.js，它可以自动识别浏览器并选择最优方案。

 

如:   <a href=”http://example.com/” rel=”noreferrer”>noreferrer!</a>

当服务器接收到了由从某个网页上点击这个链接发起的HTTP请求时，HTTP请求的Referer字段将是空的，这就好像用户在 IE浏览器（当然IE目前并不支持HTML5）地址栏直接从about:blank状态开始输入地址并访问这个网站一样的效 果，example.com并不会知道这次访问的来源信息。

当链接中的同时使用 target=”_blank” 时，WebKit同样将会把window.opener属性设为空(null)。对于这个用法的解释是：一个由于点击了网页中锚点而发起的请求，之后目标 页面执行的任何脚本应该运行在一个新的上下文环境中，即使这个目标页面通常被认为有着同样的源头。

“noreferrer”这个链接属性值只是HTML5 spec中定义的许多链接属性值的一个。在WebKit中，它是第一个被实现的。其实我们只是希望这样会让那些关心用户隐私和安全的Web开发人员的工作和生活轻松一些。

 

我看了下源码跟网上其他的文章，不发送referer有几种方式，本质是一样的，都是打开一个能刷新页面的小刷新器，再刷新页面

用window.open的方式打开一个中转页面，再在里面执行代码打开(新窗口打开)

其中location.replace刷新页面的方式也可以替换成html自刷新的方式

用iframe添加到body后,仍然用javascript的方式替换链接

用data schema的方式替换href，仍然打开一个刷新器

 

补充 这个东西有啥使用场景呢，比如百度百科之前会判断禁止从别的搜索引擎的链接跳过来。。

 

还有一点，防盗链。比如http://hi.baidu.com/aullik5/item/d677bec02a6b2e300931c6ca

比如下载链接时判断来源，有些下载站只允许本站下载。

2014 年 2 月 8 日 没有评论 Short URL

effective javascript笔记(1)

1.严格模式

有两个文件分别跑在严格模式跟非严格模式上，合并之后，谁在前面，就跑在什么模式上。 因为 “use strict”只在脚本或者函数内顶部生效

若让一个文件既有跑在严格模式也有跑在非严格模式的，可以用(function(){})把两个部分分别包起来

2.浮点数

js中所有数字都是双精度浮点数 ieee754

位运算符会把两个操作数转为整数进行计算(32位2进制)

3.类型转换

加法运算是左结合律的

完备的检测nan函数(因为 isNaN(‘foo’),isNaN(undefined),isNaN({})之类也是true)

假值表:  false 0 -0 “” NaN null undefined

测试未定义应该使用typeof

4 原始类型与封装对象

new String是一个对象 而”abc”是字符串，这意味着

new String(‘abc’)!=new String(‘abc’)

对原始值调用方法跟属性时，会有隐式包装。 之前也讨论过 http://99jty.com/?p=879

5.避免使用==

当参数同类型的时候，可以用==

还有很多的转换规则  参考15页(懒得记了。。反正记得转换的时候会转成数字)

6.分号的插入

有几个很危险的字符

( [ +- /  这五个字符可以作为一个表达式运算符和一条语句的前缀，因此如果前一行没有分号，比如

就会变成 a = b  (f())

这种情况也会出现在函数合并中 (function(){})(function(){}) 会被解析成一句，因此合并工具一定要记得加;

return关键字所在的那个换行符会强制插入分号。 throw,break continue ++ –也是这样

因此一定不要写

这种语句

7  字符串是16位的代码单元，而不是代码点

代码点是啥意思呢，比如某个符号是一个代码点，但是在 utf-16中 一个代码点需要一个或者两个16位的代码单元表示

比如高音谱号（我打不出来。。以g代替）

g12345.length 会是6  因为高音谱号是两个代码单元表示的。

在js的字符串存储中，length charAt,charCodeAt都是工作在代码单元层面的，正则表达式也是。

作用域篇

8 全局变量

尽量不使用，但是有个场景很适合，特性检测。比如检测es5的JSON对象

9声明局部变量

10 避免使用with

这个我也没用过。。应该是改变了作用域链了

11闭包

比如造一个函数之类的，之前用过不少次了，闭包的生命周期比创建他们的函数更长

 

2014 年 1 月 17 日 没有评论 Short URL

gulp与grunt-维护配置与维护流程

gulp与grunt是最近比较火的构建工具，看两段他们的配置文件

上面的配置文件比较好理解，对文件进行合并压缩与jshint验证。

 

现在我们转到gulp上

gulpfile.js

看完了是否有种眼前一亮的感觉（反正我是挺亮的）

两个自动化工具大概是这么组成的：

grunt  加载各种插件-插件配置成小单元-把小单元串成任务

gulp  加载各种工具-使用工具直接进行任务配置-跑任务

 

其实我看完了上面两个配置文件，其最大的区别是glup把“重命名”单独拿出来作为一个“工具”来使用。

而grunt则是在插件内部处理重命名这个事情。

 

因此gulp为了把任务跑好，直接把任务需要的几个东西封装好了，因此gulp只有五个方法： task，run，watch，src，和dest。他通过nodejs的stream驱动，可以把工作“流”向下一步，这其实是天然契合所谓“工作流”的。

相比较而言，grunt提供了很多很方便的配置比如readfile，还有各种模板替换之类，因此他操作配置文件的能力是非常强的。

对我的感觉来讲，gulp更偏重于 过程 一点，而grunt更偏重于对象。grunt可以定义一个很复杂的gruntfile，配置各种各样的配置。

我其实是比较担心 gulp对“工具”的可配置性。但是事实上，gulp自己宣传的卖点是:

code not config

在工作中，配置、环境部署等占了很多的工作，耽误了很多时间。。

https://github.com/jtyjty99999/teamBuilding/blob/master/workflow/Gruntfile.js  这是我之前帮朋友一个复杂项目写的gruntfile，可以看到光配置文件就有几百行，我知道的很多大项目gruntfile文件远远大于我这个。。这个是非常蛋疼的。

写了这么多废话，最终也没啥结论，大家各凭喜好吧，虽然来到了阿里巴巴，但是发现公司还用svn呢。。。

refer:

http://blog.segmentfault.com/laopopo/1190000000372547?page=1#c-1190000000372547-1050000000380216

2014 年 1 月 10 日 2 条评论 Short URL

yield解释与实现(备忘)

时间有限，先把参考文章记录下来，以后详细写

首先yield跟generator需要跑在支持javascript1.7的环境下，可以打开chrome://flags/, 搜索harmony激活就行了。

 

首先是一个示例

注意定义时候 函数名字前面有个*   你可以发现 test()每次都会返回一个对象，这个对象包含value表示yield后面的值，done表示是不是跑完所有的yield了。

 

可以这么理解，yield跟return比较类似, 但是 函数到了return的时候，会结束掉，而到了yield的时候，函数会暂停，直到使用next跑完所有的yield为止，函数才会继续运行。

这有啥用呢？

比如说解决我之前一直没搞懂的–啥时候算完问题

现在有个异步的函数

这个函数很明显，等待一段时间后执行。那我现在想完成一个功能，依次执行delay(200) delay(3000) delay(1000)

如果直接执行的话很显然三秒后这三个函数就都over了。。而且顺序是 200 1000 3000

怎么办呢，我们可以用回调函数的方式

这样其实是很蛋疼的，大家应该记得某个笑话说黑客偷了nasa的一个技术文档的最后一页，结果是

那我们想怎么写呢，说白了什么容易理解，同步呗，就想写成

delay(200)

delay(3000)

delay(1000)

这样该咋办呢。。

因为yield有个 “终止”的功能，我们完全可以把delay()扔到yield后面，从而写成这样的函数：

那么如何实现runOneByOne这种函数呢?刚才讲了 每跳一步是一个yield，可以用next()跳步，最后跳完了done是true.

因此我们可以通过不断检测runOneByOne里面那个生成的函数是否done了，如果没有就next()即可

 

然后你兴高采烈的运行了一下，尼玛坑爹啊，还是200,1000,3000的提示啊，你会问，我玩你呢？

其实这个例子只是我第一次尝试，我尝试是否能够用yield来造成“顺序运行”，事实上也确实顺序运行了delay(200) delay(3000) delay(1000)….(这不是废话么。。)

那如何得到我们想要的结果呢？需要一点小技巧。

异步之所以不知道什么时候运行，是因为异步操作下一步需要知道上一步“结束了”。因此我们需要一个办法来让下一步知道“结束了”

回调操作的意义就是告诉下一步，我结束的时候你就来啊！

那这里，我们把这个顺序运行的例子作为了一个整体，每运行一个作为一个“步骤”

我们仍然使用回调函数，而回调函数的作用不是告诉下一个函数：我结束了啊！后面的我可以开始干活了！

而是告诉整体“我结束了啊，可以开始下一步了”，让整体去触发下一步

因此这也是为什么避免回调函数嵌套的原因，我们把流程控制完全交给整体去做。

那么就有两点

1.如何去触发整体的下一步 我们可以使用整体.next

2.如何做到函数运行完毕后触发整体下一步   我们可以使用callback. 改造一下之前的函数

这样当我们执行delay后，会返回一个函数，这个函数接收一个参数作为回调函数，当函数运行完毕后触发回调。

之后改造runOneByOne

我们使用obj.value(nextStep)代替了nextStep,就是为了当前一步完全完成之后，再触发nextStep,而obj.value正巧返回了我们之前定义的那个函数。

完整代码见 http://jsbin.com/AnIveNi/1

绕了一大圈，就想说明一个问题，我认为这样写的好处：

1.让整体去控制流程，而不是让上一步控制下一步

2.避免过多的回调，前提是需要改造函数，把函数加入一个callback来触发

 

待续

 

 

 

http://www.html-js.com/article/Understanding-the-Yield-principle#2555549-tsina-1-61274-d7478d857d38e757146b9a3c44b2c179

http://blog.zhaojie.me/2010/06/code-for-fun-iterator-generator-yield-in-javascript.html

http://www.cnblogs.com/Ivony/archive/2010/06/08/1754390.html

http://cnodejs.org/topic/4f16442ccae1f4aa2700107b

https://github.com/laverdet/node-fibers

fibers  cps变换

http://www.zhihu.com/question/22196670

ref:

https://developer.mozilla.org/zh-TW/docs/JavaScript_1.7_%E6%96%B0%E9%AE%AE%E4%BA%8B

app：

https://github.com/koajs/koa

2013 年 12 月 29 日 没有评论 Short URL

google的http头为什么有冒号(翻译稿)

When Chrome is talking to a web server using SPDY, if you check the HTTP request headers in Developer Tools, you’ll find some non-standard-looking headers that all start with colons.

当chrome使用spdy访问一个服务器时（比如访问谷歌），你会通过开发者工具发现http请求中有一些看起来不怎么规范的http头，这些头都是以冒号开头

These headers don’t exist for other requests, so what are they?

在别的请求里这些头不存在，这是为啥呢？

spdy-colon-headers.png

This information already exists in the first line of the HTTP request, right?

这些信息在http请求的第一行里就包括了，不是么？

If you had no idea you were looking at headers for a SPDY connection, it might look like the browser is adding request headers where it doesn’t need to. After all, why not just parse the info out of the first line of the request? Well, because it’s SPDY, and there’s nowhere to put a single line likeGET /foo HTTP/1.1 in the SPDY protocol. These required colon headerstake the place of the first HTTP request line, to provide a consistent metadata system.

如果你不知道你观察的是SPDY的连接头,貌似你可能觉得浏览器添加了一些没用的请求头。毕竟,为什么不直接解析第一行http请求的信息吗?

因为它是SPDY,在spdy中没有地方放一行类似GET / foo 这样的东西。 这些冒号开头的头用来代替http请求的第一行，用来提供一个一致的元数据系统（这里我感觉就是要跟http规范一致吧）

By “unfolding” the values in the first line of a HTTP request — which is sort of an arbitrary string — to explicit headers in the client to be sent in the request, the whole thing is much more uniform. A simpler protocol.

Reading these explicit values on the server requires only parsing headers instead of also an arbitrary string corresponding to the first line of a HTTP request. This tiny gain is of course multiplied by every HTTP router that might be involved.

There’s an interesting little aside here, with the way that SPDY actually carries HTTP, compared to something like TLS/SSL.

Encapsulation and framing

Encapsulation is like wrapping one thing in something else. For example, consider TCP and IP.

The TCP packet is wrapped up, as-is, as the payload (data) segment of an IP packet. When the IP packet is received, the TCP packet is unwrapped and then used. The data encapsulated by an IP packet does not need to be TCP, it could instead be UDP, or something else. That IP packets are ignorant of this allows flexibility higher up the stack.

In the same way, TLS/SSL encapsulates (most often) HTTP. You set up a secure tunnel and then send the HTTP payload, unmodified, through that secure tunnel.

SPDY doesn’t really encapsulate HTTP in the same way IP encapsulates TCP. (The version 3 draft spec doesn’t mention the word “encapsulate”). But it does take the HTTP request, both header and data, and chop it up into different frames that get sent over to the server.

HTTP headers are lines separated by CRLF newline characters, but SPDY defines a way to send this data in a different form, as bytes over the wire. A spdy-dev mailing list post explains this (as well as backing up, further down, the simpler parsing point above):

SPDY is a way of converting the concept of an “HTTP message” into bytes to be sent over the wire. This is confusing because the method of doing this currently in widespread use is also called HTTP. As an example, an HTTP message contains a list of headers, each of which is a name/value pair. In SPDY, this is serialized as a series of length-delimited strings, the block of which is then gzipped. In HTTP, this is serialized as a series of CRLF-delimited strings, where names and values are separated by a colon (and isn’t gzipped).

In section 4.1 of the SPDYv3 draft the blending of the framing layer and application layer is touched upon:

Readers may note that this specification sometimes blends the framing layer (Section 2) with requirements of a specific application – HTTP (Section 3). This is reflected in the request/response nature of the streams, the definition of the HEADERS and compression contexts which are very similar to HTTP, and other areas as well.

This blending is intentional – the primary goal of this protocol is to create a low-latency protocol for use with HTTP. Isolating the two layers is convenient for description of the protocol and how it relates to existing HTTP implementations. However, the ability to reuse the SPDY framing layer is a non goal.

(Thanks to Ilya Grigorik for giving some input on this post.)

2013 年 12 月 6 日 没有评论 Short URL

第三方内容开发最佳实践 笔记（1）引入js篇

http://v.youku.com/v_show/id_XNDM5NDczNTIw.html
http://pan.baidu.com/share/link?shareid=467244&uk=2466379732&fid=2008641727  ppt 23页

可能出现的问题：

doctype，css权重

 

引入过程

  • 引入脚本
  • 调用jsapi-调用第三方服务器端api-记录信息
  • 上报信息

 

引入脚本：

同步 document.write

  • 不要使用//www.a.com/b.js
  • file协议调试会出现问题
  • 严格加上charset属性，无法保证目标页面的编码
  • 把</script>转义为<\/script>

异步脚本

  • 不需要规定type
  • 不需要async  因为js创建的script必定异步

 

插入脚本

  • 不能用document.body.appendChild(script);
  • head元素解析过程中不存在body元素
  • 不要随便删除script元素，运行中删除会存在ie6终止情况，过多的script元素会导致内存占用过大
  • 可以用setTimeout来处理。

 

引入的几种方式

 

  1. 可以在第一个script标签后插入(insertBefore)，不会导致崩溃且不需要判断。缺点是必须有一个script元素，且无法控制元素在哪，不容易定位
  2. head第一个子元素 insertBefore head[0]。需要判断head是否存在
  3. 人为插入script元素，脚本加载时间比较滞后，无其他缺点

 

嵌入第三方内容

使用iframe元素

 

  • 可以隔离样式，避免全局变量污染
  • 缺点是ie下权限问题，交互比较麻烦。
  • iframe样式需要reset  width height，自适应，margin，border等

 

使用<ins>元素

 

  • 语义正确，透明元素不会影响内容，
  • ie下p内放置div会导致崩溃

 

第三方样式

  • 使用style.cssText 添加important声明，优先级最高
  • 需要重置 float，margin等，overflow，position，display，text-align等，iecss.com

一些其他问题

  • 尽量使用insertBefore，避免ie的终止操作问题
  • 广告要在最顶端  z-index 2147483647，dom中比较靠后的元素会在最上面，因此可以使用domcontentload或者onload插入。但内容的延迟比较长。
  • 可以从当前script向上查找至body的直接子代，在其前面插入
  • 兼容怪异模式，测试文档模式即可document.compatMode

 

document.write讨论

不可异步执行，导致html解析过程回溯

必须用的情况：

  • 与执行位置相关
  • 其他第三方脚本
  • iframe

ie下时序问题

内联+外部脚本，比如

document.write hello.js  <script>hello()</script>

hello内有hello函数时，hello会报未定义

解决方法

利用try catch执行hello()，catch中加载hello.js.

2013 年 11 月 24 日 没有评论 Short URL

让手机站点像原生应用的四大途径(翻译稿)

 谢谢莫哥整理   http://www.w3cplus.com/performance/beginners-guide-to-perceived-performance.html本文由99根据Kyle Peatt的《A Beginner’s Guide to Perceived Performance: 4 Ways to Make Your Mobile Site Feel Like a Native App》所译，整个译文带有我们自己的理解与思想，如果译得不好或不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：http://www.mobify.com/blog/beginners-guide-to-perceived-performance/，以及作者相关信息

作者：Kyle Peatt

译者：99

这篇文章大约3000字。它涵盖了移动网站“感知性能”的很多方面，以及加速你网站的切实可行的解决方案。TL;博士:这不是说你网站有多快，而是用户认为有多快。——Kyle Peatt

让手机站点像原生应用的四大途径

在移动设备上构建设计良好的网站慢慢变得越来越容易。不论使用什么方法(响应式设计、自适应等),如果你了解你所做的,创建一个美观的网站不是问题。

但你的用户可能仍然要求网站有原生app的体验。完成这样的体验是一个挑战。

大多数时候,当人们谈论“app”或“原生”的感觉,他们讲的的不是一个网站的视觉体验。他们所讨论的，是用户界面如何对他们的行为进行反馈，以及这种反馈是怎样呈现的。

原生应用很“快”。原生应用的动画渲染的很平滑，按钮及时响应用户的点击，当app加载数据时也不会有什么问题。

让你的网站像原生应用一样，意味着你需要尽可能的提高你网站响应及交互的速度

提高性能已经是一个很热门且很有价值的话题了。直到最近，web端还在朝着笨重与缓慢发展。业内一直有个争论：实现一个高性能的webapp是不可能的。

这也是facebook转移到原生应用的原因，至少在他们的开发资源下，无法完成需要的速度与交互。

即使facebook这么认为，构建一个高性能的web网站也不是不可能的。但这不在我们的掌控中。我们只需要努力使这一切变为现实。从技术上讲，我们有能力是我们的网站变得更加快速，更加时髦，带来更完美的体验。

感知性能与实际性能

实际性能的提升很重要，但如果不让用户感知到提升效果，就不意味着这些提升可以到达用户。

今年早些时候,在西雅图Luke Wroblewski 曾提到过他的mobile app-polar。 他解释说,他的团队在努力提高加载投票的速度。

polar是一款很简洁的投票应用——99

同时,他们引入了一个小图标,来向用户表示投票正在加载。而之后，用户感觉投票加载很慢的反馈立即铺天盖地的涌来,尽管事实上。加载快得多。Polar迅速发布了一个补丁来移除这个加载图标,之后，投票的快速加载给用户留下了深刻的印象。

这是一个表达感知性能重要性的很好的例子。当人们“觉得”一个网站不快，那这个网站再快也没用。加载图标只是让用户注意这个事实：数据在加载，用户只能等待，而不能抽离注意力。

作为设计师和开发人员,我们的目标不应该通过一些数字的增长，建立最快的网站,同样应该创造最快的网站体验。

因此最重要的是用户如何感知你网站的速度。任何实际性能的提升只是一份锦上添花。我认为,感知性能的提升，相比实际性能更重要。但这并不意味着你需要忽略实际性能的提升。

Ok，解释足够了，如何可以马上提升网站的感知性能？

下面的四个技巧，你可以立即开始尝试

给按钮添加触摸状态

最简单的提高站点感知性能的方法，是给网站增加”active”状态。

你看,任何时候一个访问者点击网站上的一个按钮,她必须等待300毫秒才知道到底发生了啥。

浏览器设置了这个超时时间，之后可以确保用户不会进行一些其他操作（双击）。因此等待1/3秒后，浏览器知晓了用户的动作，并执行最初的点击。当这个动作发生后，按钮被一个灰色的东东覆盖。

这是很糟糕的用户体验。Nielsen组织进行了一项研究，发现任何高于100ms的延迟都会让用户认为他们在等待。他们可能只想进行一次跳转。

然而很多的移动网站，包括我做的那些，没有考虑这个感知问题。设计师通常的设计是触摸时按钮或者链接保持原样。

为了让你的网站感觉更快,你需要让你的按钮立即响应用户的触摸,给用户一个明显的视觉指示–有些事情正在发生。

有一个很赞的属性用在网站上的按钮或链接;它是:active伪类。我们在桌面端一直使用这个伪类。

不幸的是,无论是iOS还是android，当按钮或者链接被点击时都忽略了这个属性,为了激活这个状态,你需要添加一个简单的事件绑定到页面的JavaScript中:

之后你可以用css定义active状态的样式，之后去掉点击时的高亮：

对按钮设置这两个属性,用户会立即感觉到界面响应了用户的操作，即使最终的响应速度是一样的。你只是让你的界面即时反馈了用户的行动,而不会让用户傻等300 ms再看看到底干了啥。

让手机站点像原生应用的四大途径

没有触摸状态（代码）

让手机站点像原生应用的四大途径

有触状态（代码）

不过如果你想立即响应用户的操作，你可以使用另一种方案。

使用一个fasttap或fastclick这样的JavaScript函数,可以完全去除点击按钮后300毫秒的延迟。配合active状态，可以让网站快的亮瞎你的眼睛。

有关于fasttap更多的信息，可以阅读google搜索到的文章，这有一个现成的案例，你可以从github上导出。

使用弹性滚动

你试过创建一个可滚动的容器，然后被默认的慢悠悠且不响应的滚动折磨的疯掉么？

现在可以解放了，android3+与ios5+版本增加了一个新的属性：overflow-scrolling这个属性可以激活平滑滚动，而且效果也不错。

让手机站点像原生应用的四大途径

没有滚动条(代码)

让手机站点像原生应用的四大途径

有滚动条(代码)

这个弹性滚动感觉起来像原生应用，因为这个本来就是原生的滚动。你只需要向可滚动区域增加一行代码。

不过这个属性有个问题。这个属性会使点击iPhone头部状态栏让网页回到顶部的功能失效。这个bug已经存在了一段时间了，貌似也没有在新的ios7版本中修复。

有一种方法可以解决这个问题，为容器创建一个class并应用属性overflow-scrolling: touch。当且仅当容器显示时，使用javascript添加class到容器上。

Android4上你不需要使用这个属性。每个可滚动的容器均包含弹性滚动。

在老版本的Android上你有两种选择。我比较喜欢的解决方案是利用Modernizr检测弹性滚动，之后来控制布局中容器的显示。此外,有一些JavaScript库你可以试试，比如overthorw与iscroll。

创建高效的动画

App与网站最明显的差别之一就是动画效果。

现在的设备上，应用程序已经能够充分利用硬件图形加速。而在web端,开发商者使用基于javascript的动画,在移动端的cpu上跑是很慢的。

但现在,随着移动浏览器的不断支持,你可以在项目中使用基于硬件加速的CSS3动画。

这样，我们就可以添加一些视觉效果，这些效果已经被我们喜欢的一些app应用了很多年了。

事实上也没那么快，若使动画贴近原生体验，你需要避免动画的缓慢及抖动，而这都是很难处理的。Steamclock Software的Allen Pike写过一篇很赞的文章，文章里描述了动画所带给用户的快乐，也讲到低性能的动画将对用户在app上的体验产生很大的影响

有趣的是,他写的这篇是原生应用开发相关的。这使得这篇文章相当有用，我们可以跟随下列任务来创建web上的动画。

在文章中,他提出一个所谓的“时间轴感”:

  • 动画要跑在60fps下。这意味着每一帧需要花费16ms来跑完(1000ms/60=16)。这是要达到原生应用般平滑体验的最基本要求。60 fps是所有的iOS的内置动画运行的速度;这就是为什么滚动在iPhone上比Android设备上感觉更好 (虽然谷歌已经取得了很大的进步)。你应该尝试让所有直接关系到用户的交互动画跑在这个速度上。
  • 所有东西都要在100ms内渲染完毕。 这是个心理感觉慢的界限。所有低于100ms的延迟都会让用户有瞬时响应的感觉。
  • 如果它绝对得超过100毫秒,1000毫秒内绝对应该回应。艾伦表明任何需要这么长时间完成的操作，都应该给用户一些反应表明正在发生。比如一个旋转的图标或一个进度条。但是,正如我们之前研究过的那个投票app的例子,把用户的注意力聚焦到那个小菊花上，实际上可能弊大于利。我将介绍一种不同的方法来处理这个问题。
  • 所有超过两秒的响应时间都是耍流氓。

好吧，你知道这些了，所以你估计要把键盘当作帽子然后去转行了。啥时候我们创建网站需要关心动画的时间了？

别担心,有一些很赞的资源让这些东西更容易实现!

第一个是HTML5 Boilerplate中的Effeckt.css。 他们的目标是实现一些跑在60fps下的常见的转换和动画。虽然这个库并没完全完成，里面很多的效果已经跑得很好了。我极力推荐你在项目中使用这个库。

另一个很好的库是 Topcoat,Adobe网络团队编写的代码,这是一个建立在性能考虑下的CSS组件库。这个库里塞了满满的优秀的组件,运行平稳。因为性能是他们的主要目标,每一个组件都已经被跟踪性能,这样你就可以清楚地看到组件的性能。

以上两个库是齐头并进的，而且topcoat也向effeckt.css贡献代码，这两个库跑的都很赞。

然后，我要讨论之前提到的，尽可能去掉加载提示的方案。

我倾向的方案是，当等待时间大于100ms，小于250ms时，使用加载图标弊大于利，因此可以隐藏掉。

例如,如果你使用Ajax请求内容,可以对内容的容器应用动画,例如收缩起来再扩展从而适应新的内容。这样的短动画会分散用户等待时的注意力,而不是让用户盯着一个不断旋转的小菊花–他们只是等待一个短动画完成，以至于甚至没有意识到新内容没出现。

当然, 需要很长时间才能完成的重复的动画是非常令人讨厌的,所以我们要适当的使用这些动画。对于大多数动画而言都是这个道理。

提供自然的手势体验

App超过web端体验的一点，是可以在触控设备上提供很自然的手势。

Mailbox与Clear可以作为手势应用很好的例子。这些app使用简单的手势来利用了移动设备最大的特色—可以直接触摸屏幕上的物体。

然而大多数网站只使用了触摸对象。设计师对手势唯恐避之不及,结果用户感觉在web端受到了歧视一般。

我们需要考虑直接为设备开发网站。如果一个用户的设备允许手势操作,为什么不使用它们?

当然,还有一个小问题:移动操作系统有个可恶的特性,移动浏览器会劫持手势作为己用。

例如, 像Facebook一样的应用程序通过触摸屏幕的左边和右边来打开导航。然而,在浏览器段,这种交互是不可用的。对于Chrome，这种操作用来切换选项卡。iOS 7新版本的移动Safari使用这种操作前进,与后退。

好吧。这些手势在我们的可控范围之外。那么你们应该使用什么手势呢？下面有四个例子。

手势1:左右划动

即使存在边缘问题,左右划动仍然是一个很好用的手势。你只需要小心触发时不要太靠近屏幕的边缘。

这个手势最好的应用是用于移动一组对象,比如幻灯片或列表标签。

手势2:下拉刷新

下拉刷新也是用户接触到的手势。这里有一些很赞的js库可以很容易的实现这个特性，我使用hook.js来实现。

手势3:长按

有一个很有用的属性: -webkit-touch-callout: none。这将禁用移动Safari浏览器中默认的长按效果。在android禁用这个效果则需要费点劲。

长按手势可以用于拿起一个项目(如重新排序列表中的项)或显示更多选项(如社会共享)。

手势4:双指缩放

每个人都懂双指缩放。很多人当看到web端的图片后，都会尝试缩放图片来看清细节。

这里也存在浏览器劫持用户手势的情况，不过不是很难办。

当你锁定或不锁定viewport的时候，你有时不希望用户在双指缩放时缩放整个页面。为了代替这个多指手势，你可以使用这个小而精的harmmer.js库。这个库拥有一系列的手势可以为你使用，你也可以建立自己的手势。

一个很好的双指缩放例子是imgur.com 的手机站。 你可以滑动两下看看会发生什么。

只需要记住,如果你正在使用一个手势,确保对于用户而言，要么感觉自然，要么有意义。

结论

我希望有一天，我们不会需要区分本地和网络。路漫漫其修远兮，我们的工作是让用户觉得网站是围绕他们设计的，这一天很快就会到来。

我认为，最近关注性能的趋势固然很棒,但必须记住,我们的用户不是机器。

他们不关心你的网站有多少请求，屏幕重绘有多快。但他们确实关心一些影响他们体验的东西——他们的感知性能。

专注于确保你网站的外观和行为像一个尽可能快的网站。如果用户不注意的话是没有资格称作“最快的网站”的。

如果你对于改善感知性能有任何建议,请贴在评论里。

译者手语：整个翻译依照原文线路进行，并在翻译过程略加了个人对技术的理解。如果翻译有不对之处，还烦请同行朋友指点。谢谢！

关于玖玖

某创业团队前端负责人，关注javascript应用与数据可视化。个人博客、新浪微博和Github，欢迎与同学一起共勉。

2013 年 10 月 29 日 没有评论 Short URL
« Older posts