CSS书写风格

  • 评论关闭

ChromeV.46中新增网络带宽模拟属性

使用chrome的同学应该记得在调试APP时,使用的“device mode”切换图标,当调整到终端模式下,chrome显示的设备模拟属性区域,如下:

这里提供了10个不同网络状态的选项,你可以分别进行测试,并找出性能瓶颈。

在V.46这个版本中chrome把这一属性扩展到了PC端,而不仅仅是移动终端,同样提供了是个选项,但是你还可以自我定义新的网络环境,

对于响应式站点的测试会带来小的帮助,升级吧,小伙伴们。

图片来源:https://css-tricks.com/

  • 评论关闭

@font-face 支持广度测试

本文来自“http://naradesign.net/css3/font-face/” 有兴趣的可以直接看原文,此处只做简单的搬运转译:

字体在不同平台上有着不同的格式,在浏览器测也有不同的支持标准。总体来说在规范性上在逐步的朝着统一的进步,但是还需要很远的路。

这里的测试用例,把不同格式的字体在浏览器(覆盖pc、mac、mobile)上的支持进行了总结,希望对web开发工程师有一定的帮助(特别是需要使用到字体图标之类的情况)

EOT格式字体

支持IE6-9,不支持chrome、firefox、safari、opera,不建议

 media query中的EOT字体表现

支持IE6-8,不支持chrome、firefox、safari、opera、IE9,不建议

WOFF字体格式

支持chrome、firefox、safari、opera、IE9, 不支持IE6-8,不建议

 media query中的WOFF格式字体

支持chrome、firefox、safari、opera, 不支持IE6-9,不建议

 WOFF+EOT格式字体分别设置在不同的“@font-face”属性中

支持 Chrome, Safari, Firefox, Opera and IE 6~9,但是在IE下会同时下载所有字体文件,会引起不好的体验感观,不建议

 media query中不同的“@font-face”属性  WOFF+EOT格式字体

支持 Chrome, Safari, Firefox, Opera and IE 6~8,不支持IE9+,IE6-8会同时下载所有字体文件,不建议

 WOFF+EOT 字体格式设置在一个@font-face属性中

支持 Chrome, Safari, Firefox, Opera and IE 6-9,建议使用

 media query下WOFF+EOT 字体格式设置在一个@font-face属性中:

支持Chrome、Safari、Firefox、Opera、IE 6~8,不支持IE9+,不建议

下面我们来看看 bootstrap 3.0.0 之后引入的”Glyphicon Halflings”图标字体,看看它是怎么引入的:

这里分别引入了EOT、WOFF、TTF、SVG四种格式的字体文件:

正如上面分析的,引入字体统一放到一个“@font-face”属性下,这里除了EOT+WOFF外还增加了TTF、SVG格式的字体,为什么?

iOS Mobile Safari3.2+ 支持 SVG 格式;iOS Mobile Safari4.2+ 支持TTF,这样覆盖面就全了,即使在响应式条件下,不同设备上的浏览器上都能进行展示。

再看看著名的字体图标库:Font-Awesome

Font-Awesome4.4版本在上面的基础上增加了 WOFF2 字体格式,这个又是一个什么新奇事物?

来自百度的解释:Web开放字体格式(Web Open Font Format,简称WOFF)是一种网页所采用的字体格式标准。此字体格式发展于2009年,现在正由万维网联盟的Web字体工作小组标准化,以求成为推荐标准。此字体格式不但能够有效利用压缩来减少档案大小,并且不包含加密也不受DRM(数位著作权管理)限制。

W3C推出这个版本的字体就是为了在不同的浏览器上进行统一的字体展示,杜绝太多各自为阵的字体设置,减少开发难度。该草案基于广泛使用的WOFF 1.0,提供增强的字体压缩功能,减少网络带宽的使用,同时WOFF 2.0仍将支持在移动设备等上的快速字体解压缩能力。WOFF 2.0结合了内容感知(content-aware)的预处理过程,以及改进的熵编码(entropy coding)技术,比WOFF 1.0采用的Flate压缩技术具有更好的性能。

