移动Web
移动web基础
移动端开发现状
移动端的浏览器与pc端不同
谷歌浏览器 苹果浏览器、 UC浏览器 QQ浏览器 欧朋浏览器 百度手机浏览器 360安全浏览器 搜狗浏览器 猎豹浏览器等
国内的手机浏览器都是根据webkit内核修改过来的,国内没有自主研发的内核,国内的操作系统也是基于Android系统修改的。
因此在移动端,css3属性只需要加webkit前缀即可。
移动端设备尺寸不一样(尺寸非常多,碎片化很严重)
Android: 320480 480800 540960 7201280 1080*1920 2k屏 4k屏
iphpne: 640960 6401136 7501334 12422208
移动端开发分类
三种开发各有优缺点,具体用什么需要根据实际情况而定,比如预算,app注重功能还是内容等。
- 原生app(native app)
原生app是基于操作系统的开发,比如安卓,ios,windows phone,他们只能在各自的操作系统上运行。
优点:
- 可以访问操作系统,获取更多的资源(gps,摄像头,传感器,麦克风等)
- 速度快,性能高,用户体验好
- 可以离线使用
缺点:
- 开发成本高
- 需要安装和更新,更新与发布需要审核。
- 混合app(Hybrid app)
Web应用使用H5C3开发页面,为浏览器设计的基于web的应用,可以在各种智能设备的手机浏览器上运行。不需要安装即可运行。
优点:
- 支持设备广泛
- 开发成本低(使用)
- 可以随时上线与更新,无需审核
缺点:
- 用户体验极度依赖网速
- 要求联网
- 无法获取手机的资源(gps,摄像头)
- web应用(webApp)
Hybrid App是指介于web-app、native-app这两者之间的app,它虽然看上去是一个Native App,但只有一个UI WebView,里面访问的是一个Web App。(淘宝、京东、手机百度)
Hybird App说白了就是使用了Native app的壳,里面其实还是HTML5页面。
优点:
- 开发成本和难度更低,兼容多个平台
- 也可以访问手机的操作系统资源。
- 更新维护更方便
缺点:
- 用户体验相比原生app稍差。
- 性能依赖于网速
屏幕与分辨率
屏幕尺寸
通常我们所指的屏幕尺寸,实际上指的是屏幕对角线的长度(一般用英寸来度量)
1英寸 = 2.54厘米
屏幕分辨率
分辨率则一般用像素来度量,表示屏幕水平和垂直方向的像素数,例如1920*1080指的是屏幕垂直方向和水平方向分别有1920和1080个像素点而构成。
像素:指计算机显示设备中的最小单位,即一个像素点的大小。每一个像素点可以理解为就是屏幕上的一个发光点。
像素密度ppi
PPI(Pixels Per Inch)值来表示屏幕每英寸的像素数;利用 勾股定理 我们可以计算得出PPI
ppi=根号下(横向像素数平方+纵向像素数平方)/屏幕尺寸(对角线英寸)
PPI值的越大说明单位尺寸里所能容纳的像素数量就越多,所能展现画面的品质也就越精细,反之就越粗糙。
结论:当PPI 越大,展示的画质越精细。
设备独立像素
随着技术发展,设备不断更新,出现了不同PPI的屏幕共存的状态,给我们开发带来的问题;
做为用户是不会关心这些细节的,他们只是希望在不同PPI的设备上看到的图像内容差不多大小,所以这时我们需要一个新的单位,这个新的单位能够保证图像内容在不同的PPI设备看上去大小应该差不多,这就是独立像素,也叫(设备无关像素),在IOS设备上叫PT,Android设备上叫DP,在css中,叫PX。
获取设备的像素比:window.devicePixelRatio
物理像素与独立像素的比值
在css中设置宽高,用px单位后,会自适应各种ppi屏幕;然后通过视口来缩放实际大小;
window.devicePixelRatio;
物理像素与独立像素的比值;获取设备的像素比,电脑是1
逻辑分辨率
2倍图与3倍图
以后同学在工作的过程中,从UI那拿到的设计图通常都是640的设计图或者是750的设计图.
把更多的像素点压缩至一块屏幕里,从而达到更高的分辨率并提高屏幕显示的细腻程度。
设备像素比devicePixelRatio:即像素的压缩比例
结论 :在移动端为了在高清屏手机上显示得更加细腻,通常会使用更大的图片,比如2倍图或者3倍图。
视口viewport
问题:一个电脑上的网站,在手机端访问,效果是什么样的?
iPhone5的设备宽度只有320px,一张宽度为640px的图片在手机端访问,显示的效果是什么?
- 在手机端,html的大小都是980px,为什么?
- 这主要是历史原因导致的,因为在移动设备刚流行的时候,网站大多都是pc端的,pc端的页面宽度一般都比较大,移动设备的宽度比较小,如果pc端页面直接在移动端显示的话,页面就会错乱。为了解决这个问题,移动端html的大小直接就定死成了980px(因为早起的pc端网站版心就是980px居多)。
- 视口
- 在pc端,html的大小默认是继承了浏览器的宽度,即浏览器多宽,html的大小就是多宽,但是在移动端,多出来了一个视口的概念(乔布斯),视口说白了就是介于浏览器与html之间的一个东西,视口的宽度默认定死了980px,因此html的宽度默认就是980px,视口的特点是能够根据设备的宽度进行缩放。
- 视口设置。
- 对于现在的移动端页面来说,视口默认为980px肯定不合适,因为设备宽度不够的话,视口会进行缩放,导致页面展示效果不好看。
视口参数
1 | //width 设置视口的宽度 |
流式布局
移动端的特点
- 手机端的兼容性问题比PC端小很多,因为手机端的浏览器版本比较新
- 手机端屏幕比较小,能够放的内容比较少。
问题:布局的时候怎么解决屏幕大小不一致的问题?
- PC端,固定版心,让所有分辨率的电脑的版心都是一样的,比如京东
- 移动端:移动端无法设置版心,因为移动端的设备屏幕本身就小,设置版心不合适。因此移动端大多会采用流式布局(百分比布局)
流式布局,也叫百分比布局,是移动端开发中经常使用的布局方式之一。
流式布局的特征:
- 宽度自适应,高度写死,并不是百分百还原设计图
- 图标都是固定死大小的,包括字体等也是固定死的。并不是所有的东西都是自适应的。
- 一些大的图片,设置宽度为百分比自适应即可,随着屏幕大小进行变化
流式布局无法做到所有设备都非常逼真的还原设计图,有些设备显示效果不是特别的好看。但是流式布局是移动端非常常用的一种布局方式,比较简单,需要掌握(携程、京东)
经典的流式布局:
- 左侧固定,右侧自适应
- 右侧固定,左侧自适应
- 两侧固定,中间自适应(圣杯布局,双飞翼布局)
- 等分布局
- 浮动的盒子要先渲染出来,自适应的盒子不能写宽度,后渲染,用overflow: hidden;
BFC 块级格式上下文
BFC:块级格式化上下文,Block formatting context;
BFC:块级格式上下文,独立的盒子,不允许子元素去影响到外界的元素;
触发bfc的条件:
float
的值不为none。overflow
的值为auto,scroll或hidden。display
的值为table-cell, table-caption, inline-block中的任何一个。position
的值不为relative和static。
清除浮动的方法
- 父盒子定高
- 额外标签法
- 使用伪元素 单伪元素 双伪元素
- clear: both;–图像的左侧和右侧均不允许出现浮动元素;
overflow:hidden
触发了bfc
1 | .clearfix:after { |
浮动与定位元素:默认是在元素原先的位置上进行的。
重绘与回流(重排)
重绘与回流相关概念
回流(reflow)与重绘(repaint),在性能优化的时候,经常会提起,因为涉及到浏览器底层的渲染,所以掌握的童鞋并不多,但是面试经常被提及。而且在解决一些bug上,也能派上用场。
在讨论页面重绘、回流之前。需要对页面的呈现流程有些了解,页面是怎么把html结合css等显示到浏览器上的,下面的流程图显示了浏览器对页面的呈现的处理流程。可能不同的浏览器略微会有些不同。但基本上都是类似的。
- 解析HTML以构建DOM树 浏览器把获取到的HTML代码解析成1个DOM树,HTML中的每个标签都是DOM树中的1个节点。
- 解析css样式:浏览器把所有样式(用户定义的CSS和用户代理)解析成样式结构体 ,在解析的过程中会去掉浏览器不能识别的样式,比如IE会去掉-moz开头的样式,而FF会去掉_开头的样式。
- 构建渲染树:DOM Tree 和样式结构体组合后构建render tree,render tree不同于DOM树,render tree能识别样式,render tree中每个NODE都有自己的style,而且 render tree不包含隐藏的节点 (比如display:none的节点,还有head节点),一旦render tree构建完毕后,浏览器就可以根据render tree来绘制页面了。
- 布局渲染树:从根节点递归调用,计算每一个元素的大小、位置等,给每个节点所应该出现在屏幕上的精确坐标。 +
- 绘制渲染树:遍历渲染树,每个节点将使用UI后端层来绘制。
重绘(repaint)
当元素的样式属性改变,这些属性值影响自己,不会改变布局和其他元素,就会重绘,比如背景颜色;
回流(重排)(reflow)
当元素的样式属性改变,这些样式属性会改变布局和其他元素时,就会回流;比如大小,位置等;
每个页面至少会又一次回流+重绘;
- 添加或者删除可见的DOM元素;
- 元素位置改变;
- 元素尺寸改变——边距、填充、边框、宽度和高度
- 内容改变——比如文本改变或者图片大小改变而引起的计算值宽度和高度改变;
- 页面渲染初始化;
- 浏览器窗口尺寸改变——resize事件发生时;
【回流必然会重绘;】
聪明的浏览器
1 | var s = document.body.style; |
从上个实例代码中可以看到几行简单的JS代码就引起了6次左右的回流、重绘。而且我们也知道回流的花销也不小,如果每句JS操作都去回流重绘的话,浏览器可能就会受不了。所以很多浏览器都会优化这些操作,浏览器会维护1个队列,把所有会引起回流、重绘的操作放入这个队列,等队列中的操作到了一定的数量或者到了一定的时间间隔,浏览器就会flush队列,进行一个批处理。这样就会让多次的回流、重绘变成一次回流重绘。
回流队列:等到数量或者时间满足时回流;
必然引起回流的属性,提前刷新回流队列
虽然有了浏览器的优化,但有时候我们写的一些代码可能会强制浏览器提前flush队列,这样浏览器的优化可能就起不到作用了。当你请求向浏览器请求一些 style信息的时候,就会让浏览器flush队列,比如:
- offsetTop offsetLeft offsetWidth offsetHeight
- scrollTop / Left / Width / Height
- clientTop / Left / Width / Height
- width height
- 请求了
getComputedStyle()
, 或者 IE的currentStyle
优化性能
减少回流与重绘的次数,就需要简单对渲染树的操作。
- 直接使用className修改样式,少用style设置样式
- 让要操作的元素进行”离线处理”,处理完后一起更新
- 使用
DocumentFragment
进行缓存操作,引发一次回流和重绘 - 使用
display:none
技术,只引发两次回流和重绘;
- 使用
- 将需要多次重排的元素,position属性设为absolute或fixed,这样此元素就脱离了文档流,它的变化不会影响到其他元素为动画的 HTML 元素,例如动画,那么修改他们的 CSS 是会大大减小 reflow 。
- 完成功能是前提,在完成功能的情况下想着优化代码
touch事件
- 移动端新增的4个事件,PC端无效(触摸屏?)
- touchstart 手指触到触摸屏上触发
- touchmove 手指在触摸屏上移动时触发
- touchend 手指离开触摸屏时触发;由于手指离开,所以只能通过
e.changedTouches
来获取手指离开时的位置; - touchcancel 系统取消触摸事件时触发,譬如电话来了,弹出去用来设置暂停;
touch事件对象
e.touches
记录当前屏幕上的手指数量,是一个伪数组;e.targetTouches
记录当前元素上的手指数量,是一个伪数组;e.changedTouches
记录触摸时发生改变的手指;是一个伪数组;touchend事件手指离开时,e.touches
和e.targetTouches
没有手指记录;- 3个手指信息里包含:
- clientX / clientY 触摸点位于浏览器窗口的位置
- pageX / pageY 触摸点位于页面的位置
- screenX / screenY 触摸点位于屏幕的位置
IScroll插件的使用
- 支持jQuery,也支持原生JavaScript;
new IScroll("父盒子")
–子盒子滚动要嵌套在父盒子里;子盒子要比父盒子大;- 如果有图片的高度要计算,需要等待图片加载完成–load事件;
Zepto类库
- Zepto主要应用于移动端;
- Zepto比jQuery轻量;
- Zepto功能比jQuery少;
- Zepto新增了touch相关事件,使用touch事件封装的;
- click事件在移动端会有300ms的延迟
- 判断用户是否双击,(07年提出双击放大)
- Zepto的tap事件不会延时;
- 设置视口click不会有延时;
响应式布局
响应式布局的概念
响应式布局(respond layout)是Ethan Marcotte在2010年5月份提出的一个概念,简而言之,就是一个网站能够兼容多个终端(手机、平板、pc电脑、手表) ——而不是为每个终端做一个特定的版本。这个概念是为解决移动互联网浏览而诞生的。
为什么要有响应式布局?
- 在移动互联日益成熟的时候,在PC端开发的网页已经无法满足移动设备的要求。
- 通常的做法是针对移动端单独做一套特定的版本。
- 如果终端越来越多,那么需要开发的版本就会越来越多(大屏设备的普及)
- 响应式布局 :一个网站能够兼容多个终端(节约开发成本)
优点:
- 面对不同分辨率设备灵活性强
- 能够快捷解决多设备显示适应问题
缺点:
- 兼容各种设备工作量大,效率低下
- 代码累赘,会出现隐藏无用的元素,加载时间加长
- 其实这是一种折中性质的设计解决方案,多方面因素影响而达不到最佳效果
- 一定程度上改变了网站原有的布局结构,会出现用户混淆的情况
响应式开发现状:
- 如果已经存在PC的网站了,那么一般不会使用响应式开发,而是针对移动端再开发一套系统(比如京东、淘宝)
- 在新建站点 上采用响应式开发的越来越多。
- 在国内,响应式开发还不是特别的流行。但响应式开发是大势所趋,会越来越流行。
响应式布局
- 一个网站兼容不同终端;
- 根据不同的屏幕大小来设置不同的样式;
- 通过JS来判断实现;
- 媒体查询,css3新增属性
媒体查询
1 | <!-- |
响应式开发的原理:使用媒体查询实现不同终端的布局和样式的切换。
媒体查询语法:
1 | /*查询屏幕*/ |
弊端:现在只有一个div,要做一套响应式布局,就需要如此多的代码,非常的麻烦,因此我们会更多的借助一些响应式的框架,比如bootstrap。
@media screen and (min-width:970px) and (max-width:1200px) {};
- 所有中间用空格隔开;
@media
表示媒体查询;screen
表示查询屏幕宽度;min-width:970px
屏幕大于这个值生效;max-width:1200px
屏幕小于这个值生效;- screen 和第一个 and 可以省略;
bootstrap框架
Bootstrap,来自 Twitter,是目前很受欢迎的前端框架。Bootstrap 是基于 HTML、CSS、JAVASCRIPT 的,它简洁灵活,使得 Web 开发更加快捷。
基于jQuery的框架
bootstrap中文网:http://www.bootcss.com/
特点:
- 组件简洁大方、代码规范精简、界面自定义性强。
- Bootstrap是基于HTML5和CSS3开发的,它在jQuery的基础上进行了更为个性化和人性化的完善,形成一套自己独有的网站风格,并兼容大部分jQuery插件。
- Bootstrap中包含了丰富的Web组件,根据这些组件,可以快速的搭建一个漂亮、功能完备的网站。
优点:
- 有自己的生态圈,不断的更新迭代
- 提供了一套简洁、直观、强悍的组件
- 标准化的HTML+CSS编码规范
- 让开发更简单,提高了开发效率。
- 扩展性强,虽然界面组件样式已经定义好了,我们还可以自定义,修改默认样式。
版本:
- 2.x.x 停止维护
- 优点:兼容性好
- 缺点:代码不够简洁、功能不够完善
- 3.x.x 目前使用最多
- 优点:稳定,偏向于开发响应式布局,移动设备优先的WEB项目
- 缺点:放弃了IE67,对IE8支持但是界面效果不友好
- 4.x.x 测试阶段
CSS reset 和 normalize.css
- CSS reset:干掉所有的浏览器默认样式,需要使用时自己设置;
- normalize.css:统一所有浏览器的样式,保留了一些默认样式;
- 官网:http://necolas.github.io/normalize.css/
- Normalize.css与CSS reset区别:http://www.cnblogs.com/webpush/p/4974063.html
Normalize.css是一种CSS reset的替代方案。经过@necolas和@jon_neal花了几百个小时来努力研究不同浏览器的默认样式的差异,这个项目终于变成了现在这样。
normalize的特点:
- 保护有用的浏览器默认样式而不是完全去掉它们
- 一般化的样式:为大部分HTML元素提供
- 修复浏览器自身的bug并保证各浏览器的一致性
- 优化CSS可用性:用一些小技巧
Normalize.css支持包括手机浏览器在内的超多浏览器,同时对HTML5元素、排版、列表、嵌入的内容、表单和表格都进行了一般化。尽管这个项目基于一般化的原则,但我们还是在合适的地方使用了更实用的默认值。
.container
类用于固定宽度并支持响应式布局的容器。
.container-fluid
类用于 100% 宽度,占据全部视口(viewport)的容器。
.row
用来抵消 .container
的 padding(15px)
;
栅格系统:.col-XX-YY
- XX:表示在多大屏幕下生效;
- lg:大屏幕生效,1200px以上
- md:中屏及大屏生效,992px以上
- sm:小屏及中屏、大屏生效,768px以上
- xs:超小屏及小屏、中屏、大屏生效,<768px
- 根据渲染顺序生效;bootstrap的css样式是从大到小,依次向下;
- YY:表示占多少格,总共12格;
- 推荐从小往大写;
可以删除的属性
aria
src-only
role
Less
Less简介
Less 是一门CSS预处理语言,它扩展了CSS语言,增加了变量、Mixin、函数等特性。
Less不是取代CSS的,是在CSS的基础上加入了程序语言的特性,具有可编程性;
浏览器不直接识别less文件,浏览器只识别css文件,所以我们写了less文件之后,我们需要预先把less文件转换成css文件。
本质上,LESS 包含一套自定义的语法及一个解析器,用户根据这些语法定义自己的样式规则,这些规则最终会通过解析器,编译生成对应的 CSS 文件。LESS 并没有裁剪 CSS 原有的特性,更不是用来取代 CSS 的,而是在现有 CSS 语法的基础上,为 CSS 加入程序式语言的特性。
less仅仅是写css的另一种方式,写出来的less文件浏览器也不识别,所以啊,我们写完了less文件,还需要通过less解析器解析成css,最终浏览器引入的还是css文件。
node.js的安装
在cmd命令行中输入 node -v
以及 npm -v
查看是否安装成功
在cmd命令行中输入以下代码:需要联网
1 | npm install -g less |
Less的使用
浏览器不能识别Less文件,需要编译成为CSS文件;
- 1.引入JS文件,让浏览器来编译Less文件
- 需要多引入一个less.js文件
- 需要多一次http请求,file协议打开无效
- 如果浏览器禁用了js,那么无法生效
- 无法实时的看到编译的结果。
- 2.node.js
- 使用lessc命令:
lessc index.less index.css
- 使用lessc命令:
- 3.配置WebStorm
- 需要node环境
- 需要安装lessc命令
- webStorm替代我们执行了lessc命令
- 设置
1 | Program:点击路径选择自动找到; |
- 4.VsCode
- 安装easy less插件
- 默认编译在同级目录,可以设置目录
1 | // 设置为与less文件夹同级目录; |
- easy less不编译文件设置
- 有时候我们会将多个less文件导入到一个less文件中,有些less文件是不需要编译的;
- 在不需要自动编译的less文件第一行
// out: false
- 插件会识别解析第一行注释,不编译此less文件
- 5.使用考拉
Less的语法
Less变量:
@变量名:变量值;
直接使用 @变量名
;
1 | @charset "UTF-8"; |
Less注释
1 | // Less的注释,CSS不认识,不会编译到CSS文件中; |
mixin混入
可以直接使用其他类的样式;其他的类也会被编译到CSS文件中;
1 | @charset "UTF-8"; |
编译后的css
1 | @charset "UTF-8"; |
缺点:写了很多类,但是都编译到css文件中了,其实我们需要的仅仅是.my_btn这一个类。
Less函数
Less函数不会被编译到CSS文件中;
1 | .btn() { |
不带参数的函数;
1 | @charset "UTF-8"; |
带参数的函数;使用时必须要传递参数;
1 | .btn_border(@width) { |
带默认值的函数;不传递参数使用默认值,传递参数覆盖默认参数;
1 | .btn_border(@width:1px) { |
Less嵌套
我们可以在一个选择器中嵌套另一个选择器来实现继承,这样很大程度减少了代码量,并且代码看起来更加的清晰。
语法
1 | .father { |
&表示自己(相当于this?)
Less导入
1 | @import "header.less" |
Less运算
支持数值的数学运算;
提供了多种数学相关的方法;http://www.1024i.com/demo/less/reference.html
REM
rem和em的区别
- rem(font size of the root element)是指相对于根元素的字体大小的单位。它就是一个相对单位。
- em(font size of the element)是指相对于当前元素的字体大小的单位。它也是一个相对单位。
- 它们之间其实很相似,只不过计算的规则一个是依赖根元素,一个是当前元素计算。
rem的作用
rem主要用来解决不同大小屏幕的适配,用来等比例适配所有屏幕;
布局的三种方式
由于市面上手机种类繁多,导致移动端的屏幕种类非常的混乱,比如有常见的320px 360px 375px 384px 480px 640px等。在开发中,美工一般只会提供750px或者是640px的设计稿,这就要求我们通过一张设计稿能够适配所有的屏幕。通常解决方案如下:
- 流式布局(百分比布局)
- 虽然可以让各种屏幕都适配,但是显示效果不是非常的友好,因为只有几个尺寸的手机能够完美的显示出来视觉设计师和交互最想要的效果。但是目前使用流式布局的公司非常多,比如 亚马逊 、京东 、携程
- 响应式布局
- 响应式布局:响应式这种方式在国内很少有大型企业的复杂性的网站在移动端用这种方法去做,主要原因是工作大,维护性难 。所以一般都是中小型的门户或者博客类站点会采用响应式的方法从PC端页面到移动端页面以及web app直接一步到位,因为这样反而可以节约成本。
- rem布局
- rem能够适配所有的屏幕,与less配合使用效果会更好。目前使用rem布局的有:淘宝 、 苏宁
rem如何设置
在UI给出设计图后,根据UI的图的宽度,设置基准;
例如:
1 | /* 宽度为750的设计图,设置基准为100; */ |
计算方法:基准值 / 设计图宽度 = 屏幕的font-size / 屏幕的大小
1 | /* 100 / 750 = X / 640 ===> X = 100 / 750 * 640 */ |
- 根据设计图切图的尺寸直接除以基准值,元素的大小,直接就可以写成 rem为单位
实际切图大小 / 基准值 = Yrem
- 好处:不需要再计算倍图的比例,直接除以基准值即可;
- less的写法:
width: 实际大小rem(不要写px,直接写rem)/基准值(一般用@base表示);
rem布局
rem是根据根元素(html)的字体大小来设置元素的大小;
因为rem的基准点是根元素html的字体大小,因此我们只需要设置不同屏幕的html的font-size大小不一样就可以达到不同屏幕的适配了。
使用媒体查询来改变html的font-size;
搭配less设置媒体查询的条件
css媒体查询样式,缺点需要自己计算每个屏幕的值;
1 | @media (min-width: 320px) { |
搭配less可以使用数学运算来计算;
1 | //给不同屏幕的html设置不同的fontSize |
自己设置js
1 | //注意:设置fontSize的这一段js需要放到body的前面,目的:在所有的标签加载之间就应该先把html的字体大小给确定了。 |
- 优点:直接适配所有的终端
- 缺点:必须在页面加载之前设置html的font-size值,不然会出现文字大小调动的情况。
引用flexible.js
原理是把设计图分成10等份,所以基准值为设计图的1/10即可;
设计图大小不同,基准值也不相同;
【使用时,直接根据设计图的大小来确定基准值,基准值 = 设计图宽度 / 10
】
rem = 实际值 / 基准值
rem布局 flexible.js
- 淘宝工程师开发的,
<head></head>
内引用js即可; - 原理是把设计图分成10等份,所以基准值为设计图的1/10即可;
基准值 = 设计图宽度 / 10
- 不用考虑2倍图,3倍图,直接(量取数值/基准值)rem即可;
rem = 实际值 / 基准值
- 背景图,如果自适应,所有的单位都要用rem,精灵图的定位,精灵图的大小;
布局的注意内容
- a img标签最好设置为块元素,img宽度:
width:100%
; <input type="number">
可以自动生成上下增减数字的功能,框内只能输入数字;- 苹果系统(ios)不识别时间中的
-
,需要使用,来生成时间格式; <input type="search">
搜索框默认盒模型为box-sizing:content-box
;
Swiper插件
Swiper插件:轮播图的专业插件
支持PC和移动端的轮播图插件;
可以独立使用,也支持jQuery和Zepto;