Category Archives: Frontend

那些 JavaScript 容易被忽视的细节

《JavaScript 权威指南》这本书从第四版开始，一直到第六版，每个版本我都逐字逐句读过几遍，然而每一遍下来的感受却完全不一样。上上周的周一，再次翻开了这本犀牛书， 这一次我是带着批判精神和研究精神过来的，所以看的时候也写下了一些感受和笔记，都是些容易被忽略的点，部分内容犀牛书上不一定有提到。 之前都发在 微博 上，稍微整理了一番，放在这里，方便阅读。 一些小点 语句/表达式 换个角度理解语句（statemaents）和表达式（expressions）：表达式不会改变程序的运行状态，而语句会。还有一种叫做表达式语句，可以理解为表达式和语句的交集，如 ({a:1})、"use strict;"等，我觉得没必要死扣，意义不大。 字符集 ES3 要求 JS 必须实现 Unicode 2.1 及后续版本，而 ES5 只要求支持 Unicode 3 及后续版本。Unicode 字符 2005 年超过了十万字符，至今仍在不断增修，最新版本是 8.0。 分号 如果你写 JS 代码不喜欢带分号，而又搞不清什么时候必须加分号，可以这么做：在以  “(“、”[“ 、”/“、”+”、”-“ 开头的语句前面都加上一个分号，如 ;(a + b).toString()。 进制 ES5 严格模式中禁止使用八进制。目前各种引擎对 JS 的实现是存在差异的，部分支持八进制，部分不支持。八进制被禁止的原因：String 和 Number 之间经常被相互转换，而以 0 开头的八进制数据特别容易让人迷惑，也容易让机器迷惑，比如 09 是该被转换成 9 还是直接报错？十六进制不存在这个问题，如 0x98。更多信息参阅 这里。 精度 JS 采用 IEEE-754 浮点数表示法，这是一种二进制表示法，由于精度原因 JS 不能表示所有的实数。它能展示的浮点数个数是有限的，比如它不能准确地表示三分之一的数值字面量。这也导致了它在浮点数的计算上存在误差，如 0.3-0.2 != 0.2-0.1，因为在计算的过程中，存在数据的溢出，丢失了精度。 null/undefined 系统级、出乎意料的或者类似错误的值的空缺使用 undefined，而程序级、正常的或意料之中的值的空缺使用 null。平时编程给变量赋值时，不要使用 undefined 而应该用 null。值得注意的是 ES3 中的 undefined 是可以被重新赋值的，ES5 修复了这个 bug。通常我们使用 void 0 来还原/代替 undefined 的值。 eval eval 是个不好把握的东西，它在 ES3 中更像是 Function，而在 ES5 中更像是一个运算符（严格模式下不允许设置别名，否则报错，且将其作为保留字）。实际上 ES3 中也不允许给 eval 设置别名，然而很多实现却依然允许，并将其作为全局代码来执行，浏览器尤其是 IE 对它实现相当混乱，没有什么规律可循，不过 IE 中提供了一个 […]

wx.onMenuShareTimeline使用注意事项

我在开发测试过程中,发现使用wx.onMenuShareTimeline无效果,没有显示我定义的图片、title和链接,经过调试发现原因如下： 1.图片大小要大于300pix才能显示 2.这个方法必须先config成功，然后再wx.ready里才能调用。我直接放到$(function(){})里执行，实践证明是不行的。

from:http://www.cnblogs.com/zhouyu629/p/4496065.html

Navigator 对象

Navigator 对象 Navigator 对象包含有关浏览器的信息。 注释：没有应用于 navigator 对象的公开标准，不过所有浏览器都支持该对象。 Navigator 对象集合 集合 描述 plugins[] 返回对文档中所有嵌入式对象的引用。 该集合是一个 Plugin 对象的数组，其中的元素代表浏览器已经安装的插件。Plug-in 对象提供的是有关插件的信息，其中包括它所支持的 MIME 类型的列表。 虽然 plugins[] 数组是由 IE 4 定义的，但是在 IE 4 中它却总是空的，因为 IE 4 不支持插件和 Plugin 对象。 Navigator 对象属性 属性 描述 appCodeName 返回浏览器的代码名。 appMinorVersion 返回浏览器的次级版本。 appName 返回浏览器的名称。 appVersion 返回浏览器的平台和版本信息。 browserLanguage 返回当前浏览器的语言。 cookieEnabled 返回指明浏览器中是否启用 cookie 的布尔值。 cpuClass 返回浏览器系统的 CPU 等级。 onLine 返回指明系统是否处于脱机模式的布尔值。 platform 返回运行浏览器的操作系统平台。 systemLanguage 返回 OS 使用的默认语言。 userAgent 返回由客户机发送服务器的 user-agent 头部的值。 userLanguage 返回 OS 的自然语言设置。 Navigator 对象方法 方法 描述 javaEnabled() 规定浏览器是否启用 Java。 taintEnabled() 规定浏览器是否启用数据污点 (data tainting)。 from:http://www.w3school.com.cn/jsref/dom_obj_navigator.asp

HTML5 WebStorage(HTML5本地存储技术)

WebStorage是HTML5中本地存储的解决方案之一，在HTML5的WebStorage概念引入之前除去IE User Data、Flash Cookie、Google Gears等看名字就不靠谱的解决方案，浏览器兼容的本地存储方案只有使用cookie。有同学可能会问，既然有了cookie本地存储，为什么还要引入WebStorage的概念？ Cookie肿么了 cookie的缺陷是非常明显的 1. 数据大小：作为存储容器，cookie的大小限制在4KB左右这是非常坑爹的，尤其对于现在复杂的业务逻辑需求，4KB的容量除了存储一些配置字段还简单单值信息，对于绝大部分开发者来说真的不知指望什么了。 2. 安全性问题：由于在HTTP请求中的cookie是明文传递的（HTTPS不是），带来的安全性问题还是很大的。 3. 网络负担：我们知道cookie会被附加在每个HTTP请求中，在HttpRequest 和HttpResponse的header中都是要被传输的，所以无形中增加了一些不必要的流量损失。 WebStorage WebStorage是HTML新增的本地存储解决方案之一，但并不是为了取代cookie而制定的标准，cookie作为HTTP协议的一部分用来处理客户端和服务器通信是不可或缺的，session正是依赖于实现的客户端状态保持。WebStorage的意图在于解决本来不应该cookie做，却不得不用cookie的本地存储。 WebStorage提供两种类型的API：localStorage和sessionStorage，两者的区别看名字就有大概了解，localStorage在本地永久性存储数据，除非显式将其删除或清空，sessionStorage存储的数据只在会话期间有效，关闭浏览器则自动删除。两个对象都有共同的API。 复制代码 代码如下: interface Storage {   readonly attribute unsigned long length;   DOMString? key(unsigned long index);   getter DOMString getItem(DOMString key);   setter creator void setItem(DOMString key, DOMString value);   deleter void removeItem(DOMString key);   void clear(); }; 1、length:唯一的属性，只读，用来获取storage内的键值对数量。 2、key：根据index获取storage的键名 3、getItem：根据key获取storage内的对应value 4、setItem：为storage内添加键值对 5、removeItem：根据键名，删除键值对 6、clear：清空storage对象 WebStorage如何使用 在实现了WebStorage的浏览器中，页面有两个全局的对象localStorage和sessionStorage 以localStorage为例，看一段简单的操作代码 复制代码 代码如下: var ls=localStorage;             console.log(ls.length);//0             ls.setItem('name',’Byron');             ls.setItem('age',’24');             console.log(ls.length);//2             //遍历localStorage             for(var i=0;i<ls.length;i++){                 /*                     age : 24                     […]

js移动设备手机跳转地址代码

另外的三种： 版本1

版本2

版本3 百度webapp版

移动端尺寸基础知识

初涉移动端设计和开发的同学们，基本都会在尺寸问题上纠结好一阵子才能摸到头绪。我也花了很长时间才弄明白，感觉有必要写一篇足够通俗易懂的教程来帮助大家。从原理说起，理清关于尺寸的所有细节。由于是写给初学者的，所以不要嫌我啰嗦。 现象 首先说现象，大家都知道移动端设备屏幕尺寸非常多，碎片化严重。尤其是Android，你会听到很多种分辨率：480×800, 480×854, 540×960, 720×1280, 1080×1920，而且还有传说中的2K屏。近年来iPhone的碎片化也加剧了：640×960, 640×1136, 750×1334, 1242×2208。 不要被这些尺寸吓倒。实际上大部分的app和移动端网页，在各种尺寸的屏幕上都能正常显示。说明尺寸的问题一定有解决方法，而且有规律可循。 像素密度 要知道，屏幕是由很多像素点组成的。之前提到那么多种分辨率，都是手机屏幕的实际像素尺寸。比如480×800的屏幕，就是由800行、480列的像素点组成的。每个点发出不同颜色的光，构成我们所看到的画面。而手机屏幕的物理尺寸，和像素尺寸是不成比例的。最典型的例子，iPhone 3gs的屏幕像素是320×480，iPhone 4s的屏幕像素是640×960。刚好两倍，然而两款手机都是3.5英寸的。 所以，我们要引入最重要的一个概念：像素密度，也就是PPI（pixels per inch）。这项指标是连接数字世界与物理世界的桥梁。 Pixels per inch，准确的说是每英寸的长度上排列的像素点数量。1英寸是一个固定长度，等于2.54厘米，大约是食指最末端那根指节的长度。像素密度越高，代表屏幕显示效果越精细。Retina屏比普通屏清晰很多，就是因为它的像素密度翻了一倍。 倍率与逻辑像素 再用iPhone 3gs和4s来举例。假设有个邮件列表界面，我们不妨按照PC端网页设计的思维来想象。3gs上大概只能显示4-5行，4s就能显示9-10行，而且每行会变得特别宽。但两款手机其实是一样大的。如果照这种方式显示，3gs上刚刚好的效果，在4s上就会小到根本看不清字。 在现实中，这两者效果却是一样的。这是因为Retina屏幕把2×2个像素当1个像素使用。比如原本44像素高的顶部导航栏，在Retina屏上用了88个像素的高度来显示。导致界面元素都变成2倍大小，反而和3gs效果一样了。画质却更清晰。 在以前，iOS应用的资源图片中，同一张图通常有两个尺寸。你会看到文件名有的带@2x字样，有的不带。其中不带@2x的用在普通屏上，带@2x的用在Retina屏上。只要图片准备好，iOS会自己判断用哪张，Android道理也一样。 由此可以看出，苹果以普通屏为基准，给Retina屏定义了一个2倍的倍率（iPhone 6plus除外，它达到了3倍）。实际像素除以倍率，就得到逻辑像素尺寸。只要两个屏幕逻辑像素相同，它们的显示效果就是相同的。 Android的解决方法类似，但更复杂一些。因为Android屏幕尺寸实在太多，分辨率高低跨度非常大，不像苹果只有那么几款固定设备、固定尺寸。所以Android把各种设备的像素密度划成了好几个范围区间，给不同范围的设备定义了不同的倍率，来保证显示效果相近。像素密度概念虽然重要，但用不着我们自己算，iOS与Android都帮我们算好了。 如图所示，像素密度在120左右的屏幕归为ldpi，160左右的归为mdpi，以此类推。这样，所有的Android屏幕都找到了自己的位置，并赋予了相应的倍率： ldpi [0.75倍] mdpi [1倍] hdpi [1.5倍] xhdpi [2倍] xxhdpi [3倍] xxxhdpi [4倍] 各型号iPhone的倍率比较简单，我们后面会讲到。那么Android手机那么多，具体怎么分？哪些手机是几倍的倍率呢？我们先看一张表，这是友盟2014年10月到2015年03月的数据： 就目前市场状况而言，各种手机的分辨率可以这样粗略判断。虽然不全面，但至少在1年内都还有一定的参考意义： ldpi 如今已绝迹，不用考虑 mdpi [320×480]（市场份额不足5%，新手机不会有这种倍率，屏幕通常都特别小） hdpi [480×800、480×854、540×960]（早年的低端机，屏幕在3.5英寸档位；如今的低端机，屏幕在4.7-5.0英寸档位） xhdpi [720×1280]（早年的中端机，屏幕在4.7-5.0英寸档位；如今的中低端机，屏幕在5.0-5.5英寸档位） xxhdpi [1080×1920]（早年的高端机，如今的中高端机，屏幕通常都在5.0英寸以上） xxxhdpi [1440×2560]（极少数2K屏手机，比如Google Nexus 6） 自然地，以1倍的mdpi作为基准。像素密度更高或者更低的设备，只需乘以相应的倍率，就能得到与基准倍率近似的显示效果。 不过需要注意的是，Android设备的逻辑像素尺寸并不统一。比如两种常见的屏幕480×800和1080×1920，它们分别属于hdpi和xxhdpi。除以各自倍率1.5倍和3倍，得到逻辑像素为320×533和360×640。很显然，后者更宽更高，能显示更多内容。所以，即使有倍率的存在，各种Android设备的显示效果仍然无法做到完全一致。 单位 不难发现，真正决定显示效果的，是逻辑像素尺寸。为此，iOS和Android平台都定义了各自的逻辑像素单位。iOS的尺寸单位为pt，Android的尺寸单位为dp。说实话，两者其实是一回事。 单位之间的换算关系随倍率变化： 1倍：1pt=1dp=1px（mdpi、iPhone 3gs） 1.5倍：1pt=1dp=1.5px（hdpi） 2倍：1pt=1dp=2px（xhdpi、iPhone 4s/5/6） 3倍：1pt=1dp=3px（xxhdpi、iPhone 6） 4倍：1pt=1dp=4px（xxxhdpi） 单位决定了我们的思考方式。在设计和开发过程中，应该尽量使用逻辑像素尺寸来思考界面。设计Android应用时，有的设计师喜欢把画布设为1080×1920，有的喜欢设成720×1280。给出的界面元素尺寸就不统一了。Android的最小点击区域尺寸是48x48dp，这就意味着在xhdpi的设备上，按钮尺寸至少是96x96px。而在xxhdpi设备上，则是144x144px。 无论画布设成多大，我们设计的是基准倍率的界面样式，而且开发人员需要的单位都是逻辑像素。所以为了保证准确高效的沟通，双方都需要以逻辑像素尺寸来描述和理解界面，无论是在标注图还是在日常沟通中。不要再说“底部标签栏的高度是96像素，我是按照xhdpi做的”这样的话了。 Web怎么办 移动端页面的绝对单位仍然是px，至少代码里这么写，但它的道理也和app一样。由于像素密度是设备本身的固有属性，它会影响到设备中的所有应用，包括浏览器。前端技术可以善加利用设备的像素密度，只需一行代码，浏览器便会使用app的显示方式来渲染页面。根据像素密度，按相应倍率缩放。 可以通过这个测试页面 http:/m/test.html 来看看你的移动设备屏幕宽度，这是逻辑像素宽度。 以iPhone 5s为例，屏幕的分辨率是640×1136，倍率是2。浏览器会认为屏幕的分辨率是320×568，仍然是基准倍率的尺寸。所以在制作页面时，只需要按照基准倍率来就行了。无论什么样的屏幕，倍率是多少，都按逻辑像素尺寸来设计和开发页面。只不过在准备资源图的时候，需要准备2倍大小的图，通过代码把它缩成1倍大小显示，才能保证清晰。 实际应用 大家最关心的还是实际运用，画布该怎么设置。我们就iOS、Android、Web三个平台来分别梳理一下。不过在这之前，我要为使用PS进行设计的朋友介绍一个小技巧。 之前我说过，我们要以逻辑像素尺寸来思考界面。体现到设计过程中，就是要把单位设置成逻辑像素。打开PS的首选项——单位与标尺界面，把尺寸和文字单位都改成点（Point）。这里的点也就是pt，无论设计iOS、Android还是Web应用，单位都用它。当然，各平台单位名称还是要记住的。这里我们用的只是它的原理，不用在意名称。 要调节倍率，则通过图像大小里的DPI来控制。这个DPI，其实就是PPI，像素密度。有个常识大家都知道，屏幕上的设计DPI设成72，印刷品设计DPI设成300。为什么是这两个数字？ 首先说300，这和人眼的分辨能力有关。由于1英寸是固定长度，每1英寸有多少个像素点决定了画质清晰程度。之前说过，这就是像素密度，也就是DPI。DPI达到300以上，其细腻程度就会给人真实感，像真实世界中的物件。相反，DPI只有10的话，在你一个食指指节大小的长度内只有10个像素，这明显就是马赛克了。所以印刷品要设成300，才能保证清晰。 再说72，这有一定的历史原因。最早的图形设计是在mac电脑上进行的，mac本身的显示器分辨率就是72。PS中把图像DPI也设成72，就能保证屏幕上显示的尺寸和打印尺寸相同，便于设计。72的PC显示器分辨率逐渐成为一种默认的行业标准，这套规则就这么沿用下来。 现在回到正题，我们怎么通过DPI来调节倍率？既然屏幕本身的分辨率是72，DPI设成72刚好是1倍尺寸，那设成72的两倍就是倍率为2的屏幕了，就这么简单。 下面来看看3个平台各自的画布设置： […]

关于适配你需要知道的—MobileWeb适配总结

开门见山，本篇将总结一下MobileWeb的适配方法，即我们常说的H5页面、手机页面、WAP页、webview页面等等。 本篇讨论的页面指专门针对手机设备设计的页面，并非兼容全设备的响应式布局。 文中提到的 device-width 指 viewport meta 标签中 width 的值，即由浏览器指定的值，常用机型对应值可参照Screen Sizes。 适配达到的效果是什么？ 在不同尺寸的手机设备上，页面“相对性的达到合理的展示（自适应）”或者“保持统一效果的等比缩放（看起来差不多）”。 适配应关注哪些要素？ 一般来说，我们需要关注的是：字体、高宽间距、图像（图标、图片）。 其中，图像相对要复杂一些，针对流量、清晰度等问题网上也有比较成熟的解决方案，比如：矢量化、字体化、image-set 等等，在此不做深入。在满足快速开发的需求下，我们使用较为偷懒的方式：利用 css 将图像限定在元素内（ img 图片使用 [max-]width: 100% ，背景图像使用 background-size ），布局只针对元素进行。 另外要考虑到，设计师设计视觉稿时使用什么样的宽度，才能既满足设计自身的需求又能让前端开发方便的切图适配。 举个例子 围绕这三要素，我们用一个小例子来说明接下来要介绍的三种方案的实现方式，按 640px 标准需实现的效果如图： app.jpg 固定高度，宽度自适应 这是目前最通用的一种做法，属于自适应布局，viewport width 设置为 device-width，以较小宽度（如 320px）的视觉稿作为参照进行布局。垂直方向的高度和间距使用定值，水平方向混合使用定值和百分比或者利用弹性布局，最终达到“当手机屏幕变化时，横向拉伸或者填充空白的效果”。图像元素根据容器情况，使用定值或者 background-size 缩放。 粗略浏览了下一些大厂的首页，像百度、腾讯、Facebook、Twitter 都是采用的这种方案。 要点： 以小宽度作为参照是因为如果布局满足了小宽度的摆放，当屏幕变宽时，简单的填充空白就可以了；而如果反过来就可能造成“挤坏了”，考虑 header 区域，左测 logo 右测横向 nav 的情况。 需要小宽度的布局，又需要大宽度的图像，这是一个矛盾点。 320px 过于窄小，不利于页面的设计；只能设计横向拉伸的元素布局，存在很多局限性。 兼容性较好。 实现比较简单，样式中的尺寸都按照视觉稿二分之一大小设置，查看效果和代码。 固定宽度，viewport 缩放 视觉稿、页面宽度、viewport width 使用统一宽度，利用浏览器自身缩放完成适配。页面样式（包括图像元素）完全按照视觉稿的尺寸，使用定值单位 （px、em）即可完成。 优点： 开发简单：缩放交给浏览器，完全按视觉稿切图。 还原精准：绝对等比例缩放，可以精准还原视觉稿（不考虑清晰度的情况下）。 测试方便：在PC端即可完成大部分测试，手机端只需酌情调整一些细节（比如图标、字体混合排列时，因为字体不同造成的对齐问题）。 存在的问题： 像素丢失：对于一些分辨率较低的手机，可能设备像素还未达到指定的 viewport 宽度，此时屏幕的渲染可能就不准确了。比较常见的是边框“消失”了，不过随着手机硬件的更新，这个问题会越来越少的。 缩放失效：某些安卓机不能正常的根据 meta 标签中 width 的值来缩放 viewport，需要配合 initial-scale 。 文本折行：存在于缩放失效的机型中，某些手机为了便于文本的阅读，在文本到达 viewport 边缘（非元素容器的边缘）时即进行折行，而当 viewport 宽度被修正后，浏览器并没有正确的重绘，所以就发现文本没有占满整行。一些常用的段落性文本标签会存在该问题。 缩放失效问题需通过 js 动态设定 initial-scale

文本折行问题可以通过 […]

关于CSS3的box-sizing

以前写padding都要从宽高里送去相应的值，今天看京东手机版网页，发现了box-sizing:border-box;，加上之后就不用再减去相应的值了，因为填充已经到边框里面了。 定义和用法 box-sizing 属性允许您以特定的方式定义匹配某个区域的特定元素。 例如，假如您需要并排放置两个带边框的框，可通过将 box-sizing 设置为 "border-box"。这可令浏览器呈现出带有指定宽度和高度的框，并把边框和内边距放入框中。 默认值： content-box 继承性： no 版本： CSS3 JavaScript 语法： object.style.boxSizing="border-box"

修改placeholder的颜色

CHROME下去掉保存密码后输入框变成黄色背景样式

用阴影实现:

如果不想保存密码的话加个autocomplete="off"到form或者input就行了。 from:http://jinzhe.net/post/26.html