html5

Page 1 of 1

Archives

文件夹

什么是前端开发工程师 前端开发工程师是Web前端开发工程师的简称,是近五年才真正开始受到重视的一个新兴职业。 这个岗位的职能现在还存在很多争议,尤其是在互联网技术并不发达的地区,但不管如何争执,前端工程师都需要掌握以下几个技能。 HTML CSS JavaScript 而争议就在于上面三个技能水平的不同,能做的事情不尽相同,而且其他岗位,如后端开发也要了解这些技能,一些设计也需要会这三个技能,导致了前端工程师的市场出现了一阵的混乱。 而现在,我们将这些可能造成混乱的岗位,根据岗位需要又进行了细分。   前端开发工程师的分类 美工:从设计,到页面重构全包的岗位,对上面三个技能的要求都只是熟练而已,互联网行业发达的城市几乎看不到该岗位了; 页面重构师:前两年比较标准的前端工程师,精通HTML、CSS,JavaScript是熟练级别能够很好的使用一些现成的类库和框架就好。 高保真原型开发师:一些公司分工非常细,这个岗位不用写JavaScript,但是Html和Css可能是专家级别的,负责将设计稿高度还原成页面。 H5前端开发工程师(JS方向):这个方向的工程师是JavaScript的专家,他们可以不用会写页面,但是写JS是一把好手。 H5前端开发工程师:没有特殊说明的H5前端开发工程师,是三项技能都达到精通的开发者,这类开发者用的前端开发技术比较新,倾向于解决移动端开发方案。 移动端前端开发工程师:很多公司以H5开发工程师来招募这个岗位的人员,然而其实H5开发工程师不一定是移动端开发,所以移动端前端开发工程师是专注移动端页面开发的人员,更了解手持设备。 前端架构师:专家级别的js开发工程师,负责造轮子写公司前端UI架构和脚本架构。 还有与设计和动画相关的前端开发岗位在这里就不赘述了…   前端工程师需要掌握的知识 上面说了3个基本技能,然而这3个基本技能并非像想象的那么简单,尤其是JavaScript,现在的受欢迎程度节节攀升,重要程度也不再是以前那个只做表单验证的被开发人员们嫌弃的语言。 另外前端作为中游开发,负责接收UI设计进行生产,之后产出给后台同学页面(现在一些开发模式不用给后台同学页面了,因为前端包办了后台模板开发的任务),所以前端作为枢纽,需要庞大的知识面,什么都要了解一些才能得心应手地做前端工作。 那么该掌握什么呢? 必须熟练掌握基本的web前端技术,比如:css、js、html 等等; 掌握一个到多个流行的类库(jQuery、zepto等)和框架(Angularjs、backbone、bootstrap等); 至少掌握或了解一门后端语言(JAVA、PHP、.Net); 必须掌握网站的性能优化、SEO、UE、服务器端、兼容性、存在的bug等; 学会用工具辅助开发; 有良好的代码规范编写习惯。 下面的图形象的说明了前端开发根本就是个百晓生… 做前端很简单,做前端很难 前端这个岗位在开发人员中,无疑是最具趣味性的,这得益于所见即所得的开发本质。 任何有一点代码基础的人,甚至不太懂代码的人都可以很快的写出一个页面,并让它运行在你的浏览器里面。 然而前端开发的学习曲线却是异常地陡峭,因此造成了现在市场上该岗位人才的两极分化,也是现在市场上前端开发供不应求的根本原因。   最后说说HTML5 H5前端开发是个奇怪的岗位,因为很多公司招募H5前端开发,其实并不是在用HTML5。 上海这边对稍微高端些的前端开发岗位,尤其是移动端,基本都叫H5开发了。 典型的岗位需求就是你要会一点Nodejs; 要会一个或多个MVVM或MVC框架; 最好会一点Hybrid开发; 能处理手持设备的兼容问题。   结语   智能手机大爆炸时代,移动端用户大暴涨时代,所有的开发应用势必会秉承移动优先的原则,作为专注移动端开发的HTML5,无疑将是未来开发领域的佼佼者。 几年内,HMTL5已经横跨所有智能平台,让我们拭目以待前端开发工程师多彩的未来。  

