标签: html

  • 聊聊前端入门(1):HTML+CSS

    聊聊前端入门(1):HTML+CSS

    最近有一些新老同学入门前端,找我问问题,我从他们身上发现了一些共性问题,今天拿出来总结一下,希望后来者能吸取经验。

    前端三大件:HTML、CSS、JavaScript。这三位是根本,万变不离其宗,不管用多先进的技术,最终浏览器里跑的还是他们(不考虑 WASM、WebGL)。所以前端入门应该以这三种语言为基础,慢慢扩展到其它领域。

    当然有些同学可能上来就用框架,拜现代化前端技术所赐,有些同学可能完全没认真学习过这三门语言,也怼出了功能、甚至怼出了产品。但我建议,无论从上限考虑还是从下限考虑,都应该好好学习这三门语言本身。

    声明式语言

    入门一般都从 HTML、CSS 开始,因为它们很简单,简单的原因是因为它俩是声明式语言。那什么是声明式语言呢?标准定义咱们略过不谈,简单来说有两大特点:

    1. 需要什么你就写什么,需要这里有一个文字,那就写一个文字;需要有一张图片,就写一张图片。
    2. 不写的就不会出现。没有逻辑推演、计算,不会因为环境变量而有所不同,没写的就没有。

    于是它们有好处也有坏处:

    • 好处:没有心智负担,不用理解全局,就看某一行、某一段,写了就是有,没写就是没有。
    • 坏处:需要 100 个字就要写 100 个字。有 100 个元素共用一个属性,可能也要写 100 遍。

    如何学习 HTML+CSS

    有些同学上学期间学过编程,比如 C 语言、Java 语言。它们都是命令式语言,有更强的逻辑性,它们就像一本推理小说,你必须从头看到尾,不漏过一个线索,层层推理,才能得到结论。

    他们会套用自己在命令式语言方面的经验去学习 HTML+CSS,然后发现,好难……命令式语言的语法元素很少,难在组合出合适的逻辑、设计合适的数据结构。声明式语言能实现的效果总数是固定的,没有预先设计的部分,就是实现不了,谁都实现不了。但是每种效果的实现可能都是不同的,需要大量经验和记忆。用上一段的类比,声明式语言就像诗歌,甚至上一行跟下一行都没联系,但是连到一起还真有点意思。

    所以学习 HTML+CSS 就要有合适的方法。我个人的经验如下,

    1. 首先要知道

    HTML 标签 100+,CSS 属性 200+,这些都是知识性的内容,不知道就是不知道;不知道但是要用,那就做不出来。所以第一步是知道这些内容,方法大概是:

    1. 浏览文档,比如 MDN
    2. 自己实验,加深记忆和理解
    3. 跟背单词一样,要经常性重复这个过程,才能真的记住

    这个过程不需要了解的很透,重点在于知道这些标签和属性的存在,当你面对需求的时候,才会想到解决方案。

    2. 接下来要多尝试

    经常浏览 codepen.io 这样的网站,上面有很多别人做的范例,可以长很多见识,让你恍然大悟,原来可以这样做那个东西。

    同时,也可以反过来用看到的范例指导自己的学习。比如,看到一个 css 规则,这个你刚好不熟悉,就可以找来文档仔细阅读理解一下,或者在论坛上询问其他前辈。

    一段时间之后,相信你会对大部分 html、css 属性都了如指掌,看到人家的网站,也大概知道该怎么做。但是给你一个实际项目,你可能还做不出来,或者做不好。没关系,那是下一步的目标。

    3. 紧跟社区步伐

    跟其它语言不一样,声明式语言从诞生开始,语法上不会有太大变化,语法元素也很固定。升级换代主要来自增砖添瓦,即新规则、新属性。

    比如 CSS,早年我们布局只能依靠 float。很难用,有各种诘屈聱牙的概念需要记忆。后来就有了 display:flex,也就是弹性盒模型,好用的多。后来又有了网络布局。然后因为各种内部弹性外部弹性,又有了 min-contentmax-contentfit-content 等新属性。

    这些东西,很新,有时候没有办法找到合适的学习资料。于是就要紧跟社区来,通过技术账号了解到新知识,通过技术文档学习新知识。

    4. 突破自己

    自学里面,最难的一件事其实就是突破自己。就好像我今天看到一个帖子,楼主说准备找到工作后就办张健身卡去健身,然后下面一群人歪楼,说“为什么健身要办健身卡?”

    因为自己监督自己很难,自己给自己打分更难。所以学校才要安排各种考试,给学生打分,让大家知道自己的位置。

    所以,做出来自己看觉得还行,没有用。这里有几个建议:

    1. 瞄准一个产品,比如微信,做到像素级复制。可以截图然后调到 50% 透明度,叠到一起慢慢看。
    2. 选择最合适的技术,坚持到底,不要因为某些环节难以突破就乱来。
    3. 邀请比较有经验的前辈帮自己做 code review

    附加:最好找个靠谱的前辈做引路人

    (我想了想还是把这条加上。)

    互联网是个好地方,我们能免费获取几乎所有有价值的资料。但是对于 Web 开发、前端开发这种领域,长期积累的海量知识储备也可能成为大家学习的障碍——东西太多,不知道从何处下手。

    所以,有个靠谱的引路人也很重要,会帮你节省很多时间。笔者不才,亦好为人师,有需要的可以找我:

    新人常犯的错误

    新人难免会犯错,这里列举一些常见的、可以规避的问题:

    1. 沉迷细节无法自拔

    有些同学沉迷细节,喜欢抠字眼,经常会提出一些奇奇怪怪的问题。很多问题其实没有准确答案,也不需要准确答案,尤其是对于新人来说,可能三两年内都不会真的需要解决。

    尤其是 HTML、CSS,因为是声明式语言,很多时候,它们的行为就是这么设计的,不需要也没办法深究;有些设计,可能来自二十年前甚至更早,现在早已没有那个应用场景,新人难以理解也是正常的。

    所以我建议大家以记用法积累经验为主,辅以实操验证,不需要像学命令式语言那样去强迫自己理解。

    2. 遇到问题生拼硬凑

    有些同学遇到问题就发慌,然后开始百度,看到一个方案就复制粘贴试一试,能行就继续,不能行就复制粘贴下一个。结果代码就补丁摞补丁,各种解决方案混合在一起,毛病越来越多。到最后可能完全超出掌控、无法解决。

    这里大家需要明白,语言元素很多,组合方式也很多。同样的问题,可能来自不同的根源;类似的组合,也会产生不同的问题。绝大部分时候,我们都要先选择方案,然后围绕方案组织代码,解决遇到的问题。在不同方案间左右横跳,最后结果多半不是好处均沾,而是问题集中爆发。

    如果能够找到最佳实践,那就坚持。如果几个方案都差不多,那就选好一个,坚持下去。遇到问题,面对多个搜索结果,要分析它们是怎么做的,解决了什么问题,不要直接拷过来试。坚持一段时间,会有很好的结果。

    总结

    我当年也是自学成才,走过不少弯路,希望这系列分享能帮大家节省一些时间。

    有任何问题和建议,欢迎留言评论。下次聊聊 JS 方面的学习。

  • 使用 <input type=”file”> 上传 ZIP/RAR 文件

    使用 <input type=”file”> 上传 ZIP/RAR 文件

    上传文件要用到 <input type="file">,这个元素有个 accept 属性,可以用来筛选文件类型,方便用户选择。按照 MDN 的说法,这个属性的值支持以下几种形式:

    1. 合法的文件扩展名,大小写不敏感,以 . 作为开头,比如 .jpg.pdf
    2. 合法的 MIME type,不需要扩展名
    3. 媒体文件,audio/* 适配任意声音文件,video/* 适配任意视频,image/* 适配任意图片

    同时,属性值可以使用 , 连接,表示“或”的意思。注意,这里只能是单独的 ,,不能有空格,不然有空格的部分会失效。所以,比如,一个上传图片、以及 PDF 的元素就可以写成:

    <input type="file" accept="image/*,.pdf">

    使用扩展名比较方便,但是扩展名太多不方便管理,比如 .jpg.jpeg,容易漏掉,所以我更喜欢 MIME type。那么压缩文件的 MIME type 是什么呢?经过一番搜索和尝试,是:.zip,.rar,application/x-rar-compressed,application/zip,application/x-zip-compressed,application/octet-stream

  • 看看前端技术的发展动态,我们似乎应该重新规划学习方向

    看看前端技术的发展动态,我们似乎应该重新规划学习方向

    这个标题是仿照好奇心日报起的。

    近期在帮朋友招聘,目标是找到一个可以独立工作,能够应对大多数问题的前端。初筛简历的时候我比较偏爱之前经历大多是 JS 开发的候选人,比如专门写插件的,或者写过游戏的,对接的同学就问我:前端是不是做过游戏有加分?其实也不完全如此,只是由于环境的变化,JavaScript 开发在前端的整体工作中占据着越来越为大的比重。以前那种先考察切页面能力的做法已经完全不适用了。也导致,我们在前端学习上,需要重新调整侧重点。

    创造 HTML 的目的,是为了阅读文献,从 HTML 标签当中我们就能看到很多来自于印刷时代的痕迹,比如:

    1. 各种语义化的标签 <p> <h1> <h2> <blockquote>
    2. 以竖排版为主的格式
    3. 丰富的字体选项

    浏览器也是朝着这个目标去实现的。于是,早期浏览器在界面布局上做的并不好。伴随着互联网发展,越来越多的用户涌入,他们要求互联网以网页为载体,提供更多满足他们需要的产品。此时最早一代 HTML 和 CSS 就不那么适用了。在我开始做前端的那个年代,经常会碰到各种各样奇奇怪怪的问题,写出来的代码,很难达到自己的预期。于是,做前端,最重要的积累,就是各种浏 Hack,什么清浮动啊、IE6 啊,差不多就是这些。

    这些东西往往并无逻辑可言,所以,老前端比新前端的优势,就在于记住了多少这方面的经验,解决过多少这方面的问题。我们招聘的时候,也倾向于选择有丰富页面制作经验的,毕竟,编程问题很多时候归属于后端。

    然而时过境迁,我们现在再去看前端技术,它的现状和趋势已经都变了。首先,越来越多的浏览器,都在遵守 W3C 规范,我们现在已经不需要再拿那么多时间去做 Hack。浏览器之间的差异,已经从实现的差异(比如 addEventListenerattachEvent),变成了功能化的差异(比如是否支持 Grid 布局)。所以在这个时候,知道多少浏览器 Hack ,也不再是优势。

    另一方面,越来越多的工具涌现出来,我们大部分时间都在使用脚手架、预处理工具、模板引擎,已经很少直接手写最终的 HTML、CSS 代码了。再加上 MVVM 框架对整体工作流的影响,如今,使用命令行,已经是前端必修课。所以,扎实的编程基础,丰富的,在各种环境下进行调试的经验,都是高级前端工程师真正的竞争力所在。

    总结一下,现在切页面变得相对容易,大多数览器的表现都会和预期一致。所以哪怕相关经验差一些,现学也很快。但是开发经验,如果没有积累,想在短时间内快速提升到能够独立应对大多数需求的水准,就比较困难。所以前端应该尽早关注 JavaScript,尽量多的尝试各类基于命令行的工具,甚至主动跨出舒适区,自己动手实现一些工具。这些会对将来的工作,对将来应聘,带来很多好处。


    参考资料:

    1. wiki HTML
  • 前端框架点评

    前两天被人@,提问前端框架的问题。这还是第一次在微博上被陌生人提问,感觉有点小激动。今天写篇小文章,简单点评一下我用过的前端框架,希望对大家有所帮助。

    本文涉及的范围

    本文要点评的前端框架,都是我用过的,以JavaScript框架为主,也可能包括一些工具类库。由于前端的特殊性,弱语言HTML和CSS是必不可少的工具,运行机制导致很多成熟的工程学方法没法用,必须用工具库补充。烦请大家不要抠字眼,我一向很马虎,呵呵。

    Bootstrap

    一定要先推荐Bootstrap。它由Twitter的两位工程师首创,当前版本2.3.1,涵盖了文本、布局、表单、工具,除了暂时没有日期选择器之外,几乎包含了网页所需的一切。我们知道,网页出现是为了传递信息,而成熟的印刷业对其影响很大,表现出来就是,HTML中很多标签,比如H1~H6p等,都是有具体语义的。但很多前端框架并未给予他们足够的重视,所以往往需要我们重置或者自己动手写。Bootstrap则不是这样。它不仅包含大量组件,还帮助我们给每种可能用到的语义标签都定义了样式,又设计出很多helper;而其网格系统也能帮我们出色完成排版工作。总而言之,使用它几乎足以满足任何网页开发需求。

    值得一提的是,Bootstrap的组件和Widget都基于HTML标签构建,非常好用;而响应用户操作则基于对document的侦听,所以几乎不会对我们其它代码逻辑造成影响,我们可以放心大胆的在项目当中使用。当然,Bootstrap依赖jQuery,后者近期遭遇到一些纷争。不过我还是要强烈推荐这个框架。

    jQuery UI

    比较遗憾的是,虽然号称UI,但jQuery UI只能算作一个组件库。因为缺少基础排版支持,所以既想使用jQuery UI,又想和自己的样式保持一致会有些困难,需要花费不少时间做修改。

    抛开这一点,jQuery UI也是个很好的工具,几个widget都很实用,文档丰富详实,如果项目本身对交互要求不高,只是个别地方需要一些功能补充,jQuery UI确实是不错的选择。尤其当我们需要draggablesortableresizable这几个功能时,选择的余地真的不大。

    HTML5 Boilerplate

    这个工具力图给开发者提供一个舒适的起点。他们为项目建立了标准化的目录结构,并且把常用的资源都整理在合适的位置,这样我们只需要替换它们就能保证项目对所有浏览器都有完美表现。同时,他们重置了CSS,引入了GA统计,在页面中标记了合适的输入点,这样我们能尽快投入到项目逻辑的开发中。

    但这个工具的问题也很明显,它努力达成的目标,是消弭浏览期差异。假如我们只需要统一的环境就能开展工作,那H5B就足够了;而实际上,我们通常需要更多,比如排版、比如组件。所以,这个工具对我来说,学习的意义大于使用的意义。

    HTML KickStart

    我见过的前端框架里只有这个跟Bootstrap的覆盖面接近。它的设计更好,更鲜艳更有活力,不过最近的开发好像慢了下来。我并没有真正使用它,因为它的组件太少了。

    Backbone

    非常好的MV*框架,真的像根脊柱一样,把被jQuery拆的七零八散的js统一在合理的框架内,让整个项目都变得协调了。引入Collection真的很天才,结合其出色的View设计——其实Backbone的View并不是传统意义上的View,更像mediator——可以看出,Backbone的设计者对Web开发有着深刻理解。哦,差点忘了,Router还能帮我们很好的整理单页应用的逻辑。

    不过js毕竟是一门很烂的语言——或者让我换种表述方式,缺陷很多,所以它尚无法做到像AS3的Robotlegs那样好。不过,如果我们希望把代码组织的更好,Backbone类的框架是不可或缺的。

    Rachet

    Rachet的目的和架构,很像Bootstrap,不过它瞄准在移动端。Rachet现在仍处于比较低级的阶段,组件太少,开发起来不太方便,最多相当于Kickstart把。可惜的是,移动端移动框架普遍较弱,在我看来,基于它的Junior仍然是不二之选。

    Zepto

    说到移动端开发就不能不提Zepto。它力图实现一个十分类似jQuery的库,不过只考虑支持移动端,所以体积会小很多,速度也会快不少。Zepto的升级频率最近也不高,不过还是到了1.0。新版Zepto放弃了ruby,使用coffee作为编译工具,支持使用者自由组合功能模块,相当贴心。

    不过具体使用时,还是会有一些函数的用法和jQuery不同,需要注意。举个例子,css函数,jQuery里支持数字,比如$('div').css('height', 100),会把页面中所有div的高度设置为100px;而Zepto不行,必须$('div').css('height', '100px')才会正常工作。

    jQuery Mobile

    强大的jQuery团队最失败的作品。贪恋于风光的过去,迷信“全覆盖”,使得jQuery Mobile步履蹒跚,在移动平台上无法取得足够好的性能表现(早期版本甚至不支持固定底部)。而这直接带来了对HTML在移动端的质疑。有很多本不擅长前端开发的人,看到Phonegap,就直接上jQuery Mobile,结果发现性能不行,体验很差,便在各种渠道大放厥词,说HTML不行。这种行为直接伤害了HTML和Hybrid应用。

    jQuery Mobile失败不仅在于此。jQuery本身方便快捷,使用它很容易养成不重视代码组织的习惯;而在移动端,单页应用占据主流,这意味着,使用jQuery Mobile很可能无法良好的组织代码,直接带来项目维护成本的提高。另外,早期版本的设计也不可避免的带有大量Web痕迹,导致实用性不足。所以直到今天,jQuery Mobile都还是个悲剧。

    不过,jQuery 2.0已经beta2了,我们知道,jQuery 2.0里放弃了对IE678的支持,性能会得到不小的提升;jQuery Mobile 1.3已经引入了对hash的支持,组织代码好多了;同时,随着3次小版本更新,越来越多适用于移动应用的组件加入进来,大大扩充了军备库。我认为,未来的jQuery Mobile,值得一试。

    Sencha Touch

    大家可能还记得,Facebook闹过一阵,说HTML5不够好,还把他们的手机客户端用原生重做了一遍。之后Sencha的两位工程师表示不服,以HTML5为基础开发了功能几乎完全一样的客户端,他们用到的框架就是Sencha Touch。据说,它的性能比jQuery Mobile好不少。

    但是,真正用了就知道,sencha touch实在太不“前端”了。它里面几乎没有给HTML和CSS留下太多位置,明明十分强力的布局样式工具,被封装成了单薄的接口;但是没少往JS框架里加内容。结果就是用起来非常复杂,随时需要看文档;自定义困难,它里面甚至有一个属性叫“html”,用来填入大段文本类型的html;数级嵌套起来的对象也很让人头疼,而且感觉维护也不会太容易。所以我做了一半就还是放弃了。劝大家也别去尝试了。

    如果有哪位高人愿意以实际经验教育我的,我洗耳恭听。

  • 使用PhoneGap+jQuery Moblie开发蜂鸟镜头库手机App

    蜂鸟镜头库app效果图
    蜂鸟镜头库app

    自从春节期间在家尝试了PhoneGap之后,一直想做点实际的东西,好总结点经验,以备不时之需。可惜后台苦手,数据源是个问题。后来想起来以前做蜂鸟镜头库的时候有两个接口,可以取得完整的数据,于是便动起手来,开始做这个app。

    开发本身并不复杂,大概花了一天时间搞出雏形,加上翻页基本就能发布了。不过还是遇到不少问题,今天简单总结下踩过的坑,以免以后再踩。
    (更多…)

  • Chrome下填充10w个div实验

    Chrome下填充10w个div实验

    首先需要解决的是浏览器里有大量绝对定位的元素的效率问题。flash当中可以用一张位图来绘制所有的点击记录,为了能让html版尽量兼容更多的浏览器,采用div来承担这个任务是必要的。所以先来就是测试页面当中包含多少div,交互效果可以接受。

    (更多…)