随便说点实际开发中的体会吧。&br&优点：&br&&ol&&li&结构清晰，便于扩展。对于模块很多的应用特别是单页 app，经常需要用 selector 来划分不同模块的 CSS 的 scope。如果满眼望去全是 .module .action .list a, .module .action .list a:hover 很难直观地理解样式应用的范围；而写成&br&.module {&br&　.action {&br&　　a, a:hover {&br&　　　//styles&br&　　}&br&　}&br&}&br&//other modules&br&这样要清晰得多。这样可维护性必然会高很多，举个例子：如果要改变样式的应用范围，增加一个适用的 action，只需把 .action 改成 .action, .action2 即可，而纯 CSS 就悲剧了，要修改每个相关 rule set 的 selector。&/li&&li&可以方便地屏蔽浏览器私有语法差异。这个不用多说，封装对浏览器语法差异的重复处理，减少无意义的机械劳动。&/li&&li&可以轻松实现多重继承。&br&.box {&br&　display:&br&}&br&.thick-bordered {&br&　border: 5&br&}&br&.notice {&br&　.&br&　.thick-&br&}&br&这样无论父类有什么改动子类都会同步更新。有人说这个在 HTML 中把 class 写成 &notice box thick-bordered& 就好了，但是这样增加了HTML 与样式的耦合，如果模板中有多个 .notice 在修改时就难免做重复劳动，同时除了修改过的 CSS 文件外，客户端缓存的 HTML 模板也需要重新下载。在 LESS 中，如果利用 mixin 来作继承在编译后都无需生成无用的父类样式代码。&/li&&li&完全兼容 CSS 代码，可以方便地应用到老项目中。LESS 只是在 CSS 语法上做了扩展，所以老的 CSS 代码也可以与 LESS 代码一同编译。&br&&/li&&/ol&&br&缺点：&br&&ol&&li&须要编译。无论是放在客户端还是服务器端，都是一种额外的花销。&/li&&li&作者更新不够活跃，对社区的力量使用不足。作者对 GitHub 上的 pull request 基本置之不理，他解释说是 GitHub 上的通知让他看不过来所以基本都无视了。所以使用中遇到的一些问题可能官方代码得不到及时的更新。&/li&&/ol&
随便说点实际开发中的体会吧。优点：结构清晰，便于扩展。对于模块很多的应用特别是单页 app，经常需要用 selector 来划分不同模块的 CSS 的 scope。如果满眼望去全是 .module .action .list a, .module .action .list a:hover 很难直观地理解样式应用的范…
泻药。&br&&br&这种 Google 一下就能找到的问题真心不建议来知乎提问。&br&&br&不同的写法是对应不同时期的 Flex 规范，强烈建议使用 &a href=&/postcss/autoprefixer& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&autoprefixer&i class=&icon-external&&&/i&&/a& 自动增加前缀，在开发的时候只写标准属性「display:flex」，然后通过插件自动生成前缀。&br&&br&各个写法的兼容性如下：&br&&br&&div class=&highlight&&&pre&&code class=&language-css&&&span class=&nc&&.foo&/span&&span class=&p&&{&/span&
&span class=&k&&display&/span&&span class=&o&&:&/span& &span class=&o&&-&/span&&span class=&n&&webkit&/span&&span class=&o&&-&/span&&span class=&n&&box&/span&&span class=&p&&;&/span& &span class=&c&&/* Chrome 4+, Safari 3.1, iOS Safari 3.2+ */&/span&
&span class=&k&&display&/span&&span class=&o&&:&/span& &span class=&o&&-&/span&&span class=&n&&moz&/span&&span class=&o&&-&/span&&span class=&n&&box&/span&&span class=&p&&;&/span& &span class=&c&&/* Firefox 17- */&/span&
&span class=&k&&display&/span&&span class=&o&&:&/span& &span class=&o&&-&/span&&span class=&n&&webkit&/span&&span class=&o&&-&/span&&span class=&n&&flex&/span&&span class=&p&&;&/span& &span class=&c&&/* Chrome 21+, Safari 6.1+, iOS Safari 7+, Opera 15/16 */&/span&
&span class=&k&&display&/span&&span class=&o&&:&/span& &span class=&o&&-&/span&&span class=&n&&moz&/span&&span class=&o&&-&/span&&span class=&n&&flex&/span&&span class=&p&&;&/span& &span class=&c&&/* Firefox 18+ */&/span&
&span class=&k&&display&/span&&span class=&o&&:&/span& &span class=&o&&-&/span&&span class=&n&&ms&/span&&span class=&o&&-&/span&&span class=&n&&flexbox&/span&&span class=&p&&;&/span& &span class=&c&&/* IE 10 */&/span&
&span class=&k&&display&/span&&span class=&o&&:&/span& &span class=&n&&flex&/span&&span class=&p&&;&/span& &span class=&c&&/* Chrome 29+, Firefox 22+, IE 11+, Opera 12.1/17/18, Android 4.4+ */&/span&
&span class=&p&&}&/span&
&/code&&/pre&&/div&
泻药。这种 Google 一下就能找到的问题真心不建议来知乎提问。不同的写法是对应不同时期的 Flex 规范，强烈建议使用
自动增加前缀，在开发的时候只写标准属性「display:flex」，然后通过插件自动生成前缀。各个写法的兼容性如下：.foo{
CSS的早期历史可以读此文：&a class=& external& href=&http://www.w3.org/Style/LieBos2e/history/& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&w3.org/Style/LieBos2e/h&/span&&span class=&invisible&&istory/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a& ，以及CSS之父的&a href=&-/css/thesis-of-Hakon-Wium-Lie/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&博士论文：层叠样式表&i class=&icon-external&&&/i&&/a&。&br&你问到的这些特性确实大多由印刷出版业而来，我的许多答案中也提到这点，比如：&br&&a class=&internal& href=&/question//answer/&&CSS 中 margin 为何要叠加，W3C 的设计初衷是什么，未来还有没有必要存在这样的特性？&/a&&br&&a class=&internal& href=&/question//answer/&&CSS中margin-top/bottom(padding-top/bottom)百分比为何以最近的块级祖先元素的宽度而不是高度作计算？&/a&&br&&a class=&internal& href=&/question//answer/&&在 CSS 中，用 float 和 position 的区别是什么？&/a&&br&&br&CSS的设计是为了满足最常见的网页排版需求，随着后来的发展也加入了更多的特性，但是不可能“表现任意想要的效果”。比如瀑布流布局到目前为止无法单纯用CSS达成。&br&&br&以上。
CSS的早期历史可以读此文： ，以及CSS之父的。你问到的这些特性确实大多由印刷出版业而来，我的许多答案中也提到这点，比如：
这是典型的&b&因果倒置&/b&。事实上，正是由于 web 技术在标准化过程中&b&进展缓慢&/b&，拖了技术进步的后腿，谷歌之类的浏览器厂商才引入了 -webkit 之类的前缀，使得自己能够&b&超前&/b&标准的实现一些特性。&br&&br&但是现在大家越来越多的使用前缀，导致 web 又陷入跨浏览器兼容性泥潭，恰恰再次印证了标准化的缓慢程度和应用领域对这些特性的强烈需求之间的矛盾。&br&&br&所以，解决眼下问题的根本在于加快标准化进程，而不是责怪前缀本身。
这是典型的因果倒置。事实上，正是由于 web 技术在标准化过程中进展缓慢，拖了技术进步的后腿，谷歌之类的浏览器厂商才引入了 -webkit 之类的前缀，使得自己能够超前标准的实现一些特性。但是现在大家越来越多的使用前缀，导致 web 又陷入跨浏览器兼容性泥…
来自 yahoo 的一个 ppt 全面的介绍了网页图片的压缩技术，其中提到很多有用的方法和工具。&br&大纲列这：&br&&ol&&li&优先用 png 而不是 gif&/li&&li&压缩 png&/li&&li&去掉 jpg 的 metadata&/li&&li&压缩 gif 动画&/li&&li&尝试使用 png8&/li&&li&避免使用 AlphaImageLoader&/li&&li& 压缩动态生成的图像&/li&&li&使 favicon 更小 可缓存&/li&&li&使用 CSS Sprites&/li&&/ol&&a href=&http://www.slideshare.net/stoyan/image-optimization-for-the-web-at-phpworks-presentation& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&slideshare.net/stoyan/i&/span&&span class=&invisible&&mage-optimization-for-the-web-at-phpworks-presentation&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&你所说的情况可能是它使用的是 png8 的格式，不含多余 chunk 的 png8 同等质量下比 gif 体积还小。jpg 适合压缩较大的，拍摄的，允许一定失真的图片，不适合压缩几十像素的小图片。&br&&br&&br&
来自 yahoo 的一个 ppt 全面的介绍了网页图片的压缩技术，其中提到很多有用的方法和工具。大纲列这：优先用 png 而不是 gif压缩 png去掉 jpg 的 metadata压缩 gif 动画尝试使用 png8避免使用 AlphaImageLoader 压缩动态生成的图像使 favicon 更小 可缓存使…
简单地说，就是一些事先写好的css，你只需要给你的html元素加上一些特定的类，就可以快速的得到一些想要的效果。&br&&br&Blueprint是比较早的，基于静态css的框架。但是现在有两个主要的动态css语言，LESS和SASS，给css提供了变量，mixin，运算符等功能，让写出模块化的css框架成为可能。&br&&br&Bootstrap现在基本是欧美这里最流行的框架，基于LESS，最近升级2.0以后完全模块化，也不需要太多配置，很好用。这个框架对大部分元素的视觉细节都已经做得很完整，基本上你只需要写html，加几个class，就可以做出像模像样的页面了，做起prototype来嗷嗷快。不过这也是个缺点，因为用的人多了样式都长一个样... 当然，模块化的框架你要修改起来也是很方便的，基本上修改变量就可以了。&br&&br&另一个比较流行的是基于SASS的Compass，这个框架包含了Blueprint作为其中的一个模块。需要注意的是这个框架和Ruby on Rails是高度整合的，用起来需要大量的命令行操作，比Bootstrap麻烦，但是在Rails开发人员里面用得比较多。
简单地说，就是一些事先写好的css，你只需要给你的html元素加上一些特定的类，就可以快速的得到一些想要的效果。Blueprint是比较早的，基于静态css的框架。但是现在有两个主要的动态css语言，LESS和SASS，给css提供了变量，mixin，运算符等功能，让写出模块…
position:&br&top:50%;&br&left:50%;&br&-webkit-transform:translate(-50%,-50%)
position:top:50%;left:50%;-webkit-transform:translate(-50%,-50%)
网页上的图标有两种做法：位图（PNG, GIF, JPG 等格式）或者矢量图 (SVG 格式）。位图不能任意缩放，如果需要不同尺寸的相同图标，要自己重新制作多个尺寸，麻烦不说，管理成本和流量成本会随之飙升。当然你也可以只制作一个大尺寸的图标，然后交给浏览器用算法缩小到合适的尺寸，但不要指望这样做在非 OS
X 平台上能有多好的显示效果。矢量图则可以任意缩放，可惜不是所有浏览器都支持 SVG 格式，而且支持的浏览器对 SVG 格式的不同规范实现也不一样，兼容性很成问题。更不用提 SVG 格式无法有效实现位图的一些特效（比如逼真的光影、烟雾、纹理等）。
&br&&br& Font-embedding Icons 中文大约可以翻译为「图标字体」。这个概念其实并不是什么新东西，Windows 上很早就存在这样的 *ding 系列矢量字体，比如 Webdings, Windings 1, Windings 2 等系列字体。这些字体包含的不是文字，而是图像：每一个「字」实际上是一张矢量图。图标字体的主要问题是不能实现颜色：本质上图标字体的每个字都只有二维的几何轮廓，完全没有【也不会有】颜色特征。也就是说图标字体只能达到简单的显示一个几何图形的作用。换句话说，图标字体无法实现复杂的图标。
&br&&br& 但对于简单的单色图标，使用图标字体可以非常方便的在任何位置嵌入图标：只需要调用合适的图标字体、然后键入对应图标的字符就可以得到相应的几何图形，比起用 img 标签、CSS 来指定图标都方便不少。利用合适的工具，还可以自己绘制需要的图标，然后生成特定的图标字体，通过网页字体的方式嵌入到网页中，从而在页面上实现订制化的图标集。
&br&&br& 图标字体的优点那篇文章提到有：
&br&&ul&&li&减少 HTTP 请求数：这和 CSS sprite 是一个原理，将多个小文件的请求融合成为一个大文件的请求，可以显著减少 HTTP 请求数，从而避免昂贵的 TCP 连接建立开销，提高网页的相应速度。&/li&&li&矢量图标，任意缩放。&/li&&li&易于管理：改变图标颜色【虽然只能是单色】和选择图标都变得异常容易。&/li&&li&只需要改动一行字体文件的位置就可以自动切换页面上的全部图标。&/li&&li&还可以用 CSS3 动画效果。&/li&&/ul&&br&&br& 缺点也很明显，那篇文章提到的有：
&br&&ul&&li&字体文件体积庞大：复杂的矢量图的尺寸本来就不小。如果页面上图标使用不多，采用图标字体反而可能会延长页面读取时间。&/li&&li&字符和图标字体中的图像对应关系并不标准，输入图标可能是个问题（A 对应什么图像？）&/li&&li&错误的使用图标字体可能会污染你的 HTML 标签【但作者并未给出例子，很费解这个】&/li&&li&只能单色的简单几何图形&/li&&/ul&&br&&br& 另外我想到的问题有：
&br&&ul&&li&内容和样式混杂：图标本质是样式，但用字符替代图标会导致内容和样式不分。写 HTML 代码的时候你看到一个 &A& 可能并不是真的代表英文字母，而是对应的一个图标。这会导致易用性的问题。&/li&&li&正如字体渲染在不同平台上的效果不同一样，图标字体在不同平台上的渲染效果差别很大。最悲剧的是 Windows ，你就等着看那丑陋的字体吧！&/li&&li&有些浏览器不支持 font-face，为了兼容性还得给一套 fallback 方案，并没有节省到时间，得不偿失。&/li&&/ul&
网页上的图标有两种做法：位图（PNG, GIF, JPG 等格式）或者矢量图 (SVG 格式）。位图不能任意缩放，如果需要不同尺寸的相同图标，要自己重新制作多个尺寸，麻烦不说，管理成本和流量成本会随之飙升。当然你也可以只制作一个大尺寸的图标，然后交给浏览器用…
泻药。&br&&br&此乃历史问题。不难理解，空白字符压缩（white space collapse）是西文排版的必然结果。SGML、TeX都是如此。不过对于不使用空格作为词分界的语言，比如东亚语言来说，就造成了问题。所以其实这是行内（inline）的问题（inline-block也是将其本身作为inline，内部作为block），题目或许应修改下。&br&&br&在CSS控制空白字符压缩特性尚未得到普遍支持之前，可行的办法有：&br&1. CSS trick，如设font-size/line-height为0。但此种方法副作用过多，&b&完全不可取&/b&。&br&2. 某些元素不写结束标签不会产生额外的空白节点，比如li元素。缺点是不是所有元素都可以用这个方法，且要求使用HTML语法，而不能用XHTML语法。&br&3. 特殊的标签写法，如：&br&&ul&br&
&&li&1&/li&br&
&&li&2&/li&br&
&&li&3&/li&br&&&/ul&&br&个人认为此种也是削足适履的方式，不建议。&br&4. 删掉空白。缺点，源代码排版会面临困难。&br&5. 我认为目前来说最优雅的方法，使用不产生额外空白节点或者支持空白控制的模板语言。比如Jade、Smarty（&a class=& wrap external& href=&http://www.smarty.net/docsv2/en/language.function.strip.tpl& target=&_blank& rel=&nofollow noreferrer&&{strip} | Smarty&i class=&icon-external&&&/i&&/a&）等。缺点，你不是直接写HTML，即使没有其他使用模板的必要。另外阅读生成的代码比较困难。不过这两个缺点对于专业前端工程师来说基本上不成为问题。
泻药。此乃历史问题。不难理解，空白字符压缩（white space collapse）是西文排版的必然结果。SGML、TeX都是如此。不过对于不使用空格作为词分界的语言，比如东亚语言来说，就造成了问题。所以其实这是行内（inline）的问题（inline-block也是将其本身作为i…
PC 上禁用该属性的具体变更集在这里：&a href=&http://trac.webkit.org/changeset/145168& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Changeset 145168&i class=&icon-external&&&/i&&/a&&br&BUG 地址：&a href=&https://bugs.webkit.org/show_bug.cgi?id=56543& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Bug 56543 – CSS property &-webkit-text-size-adjust& means different things in Safari and iOS&i class=&icon-external&&&/i&&/a&&br&例如在 Chromium 27.0.7669) 中就会看到该属性变为未识别的了：&br&&br&&img src=&/dc19b3dd56f64_b.jpg& data-rawwidth=&264& data-rawheight=&67& class=&content_image& width=&264&&&br&Chrome 对于简体中文版最小字号限制为12px 一直是我不解的，这样会间接带来好多问题。目前似乎只有通过类似&br&&div class=&highlight&&&pre&&code class=&language-css&&&span class=&nt&&transform&/span&&span class=&nd&&:scale&/span&&span class=&o&&(&/span&&span class=&nt&&0&/span&&span class=&nc&&.875&/span&&span class=&o&&);&/span&
&/code&&/pre&&/div&&br&的方式来解决了。&br&可以看这个 Demo：&a href=&/efuhaw/1/edit& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&JS Bin - Collaborative JavaScript Debugging&i class=&icon-external&&&/i&&/a&&br&&br&从另外一个方面来说，这也是一件好事，因为&b&一直以来「&a href=&https://bugs.webkit.org/show_bug.cgi?id=56543& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&-webkit-text-size-adjust&i class=&icon-external&&&/i&&/a&」属性被滥用&/b&，经常会看到全局设置「&b&-webkit-text-size-adjust:&/b&」，直接导致了放大网页的时候字号不能改变（例如：&a href=&/blog/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&TaoBaoUED | 做地球上最好的UED&i class=&icon-external&&&/i&&/a&），可用性大大降低，对于视觉障碍的用户是没有情怀的（比如作为近视的我，知乎默认我会放大 125% 来浏览）。&br&&br&在 &a href=&http://dev.w3.org/csswg/css-size-adjust/#text-size-adjust& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CSS Mobile Text Size Adjustment Module Level 1&i class=&icon-external&&&/i&&/a& 规范中，&b&text-size-adjust &/b&的取值如下：&br&&div class=&highlight&&&pre&&code class=&language-text&&取值：auto | none | &percentage(百分比)&
默认值：auto（iPad 默认值是 none[1]）
继承性：有
&/code&&/pre&&/div&&br&该属性最先是由 iOS 1.0 引入的，所以本来就是解决移动设备上的问题而出现的。通常 iPhone（iOS4）横屏时，「-webkit-text-size- adjust」 的值约为140%。所以如果想取消 iOS 设备横屏切换时候字号变大，正确的用法应该是：&br&「&b&-webkit-text-size-adjust:100%;&/b&」&br&&br&&img src=&/cec8abc6de_b.jpg& data-rawwidth=&503& data-rawheight=&122& class=&origin_image zh-lightbox-thumb& width=&503& data-original=&/cec8abc6de_r.jpg&&&br&[1] &a href=&/library/ios/DOCUMENTATION/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Safari Web Content Guide: Customizing Style Sheets&i class=&icon-external&&&/i&&/a&
PC 上禁用该属性的具体变更集在这里：BUG 地址：例如在 Chromium 27.0.7669) 中就会看到该属性变为未识别的了：Chrome 对于简体…
&b&《 CSS Writing Mode 现状》&/b&&br&&br&目前 W3C 关于竖排文本的排版规范统一在「&a href=&http://dev.w3.org/csswg/css-writing-modes/#writing-mode& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CSS Writing Modes Module Level 3&i class=&icon-external&&&/i&&/a&」中。&br&&br&主要有以下几个属性：&br&&br&一、&b&「writing-mode」设置文字的书写方向&/b&&br&&br&IE 在文字排版方面一直是先驱，早在 IE 5.5 就实现了私有属性「writing-mode」，后来被 W3C 在 CSS2 中采纳作为规范。在 Level 3 草案中「writing-mode」是 「direction」 和 「block-flow」 属性的简写[1]，2010年起「block-flow」 属性被删除了，其功能融合进「writing-mode」。&br&&br&IE 实现的私有属性包含以下取值：&br&&img src=&/5f4751ccfc54f560f508_b.jpg& data-rawwidth=&616& data-rawheight=&259& class=&origin_image zh-lightbox-thumb& width=&616& data-original=&/5f4751ccfc54f560f508_r.jpg&&&br&但在最新的规范中「writing-mode」属性缩减为三个值：&br&&ul&&li& horizontal-tb（&strong&默认值&/strong&）：自上而下，从左到右的横排书写方式。（类似IE私有值lr-tb）&br&&/li&&li&vertical-rl：从右到左，自上而下的竖排书写方式（典型的汉字竖排排版方式）。（类似IE私有值tb-rl）&br&&/li&&li&vertical-lr：从左到右，自上而下的竖排书写方式（主要用于内蒙古的&a href=&http://zh.wikipedia.org/zh/%E8%92%99%E5%8F%A4%E8%AF%AD%E5%AD%97%E6%AF%8D& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&蒙古语&i class=&icon-external&&&/i&&/a&和&a href=&http://zh.wikipedia.org/zh/%E6%BB%A1%E8%AF%AD& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&满语&i class=&icon-external&&&/i&&/a&。）。&br&&/li&&li&由于自下而上的横排书写方式太少见，经过讨论去掉了「horizontal-bt」关键字。[2]&/li&&/ul&&br&二、双向排列&b&「direction」&/b&与&b&「&/b&&strong&unicode-bidi&/strong&&b&」&/b&&br&&br&在一些多语言混合排版的文档中会存在文字书写方向的不同，比如阿拉伯文和希伯来文便是从右往左书写的，这一现象称之为「双向排列（bidirectionality）」，简称「bidi」。&br&&br&在Unicode规范中，定义了一个复杂的算法来确定文字的正确方向，CSS便是依赖于该算法来获得正确的双向字符渲染。[3]「direction」与「unicode-bidi」便是用来匹配该算法的。&br&&br&它们都是 CSS2 中便有的属性。&br&&br&「direction」属性指定了块的基本书写方向，以及 Unicode 双向算法中嵌入和超越的方向（参见「unicode-bidi」）。另外，它还规定了表格列布局的方向，水平溢出的方向，以及块设置了「text-align: justify」时，最后一个不完全的行的位置。其取值有：&br&&ul&&li&ltr：从左到右的方向。（&strong&默认值&/strong&）&br&&/li&&li&rtl：从右到左的方向。 &/li&&/ul&&br&三、「&b&text-orientation&/b&」控制行内字符的旋转&br&&br&四、「&b&text-combine-horizontal&/b&」用于控制在竖排时同一行内显示多个非 CJK 字符的情况&br&在日文排版中这种情况称为「&a href=&http://ja.wikipedia.org/wiki/%E7%B8%A6%E4%B8%AD%E6%A8%AA& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&縦中横&i class=&icon-external&&&/i&&/a&」，规范称为 「tate-chu-yoko」。我们可以称之为&b&「纵中横」&/b&或&b&「直中横」&/b&。&br&Word 里称为「纵横混排」：&br&&img src=&/d1e272cc7f87447c86bfc18a8c726ace_b.jpg& data-rawwidth=&215& data-rawheight=&460& class=&content_image& width=&215&&&br&InDesign 里称为&b&「直排内横排」&/b&：&a href=&/zh_CN/indesign/cs/using/WSFC849FB1-7F66-47b2-97F7-1BAE6C2F0546a.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/zh_CN/in&/span&&span class=&invisible&&design/cs/using/WSFC849FB1-7F66-47b2-97F7-1BAE6C2F0546a.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&img src=&/0a0ff5f9e7d4eb8b9157_b.jpg& data-rawwidth=&671& data-rawheight=&391& class=&origin_image zh-lightbox-thumb& width=&671& data-original=&/0a0ff5f9e7d4eb8b9157_r.jpg&&&br&Webkit 支持旧版本[4]的 text-combine 属性，但是问题多多，Demo：&a href=&/aruwoc/2/edit& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&JS Bin - Collaborative JavaScript Debugging&i class=&icon-external&&&/i&&/a&&br&&br& 更新：&br&IE11.0.9431.0 开始支持该属性。&br&&br&&b&「writing-mode」属性兼容性&/b&&br&&br&&br&Demo：&a href=&/erataf/3& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CSS writing-mode 测试 by 一丝&i class=&icon-external&&&/i&&/a&&br&&ul&&li&IE6-10，Opera 不支持标准属性：horizontal-tb | vertical-rl | vertical-lr&/li&&li&IE6只支持 tb-rl | lr-tb，IE7 只支持 tb-rl | lr-tb | rl-tb | bt-rl&br&&/li&&li&Webkit 目前实现的最好，为了兼容旧的规范，虽然支持 lr-tb | tb-rl 属性值，但未实现效果&br&&/li&&li&Opera 12.1 虽然支持 lr-tb | tb-rl 属性值，但未实现效果&/li&&li&Firefox 不支持 writing-mode 属性&br&&/li&&/ul&&br&&br&[1]&a href=&http://dev.w3.org/cvsweb/~checkout~/csswg/css3-writing-modes/Attic/Overview.src.html?rev=1.12& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&dev.w3.org/cvsweb/~chec&/span&&span class=&invisible&&kout~/csswg/css3-writing-modes/Attic/Overview.src.html?rev=1.12&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&;content-type=text%2Fhtml#block-flow&br&&a href=&https://bugs.webkit.org/show_bug.cgi?id=47285& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Bug 47285 – Remove the block-flow property and update writing-mode&i class=&icon-external&&&/i&&/a&&br&[2]&a href=&http://lists.w3.org/Archives/Public/www-style/2010Oct/0631.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&lists.w3.org/Archives/P&/span&&span class=&invisible&&ublic/www-style/2010Oct/0631.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&变更：&a href=&http://dev.w3.org/cvsweb/csswg/css3-writing-modes/Attic/Overview.src.html#rev1.45& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CVS log for csswg/css3-writing-modes/Attic/Overview.src.html&i class=&icon-external&&&/i&&/a&&br&[3]&a href=&http://dev.w3.org/csswg/css-writing-modes/#text-direction& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CSS Writing Modes Module Level 3&i class=&icon-external&&&/i&&/a&&br&[4]&a href=&http://www.w3.org/TR/2011/WD-css3-writing-modes-/#text-combine& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CSS Writing Modes Module Level 3&i class=&icon-external&&&/i&&/a&
《 CSS Writing Mode 现状》目前 W3C 关于竖排文本的排版规范统一在「」中。主要有以下几个属性：一、「writing-mode」设置文字的书写方向IE 在文字排版方面一直是先驱，早在 IE 5.5 就实现了私有属性「writing-mode」，后…
Safari 6:&br&使用 CustomReader 扩展: &a href=&/customreader& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/customread&/span&&span class=&invisible&&er&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&Safari 5 及之前版本:&br&改 /System/Library/PrivateFrameworks/Safari.framework/Resources/Reader.html 的 CSS。
Safari 6:使用 CustomReader 扩展: Safari 5 及之前版本:改 /System/Library/PrivateFrameworks/Safari.framework/Resources/Reader.html 的 CSS。
不知道题主自己是否懂前端，我认识一位做前端的大牛，从来不依靠猎头，不唯学历也不唯神马工作经历，看重的是对前端的认知度，可塑造的潜力和职业方向与公司的一致性，从当初的一个人，现在已经搭建起了自己的前端团队，他的团队里有肄业生，有不知名学校毕业生，也有清华出来的高材生；有应届生，也有工作过四年的人，团队成员成长很快，归属感很强，有个底子薄的不到一年就能独当一面，靠的是强烈的归属感下的勤奋，有个半年就很突出的，靠的是基础+脑瓜灵活&br&&br&所以&br&首先自己要懂前端，很多人不知道是干什么的，团队里也不知道前端是什么位置，那找一个优秀靠谱的前端很难&br&二，你实在不懂前端，那至少去了解下前端的常识，别犯二，别跟优秀的前端说DIV+Css，也别装13，别懂了点常识就以为自己真的就懂了&br&三，千万别抄大公司的招聘信息&br&四，要知道自己招的到底是要放在什么位置的人，单纯干活的，还是要架构的&br&五，最简单的办法是找一个靠谱的前端然后帮你招人&br&六，不仅要会招人，还要会带人&br&七，归属感很重要
不知道题主自己是否懂前端，我认识一位做前端的大牛，从来不依靠猎头，不唯学历也不唯神马工作经历，看重的是对前端的认知度，可塑造的潜力和职业方向与公司的一致性，从当初的一个人，现在已经搭建起了自己的前端团队，他的团队里有肄业生，有不知名学校毕…
作用主要是利用伪元素装饰内容 (无论是装饰图片还是音效) 而不需要更改 HTML 的内容，从而帮助内容与样式更好地分离。因为如果仅仅为了画一个装饰用的三角就在 HTML 里多加一个元素，这上对于实际内容来说其实是多余的，对自动分析网页的语义也可能会产生不好的影响 (这取决于分析程序的具体实现)。
作用主要是利用伪元素装饰内容 (无论是装饰图片还是音效) 而不需要更改 HTML 的内容，从而帮助内容与样式更好地分离。因为如果仅仅为了画一个装饰用的三角就在 HTML 里多加一个元素，这上对于实际内容来说其实是多余的，对自动分析网页的语义也可能会产生不…
来自子话题：
把整个过程比喻成组装一个机器人的过程&br&&br&HTML是这个机器人的支架 骨骼 关节 什么的&br&&br&CSS是这个机器人外部的涂装 用什么颜色 什么主题（荧光白 钻石红）什么的&br&&br&JS是控制这个机器人行为的 让他抬胳膊 开火 行走 跑步 等等&br&&br&HTML5是一种新型材料 组成的支架 更耐用 更简洁 更清晰 同时提供一些可以调用的新的牛逼的行为（JS API） 比如 获得该机器人坐标 自动缓存数据 绘图功能 等等&br&&br&CSS3是一种改进版涂装 更轻 渲染更快 颜色更加绚丽 &br&&br&Jquery是基于JS封装好的控制行为的库 用这种指令 就可以更快的写出控制机器人行为的内容 用这种东西 写出的指令 开发人员可以节省时间 提高效率 但是没有原生的动作（JS） 他什么都做不了&br&&br&你完成的网站或者web APP就是组装好的机器人 如果你用的是先进的HTML5和CSS3完成的机器人 有一个悲剧就是 只有在高级作战环境下才能全部发挥作用（&a href=&/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&） 如果是低级环境（牛逼哄哄的ie6等） 你的机器人就是一坨废铁
把整个过程比喻成组装一个机器人的过程HTML是这个机器人的支架 骨骼 关节 什么的CSS是这个机器人外部的涂装 用什么颜色 什么主题（荧光白 钻石红）什么的JS是控制这个机器人行为的 让他抬胳膊 开火 行走 跑步 等等HTML5是一种新型材料 组成的支架 更耐用 更…
我是一个写前段代码的码工。&br&&br&HTTP协议是个挺简单的协议。 就算实现也花不了多少时间。
可能在实际的开发中， 用起来会比较麻烦。 比如想往HTTP 加个cache header， 有些lib或框架不是特别方便， 也可能是由于对lib或框架的不熟悉。&br&&br&如果想了解协议的话， 建议多尝试， 比如telnet一个网页， wget
-S看看返回的header是什么。 也可以尝试自己写动手写个 简单的HTTP 文件服务器。 我写过一个，也就400行C &a href=&/shenfeng/tiny-web-server& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/shenfeng/tin&/span&&span class=&invisible&&y-web-server&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&如果你确实不了解， 也不用过于担心， 因为很多人也不知道。比如我注意到， baidu的爬虫在抓取网页时， 就没有加 Accept-Encoding: gzip,deflate,sdch 头， 造成被抓网站， 和baidu自己的流量浪费。 连非常厉害的baidu的爬虫工程师都对http 协议都不是很了解， 我们这些前端就不必紧张了。
我是一个写前段代码的码工。HTTP协议是个挺简单的协议。 就算实现也花不了多少时间。 可能在实际的开发中， 用起来会比较麻烦。 比如想往HTTP 加个cache header， 有些lib或框架不是特别方便， 也可能是由于对lib或框架的不熟悉。如果想了解协议的话， 建议…
一年后，自己回答这个问题&br&之前的公司，从零开始，三个前端，选用了KISSY，挺好的，虽然现在感觉不够GEEK了。。。因为有点老了。。&br&现在的公司，从零开始，一个前端+我，只是我现在不是专职前端，不过前端架构和优化等工作还是我来制定，这次我选择了简单之美。整个网站除了jquery，不引入任何css和js框架。&br&我准备做一个从0开始的松散的但是又有很多前端规范的前端环境。这跟我们网站的需求吻合，现在网站的脚本基本很少，所以选择最简的结构，开始不做代码合并，不做包管理，甚至不做代码压缩。&br&然后，现在网站是在一个需求很不稳定的阶段，将来很可能会变化很多，所以从轻量开始，在随着需求和页面慢慢增多的情况下，然后在我和团队的人精力足够的情况下，制定新方案，搭建新建筑，不管是更灵活的代码，更重的逻辑，更优的管理方式，更多的插件引入，包管理，甚至mvc，这些都是以后慢慢以软装的形式加入。&br&这是一个逻辑轻量化的网站的架构，每个网站都有适合自己的架构和选型，不能一概而论。&br&如果现在让我架构电商网站，还是比较重逻辑的，除了jquery，必然会引入一些其他的全局顶层的管理框架。jquery只是一把锤子而已。
一年后，自己回答这个问题之前的公司，从零开始，三个前端，选用了KISSY，挺好的，虽然现在感觉不够GEEK了。。。因为有点老了。。现在的公司，从零开始，一个前端+我，只是我现在不是专职前端，不过前端架构和优化等工作还是我来制定，这次我选择了简单之美…
你先别管入门低不低，首先你一开始觉得入门低就是错误，往往人就是这样的心态，觉得简单就得不到重视，但是你真正要去深入他是非常难的！&br&
再之往往你们所谓的“入门低的语言”更难学，比如javascript，他很容易入门，但是他又很灵活。&br&
互联网发展到今天，用户体验的要求也越来越高，前端开发的技术难度越来越大。&br&
总的来说，前端开发，涵盖的知识面非常广，不光光会javascript、html、css，还要求你会后端语言，数据库，UI，SEO等。。。既有具体的技术，又有抽象的理念。简单地说，它的主要职能就是把网站的界面更好地呈现给用户。&br&不说了，上一张老掉牙的图片。&br&&img src=&/aad0b646a5d554a352d93f_b.jpg& data-rawwidth=&800& data-rawheight=&497& class=&origin_image zh-lightbox-thumb& width=&800& data-original=&/aad0b646a5d554a352d93f_r.jpg&&　　ps：如果要做得更好、更专业，真的是不简单。这就是前端开发的特点，所以你觉得他简单，但是他却是最难让人琢磨的技术。
你先别管入门低不低，首先你一开始觉得入门低就是错误，往往人就是这样的心态，觉得简单就得不到重视，但是你真正要去深入他是非常难的！ 再之往往你们所谓的“入门低的语言”更难学，比如javascript，他很容易入门，但是他又很灵活。 互联网发展到今天，用…
所谓“不能”，是html语义层面（spec中指定的每个元素的内容模型）。在浏览器层面，实际上是可以把div插入到span里的（不过在老浏览器中可能发生奇怪的事情）。&br&&br&无论如何，DOM结构约束跟css是没有关系的。否则我插好后再把display改为inline你说应该发生什么事情？
所谓“不能”，是html语义层面（spec中指定的每个元素的内容模型）。在浏览器层面，实际上是可以把div插入到span里的（不过在老浏览器中可能发生奇怪的事情）。无论如何，DOM结构约束跟css是没有关系的。否则我插好后再把display改为inline你说应该发生什么…
来自子话题：
给你个中文的版本 &a href=&/bootstrap/docs/base-css.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/b&/span&&span class=&invisible&&ootstrap/docs/base-css.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
给你个中文的版本