Growth CSS

Growth CSS

@(Front End Growth)[前端开发, Vue.js, JavaScript, github]


Front End Growth 系列文章。记录 XX 前端成长过程的点滴。仅供参考,也许不具备通用性,请结合自身实际,切勿强行模仿~
Growth CSS 介绍了 XX 对 CSS 的认知以及学习、应用上的建议。


What is CSS

是一门面向交互设计、视觉设计的声明式语言

  • 视觉
    • 布局 (display、margin、padding、width)
    • 字体排印 (font、text、color)
    • 装饰 (background、box-shadow、gradiant)
    • 动画 (animation、transistion、transform)
  • 交互
    • 反馈 (:hover, :visited)
    • 引导 (position: fixed)
    • 互动 (:hover .show)

也是一门需要一些技巧或工具来优雅编码的伪 OO 语言

  • 面向对象
    • 继承 .parent{styleA: xxx;} .child { styleA: inherit; } / .parent() {} .child { .parent(); }
    • 扩展 .classA.classB / .classA() {} .classB() {} .classC() {} .classFinal {.classA(); .classC(); style:xxx;}
    • 重载 .classA.classB .classA { xx: oo} .classB { xx: xx}
  • 代码规范
  • 代码复用 DRY (Less)
  • BEM
  • 变量、函数命名
  • 权重控制
  • 语义性

How I learn CSS

  • 概念(flexbox 布局)
  • demo(动手调试一下所有 flex 属性)
  • 应用(使用所学技术,实现一个页面 or 模块 or 方案)
  • 融汇(与已有知识体系进行关联,梳理知识、归纳、分类)
  • 贯通(结合已有的相关联知识点,头脑风暴,例如:实现垂直居中的 N 种不同方案 )
  • 初心(根本目的是为了实现视觉效果,所以心中永远有一个当前场景最合适方案)

How I Code CSS

Consideration

  • 视觉还原度
  • 兼容性
  • 性能
  • 开发效率
  • 可维护性
    • 语义性
    • 权重控制
    • 嵌套层级
  • 可控颗粒度
  • 调试技巧

CSS Code Standards

BEM

Less

Learning Tips

毕竟 CSS 是一门“面向视觉”的语言,所以学习资料尽量以图像为主,可以加深记忆效果。

@Design

与设计师的沟通

设计理念

一致性 可用性 易用性 反馈

这里不一定实时更新,可以关注 github 地址获取最新内容:

https://github.com/xunge0613/front-end-growth/blob/master/tech-growth/growth-css.md

前端开发负责人修炼指北

前端开发负责人修炼指北

大家好,我叫XX,江湖人称吃土小2叉,目前担任公司的前端负责人半年多了,一路上摸爬滚打,历经团队人员变动,近日颇有感触,于是结合自己近半年的前端负责人实践经验,权当作一个学习记录,整理归纳一下前端负责人的修炼要点(大部分只是记录了关键词,没有详细展开),以及自己的实践记录。一些观点可能不是很成熟,也可能都是一些政治正确的废话…… 欢迎各位老司机多开车指点指点,交流交流哈~.

职责

  • 营造存在感、归属感、成就感
  • 把控技术方向
  • 新人引导
  • 促进团队提升、培养团队
  • 权衡公司利益以及 队员利益
  • 与其他部门衔接和沟通
  • 创造希望 (eg: 画大饼、某种意义上的程序员精神鼓励师)

关键词

团队建设、技术选型、人员安排

  • 团队建设
    • 技术氛围
    • 人文氛围
  • 技术选型
    • 产品需求
    • 稳定性
    • 兼容性
    • 开发效率
    • 招人难易度
    • 留人难易度
    • 转型成本(时间成本、学习成本)
    • 舍弃用户成本(转化率:兼容性; 访问量:SEO)
  • 人员安排
    • 让优秀的人变得更优秀 (技术栈:最前沿的技术; 老带新)
    • 让普通的人加速提升 (技术栈:最成熟的技术)
    • 淘汰余下的人

常见问题分析

面试时经常遇到一些人的离职原因就是以下一些……

1. 没有提升

什么是提升?

  • 更快解决问题 7
  • 更优解决问题 8
  • 解决以前不能解决的问题 9
  • 编程能力提升 (编码、设计、架构) 9
  • 掌握新技术、新语言、新工具 5
  • 工资提升 6
  • 知名度 7

