分类: 技术

各种开发心得,包括语言、软件工程、开发工具等

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

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

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

    近期在帮朋友招聘,目标是找到一个可以独立工作,能够应对大多数问题的前端。初筛简历的时候我比较偏爱之前经历大多是 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
  • 面试经:GitHub

    面试经:GitHub

    GitHub 越来越有名,很多同学都把它作为一个关键字加入自己的简历当中。不过我在面试中,问到如何使用 GitHub,对方通常会答复:上去看源码呀!这个答案完全无法让我满意,具体的原因,一方面可以参考我之前的一篇文章《谈学习:读源码》,源码不是小说,直接看源码收获太小。另一方面,看源码是一个太直接的逻辑推断——上面有源码所以我去看源码——我不认为这是一个细心耕耘慢慢养成的习惯。

    接下来我想简单谈一下,我认为应该如何使用 GitHub。

    Issues 和 PR

    一个 GitHub 仓库可不仅仅是一份源代码那么简单。GitHub 是开发者社交平台,所以每个项目在代码之外,都会有两个非常重要的模块:

    1. Issues 问题,包括 Bug,和其它使用者希望有的功能
    2. Pull Requests(PR) 其他的开发者在这个项目上做出了一些改进,或者修复了一些 Bug,希望能够合并到 master 当中,就会发起 PR

    完美的代码是不存在的,越是用的人多的库,存在的问题,或者说被发现的问题可能就越多。阅读其他人提的问题,很多时候可以获得不小的收获,比如,大家开发时都遇到了什么问题?有没有与我类似的情况?他们是怎么解决的?大家最想要的新功能是什么?有哪些值得关注?我能做什么?等等。

    以及,可能是更重要的,我们应该怎么样通过 Issues 与仓库的原作者进行交流。

    毕竟我们每个人的时间都是有限的,对于大部分开源的类库来说,了解怎么用、有哪些问题、怎么避免踩坑,通常会比你知道它某个函数是怎么写的更有价值。

    看文档

    好的开源类库通常还会有一个做得非常到位的地方,便是它们的文档,做得通常详尽有价值。通过阅读文档,可以很快的了解这个仓库是干嘛用的,应该怎么用,能解决哪些问题,以及接下来,它的发展方向是怎样的。

    据我观察,文档通常分布在三个地方:

    1. README.md,也就是打开仓库页面,默认渲染在文件列表下面的那块
    2. 官方网站,通常在导航下方,仓库简介那里
    3. wiki,通过导航链接可以到达

    观察提交频率

    并不是所有的仓库,都有开发者在进行积极地开发和维护。如果搜索到几年前的文章,被导引到一些比较古老的仓库,可能出于某种原因,已经没人对它进行维护了,这个时候,该放弃就要放弃。

    人生苦短,时间有限,总会有更具价值的仓库供我们学习。

    GitHub 热门趋势

    GitHub 还有一个热门趋势页面,从中你可以了解到全世界的开发者都在关注哪些仓库,你可以把自己感兴趣的那些加星标记一下,将来不定时的翻一翻看一看它的 Issue、PR 和文档,通常都会有不小的收获。

    GitHub Pages

    GitHub 还提供给我们一个非常好的静态网站空间,完全免费,全世界都有 CDN,不用白不用。便是传说中的 GitHub Pages。

    我们可以用它写博客,做笔记,重点是内容完全可以进行版本管理。

    具体做法请自行 Google。

    不要放弃提交自己的仓库,也应积极向别的开发者提出 Issue 和发起 PR

    我觉得这件事和写博客一样,如果你只是在纸上记笔记给自己看,那多半会不求甚解;但是你想到写成博客总会有人看到,那多半还是会把要写的内容搞清楚,写全面,逻辑清晰可自洽。所以写博客是比记笔记更好的学习方法。以此类推,把自己的仓库推到 GitHub,也理应也是比在本地练习更好的学习方式。

    这里绝不鼓励大家乱来,相反,我希望大家对自己的行为负责,重视 Issue 和 PR,毕竟都是提给其他开发者的,或多或少都会对别人造成影响。所以在提之前,十分有必要阅读仓库主人的提交须知,按照对方的代码规范书写代码,写好相关测试,然后再提交。做到言之有物,切不可乱来画猫。


    总结

    这篇文章不是传授大家应聘技巧的,而是希望分享自己的一些经验,让大家能够通过 GitHub 这个世界上最大的代码托管平台,正确的学习开发技巧。

    如果您有相关的经验技巧,欢迎交流。

  • 第三次直播总结,兼谈技术教学

    第三次直播总结,兼谈技术教学

    前几天完成了第三场直播:《Web 永恒不变的主题:布局——Box,Flex,Grid》,这里总结一下。

    坦率的说,第二场直播给我造成了一些错觉。因为第二场直播比第一场多了十个人,差不多1/3,让我以为自己取得了不小的进步,甚至上一次总结的时候还信心满满。然而,这一场观众数又给我干了回来,甚至还不如第一次。感觉尚未稳固的信心又失去了……

    尤其是,第二场开播之前,有将近40个人加入我开辟的答疑群,这个人数几乎和购买课程的人数相等。但是第三场,前后只有不到10个人加了进来。我只能自我安慰,告诉自己,很多人之前已经加入了……

    从准备的充分程度来说,第二场 Promise 的 N 种用法,应该是最充分的。但是从技术的实用角度来看,第三场 CSS 布局应该也不差。而且理论上,CSS布局更基础,来听的人应该更多才是——我只能认为,Promise 解决的异步回调问题,比 Grid 解决的复杂网格布局,更重要,更有价值,

    希望下一场会好一点吧!

    接下来谈两点想法。

    干货

    从选题开始,我就不想讲什么个人发展,或者前端技术展望之类的。我不是说这个主题不好,我只是觉得这个对听众来说用处不大。如果听众是一个自我驱动非常强、喜欢技术、喜欢开发的人,我相信他应该很容易找到类似的信息,清楚自己的前进方向;相反,如果用户还比较迷茫,只是试探性的踏入这个领域,听了意义不大。

    因为,之后真正的学习,会耗费大量的时间,这个时候就不是听听故事便足够了,而是需要个人反复练习。另一方面,每个人的情况不一样,想要制定合适自己的学习计划,恐怕只有一对一的交流,才能产生真正的价值。

    总而言之,我决定只讲干货,也就是用户听了,他就会了,按照我讲的思路,12345,上手就能干活。我认为如此一来,多学多练,构建起自己的技术体系,比听别人的故事收益更大。至少,我当年就是这么学的。

    但是就结果来看,我的课卖的并不好。我觉得跟我自身品牌有很大关系,还是要继续积累。上次课讲完,有个同学找到我,说觉得我的课更干货,鼓励我坚持下去。其实这个时候听到这样子的鼓励,心里还是挺暖的。

    道 & 术

    上次直播到问答时间,立刻就有同学提问一个我认为我已经说清楚的问题,或者说,我PPT里明确讲到的问题。对此我也进行了反思。

    我当然不会认为是同学没有认真听讲,大家都是花钱来的。反省之后,我认为,在讲述的过程当中,我想传达的是“道”,也就是所以然;但是很多同学,因为经验问题,因为视野问题,他可能只想听“术”,也就是然。

    从备课的角度来说,我一定要做到逻辑自洽,不仅要讲明其然,还要讲明其所以然。所以在实践过程中,我可能更关注的是讲明其所以然,也就是原理,回归到规范、定义、浏览器实现等更基础的地方;但是听众想知道的很可能是具体操作。比如布局,我会讲,外层元素没有被浮动的子元素撑开,是因为外层元素没有触发独立的 BFC,然后 BFC 是 XXOO,所以你这个时候要想办法触发它的 BFC;但是听众其实更关心“高度塌陷”怎么解决?浮动怎么清?BFC 什么的一下听不懂就整体忽略掉了。

    这是我日后需要注意的地方:减少掉书袋,讲好What How Why。


    最后给下一场打个广告。

    写 CSS 也要开脑洞:万能的 :checked + label 将于4月27日,下周四,晚上8点直播。这场课程,是既有基础,又有进阶的中级课程。相信会对大家有所启发,欢迎大家光临。

  • 第二次直播课程完结,兼谈对前端,对培训行业的看法

    第二次直播课程完结,兼谈对前端,对培训行业的看法

    这篇文章写于上周,结果赶上服务器故障,写到一半去迁机器了……参见上篇文章

    前些天播出了直播课程的第二讲,《Promise 的 N 种用法》,感觉播出本身还算成功。现场气氛不错,学员们积极提问,我做完解答,大家也纷纷表示听懂了,有收获。

    如果人多点就更好了……

    这里再打次广告,课程地址:https://segmentfault.com/l/1500000008757392。购买后可以任意回看,页面上还有推广链接,分享可以得实惠。如果大家想学 Promise 的用法,看这个视频,就够了,完全够了。

    最开始策划这堂课的时候,把问题想简单了,结果做幻灯片的时候才发现,那句话:老师要想给学生一杯水,自己至少要有一桶水,古人诚不我欺。准备的时候花费了比第一次直播,比想象多得多的时间,讲试了两次,才得到了比较满意的结果。

    这次购买的人数也比上次稍微多了几个,感谢亲友团支援,也希望更多的是真实用户吧!试讲的时候,在斗鱼也取得了不错的效果,增加了几个关注,还有人给了100鱼丸。以后录像的时候,都会选在斗鱼同步直播。如果能借机积累点人气的话就更好了。

    总而言之,有进步。


    做了两次直播之后,会有朋友问我说以后是不是就准备干这个了?关于这点我有几个想法跟大家分享。

    选择这个时间去做前端培训,很合适

    在过去很长一段时间里,前端这个行业,发展非常快。新技术新框架,层出不穷,快速更迭。对于我们这些从业者来说,确实不敢放松,甚至有些同学表示担心,学不过来。这个阶段我认为不能当导师,很可能误人子弟,既坑自己,又坑别人。

    但是现在,情况有所改变。ES2017 增加的新特性数量,相对于 ES2015 而言,少得多。现在被大家津津乐道翘首以盼的,也就 Await/Async。CSS4 新增的特性,比 CSS3,也少很多。至于 ES2018,就更少了,写成博客都不带翻页的。这其实也很自然,就像 iPhone567,代际之间几乎没有什么大变化。因为过去的技术积累,其它语言当中有价值的特性,多半已经被前端吸收借鉴进来了。能够极大改善我们开发环境、生产环境的点,基本都已经被发掘过了。

    未来的日子里,我们必须学会不断打磨手头已有的工具和技术,把思路从学习吸收,向深耕细作转换。比如用 ESlint 工具维护统一的代码风格,提升代码质量,提升安全系数,补足团队短板。或者,开拓前端的新边疆,比如 Hybrid,PWA,Electron 正在做的。

    在这样的时刻,我觉得,可以停下来一段时间去做培训。正如我在上面所说,老师要给学生一杯水,自己至少要有一桶水。培训教学是非常好的总结、查缺补漏的手段。可以说利人利己。

    换个角度,现在停下脚步做培训,一时半会儿也不会落后于行业。

    终身学习的庞大市场

    这是我的第一个想法,第二个想法从罗辑思维听来,便是所谓的“终身学习”。

    在他的设想中,我们的未来,会是一个终身学习的时代,所有人都学习,并且是终身不断学习。我觉得至少在程序开发领域,他没说错,我自己就是例子。我2006年参加工作,做页面仔,切图。一边切一边学习 PHP,学习 JS,学习 AS,学习面向对象,学习开发模式,一路边学边干,走到现在。

    我没有放松过学习,并且积极走出舒适领域,主动逼自己学习。回想我的学习历程,主要分两部分:

    1. 刚工作的时候,跟前辈学,靠脸皮厚,抱着大腿猛学
    2. 把他们学得差不多了,就只能自学,订阅博客,关注微博,以及看文档读源码

    然而我发现,并不是所有人都能自学。比如前阵子认识个小妹,我发给她文档链接,她说看不懂英文……然而她必须学会,因为他们公司只有她一个前端。所以这又是一个非常大的市场,即由我,藉用我磁性的声音,清晰的普通话,带领他们学习,帮助他们学习。

    并且现阶段来看,用户的付费意愿,也蛮强烈;付费习惯,也基本养成。

    而且我觉得我周围的大多数人,还不太认可这一点,那么这也是一个机会。培训讲师常有,有10+年一线开发经验的资深前端工程师,愿意做培训讲师的,则不常有。

    与时间赛跑

    综合前面两点,我觉得,眼下这个时机,很适合切换到新跑道。毕竟以现在的我而言,一方面有前线工程师的视野和能力,另一方面又有专职讲师的时间和精力,并且我普通话说得好,声音稳定有磁性,天赋不能浪费。

    希望接下来的时间里,能把讲师做好。说实话,现在课没人买没人听,我并不太担心。我觉得这是必经之路,想想郭德纲当年一后台人给一个听众(都不堪称“众”……)讲相声,也是这么熬过来的。我花了十多年时间才成为一个资深工程师,自然也要花很多时间,才可能成为一名优秀讲师,这很自然。同样借罗辑思维的话,终身学习知识服务,不是随随便便就能搞成的,一样需要专业人士专业服务。

    所以现在我要做的,就是积累课程、积累用户、积累行业内的名气。我计划今年就干这个。所以我也是在跟时间赛跑:在全家饿死之前,把课程培训做起来。


    最后再打个广告,明天我会开始第三次直播:《Web 永恒不变的主题:布局——Box,Flex,Grid》,这次要分享的内容是比较基础的 CSS 布局,除了回顾前几年妖魔鬼怪横行的布局 hack,还会展示 Flexbox 使用和最新的 Grid。对各种级别的前端同学都是很好的一堂课。欢迎大家光临,帮我推广也感激不尽。

    另外我考虑接下来用3周时间,直播一个完整的项目,包括项目配置、webpack + babel + ES6、CSS 预处理、gulp 批处理,整个一套做下来,以及自动化测试、代码规范检查等等。这个得跟站方商量一下。

  • 新番预告

    新番预告

    下周四(4月6日)晚8点,我会继续在 SegmentFault 开播,内容是《Promise 的 N 种用法》。

    房间:https://segmentfault.com/l/1500000008757392

    欢迎光临。

    坦率地说,这次准备比上次投入精力更多,准备也更充分,试讲就准备讲两次(已经讲了一次)。同样 ¥10.24,这次比上次性价比更高。50P 的 Slide,准备了 20 份代码范例,应该是我近期最大的一笔投入了。


    今天晚上把其中递归循环也写出来了,还是很不容易呀。


    这个标题呢,开始我是想讲 Promise 相关,标题没想好,随便写了个,结果这会儿他们的直播数量还不太多,所以很轻易就给我通过了,然后还宣传了……所以我也就懒得改了,就这么着吧。

  • 小试 Element UI

    小试 Element UI

    不确定写多长,写先结论吧:暂时不推荐使用。原因如下:

    1. 影响使用的小 Bug 有点多
    2. 需要重新学习一门语言


    接下来详述。

    从前司离职之后,我开始更新技术栈。离开惯用的 Backbone,考虑再三,投入 Vue 怀抱。选择 Vue,而不是竞品 Angular、React 有三个理由:

    1. 文档友好,社区活跃。
    2. 模块拆分的很好,学习曲线平缓。
    3. 基于标准化技术,可以最大限度的避免浪费。

    不过实操之后发现,Vue 与我惯用的 Bootstrap 有些冲突,主要在于:

    1. Bootstrap 对过渡效果和切换的操作依赖于样式,比如 .active.in。Vue 在处理模板时会把当前样式先缓存起来,然后根据数据增删绑定的样式。此时就可能出问题,tab 页切不动或者动画突然打断之类的。
    2. Bootstrap 会广播特定的事件,这些事件无法被 Vue 捕获,只能在 mounted() 的钩子里手工绑定。

    于是我觉得,既然根基(jQuery)变了,最好把整条线都更新了吧。左右看了看,准备先试下 Element UI。这是饿了么推出的基于 Vue2.0 的组件库,目测组件齐全,文档详细,而且直接以 2.0 为基础,符合我追新的想法。

    实际用了之后……唉……有点……遗憾。项目地址

    首先,Element UI 把所有组件都封装了,包括布局,比如 <el-row><el-col>,我觉得这样太过了。从现实经验来看,布局元素几乎不可能够用,别人总要补充一些。封装的元素我不太知道最终生成的代码是什么样的,也就不好操作,总不能审查元素一个一个看吧?——对了,Element 的文档里缺少样式列表,也是个问题。

    封装的另一个问题,所有元素都要通过后期渲染,总让我感觉不舒服。以及,我几乎无论干什么都要查文档,几乎没法直接动手,这和我选择 Vue 的初衷是相违背的。

    接下来,小 Bug,有点多。除去布局和提示之类,我只用到3个组件:<el-button><el-table><el-pagination>,结果就遇到4个 bug,浪费很多时间去调试,有两个我给他们开了 issue,还有两个懒得弄了。这里列一下吧:

    1. <el-button :loading="scope.row.fetching"> 无法把 loading 绑定到数据的 .fetching 属性上
    2. <el-pagination> 设置 total 不更新视图
    3. <el-pagination> 更新 total 之后再次广播 current-change 事件,导致重复刷新
    4. <el-table> 里每行的 ref 属性没法正确生成数组

    2017-04-04 更新:

    经过 issue 沟通,我的理解的确有些问题,

    1. Vue 绑定属性的时候,如果该属性层次较深,比如 a.b.c,就不会修改它的 getter/setter,于是会失去响应式更新的特性;同时也不会报错。
    2. <el-table> 不是通过 v-for 渲染的,自然 ref 的表现也就正常了。

    可能别的组件很健壮吧,我运气不好。

    总之,我觉得就目前这个版本,1.2.5,来看,Element UI 还没到让人放心用并且用得好的程度。

    下一次我可能会选别家的再试下,或者继续用 Bootstrap 然后自己拼些小组件出来——我这次就是想找个有 loading 的 button 才找 UI 库的。


    啊,最后,还是感谢 Element UI 团队,感谢饿了么。希望你们再接再厉,相信将来这套库会更好。

  • 准备搞一场专题直播

    准备搞一场专题直播

    准备在 SegmentFault 搞一场专题直播,标题是《jQuery, Backbone, Vue》,计划通过对比老中青三代框架开发的差异,带领大家理解前端发展的趋势,接触更好的未来。

    直播地址:https://segmentfault.com/l/1500000008694676
    幻灯片地址:https://meathill-lecture.github.io/jquery-backbone-vue/
    范例代码仓库:https://github.com/meathill-lecture/jquery-backbone-vue

    求关注,求购买。

  • Ubuntu 16.04 搭建 LNMP 开发环境

    Ubuntu 16.04 搭建 LNMP 开发环境

    前天帮人配了台机器,未来可能还要帮人配。在学会用 Docker 之前,先写一篇记录下怎么搭建环境吧。

    这篇收费!¥4.99,请阅后自觉打钱。

    (更多…)
  • 一个超级诡异的 iOS Safari `position: fixed` 失效问题

    一个超级诡异的 iOS Safari `position: fixed` 失效问题

    今天前同事李某找我咨询 Hybrid 开发的问题,想起来大前天搞这个问题搞了一天,赶紧记下来,省得忘记。

    先说需求。东家让我做个日历组件,在手机 Web 上用。组件的样式是这样的,很多地方都可以见到,比如南航国航的客户端。

    日历控件需求图

    看起来并不复杂,事实上也是,基本上顺顺利利的开发完成,准备交付。这里有个伏笔,开发中我按老习惯,使用桌面 Chrome,和实际生产环境不太一样。不过我自然要去真机上测试,结果一测问题就出来了。

    因为组件需要全屏展示,所以我设置了如下的CSS:

    .date-picker {
      position:fixed;
      top:0;
      left:0;
      right:0;
      bottom:0;
      background-color: white;
      z-index:1024;
    }
    

    同时,对原本的 <input name="date">,我给它加上 readonly,避免弹出虚拟键盘。理论上,这样的就可以了。但实测时,不滚屏的时候,组件弹出时尺寸是准确的,盖满全屏;然则一旦滚屏,组件就会占据从页面最上方到当前最下面这截位置。大约相当于 position:absolte;top:0 的效果。

    Safari 截图
    手机截图
    如图,可以看到组件占据了全屏,但实际是从页面最上面开始的,定位有问题。用桌面 Safari 调试也可以看出来它的高度是 968,远大于正常的 667。

    这很诡异,上下左右全为0,是上古巨兽 IE6 都支持的做法。iOS Safari 虽然 Bug 多多,不应该连这个都有毛病啊。以 ios safari position fixed 为关键词 Google 之,结果 iOS Safari 历史不清白,当年 iPhone 刚出的时候的确有定位问题,于是虽有满屏的结果,但都不适用。

    然后我想到找其它库,比如 Bootstrap,它的 Modal 组件也是类似的效果。但是怎么测都正常,于是我只好一个样式一个样式修改,仍然没有结果。

    时间慢慢流逝,转眼已经凌晨2点了,就在我几欲放弃之际,突然发现,虽然组件弹出的时候定位有问题,但只要我点掉下面的完成,定位就会立刻恢复正常。

    手机截图
    注意,就是那个“完成”。

    问题至此已经明朗:在 iOS Safari 里,即使 <input> 设置了 readonly,它仍然可以获取输入焦点。获取输入焦点之后,虽然没有弹出虚拟键盘,但仍然是待输入状态。

    此时页面各种交互都是正常工作的,比如点击、滚屏。唯独 position:fixed 定位有问题。点击“完成”离开输入状态,Safari 自动刷新页面元素,定位就正常了。

    于是我在组件弹出后,自动 input.blur(),使其失去焦点,组件的尺寸便正常无误了。


    总结

    移动端 Web 开发总有各种各样稀奇古怪的问题。有些好解决,有些不好解决,比如这个问题,很难定位:

    1. 历史不清白,搜也搜不到
    2. 组件要求全屏,需要避免虚拟键盘,所以会改变默认行为
    3. 其它情况下都是好的

    我能想到的方案,就是想办法,用所有能用的工具,排除掉所有其它问题,最终还是能搞出来的。

  • FontAwesome 通过组合创建新图标

    FontAwesome 通过组合创建新图标

    FontAwesome 提供了很多好看的图标,使用 WebFont 嵌入页面更是简单又好用,所以我基本上一直用它。不过有时候还是觉得不太够用,这就需要复合使用多个图标。

    下面是个例子,我在图标的右下角增加一个圆形加号,表示增加、创建。

    See the Pen add icon by Meathill (@meathill) on CodePen.

    这里有两个选择:

    1. FontAwesome 提供了一个堆叠图标的样式:fa-stack,可以堆叠任意多的图标。
    2. 因为它实际上只占用了 :before,所以也可以使用 :after 来容纳新增的图标。如果只需要两个图标,这个方式更简单。