大势趋同,至繁则简,在字体这条路上还有很长的路要走,共勉。

  • 评论关闭

前端工具集

今天收拾电脑的时候,发现了以前做的一个小工具,感觉还有那么一点用,打了个一个包分享出来。里面的代码基本上都是网上已有的,整合了一下,以后可能还会加入一些新的功能。

下载地址如下:

百度云

360云盘(提取码:e674)

  • 评论关闭

新品发布-番茄钟

番茄工作法是简单易行的时间管理方法。番茄工作法是弗朗西斯科·西里洛于1992年创立的一种相对于GTD更微观的时间管理方法。在番茄工作法一个个短短的25分钟内,收获的不仅仅是效率,还会有意想不到的成就感。

番茄钟是什么呢?基于什么样的理论基础?请这里:番茄工作法

从开始建立开发环境到10号发布V 1.0.0,三人团队在开发过程中经历了界面布局、设计、交互方式,团队协作、进度把控、A/B测试、内部测试等一系列细微的发酵,终于这份饕鬄盛宴摆上了大家的手机桌面。虽然时间不长,但是我们做得很用心,app中的每一个细节都包含了我们的想法。尽量地梳理其中的操作流程、信息提示做到清晰明了,入手门槛低,有一份真情的实用,并带着一点的娱乐。欢迎大家在使用过程中反馈你们遇到的问题;如果你有好的idea也可以提交给我们。

番茄钟可以帮助你把握明天的方向,珍惜今日的时光,专注当下的时间,找到最好的自己。番茄钟非常适合拖延症患者、白领、学生、上班族、程序员、设计师、文字工作者等等人群,可有效提升工作效率,加倍增强执行能力,在吃完一个又一个番茄之后,你将获得满满的成就感和幸福感。

番茄钟1.0版本提供如下功能:

  • 计划管理
  • 今日事管理
  • 日志查看
  • 精致的番茄计时器
  • 蕃茄数统计
  • 其他辅助功能(设置、关于、远景、帮助)

安装要求:
Android4.0以上版本

V1.0版本下载:

tomato 1.0

  • 评论关闭

chrome开发者工具调试响应式设计【二】

这是“chrome开发者工具调试响应式设计【一】:PC 版 chrome 开发者工具模拟器调试”的第二节,主要内容是补充web app和网页版应用的远程调试方法,解决一些在真机上才能复现的特殊bug问题,让我们直接切入主题:

在PC版chrome32版本开始,google提供了一个实用的设备直连调试工具,类似于我们在开发android原生应用是使用到的SDK工具。通过“菜单->工具->检查设备” 或则在地址栏输入 “chrome://inspect/” 进入到调试工具面板:

可以看到,这里提供了:Devices、Pages、Extensions、Apps、Shared workers、Other 7个子功能,来看看他们各自的作用呢。

请确保您的手机和电脑通过USB正常连接;手机上开启了USB链接调试功能;手机浏览器正常打开;手机保持和电脑处在同一个可以互相访问的网络环境中;Android chrome版本是32+;PC chrome 32+;国内用户具备翻墙的能力。

Device 设备

在这个子菜单中将会完成我们大部分工作,从发送页面到移动终端,到调试平台,都能实现。

点击“Discover USB devices”,直连我们的移动设备,当设备正常保持USB连接时,浏览器会自动生成一个唯一的设备标示ID:“#4Dxxxxxxxxxxx07D”,并注明设备状态(此时是Offline),同时设备上会自动弹出“是否允许USB调试”确认框,点击“确定”即可。

在确定后,chrome将会自动与设备建立联系,识别出设备的型号,并给出调试页面地址输入框,如下:

这里给出了设备型号“GT-9500”,android chrome 33.0.1750.136版本,转发端口8080,如果你的机子上8080端口被占用,你可以通过“Port forwarding”进行调整(这里不细说了)。