注: 数值为XX认为的较为合理的权重值,满分10,个人意见,仅供参考

如何提升?

缺一不可

  1. 时间
  2. 方向
  3. 坚持
  4. 实践

加分项

  • 聪明 (XX注:可遇不可求)
  • 有老司机指点 (XX注:可遇不可求)
  • 好奇心
  • 自我驱动力/主观能动性
  • 专注

注: 除去 聪明、 有老司机指点, 这两个是可遇不可求的; 其余都是可以后天培养的。

为什么没有提升?

工作只使用旧框架、旧技术 【应聘人经常提及】
基础薄弱,学新技术难,求带,抱大腿
光看不练
没有时间
前端要学的太多太杂,学了这个忘了那个
新框架一个又一个, 来不及学

负责人能做的

  • 保证产品稳定性,满足产品兼容性需求的情况下,尽量让团队使用最前沿的技术
  • 推动团队技术学习、分享氛围,必要时给予物质奖励
  • 为成员腾出一定自由时间
  • 让自己成为队员的大腿、答疑解惑
  • 完善技术文档
  • 写优秀的代码
  • 造轮子、改进项目基础设施
  • 挡需求、砍需求、改需求、加需求

负责人不能做的/很难做的/不应该做的

  • 不应该回答what的问题、 减少回答how的问题,而是更多回答why的问题
  • 不应该每天催着队员去学习、去分享,而是要激发队员的自我驱动力、主观能动性
  • 不应该安排超负荷任务,而是分配合理的任务总量
  • 不应该花费大量时间(80%)开发业务需求,而应该花一半时间(50%)思考和设计如何改进现有开发模式

2. 没有成就感

如何获得

  • 回报 >= 付出 (精神、物质)
  • 对产品的认可
  • 对技术栈的认可
  • 对自己付出的认可
  • 对他人付出的认可
  • 助人且助人的反馈是积极的
  • 个人发展、晋升

概况: 回报 >= 付出 (精神、物质)

3. 加班太多 没有时间 到家后太累了

首先明确一点,业务需求是永远做不完的

我们能做的,只是每周根据已有的开发资源,开发相对最重要最紧急的业务

另一方面,也要注意: 程序员自我提升 的重要度也是极高的

队员层面

  • 合理评估工期
  • 不断提升自己,不断提高效率
  • 量力而为,保重身体

负责人层面 【主要背锅人】

  • 合理审核工期
  • 合理安排任务 【重要】
  • 技术选型是否合理、是否高效
  • 新人的引导是否到位

4. 技术分享参与度不高

如何改善

  • 负责人牵头分享
  • 奖励机制
  • 避免布置过饱和任务量

应聘人的期望

(以下回答来自XX面试过的应聘人)

  • 我比较期待能有一个经常相互讨论最新技术的环境
  • 技术氛围好点,可以互相交流的,然后加班不要太多,有意义的加班可以接受
  • 希望有挑战性和持续成长空间,同事之间比较容易沟通的,当然做的产品有趣就更好了
  • 希望有大牛带
  • ……

XX实践

团队建设

技术氛围

  1. 技术分享考评制度(鼓励竞争 、 与培训机会、年终考核挂钩)
  2. 定期 code review (2周1次) 优先级: 高
  3. 不定期 小分享 (不限次~2周1次) 优先级: 高
  4. 定期 大分享 (2个月1次)
  5. 鼓励参与翻译英文技术文章
  6. 整理、维护、更新前端知识库 wiki (涵盖: 代码规范、工具教程、开发流程、组件 Demo、语言教程等)
  7. 前端每周一题 , 以经典案例题形式传授实际价值较高的知识点
  8. LeetCode 刷题活动 (算法题为主)
  9. 每周周会只探讨各自遇到的难题1~2个,思考更优解
  10. 开源项目 【构思中】
  11. 新技术交流、研讨会 【构思中】
  12. 以上各种分享,负责人带头进行

考核制度 DKP

v0.1 版本 考察两个维度: 分享贡献度、业绩贡献度; 每个月设置合格线,低于合格线进入考察期

  • 试行了1个月,实际效果一般,参与度不高,仅一人达成分享贡献度合格;
  • 不同产品线业绩难以量化衡量;
  • 较反感惩罚制度

v0.2 版本 仅考察 分享贡献度。不设合格线,分值仅作为奖励评定标准

