整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          蘋果Safari瀏覽器支持“垂直表單控件”,可實現語言文段豎排

          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。

          在各種論壇中經??吹疥P于css是否是一門編程語言的爭論。在我看來,最好用對待編程語言的態度來看待css,不要忽視css,否則,在項目后期,你會發現,你的css越來越混亂,important會越來越多,不同位置的類名互相沖突覆蓋,改一個類的樣式,要檢查整個項目的頁面是否受到影響,項目內部的css共享完全依賴拷貝……從這個角度來說,你敢說css不是編程語言?它完全有了像編程語言一樣能把你搞得焦頭爛額的能力。而這一切都來源于你在一開始對她的忽視與不屑。出來混,總要還的?。?/p>

          css的問題

          盲目的定義基礎樣式

          在項目開始之初,拿到UI設計稿,信心滿滿地開始定義css的全局基礎樣式,謝天謝地,css對這一點支持得很徹底,一處定義,所有頁面都可以引用。

          先來一個color-red。

          .color-red {
          	color: red
          }

          這樣,在整個項目中,都可以給任意元素添加一個color-red類,美滋滋,我真是個小機靈鬼!

          幾個迭代過去,你已經把color-red這面紅旗插滿了整個項目。UED說,咱們改個版,所有紅色的文本改為藍色,紅色的link不變!

          嗶!——(你發出的聲音)

          你又得屁顛屁顛地把一個一個的紅旗拔出來,再插上藍色的旗子(因為你不敢不干呀)。

          命名沖突

          在一個頁面,你定義了一個.header,寫了個完美的特效,發布到dev一看,就是不管用,橫看豎看,本地是好的啊,神奇(生氣)!過了若干時間的排查,另一個同事在另一個地方也寫了一個.header,完美的覆蓋了你的。把你頭打歪!

          編輯器可不會提醒你哦!

          慢慢你會發現,這種命名沖突可太頻繁了呀!頭大,要不要用上css modular?。?/p>

          子類覆蓋

          有的小伙伴聰明地將類名嵌套定義,這就不會沖突了吧?嘿嘿,你想多了!

          /* 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,還是得從根本上入手呀!


          主站蜘蛛池模板: 日本精品一区二区在线播放| 精品人妻AV一区二区三区| 精品国产一区二区三区2021| 久久亚洲日韩精品一区二区三区| 亚洲AV成人精品一区二区三区 | 在线观看国产一区二区三区| 久久久综合亚洲色一区二区三区| 国产激情一区二区三区| 日韩精品免费一区二区三区| 亚洲综合色一区二区三区| 日本内射精品一区二区视频 | 无码精品人妻一区二区三区漫画 | 亚洲一区精品中文字幕| 中文字幕日本精品一区二区三区| 国产在线精品一区二区在线看| 波多野结衣久久一区二区| 亚洲午夜精品一区二区公牛电影院 | 国产免费私拍一区二区三区| 成人精品一区二区激情| 国产福利日本一区二区三区| 亚洲乱码一区二区三区国产精品 | 天堂资源中文最新版在线一区| 国产一区二区三区高清在线观看| 国产在线精品一区二区夜色 | 一区二区视频传媒有限公司| 三上悠亚一区二区观看| 中文字幕精品一区| 无码一区二区三区在线观看| 无码精品人妻一区二区三区免费看| 亚洲av一综合av一区| 麻豆aⅴ精品无码一区二区| 蜜桃无码AV一区二区| 亚洲av乱码一区二区三区按摩| 蜜桃AV抽搐高潮一区二区| 色天使亚洲综合一区二区| 国产一区二区在线视频播放| 不卡一区二区在线| 亚洲Av高清一区二区三区| 天美传媒一区二区三区| 福利视频一区二区牛牛| 国产乱码一区二区三区爽爽爽|