转自:http://www.php100.com/html/webkaifa/HTML5/2012/0831/10979.html 结合坑爹的viewport一起了解 随着高端手机(Andriod,Iphone,Ipod,WinPhone等)的盛行,移动互联应用开发也越来越受到人们的重视,用html5开发移动应用是最好的选择。然而,每一款手机有不同的分辨率,不同屏幕大小,如何使我们开发出来的应用或页面大小能适合各种高端手机使用呢?学习html5 viewport的使用能帮你做到这一点……viewport 语法介绍: 01<!– html document –> 02<meta name=”viewport” 03content=” 04height = [pixel_value | device-height] , 05width = [pixel_value | device-width ] , 06initial-scale = float_value , 07minimum-scale = float_value , 08maximum-scale = float_value , 09user-scalable = [yes | no] , 10target-densitydpi = [dpi_value | device-dpi | high-dpi | medium-dpi | low-dpi] 11″ 12/> width 控制 viewport 的大小,可以指定的一个值或者特殊的值,如 device-width 为设备的宽度(单位为缩放为 100% 时的 CSS 的像素)。 height 和 width 相对应,指定高度。 target-densitydpi 一个屏幕像素密度是由屏幕分辨率决定的,通常定义为每英寸点的数量(dpi)。Android支持三种屏幕像素密度:低像素密度,中像素密度,高像素密度。一个低像素密度的屏幕每英寸上的像素点更少,而一个高像素密度的屏幕每英寸上的像素点更多。Android Browser和WebView默认屏幕为中像素密度。 下面是 target-densitydpi 属性的 取值范围 device-dpi –使用设备原本的 dpi 作为目标 dp。 不会发生默认缩放。 high-dpi – 使用hdpi 作为目标 dpi。 中等像素密度和低像素密度设备相应缩小。 medium-dpi – 使用mdpi作为目标 dpi。 高像素密度设备相应放大, 像素密度设备相应缩小。 这是默认的target density. low-dpi -使用mdpi作为目标 dpi。中等像素密度和高像素密度设备相应放大。 <value> – 指定一个具体的dpi 值作为target dpi. 这个值的范围必须在70–400之间。 1<!– html document –> 2<meta name=”viewport” content=”target-densitydpi=device-dpi” /> 3<meta name=”viewport” content=”target-densitydpi=high-dpi” /> 4<meta name=”viewport” content=”target-densitydpi=medium-dpi” /> 5<meta name=”viewport” content=”target-densitydpi=low-dpi” /> 6<meta name=”viewport” content=”target-densitydpi=200″ /> 为了防止Android Browser和WebView 根据不同屏幕的像素密度对你的页面进行缩放,你可以将viewport的target-densitydpi 设置为 device-dpi。当你这么做了,页面将不会缩放。相反,页面会根据当前屏幕的像素密度进行展示。在这种情形下,你还需要将viewport的width定义为与设备的width匹配,这样你的页面就可以和屏幕相适应。 initial-scale 初始缩放。即页面初始缩放程度。这是一个浮点值,是页面大小的一个乘数。例如,如果你设置初始缩放为“1.0”,那么,web页面在展现的时候就会以target density分辨率的1:1来展现。如果你设置为“2.0”,那么这个页面就会放大为2倍。 maximum-scale 最大缩放。即允许的最大缩放程度。这也是一个浮点值,用以指出页面大小与屏幕大小相比的最大乘数。例如,如果你将这个值设置为“2.0”,那么这个页面与target size相比,最多能放大2倍。 user-scalable 用户调整缩放。即用户是否能改变页面缩放程度。如果设置为yes则是允许用户对其进行改变,反之为no。默认值是yes。如果你将其设置为no,那么minimum-scale 和 maximum-scale都将被忽略,因为根本不可能缩放。 所有的缩放值都必须在0.01–10的范围之内。 例: (设置屏幕宽度为设备宽度,禁止用户手动调整缩放) <meta name=”viewport” content=”width=device-width,user-scalable=no” […]