团队氛围

(需加强)

  • 多关心队员真实诉求,阶段性一对一对话
  • 设定阶段性目标(例如:官网重构计划),达成后一同庆祝
  • 定期组织 TeamBuilding

技术选型

数据驱动 + 业务驱动 + 人才驱动

  • 产品需求
  • 稳定性
  • 兼容性
  • 性能
  • 开发效率
  • 技术价值 (对程序员自我提升产生的价值)
  • 招人难易度
  • 留人难易度
  • 转型成本(时间成本、学习成本)
  • 舍弃用户成本 (数据驱动)
    • 舍弃兼容性带来转化率下降的成本: IE8 用户
    • 舍弃SEO造成访问量下降的成本: SEO 流量

人员安排

  • 让优秀的人变得更优秀 (技术栈:最前沿的技术; 老带新)
  • 让普通的人加速提升 (技术栈:最成熟的技术)
  • 淘汰余下的人

技术选型规划

以 PC 官网前端重构计划为例

现状

jQuery + 类 require.js 加载机制 + less + gulp + C# , 传统电商网站

目标浏览器

不低于 5% 访问量的浏览器

目标流量来源

SEM + SEO + 市场活动推广

其中, SEO 目前平均占比约 15% 流量

业务痛点

设计风格不统一、特别大量重复性工作 (各种合作方系统定制化移植官网)、 前后端耦合程度大

人员痛点

技术栈落后、招人难、留人难

重构好处
  • 组件化设计: 提高代码复用性;有助于快速移植组件、促进合作方项目进度同步
  • 技术栈升级: 有利于招人以及留人
  • 前后端分离: 有利于提升开发效率
重构弊端
  • 时间成本: 大量
  • 兼容性成本: 只兼容IE9+
  • 白屏时间: 比起传统服务器端渲染,会存在一定的白屏时间,而短期内不一定会使用 node.js + vue.js SSR
路线图
  1. 在后台管理系统中试点 Vue.js 框架,积累 Vue.js 经验 【DONE】
  2. 在完成 2~3 个后台管理产品后,渐进式(帮助中心页入手)改造官网前端 【View层 Vue.js框架 ; Action 层 c# .net】 【PLAN】
  3. 在确定舍弃 IE8 用户后,官网全站转型 Vue.js 框架
  4. 在确定舍弃 SEO 流量 改用 Vue-Router , .net 只提供容器
  5. Vue.js + Node.js 服务器端渲染有一定积累后,官网前后端完全分离

近期实践

时间 分类 内容
2017.4.8 讲座 前端小组集体参加中第二届国前端开发者大会…… 公司报销
2017.4.14 大分享 XX: 自动埋点工具介绍(很low……) ATM https://github.com/xunge0613/ATM
2017.4.21 小分享 XX: 掘金翻译计划参与体会 + GitHub Review 功能
2017.4.23 技术研讨 官网 PC 前端重构规划

任务安排

2 – 8 原则

如何做

数值仅供参考,具体情况具体分析
每周任务安排 4 天工作量
每天花 0.2 天 , 约 1.5 ~ 2 小时,自我提升

目的

为了提升队员开发效率

定期安排技术型任务

  • 督促技术提升
  • 考核方式

按需分配需求

一般业务需求无非考验以下两点

  • 业务熟悉度
  • 技术熟练度

理想情况下,对于业务不熟悉的队员,优先分配需要熟悉业务的需求;反之亦然

结语

知易行难
贵在坚持


题外话: XX的前端奇妙历险

3年弯路
13 年 4 月实习加入一家初创公司,工作不到半年,原先前端 leader 转岗做运营,只剩下我一个前端,持续了半年左右。由于人少,写前端的同时还要写 C# 代码,偶尔研究 SEO,兼职半个网管,还负责了每天晚上给加班童鞋点晚餐外卖…… 这个状态差不多从进入公司开始持续了 2 年。所以虽然自己工作了也有将近 4 年了,但精力比较分散,走了很多弯路,做了许多重复性劳动;同时又与外界其他前端的交流很少,唯一和外界的交流机会几乎就是当面试官与应聘人交流;且当时很长一段时间疲于业务开发,经常 9、12+、6 ,自己学习主动性下降了许多,业余一有休息时间自己几乎也是“荒废”了,也不再如大学时自学前端那阵子折腾自己的博客站点、折腾各种技术、写博文做小结(单反穷三代、游戏毁一生)。前端技术的沉淀比较欠缺。另一方面,也大约3年左右时间单相思,受困于情感问题耽误了不少时间。