在输入框中输入调试页面地址,点击“open”,移动设备就会自动地在新标签中打开此页面(我们这里以bootstrap 2.3 –http://twitter.github.com/bootstrap/index.html)

点击其中的“respect”,PC chrome会自动弹出调试窗口,在其中会呈现在pc端熟悉的调试场景,后续的工作就看你自己的了

(这里采用了google官方的一张图片,写稿时没能进行翻墙操作,respect出来是一片空白窗口)

Pages 页面:

在个子菜单中列出了PC chrome上打开的所有标签页面,也可以通过“respect”按钮直接调出开发者工具进行pc上面的调试(和主题关系不大,不做详细说明)

Extensions 扩展:

这里和Pages子菜单类似,只不过是列出了PC chrome扩展的信息,同样的“respect”,同样的调试方法。

APP chrome应用:

同上

Share workers 协同工作者:

这个功能还没有细究过,等空了看看使用场景和方法,再做补充。

Other 其他:

一片空白,不知道干嘛的,等空了再看看

DevTool 官网

5步解决移动设备上的300ms点击延迟【译】

原文:5 Ways to Prevent the 300ms Click Delay on Mobile Devices

作者:Craig Buckler

译者:jmouse

大多数基于触摸的浏览器设备,在点击时都会有个 300ms 的事件触发等待时间,做过 web app 开发的同学应该都遇到过这个情况,通过下面的5步可以轻松搞定这个延迟。虽然解决方法网上早就出来了,但是看到这篇文章是还是忍不住想翻译分享出来,系统地给大家一个解决思路。

这个 300ms 为什么会被设计出来呢?原因在于单击后面还有个双击缩放动作,这个涉及到触摸设备的手势交互行为原生设计,在平台提供商比如苹果和 google ,本意是通过 300ms 来区分两者之间的不同行为,单击一次等待 300ms 后没有再次单击那么就会触发缩放等双击行为。本意是好的,正常的逻辑实现,但是在现实的应用场景中,用户往往会觉得 web app 的事件触发不是那么灵敏,有那么一点延迟,那么我们如何避开这个特殊的300ms呢。

1、不要太纠结于此

是否能接受这 300ms 的时间延迟,往往取决于你的应用和目标受众,比如:如果是个内容为主,并且菜单较少的应用,那么用户在阅读上花费的事件远远大于在菜单上消耗的事件,这种情况下 300ms 是完全可以接受的,并且没有 300ms 延迟的体验并不会好很多。分析你的应用判断是否需要解决这个不是问题的问题,在做结束抉择。

2、禁用缩放 (chrome 和 firefox)

在 chrome 和 firefox 的移动版本中,如果禁用了页面缩放,那么着 300ms 的延迟就会自动消失,具体代码如下:

或则:

但是这一方案在 safari 上并不起作用,还会降低有视觉或运动障碍用户的可访问性。

3、设置 viewport 的 device-width (chrome 32+)

在 chrome 32+ 中,如果设置了 viewport 的宽度小于或等于物理设备的宽度,那么也会达到禁用缩放的效果。

注意:这里的最大缩放比与上面meta中的值并不一致,这个是关键点

 4、使用指针事件 (IE10+)

微软已经针对触摸问题发布了具体的规范,例如:在你滚屏的时候 pointerup 事件并不会被触发。

这儿有一个非标准的 CSS 触摸 action 属性,它允许你移除特定元素或整个文档的触发延迟,而无需禁用缩放:

 5、使用 touchend 事件处

不同于 click 和 touchstart,touchend 没有这个 300ms 的延迟,而是即时触发,你完全可以在 WebGL 或 canvase 游戏中进行实践,但是在web 页面中单单使用 touchend 并不一定靠谱。

  • 如果用户在两个不同元素之间触发了 touchstart 和touchend,那么 click 不会被触发
  • 如果用户触发了 touchstart ,但是在touchend之前是一个长长的 touchmove 滚动,那么 click 也不会被触发
  • 在站点上任然应该保留 click 事件以兼容那些非触摸设备,这是你就要考虑事件的重复触发问题

已有同行为我们封装了部分解决方法:

  • FastClick 来至于FT实验室的一个插件,仅仅只有10kb,但是能解决上面的2-4步
  • Tappy 来自于Filament Group,仅仅1kb,概念上类似于上面的指针事件

问题:当你为多个元素进行这些事件绑定时,有可能出现性能的损耗

是否有完美的解决方案呢?

是否需要解决 300ms 在于自己的判断,300ms被设计出来是有特定的用途,上面的meta属性中进行了设定,在chrome和firefox下能起作用,希望其他厂商也能尽快提供这类支持。touch-action: manipulation 这个css属性能把风险降到最低,虽然现在只有微软支持,但是作为W3C规范和HTML5test的一部分,因此也许我们并不需要等待太久。

 

 

  • 评论关闭

chrome开发者工具调试响应式设计【一】

随着智能手机以及pad类终端设备的普及,用户对一个产品的使用通常通过以下几种途径:

  • 产品native APP,通过安装此产品开发的app来访问服务,通常应用提供者需要对应用进行特定梳理,适配终端类特性和交互方式,再针对几个系统平台进行分别开发不同的app进行分发,开发周期往往比较长,不同系统平台的体验不一致
  • hybird APP:通过html5+css3技术开发页面,做好适配,使用浏览器外壳进行封装,典型的是使用phonegap之类的封装应用,这类app开发快速,升级方便,但是面临本次资源的加载速度和app之间的衔接,独立的app特性总让各个应用app之间显得格格不入,最多的就是分享之类的交互
  • 移动端网站访问:通过和PC端一样的访问方式,以页面的方式呈现,唯一的要求是界面的移动终端优化,通过响应式设计来匹配不同终端的访问体验,在几个方案中成本是最低的,也填补了这一部分的运营空白。

这篇文章中主要表达的是移动终端网站的响应式开发调试,以达到移动网页在不同设备上能提供完美的体验。响应式设计的过程在此不做描述,如果需要了解,请参见《响应式web设计—HTML5和CSS3实战》、《简单的响应式设计指南

调试部分分为两节:

  1. chrome开发者工具调试响应式设计【一】:PC 版 chrome 开发者工具模拟器调试
  2. chrome开发者工具调试响应式设计【二】【未发布】: PC 版 chrome 开发者工具远程调试

当你的响应式页面已经静态demo开发完成,如何验证页面在这些主流的手机终端上是否完全按照你的意愿进行展示呢?chrome 开发者工具提供了这么一套解决方案,通过内置的仿真器进行逐个测试,并实时修改样式进行优化,具体的流程如下:

:此处演示的系统为window 7 64位旗舰版;chrome版本 33.0.1750.154;调试站点:bootstrap 2.3.2

1、在控制台中开启仿真模拟器设置

使用 F12 或则 ctrl+shift+i 打开 chrome 的开发者工具面板,点击右上角的设置按钮进入设置面板,在 General 面板下有个 Appearance设置,勾选其中的 “Show ‘Emulation’ view in console drawer.”,开启仿真模拟器设置

开启仿真模拟器

在开发者工具面板中使用 ESC 或则点击右上角的 “ hide drawer ” 按钮,将在面板下发显示如下栏目:

仿真模拟器面板

2、使用仿真模拟器

在 Emulation 下有这么几个子菜单:Device、Screen、User Agent、Sensors,这几个子菜单中所包含的属性选项在测试常用的界面展示上已经完全够用,通过不同的搭配,可以就你想测试的方面进行单独模拟,完美解决界面适配问题。

Device 设备子菜单

 在设备中列出了40多种常见设备,各种分辨率几乎都包含,选择其中一种设备,以S4为例,点击 “Emulate” ,当前页面就会自动切换到S4浏览模式,并且 “Screen、User Agent Sensors” 会自动选中S4所具备的设备特性,包括屏幕大小、缩放比率、触摸支持等,如下图:

        点击 ” Reset “清除当前选中设备的特性模拟,网页会恢复pc浏览器浏览的状态。

Screen 屏幕子菜单:

选中其中的 “ Emulate screen ” 选项,就可以设置窗口分辨率,我这里设置的是S4的分辨率1080*1920,设备缩放比3,适应缩放,css media为screen,界面展示如下图:

            点击 “CSS media” 可以选择不同用途的css样式,比如:打印、tv、屏幕等;切换分辨率宽高,还可以进行横竖屏切换;这些都可以一一尝试

User Agent 用户代理子菜单:

这里只有一个选项 “虚拟浏览器用户代理信息”,通过选定特定的浏览器内核模式,页面会触发相对应的CSS和JS加载,这在响应式设计中向下兼容测试时很有用,毕竟现代浏览器之间的差异是微乎其微的,界面变化不大。

Sensors 感应器子菜单:

这里有三个特性模拟,第一个是触摸模拟,选中后,屏幕上的鼠标会变成一个圆圈的触摸图;第二个是地理信息模拟,可以填写具体的经纬度进行模拟,触发相关的事件;第三个加速器,并且可以进行设备原型拖动,具体的应用场景不清(估计是在游戏类加速上应用,有了解的朋友可以介绍一下)。

3、修改样式并同步demo代码

针对仿真器上测试结果,对其中的样式进行微量调整,当页面展示正常后,即可把这些修改的属性同步到静态demo中的属性中去,完成测试优化。

 

系统级别的界面元素,会因为系统的深度定制(android为甚),造成部分样式或元素效果改变,为了测试这种特殊的界面偏差,我们需要用到真机进行远程调试,请参见第二节:chrome开发者工具调试响应式设计【二】【未发布】: PC 版 chrome 开发者工具远程调试

 

 

  • 评论关闭

简单的响应式设计指南

简单的响应式设计指南

  • 评论关闭

通过摄像头获取照片【译】

简介:

这是一个快速教程,关于如何通过笔记本摄像头抓取照片,你可以访问在jsFiddle上的示例代码。还有一个高级版不能能直接上传图片到imgurgithub或则demo

HTML代码如下:

当你需要访问通过webRTC访问摄像头,在页面上你需要两个标签:videocanvas;video元素能够获取到webRTC中的视频流信息,canvas用来从这些流中抓取你想要的图片信息。另外我们还增加了img标签用来充当拍照图片替换的占位图片。

javascript代码:

实现的原理:

1、匿名函数

首先用一个匿名函数把我们的方法主体包起来,以防止全局变量的干扰。通过变量获取到页面上的标签元素,并设定照片需要宽度320,这里的高度设置为0,主要是因为我们需要在抓取照片后,需要根据照片大小缩放后再计算高度。

【注意】:使用getUserMedia获取到的流尺寸在不同浏览器中存在差异,在firefox中设定的尺寸是352×288,而在chrome和opera中的尺寸是640×400,我们通过调整不同的缩放比率,来获取不同浏览器中比较正常的图片大小。

2、获取视频流 

通过video获取摄像头中的视频流,这里对浏览器的不同API进行了兼容设置。

通过参数设置,屏蔽掉video中的音频信息,并在回调中获取到视频流:

 【注意】:在firefox浏览器中,为了启用video需要设置mozSrcObject属性,并可以直接使用视频流;而在chrome和opera中你需要手动创建src属性后才可以正常使用视频流。这一切在将来应该可以统一掉。

3、重设video的尺寸

我们通过监听”canplay”事件来获取到video的宽高videoHeight、videoWidth;并通过设置streaming为true让此监听只发生一次。

以上就是让整个video跑起来所需要进行的设置。

4、抓取照片

现在我们就可以通过canvas来抓取照片了,首先给按钮绑定”click ”事件来调用”takepicture ”:

在”takepicture ”方法中,我们获取到视频流中的当前帧,并把此数据拷贝到canvas中,通过”data URL”编码成png格式,并把此地址赋给img的src属性。

这样我们就获取到了对应的照片,此方法兼容firefox、chrome、opera

 

原文地址:https://developer.mozilla.org/en-US/docs/WebRTC/taking_webcam_photos

webRTC封装好的库:

 

  • 评论关闭

return top

日志宝-在线日志分析平台