转载自:http://hax.iteye.com/blog/978184   最近我做了一点儿针对手机的Web开发和相关研究。按说,Web自设计之初,就已经考虑了设备无关性。然而,现实总是不尽如人意。  我们知道大多数网页都是针对桌面显示器开发和测试的,但是手机屏幕通常要比桌面显示器小很多,比如iPhone也就是320px。那么那些网页在手机上如何浏览呢? 一种是把网页缩放到很小,你可以看到整个网页但是看不清字了;或者只看网页的一个局部,然后上下左右移动来看其他部分。现在的手机浏览器把两种模式结合使用。(或许还有第三种——分析网页,将其中内容抽取出来,重组,然后呈现,不过这里不讨论这种方式。) 如果仅仅是出现横向滚动条,那问题倒不是很大。对于那些采用固定布局的“像素级精确设计”确实就是如此。但是使用自适应布局的网页就有问题了。比如一个三栏布局,其中一个边栏可能只有20%宽度,320px的屏幕上只有60多像素,只能放5个汉字,排版不美观不要说,如果里面有一些图片,很可能图片的宽度都超过60像素,造成overflow,从而破坏了布局。另一种常见布局方式是采用固定大小的边栏,例如240px宽,而主体部分则自适应宽度。然而对于320px的屏幕来说,本来是次要的边栏占据了3/4空间,主要部分却只有1/4空间,另外也极有可能因为内容包含图片等造成overflow。 说到这里,那些喜欢固定布局的人(比如那些热衷于960px grid排版的同志们——哦,最近淘宝升级成1000并放弃了栅格!不过那仍然是固定布局)可能要乐了,你们倡导了半天流式布局,结果在mobile设备上表现反而很糟糕,真是费力不讨好。 真正掌握CSS的同志(是的,珍稀动物!)肯定会反驳。上面这些问题其实都很容易解决。比如设定min-width。还有,适应不同屏幕大小的“正确”的方案,应该用media query。 问题是,大多数网页没有这么做!或者说不是按照“正确”的方式写的!未必是网页作者不懂CSS,而只是他们压根没费心考虑过手机大小的屏幕(毫不惭愧的说,本人也是其中一份子)。你可以试着把桌面浏览器收缩成320px宽(或者可以试着zoom in到300%),可以看到不少网页会发生严重的布局错乱,至少也是浏览体验上的大幅下降。为了迎合这些网页,手机浏览器厂商发明了两个viewport。 简单来说,就是手机浏览器把自己冒充为拥有一个更宽的屏幕,这样页面的布局就能跟桌面浏览器一样了。不同浏览器冒充的数值不一样:iPhone是神奇的980——960它表弟;Android是保守的800——冒充一个800*600的显示器;而Windows Phone 7则是1024——冒充一个1024*768的显示器(充分体现微软的庸俗特质)。 原本布局就是按照viewport(桌面上的浏览器窗口)大小来进行的,现在决定布局的viewport和窗口分裂了,产生了两个viewport。 两个viewport其实并不新鲜。就像前面说的,所有做固定布局的同学其实都在不自觉使用两个viewport——固定布局,其实相当于人为设定了布局viewport。 使用独立的布局viewport还有一个好处,那就是缩放变得很简单,不用引起relayout。 在浏览器的历史上,主要有两种不同的缩放方式,一种是以IE6为代表的缩放(文字大小),实质是改变root元素的字体大小。另一种是像素缩放,实质是改变CSS pixel的大小(即1个css像素不再对应1个物理像素),或者说改变了浏览器的内部DPI。(Firefox还支持真正的字体缩放,与改变root元素的字体大小不同,它会缩放所有元素的font-size最终使用的值(used value),因此不仅对于以em设定的字体大小有效,对于以px和pt等所有单位设定的字体大小都有效。) 在桌面浏览器上,因为缩放时viewport的物理大小是固定的,如果进行像素缩放,实际就意味着viewport以CSS pixel计算的宽度和高度会随之改变,比如若放大到200%,CSS宽高就会缩小到原来的50%。而这必然引起relayout。 相反,在mobile浏览器上,像素缩放时,布局viewport的物理大小可随之缩放,因此其CSS宽高值是不变的,就不必引起relayout。这不仅避免了relayout的大量计算,也更符合移动设备上的用户体验(考虑一下你如何缩放地图就明白了)。 虽然两个viewport能比较好的解决在手机上浏览过往网页的问题,然而,这毕竟是一个向后看的方案,体验毕竟是受限的。想象在320宽的窗口里看960固定布局的网页,不可避免的要时常缩放和使用横向滚动条。在触摸屏上我们可以用手势来控制,会方便一点,但是仍然很麻烦。所以绝大多数移动Web开发者最终还是选择针对小屏幕(重新)进行设计。 不过一个显然的问题是,如果我的网页已经考虑了小屏幕,甚至就是专门为手机设计的,那么我其实不需要两个viewport(也不需要缩放),这时候怎么办?更一般的问题是,如果我设计的网页不是针对960或者800或者1024的呢(至少你选了960,就排除了800和1024;你选了800,就排除了960和1024;你选了1024,就排除了800和960……)? 于是Apple发明了viewport的meta标签,例如: <meta name=”viewport” content=”width=320, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0″> 其中width表示网页的布局layout宽度。initial-scale表示初始时的缩放比例,minimum-scale和maximum-scale分别表示最小和最大缩放比例。这样,上面这个meta就表示布局宽度320像素,初始缩放为1倍(即不缩放),且禁止用户缩放(因为最大最小缩放都为1倍)——一个专为iPhone优化的网页通常就会用这样的设置。 如果你是针对960设计的,那么可以用这样一个meta: <meta name=”viewport” content=”width=960, initial-scale=0.33″> 这表示布局宽度为960像素,初始缩放为0.33,也就是,会缩小到大约1/3,这样正好可以在320像素的宽度里看到整个网页。你也可以不设initial-scale,因为手机浏览器大多默认会初始缩放到可容纳整个网页宽度。 嗯,看上去不错吧。 可是,说到底,手机浏览器的这种设计,实际上揭示了一个难堪的真相——你们这些网页仔,其实从来没真正做好过屏幕适应。因为一个能自动完美适应不同屏幕大小的“正确”方案,width的取值就不应该是一个固定数字。幸好,safari的工程师在发明viewport时还是给我们留了点面子,width的取值除了像320或960这样的数字,也可以是关键字device-width(其实我认为更合适的词是auto),表示采用设备宽度。 然而,历史总是杯具的重复自己。微软就又(嗯,我为什么要说“又”呢?)贡献了这样一个例子:Window Phone 7的设备宽度通常至少是480,那么按理说,如果viewport中设置了width=device-width,layout宽度应该是480像素,可是IE mobile会将viewport设为320!这是神马原因呢? 原来据说微软收集的数据表明,有大量站点使用了device-width,但是其实只为320像素宽(也就是iPhone的宽度)优化——比如直接用一个固定宽度320px的<div>将内容wrap起来!我勒个去,诸位移动Web开发者,你们有木有这么干?有木有! 那后面的故事就不用说了。微软当然是做出了一个“正确”的选择。 另外需要注意的是,width只是设置layout宽度,还要乘上缩放比例,才能得到最终的显示宽度。那么对于480像素的屏幕来说,若device-width“被320”,那initial-scale应该是1.5才能占满整个屏幕宽度。可是如前所述,针对性优化的网页会把initial-scale设成1.0! 对此微软是如何处理的呢?文档语焉不详,而其模拟器要在Windows 7上才能运行,所以我也暂时没有进行实测,不过据我推测,其initial-scale应该仍旧会保持1.0,也就是这1.5会变成额外的缩放因子。实际上其他移动浏览器已经这样做了,比如Fennec(Firefox的移动版)就是如此。Android和iPhone 4也都有类似的设计,为什么会这样?这样会不会产生新问题?留待下一篇博客再讨论。

下载地址:http://www.xyhtml5.com/html5-development-tools.html 出了5.5这个补丁不建议再用,会影响自动排版的规则! Dreamweaver CS5和HTML5 Pack 安装 HTML5 Pack 之后,可以在 Dreamweaver CS5 中使用以下特性和支持: HTML5 代码提示 HTML5 代码提示与 Dreamweaver 中的其他代码提示相似。在 Code 视图中,开始输入感兴趣的标记,Dreamweaver 会提供代码提示。 除了提示新的 HTML5 标记之外,Dreamweaver 还为现有标记提供新属性和值代码提示(例如,input 标记的新属性和值)。 CSS3 支持和代码提示 除了 HTML5 代码提示之外,HTML5 Pack 还在 Dreamweaver CS5 中添加 CSS3 代码提示。新的代码提示并不支持每个 CSS3 选择器和属性,而是只支持 W3C 规范中当前完成的选择器和属性。 另外,这个扩展包含对 –moz、-webkit 和 -o CSS 属性的基本支持。 多屏幕预览和媒体查询支持 Multiscreen Preview (File > Multiscreen Preview) […]