简单来说,前 3 年走了很多弯路,几乎是 3 年的工作时间以及 1 年的加班时间,换来了 0.5 年的前端经验,原因是: 精力分散、视野狭窄、缺乏实践、缺乏学习主动性、缺少反省、公司缺人。

决定性时刻
后来,陆陆续续前端团队一点点扩张,但直到去年年中,一共也只有 3 个前端,应付公司 3 个电商类前端产品(PC + M)。也一直没有所谓的前端 leader,都只是各自负责各自的产品线,大家也都很年轻,2~3年经验。当时 CTO 问我,要不要招一个资深的前端来带我们,还是让我们自由竞争,我当时也挺迷茫和纠结,一直以来,都感觉自己对于前端职责的定位以及今后发展方面,缺乏系统和全面的认知,以及也不清楚技术团队的 leader 的职责应该是什么,觉得如果招个老司机,自己能有更明确的目标和规划,同时对公司来说虽然要负担更多的薪资开销,但是想必能有更多可能性,会有更多回报。而自己这几年在前端上基本是靠自己摸索以及参考知乎上的解答。

半年来
结果是,去年下半年,我受命担任前端组负责人…… 恰逢自己终于决定放弃 3 年多的单相思。于是打鸡血般花了大量时间接触外界,开阔技术视野,(包括参加了许多前端的知乎 live ,从最早围观的小爝老师、Hax 老师…到近期 vczero 、吕毅以及 justjavac 大神们的 live,以及 姬光、i5ting、小问等大大的 gitchat……以及 vczero 和 前端早读课情封 的小密圈…… 以及加了 豪情大大的前端 js 跳板 QQ 群…… 以及传说中的微信小程序联盟论坛,以及相关的 QQ 群,每天至少回答群里一个小程序的技术问题 ),研究新技术,补习自身基础,研究如何带团队,促进团队提升… (然后也就有了现在这篇文章) 现在前端团队一共 6 人…… 还在招…… 欢迎推荐……

Anyway, 最好的学习时间是昨天和现在,即使花了 3 年多走了那么多弯路,至少,现在正了一些,也不错啊。

最后,还是想感谢一下,领导对我的信任 =。= 以及同事们的支持以及各位大神们的指导~

 

观后感:2017第二届前端开发者大会

从我一个毕业快四年的前端小菜鸟的角度,关于昨天第二届前端开发者大会一些小想法&记录(有点长长长长长……)
欢迎探讨、指点~
今日关键词: 解决问题、自我定位、 未来发展

今天议程的主题,有Vue,有weex,有动画,有redux,有RN,有CRN,甚至还有Model层面的ReactiveDB。
简单概括一下,大致内容就是,为了解决XX问题,为了改善XX现状,基于XX理念,使用了XX技术,带来XX好处,[存在XX不足]……
而前端框架的发展,也是为了解决日益增长的产品复杂度同落后的开发能力、开发效率之间的矛盾。
而我们实际工作中,身为一个前端码农,首要的工作职责就是解决工作中遇到的问题,至于前端技术选型,本身也是为了公司的业务和产品所服务的,要从自家产品的实际角度出发,权衡留人能力,招人难易度,开发效率,稳定性,兼容性,可靠性,用户体验,技术转型的成本等等因素,不能盲从也不能落伍。

而至于前端自身的定位,想到5年前我引用了2位大神的思维导图在知乎上的回答“一名合格的前端工程师的知识结构是怎样的”……
虽然许多名词已经逐渐退出视野,但其实我们开发的本质还是没有变化,本质上是为了打通产品与用户之间的最后一道门,技术只是为了解决特定问题而存在的一种工具。
因此在具备一定技术、能力之后, 更需要具备一种使命感,要对产品本身质量负责,对开发进度负责……
接着,不停地学习,横向与纵向知识面的深入……
今天的几个议题中有不少问题的性能优化方案也都是借鉴了操作系统的设计模式,若是产品足够复杂,就如今天Teambition的案例,前端的数据种类非常多,数据间的关联性非常强,并且产品对于实时性要求特别高,针对这种业务场景,若还是使用jQuery,难以想象其维护难度和成本…… 而他们目前前端采用的解决方案,更像是传统后端、客户端做的事情。

