整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
T之家 3 月 25 日消息，在瀏覽器互通項(xiàng)目 Interop 2023 的倡議下，目前業(yè)界主流瀏覽器都開始統(tǒng)一垂直表單控件支持。近日蘋果公司便在 iOS / iPad OS 17.4 及 macOS 14.4 中為 Safari 瀏覽器添加了完整的垂直表單控件支持。
IT之家注：垂直表單控件主要用于呈現(xiàn)豎排文字，雖然此前 CSS 已經(jīng)在書寫模式屬性中添加了豎排文字的支持，不過許多瀏覽器對表單控件 vertical-lr 和 vertical-rl 值都采用不同的標(biāo)準(zhǔn)，因此在先前的 Interop 2023 會(huì)議中，各廠商一致決定實(shí)現(xiàn)統(tǒng)一的垂直表單控件支持。
▲ 豎排文字示例在布局方面，目前 WebKit 中的表單控件大量使用自定義布局代碼，以在不同的環(huán)境和條件下保持一致和功能性，但此類布局代碼主要基于橫排模式設(shè)計(jì)，在豎排模式下會(huì)出現(xiàn)問題。
開發(fā)團(tuán)隊(duì)在 Safari 17.4 版本中改進(jìn)了相關(guān)代碼，在代碼計(jì)算邏輯寬度時(shí)會(huì)同時(shí)考慮豎排模式，同時(shí)也改進(jìn)了自定義基線調(diào)整邏輯功能，使復(fù)選框和單選按鈕等控件能與豎排文字相搭配。
開發(fā)人員重點(diǎn)談到了 macOS 平臺(tái) Safari 瀏覽器的改進(jìn)，由于 macOS 本身不支持豎排模式，例如 <progress> 等控制元件便無法直接在豎排模式下渲染，因此在 Safari 17.4 版本中，WebKit 會(huì)直接旋轉(zhuǎn)這些控件來支持豎排渲染。
不過有些擁有陰影的控件（例如 <select> ）無法單純通過旋轉(zhuǎn)來契合豎排模式，在遇到此類特定控件時(shí)，WebKit 便會(huì)為相關(guān)控件使用“特別的渲染邏輯”，從而兼容豎排渲染模式。
實(shí)現(xiàn)如下內(nèi)容的樣式，即文字是豎向排列，并且如下圖的35這個(gè)數(shù)字，要將其變成橫向排列。
想要方案豎向排列，需要用到css3的writing-mode:vertical-rl;//即豎直廣告，從右到左的方式
.qqbox-text{writing-mode: vertical-rl; /* 文字從上到下，從右到左 */}但這樣寫一個(gè)奇怪的問題，就當(dāng)中我們有一個(gè)35，我們要單獨(dú)把這個(gè)數(shù)字區(qū)域拿出來，如下圖，我們?nèi)绻话?5這個(gè)數(shù)字單獨(dú)設(shè)置，將出現(xiàn)如下的排版，則非常影響閱讀體驗(yàn)。
所以，我們要把這個(gè)35數(shù)字，單獨(dú)放在一個(gè)盒子里面，并且修改它的writing-mode屬性，讓其恢復(fù)正常即可。
這樣就可以實(shí)現(xiàn)，文字豎排，并且數(shù)字橫向，不影響閱讀。
writing-mode屬性,這在我們寫古詩句的時(shí)候，非常有用。
horizontal-tb://默認(rèn)模式，從左到右，從上到下
vertical-rl://從上到下，從右到左
vertical-lr://從上到下，從左到右
ss是前端領(lǐng)域的一個(gè)難纏戶，一提到css，沒有人會(huì)說難，也沒有人愿意承認(rèn)自己不會(huì)寫，甚至在面試的過程中css相關(guān)的內(nèi)容都很少提及，足以說明大家對css的不重視。你真的會(huì)寫css嗎？
關(guān)于css有兩類問題值得我們重視：樣式和工程。樣式問題指的是具體的效果實(shí)現(xiàn)，能否實(shí)現(xiàn)某個(gè)效果，同一個(gè)效果有多種實(shí)現(xiàn)方式，如何抉擇；工程問題是如何在大型項(xiàng)目中寫出可維護(hù)性、可讀的css。
在各種論壇中經(jīng)常看到關(guān)于css是否是一門編程語言的爭論。在我看來，最好用對待編程語言的態(tài)度來看待css，不要忽視css，否則，在項(xiàng)目后期，你會(huì)發(fā)現(xiàn)，你的css越來越混亂，important會(huì)越來越多，不同位置的類名互相沖突覆蓋，改一個(gè)類的樣式，要檢查整個(gè)項(xiàng)目的頁面是否受到影響，項(xiàng)目內(nèi)部的css共享完全依賴拷貝……從這個(gè)角度來說，你敢說css不是編程語言？它完全有了像編程語言一樣能把你搞得焦頭爛額的能力。而這一切都來源于你在一開始對她的忽視與不屑。出來混，總要還的啊！
盲目的定義基礎(chǔ)樣式
在項(xiàng)目開始之初，拿到UI設(shè)計(jì)稿，信心滿滿地開始定義css的全局基礎(chǔ)樣式，謝天謝地，css對這一點(diǎn)支持得很徹底，一處定義，所有頁面都可以引用。
先來一個(gè)color-red。
.color-red {
color: red
}這樣，在整個(gè)項(xiàng)目中，都可以給任意元素添加一個(gè)color-red類，美滋滋，我真是個(gè)小機(jī)靈鬼！
幾個(gè)迭代過去，你已經(jīng)把color-red這面紅旗插滿了整個(gè)項(xiàng)目。UED說，咱們改個(gè)版，所有紅色的文本改為藍(lán)色，紅色的link不變！
嗶！——（你發(fā)出的聲音）
你又得屁顛屁顛地把一個(gè)一個(gè)的紅旗拔出來，再插上藍(lán)色的旗子（因?yàn)槟悴桓也桓裳剑?/p>
命名沖突
在一個(gè)頁面，你定義了一個(gè).header，寫了個(gè)完美的特效，發(fā)布到dev一看，就是不管用，橫看豎看，本地是好的啊，神奇（生氣）！過了若干時(shí)間的排查，另一個(gè)同事在另一個(gè)地方也寫了一個(gè).header，完美的覆蓋了你的。把你頭打歪！
編輯器可不會(huì)提醒你哦！
慢慢你會(huì)發(fā)現(xiàn)，這種命名沖突可太頻繁了呀！頭大，要不要用上css modular啊？
子類覆蓋
有的小伙伴聰明地將類名嵌套定義，這就不會(huì)沖突了吧？嘿嘿，你想多了！
/* 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是沖突呢還是不沖突呢？
以上的這些問題，在項(xiàng)目中相信大家都遇見過，并且項(xiàng)目越大，出現(xiàn)的概率就越高，最后就會(huì)演變成一座[屎]山。
“大家都別動(dòng)，牽一發(fā)而動(dòng)全身哦！”
“這就是蝴蝶效應(yīng)吧？？？”
難道css這些問題就沒法解決了嗎？當(dāng)然不是，我們來看看大神們是如何解決這些問題的。
BEM是Block、Element、Modifier的縮寫，是一個(gè)類命名的規(guī)范。
首先我們來看一個(gè)例子：
/* Block */
.btn {}
/* Element that depends upon the block */
.btn__price {}
/* Modifier that changes the style of the block */
.btn--orange {}
.btn--big {}相信小伙伴們已經(jīng)有了一個(gè)初步的認(rèn)知：
Block是一個(gè)獨(dú)立的組件（元素），定義的了“組件是什么，按鈕？還是菜單？”。
Element是屬于Block，是依賴于Block的元素，描述的是“Block里面的什么？比如，文本？圖標(biāo)？”
Modifier用于描述Block或者Element的外在表現(xiàn)，比如大小、顏色、狀態(tài)等。
看一個(gè)例子：
<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內(nèi)部的input元素；
search-form__button是Element，描述的是search-form內(nèi)部的button元素；
search-form__button_size_m是Modifier，描述的是size為m的search-form__button；
這樣寫css是不是非常的清晰？瞬間就提高了可讀性和可維護(hù)性？
概念如此簡單，還不趕緊多了解一下？
另外，可能有些小伙伴也注意到了，Block和Element使用雙下劃線分隔，和Modifier是用中劃線分隔，這也不是一成不變的，可以按照自己的喜好來決定如何分割。
有些小伙伴可能會(huì)有疑問，BEM和Saas、Css Module有什么區(qū)別？解決的問題是一樣的嗎？
Sass是css的預(yù)處理器，在寫css的時(shí)候定義了一套規(guī)范，經(jīng)過編譯處理后輸出為css，和BEM是兩個(gè)不同的概念。使用saas或less也能實(shí)現(xiàn)BEM。BEM其實(shí)是不推崇類名的嵌套定義的，如果想像sass那樣嵌套的寫出標(biāo)準(zhǔn)的BEM，可以使用@at-root。
Css Module解決的問題是多個(gè)模塊的css的命名沖突問題，個(gè)人覺得是傻瓜式解決方案，在應(yīng)用層的css-in-js應(yīng)用比較多，適合css入門選手。要想寫好css，還是得從根本上入手呀！
*請認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
