T之家 3 月 25 日消息，在浏览器互通项目 Interop 2023 的倡议下，目前业界主流浏览器都开始统一垂直表单控件支持。近日苹果公司便在 iOS / iPad OS 17.4 及 macOS 14.4 中为 Safari 浏览器添加了完整的垂直表单控件支持。

IT之家注：垂直表单控件主要用于呈现竖排文字，虽然此前 CSS 已经在书写模式属性中添加了竖排文字的支持，不过许多浏览器对表单控件 vertical-lr 和 vertical-rl 值都采用不同的标准，因此在先前的 Interop 2023 会议中，各厂商一致决定实现统一的垂直表单控件支持。

在布局方面，目前 WebKit 中的表单控件大量使用自定义布局代码，以在不同的环境和条件下保持一致和功能性，但此类布局代码主要基于横排模式设计，在竖排模式下会出现问题。

开发团队在 Safari 17.4 版本中改进了相关代码，在代码计算逻辑宽度时会同时考虑竖排模式，同时也改进了自定义基线调整逻辑功能，使复选框和单选按钮等控件能与竖排文字相搭配。

开发人员重点谈到了 macOS 平台 Safari 浏览器的改进，由于 macOS 本身不支持竖排模式，例如 <progress> 等控制元件便无法直接在竖排模式下渲染，因此在 Safari 17.4 版本中，WebKit 会直接旋转这些控件来支持竖排渲染。

不过有些拥有阴影的控件（例如 <select> ）无法单纯通过旋转来契合竖排模式，在遇到此类特定控件时，WebKit 便会为相关控件使用“特别的渲染逻辑”，从而兼容竖排渲染模式。

实现如下内容的样式，即文字是竖向排列，并且如下图的35这个数字，要将其变成横向排列。

想要方案竖向排列，需要用到css3的writing-mode:vertical-rl;//即竖直广告，从右到左的方式

.qqbox-text{writing-mode: vertical-rl; /* 文字从上到下，从右到左 */}

但这样写一个奇怪的问题，就当中我们有一个35，我们要单独把这个数字区域拿出来，如下图，我们如果不把35这个数字单独设置，将出现如下的排版，则非常影响阅读体验。

所以，我们要把这个35数字，单独放在一个盒子里面，并且修改它的writing-mode属性，让其恢复正常即可。

这样就可以实现，文字竖排，并且数字横向，不影响阅读。

writing-mode属性,这在我们写古诗句的时候，非常有用。
horizontal-tb://默认模式，从左到右，从上到下

vertical-rl://从上到下，从右到左

vertical-lr://从上到下，从左到右

ss是前端领域的一个难缠户，一提到css，没有人会说难，也没有人愿意承认自己不会写，甚至在面试的过程中css相关的内容都很少提及，足以说明大家对css的不重视。你真的会写css吗？

关于css有两类问题值得我们重视：样式和工程。样式问题指的是具体的效果实现，能否实现某个效果，同一个效果有多种实现方式，如何抉择；工程问题是如何在大型项目中写出可维护性、可读的css。

在各种论坛中经常看到关于css是否是一门编程语言的争论。在我看来，最好用对待编程语言的态度来看待css，不要忽视css，否则，在项目后期，你会发现，你的css越来越混乱，important会越来越多，不同位置的类名互相冲突覆盖，改一个类的样式，要检查整个项目的页面是否受到影响，项目内部的css共享完全依赖拷贝……从这个角度来说，你敢说css不是编程语言？它完全有了像编程语言一样能把你搞得焦头烂额的能力。而这一切都来源于你在一开始对她的忽视与不屑。出来混，总要还的啊！

css的问题

盲目的定义基础样式

在项目开始之初，拿到UI设计稿，信心满满地开始定义css的全局基础样式，谢天谢地，css对这一点支持得很彻底，一处定义，所有页面都可以引用。

先来一个color-red。

.color-red {
	color: red
}

这样，在整个项目中，都可以给任意元素添加一个color-red类，美滋滋，我真是个小机灵鬼！

几个迭代过去，你已经把color-red这面红旗插满了整个项目。UED说，咱们改个版，所有红色的文本改为蓝色，红色的link不变！

哔！——（你发出的声音）

你又得屁颠屁颠地把一个一个的红旗拔出来，再插上蓝色的旗子（因为你不敢不干呀）。

命名冲突

在一个页面，你定义了一个.header，写了个完美的特效，发布到dev一看，就是不管用，横看竖看，本地是好的啊，神奇（生气）！过了若干时间的排查，另一个同事在另一个地方也写了一个.header，完美的覆盖了你的。把你头打歪！

编辑器可不会提醒你哦！

慢慢你会发现，这种命名冲突可太频繁了呀！头大，要不要用上css modular啊？

子类覆盖

有的小伙伴聪明地将类名嵌套定义，这就不会冲突了吧？嘿嘿，你想多了！

/* in article.css */
.article .title {
  border-bottom: 1px solid;
  font-size: 1.5em;
}

/* in widget.css */
.widget .title {
  color: gray;
  text-transform: uppercase;
}

如果在dom树里面，article和widget在一棵树的路径上，你说title是冲突呢还是不冲突呢？

以上的这些问题，在项目中相信大家都遇见过，并且项目越大，出现的概率就越高，最后就会演变成一座[屎]山。

“大家都别动，牵一发而动全身哦！”

“这就是蝴蝶效应吧？？？”

认识BEM

难道css这些问题就没法解决了吗？当然不是，我们来看看大神们是如何解决这些问题的。

BEM是Block、Element、Modifier的缩写，是一个类命名的规范。

首先我们来看一个例子：

/* Block */
.btn {}

/* Element that depends upon the block */ 
.btn__price {}

/* Modifier that changes the style of the block */
.btn--orange {} 
.btn--big {}

相信小伙伴们已经有了一个初步的认知：

Block是一个独立的组件（元素），定义的了“组件是什么，按钮？还是菜单？”。

Element是属于Block，是依赖于Block的元素，描述的是“Block里面的什么？比如，文本？图标？”

Modifier用于描述Block或者Element的外在表现，比如大小、颜色、状态等。

看一个例子：

<form class="search-form search-form_theme_islands">
    <input class="search-form__input">
    <button class="search-form__button search-form__button_size_m">Search</button>
</form>

search-form是Block；

search-form_theme_islands是Modifier，描述了theme为islands的search-form；

search-form__input是Element，描述的是search-form内部的input元素；

search-form__button是Element，描述的是search-form内部的button元素；

search-form__button_size_m是Modifier，描述的是size为m的search-form__button；

这样写css是不是非常的清晰？瞬间就提高了可读性和可维护性？

概念如此简单，还不赶紧多了解一下？

另外，可能有些小伙伴也注意到了，Block和Element使用双下划线分隔，和Modifier是用中划线分隔，这也不是一成不变的，可以按照自己的喜好来决定如何分割。

Saas、Css Module

有些小伙伴可能会有疑问，BEM和Saas、Css Module有什么区别？解决的问题是一样的吗？

Sass是css的预处理器，在写css的时候定义了一套规范，经过编译处理后输出为css，和BEM是两个不同的概念。使用saas或less也能实现BEM。BEM其实是不推崇类名的嵌套定义的，如果想像sass那样嵌套的写出标准的BEM，可以使用@at-root。

Css Module解决的问题是多个模块的css的命名冲突问题，个人觉得是傻瓜式解决方案，在应用层的css-in-js应用比较多，适合css入门选手。要想写好css，还是得从根本上入手呀！