关于未来发展,全栈是极好的,但人的精力是有限的,在优点方面发挥出自己极限,树立起你的不可替代性和价值。

最后感谢公司 @爱回收 报销了前端组参加这次活动的门票钱~

【MDN翻译】CSS常见问题

翻译作者:徐迅 XuXun(清风迅来 XX)

最后更新:2014年5月16日2:24:34
原文链接:https://developer.mozilla.org/en-US/docs/Web/CSS/Common_CSS_Questions
译文链接:https://developer.mozilla.org/zh-CN/docs/Web/CSS/Common_CSS_Questions

1 为什么我的CSS语法正确,但没有正常渲染?

 

2 为什么我的CSS语法正确,但完全没有渲染?

为了应用CSS,Web服务器必须以 text/css MIME 类型来处理 CSS 样式表;反之,CSS将不会被渲染。

3 id 和 class 有什么区别?

 

4 如何将CSS属性恢复到默认值?

 

5 如何继承CSS规则?

 

6 如何为一个元素设置多个class?

 

7 为什么我的CSS规则没有起作用?

 

8 诸如 -moz-*, -ms-*, -webkit-*, -o-* and -khtml-* 之类的属性的作用是什么?

 

9 z-index 属性与元素定位有什么联系?

 

未完待续

徐迅 / 叉叉 / 清风迅来
XuXun / XX / Dalston Xu

Google Analytics 使用技巧

作者:徐迅 XuXun(清风迅来 XX)

最后更新:2014年5月13日1:16:18

本文为徐迅童鞋在使用Google Analytics(简称GA)过程中学习、整理的一些使用技巧,如有不足或有更好的方案,恳请各位大神指点!

1 如何使用同一份GA统计代码,统计不同子域名网站数据

答:使用“过滤器 Filter”

进入“管理”界面,选定主域名网站所在的“媒体资源”,在“查看”部分中,选择“创建新视图”

新建报告数据视图
新建报告数据视图

创建完之后,在“过滤器”选项中,选择“+新过滤条件”,为过滤器命名:仅 m.aihuishou.com ;

接着最关键的一步到了,“过滤器类型”中选择“预定义过滤器”,在下面的单选框中,选择“仅包含”,“访问主机名的流量”,“等于”,然后在下方输入框中填入子域名的地址:m.aihuishou.com

向数据视图添加过滤条件
向数据视图添加过滤条件

点击保存后,就OK了

过滤器添加成功
过滤器添加成功

本方法的原理其实很简单,

  1. 首先第一步也是很重要的一步是要确保在子域名上也添加了相同的GA统计代码。
  2. 第二步,我们创建了新的数据视图,而这个时候又因为子域名下部署的统计代码属于主域名下的网站,不构成跨域,所以在统计数据中将不仅包含主域名下流量,还会包括子域名下的流量(只要部署了相同的统计代码)。
  3. 第三步,我们其实要做的就是将这份子域名下的流量给剥离出来,这个时候就用到了过滤器,我们设定过滤规则为仅包含该子域名的流量,这样就可以实现在同一份GA媒体资源中,统计单独的子域名网站数据了。

2  如何检测用户在网站上进行了哪些站内搜索操作?

答:很方便。如图,在数据视图分栏下,选择“查看设置”,在最下方找到“网站搜索设置”,开启后,在下方输入框中输入你的网站中搜索输入框的关键词字段的input name即可。

网站搜索设置
网站搜索设置
未完待续
徐迅 / 叉叉 / 清风迅来
XuXun / XX / Dalston Xu

前端开发经验札记

最后更新:2014年5月1日1:57:33

作者: 徐迅 (清风迅来 XX)

真正从事Web前端开发有一年多了,而接触前端最早可以追溯至小学时候电脑课上的网页制作,那个时候还在使用Front Page(我才不会说那个时候自己设计的网页巨丑…);后来一直到大学才“重拾旧业”:大二曾帮老师做过课程介绍网站,使用的仍然是DreamWeaver,并开始搭建 xuxun.me ;大三拥抱notepad++和zen-coding,开始折腾JavaEE的项目;大四毕业设计又回归PHP,偶尔接触了Python;工作以后爱上sublime text 2、less和coffee script,在C#坑中渐行渐远。

希望这篇文章能一直更新下去吧.

加油XX,奔跑在大前端之路上吧!

一、前端语言基础

(一)HTML

     1 标签语义化:使用合适标签,少使用无语义标签
     2 使用 <!DOCTYPE html> 既可以向前兼容,又体现了你网站的高大上!
     3

(二)CSS

     1 选择一款合适的CSS预处理语言(个人比较喜欢Less),大大提升CSS编写效率
     2 通用的样式提取成 .class 或者 less 中的 mixin() {} 更佳
     3 多使用限定度高的选择器, 例如 > + , 尽量避免后代选择器过度使用
     4 多用组合少用继承,减少耦合
     5 选择器权重222原则(XX自创……): 选择器权重不超过222,即最多2个id,2个class和2个tag……
     6 CSS伪类是个神器,例如使用:hover、:after等伪类可以替代JS实现不少效果

(三)JavaScript

     1 JS我是渣.

二、前端框架基础

(一) Bootstrap

     1 Bootstrap 的less 代码质量好,价值高,推荐学习

(二)JQuery Mobile

     1 深坑,慎入

三、前端杂七杂八

     1 适当了解浏览器的渲染机制,避免代码性能过低
     2 替换 .class 优于 替换 <xx style=”xx:xx;” ></xx>
     3 图片记得压缩, jpegtran 是个不错的jpg图片无损压缩工具

四、前端各种坑爹

1 IE 7 不支持 console.log ,因为 IE7 根本没有 console ,所以当你使用 IE 7 运行有 console.log 的页面你会悲剧..
2

 

徐迅 / 清风迅来

XX   / Dalston Xu

Google

解决Swiper中translate3d导致字体模糊

2014年4月11日0:34:17

今天公司的设计师sama跟我说,官网旧机回收首页上有个UI问题,说是用户晒单那部分的字体模糊,如下图所示:

translate3d导致字体模糊
translate3d导致字体模糊

(PS:以上原先是#666的字体颜色,为了使效果更明显于是我改成#000,原先在浏览器上比这个更模糊的画面木有截取下来= =)

嗯,这是使用了 swiper 插件,导致了文字出现了模糊。(不过在firefox、IE中倒是好的!)

于是乎我就开始找问题原因之所在咯,第一个想到是不是字号大小不一致,结果我查看了下一切都正常都是12px,特地调大还是会有模糊。

接着我想到的就是去swiper的官网上看看它的API上有木有相关的方法。

结果还真有一个:手册上有一个参数名是: useCSS3Transforms ,默认为true的,改成 false即可。

但是如果真的这么快就可以解决这个问题的话,我就用不着大费周折写这篇文章了吧……

所以结果是虽然修复了字体模糊问题,但是带来了另一个大问题.. chrome下每次滚动竟然4个一起滚了(原先每次移动1个项的)… orz ..!

于是没办法,只好在保持使用 css3 transform 的 translate3d 的情况下,继续寻找解决方案了。

在stackoverflow上,我也找到相关技术的话题讨论: http://stackoverflow.com/questions/8024061/webkit-blurry-text-with-css-scale-translate3d

网上有说是使用:     -webkit-font-smoothing: subpixel-antialiased; 这个的

也有说使用  -webkit-perspective: 1000; 这个的…

当然结果也都是木有用……

我甚至在 github 上面swiper官方的issue中找到了相关问题: https://github.com/nolimits4web/Swiper/issues/45 但问题是作者似乎木有给出有效解决方案=-=

倒是解释了下为何使用 translate3d,说是这样可以强制浏览器使用GPU来渲染,可以大大提高页面的性能,尤其是移动端(但会在一定程度上降低质量…正如API文档中所写的)

好吧,最终,又是经由API文档中另外一个参数的启发:

 roundLengths
Set to true and Swiper will round width/height values, may be useful if you have rounding errors (like 833.48px width) in responsive swiper.

于是就想是不是因为外围容器它的 translate3d 属性有小数的原因。

然后我就去看了下,结果还真是如此! 哦也!

我发现当 translate3d 属性中只要出现小数,那么容器中的文字就会有一定程度的模糊,当该属性为 *.5 时,模糊的现象最严重。

translate3d的值出现小数时会导致文字模糊
translate3d的值出现小数时会导致文字模糊

当这个值为整数的时候就木有模糊现象了!

于是就决定更新容器宽度,使之能被4整除!

这样就解决该问题了…

translate3d的值改为整数以后文字就不模糊了
translate3d的值改为整数以后文字就不模糊了

SO,现在看起来舒服多了吧~

另外: IE11 下,在 dulplicate的slide中,用户的微博头像会错位… 这个问题有点坑。。倒是IE10等都是好的..

XuXun 清风迅来

2014年4月11日0:09:01

【MDN翻译】响应式Web设计

最后更新:2014年4月3日1:32:48

Contributor:清风迅来

原文链接:https://developer.mozilla.org/en-US/docs/Web_Development/Responsive_Web_design

 

随着越来越多的用户使用移动设备来浏览网站和应用,Web设计人员和开发人员需要确保他们的作品在移动设备上同样能正常运作,并且看上去和在传统台式电脑上一样好。 著名设计师 Luke Wroblewski 主张 “移动优先” 设计而不是为桌面端设计完之后再考虑移动端。 无论您将移动设备作为主要目标来设计或作为额外目标,您都可以借助强大的CSS来保证同样的内容从手机到宽屏高分辨率显示器上,实现跨全部硬件平台访问和适应。

这种方法被称为“响应式 Web 设计”。它的一些策略包括::

  • 流式布局: 按照浏览器视窗的百分比来设定所有容器的宽度,从而使容器在浏览器窗口大小变化时自动缩放。
  • 媒体查询: 基于显示设备的物理特性(例如:尺寸、分辨率、宽高比、颜色位深等)来调用不同的样式表。
  • 流式图片: 设置图像所占宽度至多为设备的最大宽度。

Firefox Marketplace 的最低需求

如果您提交一个应用到 Firefox OS 或 Firefox for Android 上的Firefox Marketplace,那么这个应用必须响应不同的手机屏幕尺寸和屏幕像素密度。请记住屏幕最小尺寸为 320 * 480 像素。另一个常见的错误是未识别屏幕像素密度,以至于没有相应地调整字体大小和触摸目标。欲了解更多信息, 请参阅 Marketplace 审查准则

相关资源

概述

技术文档

工具

样例

译注:这篇响应式设计的概述简单地介绍了一些响应式策略,又疑似顺便为Firefox Marketplace 做了个小广告..
之后提及的一些资料,其中的pointer media query 似乎有点意思,这个是根据不同的物理指针(pointer)的精度作为media query的查询条件,比方说鼠标就是fine,表示精度很高,普通的触屏设备比如pad啊mobile啊之类就是coarse,不具备任何指针的就是none(似乎很少见诶)……
不过呢,好像这货CSS 4 才支持哦….

【MDN翻译】Web 标准

最后更新:2014年4月2日0:32:24
Contributor:清风迅来(XuXun)
Web标准 Web标准经过精心设计,旨在让广大用户享有最佳的上网体验,同时也确保在网上发布的文件经久不衰。由这些标准设计、构建的网站简化并降低了开发成本,同时又可以让更多人访问,并适应更多的上网设备。随着传统桌面浏览器的进化、新型互联网设备进入市场,经由这些准则开发的网站将继续正常运作。

参考文章

将应用从IE浏览器迁移到Mozilla浏览器
是否在迁移针对IE浏览器定制的应用到Mozilla浏览器时遇到了麻烦?本文涵盖了迁移应用到开源的基于Mozilla的浏览器的过程中相关的常见问题。
在您的网页中应用Web标准
本文概述了如何升级你的网页从而使之遵循 W3C Web标准。
为什么选择符合标准而不是私有实现?
应用通常是跨多个开发小组设计的,因此在开发过程中需要一个通用标准。
Web标准的商业价值
本文探讨了遵守Web标准、丢弃私有标记和技术是如何帮助一家公司实现其商业目标的。

查看全部…

社区

  • 浏览 Mozilla 论坛…

 

工具

查看全部…

Examples

CSS, DHTML, HTML, Web 开发, XHTML, XML

The Web Standards Project

 

后注:

第一次尝试在MDN上贡献翻译文,自己英文也很久没啃了.. 翻译技巧啥的估计也都还给老师了,这篇小短文就花了我快1个多小时时间呐。。好拙计。。
总之自己好好努力…好好学习天天向上吧~

清风迅来 (XuXun)
Dalston Xu

2014年4月2日0:37:31