大約一年前，我寫了一篇關于在Web中實現垂直排版的文章。這是一個簡單的Demo，它允許你通過復選框來切換書寫模式。
在不久之后我遇到了@Yoav Weiss，并一起聊了一些關于響應式圖片社區小組，因為我提到了如果可以通過媒體查詢得到元素的-mode,就不必在切換排版的時候通過一些黑魔法的方式對圖片進行轉換。他建議我寫一個響應式圖片的用例。
當我重新打開這個Demo的時候，看到的結果讓我感到無語。為了宣泄一下，我將一步一步寫下各種瀏覽器的渲染結果，以及目前可能的解決方案。
這篇文章的篇幅很長，可能會花費你一定的時間。
初步的調查結果
我只看我能立即訪問的瀏覽器。因為我還有別的事情需要做。
(64.0.3278.0 dev)
效果看起來很不錯。要是我說所有的一切都被破壞了，那其實有點夸張。所有的文字和圖片都占滿，在垂直書寫模式下沒有重大的渲染問題。，這就是我喜歡你的原因之一。
切換排版模式，將東西都放到瀏覽器的右側去。我記得在垂直排版下將東西水平居中是一件讓人特別痛苦的事情，所以在第一次不太順利的嘗試中，我肯定是用了某些我自己都忘了的黑魔法。
這個在2017年年初是絕對可行的，我有絕對的信心這么的認為。因為我為在.Asia做分享的PPT中有這個效果的錄屏。我很確定當時用的是。幾個月的時間，Demo的效果就變得令人難以置信。我的老大曾經提到過一個詞叫作代碼腐爛，也許就是這樣的吧。
(59.0a1 )
效果令我再次感到無語了。 還是我的默認瀏覽器，所以我的最初反應是這一切都被破壞了，整個人都崩潰了。事實上，垂直排版是被破壞了，還出現了無限的水平滾動條。到底發生了什么？我自己也是一臉的蒙逼。
我們來切換一下狀態，可我找了半天的復選框，都不知道在哪里了。不管怎么說，至少我將復選框綁在了label標簽上，這樣我仍然可以點擊label標簽來切換。所以，這絕對不是居中，但也沒崩潰。兩個瀏覽器的渲染效果可以說是天差地別。
44
哈哈哈...。看起來令人驚訝，效果出奇的好。甚至連高度都是正確的。可能我太輕看了。瀏覽器的渲染引擎到底是什么呢？好吧，是。
這是頁面的中間部分。如果不查看代碼，我也確定我嘗試過一些很奇怪的轉譯來改變整個內容塊，因此在每個瀏覽器中行為不一致。但這是個令人欣慰的驚喜。
Edge 16.17046
這是 10內置快速通道版本，所以我認為我的Edge瀏覽器應該比大多數人的版本更高。沒關系，我也可以用我的手機（(^_^)不要有任何的奇怪，我用的就是 Phone）。
不管怎么說，效果看上去還不算太壞。只是那個復選框有點偏了。更重要的是滾輪能正常的工作！其他所有的瀏覽器都不允許我用滾輪水平滾動。雖然我不知道這是的功勞還是Edge的功勞。
事實也是隱約的居中。我真的需要馬上檢查一下我的轉換代碼。現在我可能對我的復選框究竟怎么了，也產生了一定的疑問。使用滾輪無法垂直滾動，這就有趣了。另外，注意滾動條在左邊。
Edge 15.15254
Edge 15的-rl效果
Edge 15的-tb效果
幾乎和Edge 16的效果一模一樣。我有理由相信 Phone上的Edge瀏覽器用的是與桌面版本同樣的渲染引擎，如果有錯，煩請各路大嬸拍正。
iOS 11
iOS 11 的-rl效果
iOS 11 的-tb效果
盡管我的iPad上裝了一大堆的瀏覽器，但我知道它們的渲染引擎都是，因為Apple從示允許過第三方的瀏覽器引擎。正如在桌面版展示的那樣，這是表現比較好的瀏覽器。
開始擼碼
好了，既然我們已經確定了排版被打破的基準，現在是時候揭開塵封的面紗，看看下面到底有什么怪異的代碼。說句公道話，沒有太多的東西，考慮到這是一個非常簡單的示例，所以效果還是不錯的。
同量我還要強列的安利一波，這也是我最重要的開發工具，尤其是需要在不同的設備的不同瀏覽器上調試的時候。如果沒有，我將會多很多無趣的事情做。
一些背景知識
切換器的實現可以用兩種形式，一種是通過切換類，另一種是使用復選框（其實也可以使用單選按鈕）。不過我通常傾向于只使用CSS的解決方案（能用CSS實現的功能，絕不用），所以我決定使用復選框的方案。這個Demo很簡單，所以不會有太多鍵盤控制方面的干擾。我的意思是，你可以像其它任何的復選框一樣用tab切換到它然后切換。
我真的需要研究可訪問性的問題，以確定我是否會在屏幕閱讀器上搞砸它，但那是另外一回事了，不是今天要聊的事情。回到我們的主題中，處理垂直排版的問題。
如果你沒有嘗試過復選框，這也不要緊，因為它不會太復雜，它涉及到:狀態選擇器的使用和兄弟或子選擇器。你可以通過這種方式來控制復選框選中的狀態。
需要注意的是，切換:狀態的input（通常是類型），必須處于與你相切換狀態的目標元素相同或更高的層級。
問題就在復雜度上。在同一個頁面上混合使用不同的嵌套的書寫模式確實會使用瀏覽器更加混亂。我不是瀏覽器工程師，我所掌握的渲染知識其實是微不足道的。但我是一個執著的人，所以必受其苦。
在最初始的Demo中，我在body元素上設置了-mode的默認值為-rl，然后使用復選框來切換main元素里的-mode值。但是看起來似乎每個人（瀏覽器渲染引擎）都像上面的截圖目錄一樣，以不同的方式處理嵌套的書寫模式。
調試：重置到基線
記住，這是一個大腦轉儲條目，如果你覺得無聊，我對此表示抱歉。我做的第一件事情就是刪除所有樣式，重頭再來。再說一次，這是可行的，因為這個Demo很簡單。朋友們，只有結合上下文才是一切。
這幾乎成了我所有項目的實際起點。將所有元素設置成-box，而且通常我還會加上:0和:0作為樣式重置的基礎。但是就這個Demo而言，我將讓瀏覽器保留它的空白，并重置body元素。
這個Demo幾乎全是中文，所以我只添加了中文字體，把系統自帶的sans-serif作為后備。不過大多數情況來說，優先選擇基于拉丁語的字體是個普遍的共識。但在這里，中文字體支持基本的拉丁字符，而反過來情況就不一樣了。
當瀏覽器遇到中文字符時，它不會在基于拉丁語的字體中尋找，所以它會選用下一種備選字體，直到找到合適的。如果你先將中文字體列出來，瀏覽器將使用中文字體中的拉丁語字符，有時候這些字形沒被打磨，看起來不也太好，尤其是在上。
接下來是一些不太影響布局的美化（line-算嗎？(^_^)）。
基本工作做好了，那我們就開始來看看-mode在瀏覽器中的渲染行為了吧。感覺寫了一大堆的費話，現在才像是大家想要的東東。
-rl的含義
每個元素的-mode的默認值都是-tb，而且它是一個繼承屬性。如果設置了一個元素的-mode，這個值將會傳遞到它所有的子元素。
如果main元素的-mode設置為-rl，在每個瀏覽器上，所有的文字和圖像都被正確渲染了。有15px輕微的垂直溢出，我懷疑是因為瀏覽器滾動條造成的，但我不敢確定就是這個原因。其它的瀏覽器一點水平溢出都沒有。
main元素在垂直書寫模式的同時，本身是水平的書寫模式，就會產生問題。這意味著內容從左邊開始，而且我們最終會看到第一次加載的文章末尾的內容。
因此，我們把事情提高到一個層次，在body上設置-mode:-rl。、和Edge幾個瀏覽器中的渲染結果，正如我們所想的一樣從右到左渲染內容。但在瀏覽器中仍然顯示文章的末尾，盡管這確實修復了滾動條溢出的問題。這看起來和Bug 有關。
最后，如果我們把html設置-mode:-rl，終于正常的渲染了，從右到左顯示，而且沒有溢出。
IE11支持-mode屬性，只不過使用較早的規范定義的舊語法-ms--mode:tb-rl。這工作正常，但我由于現在使用的main標簽，IE11并不支持，切換器失效了。甚至將main標簽設置成:block都無法修復。我可以為了更好的兼容性將main替換成div。
布局切換
由于有已知的垂直書寫的彈性盒模型的問題，所以我將把調試任務分成兩個部分，一是純粹的布局。找出使切換器正常工作的不同方法，而且沒有任何奇怪的溢出。
第二個部分將與圖像居中有關，這讓我陷入困境的原因。除了居中，我還想調整圖像的方向，它是讓我首先重溫RICG用例匯總的原因。
解決方案一：使用
讓我們先來談談解決方案。既然問題出在混用的-mode上，也許我們停止混用，效果就會不一樣呢？基于上面的觀察，用一個事件監聽器去切換html元素的CSS類，可以隱性修復許多奇怪的渲染問題。好了，不再憑空想像，動手寫代碼吧。
我想切換的兩個類的類名簡單的命名為和。既然有了復選框，也許也可以用作類的切換器。
內容塊居中的效果很完美。因為再也沒有嵌套的書寫模式或者彈性盒模型。直接將設置為auto就可以在所有瀏覽器中完美實現居中:
我們經常看到的是-left和-right設置為auto，并且配合元素的width可以完美的實現水平居中的效果，那是因為我們的書寫模式是水平的。而現在我們聊的是垂直書寫模式，所以需要將對應的-left和-right換成-top和-。比如上面的示例所示。
有趣的是，在垂直書寫模式，我們可以用-top:auto和-:auto來實現垂直居中。但請相信我，水平居中將比你想像的更令人痛苦。在下一個復選框的方案中，你將看到。
Edge遵守嚴格模式下不允許分配只讀屬性的規范，但是和在嚴格怪異模式下仍然允許，很可能是為了代碼兼容。我最初嘗試使用來切換類名，但它是一個只讀屬性，而則不是。更詳細的內容可以閱讀下面的鏈接。
解決方案二：復選框
這種技術方案的原理類似于使用，和方案的最大區別在于我們不使用CSS類來切換狀態，而是使用:狀態選擇器。如我們前面所討論的，復選框元素必須和main元素在同一層級才會生效。
布局代碼與.和.一樣，但遺憾的是，結果卻不一樣。垂直居中是好的，看起來好像是我們在用。但是水平居中更向右偏了。的auto似乎并沒有發揮作用。
但仔細想想，這樣的行為并沒有錯，因為我們同樣不能用這種方式在水平書寫模式下實現垂直居中。為什么呢？看看規范就懂了，我想你也懂的。
所有的CSS屬性都有值，一旦你的瀏覽器解析了一個文檔并構造了DOM樹，每個元素的每個屬性都需要賦值。@Lin Clark寫了一個精彩的動畫（代碼漫畫）來闡述CSS引擎如何工作，強烈建議你閱讀，不要錯過。話又說回來，值在規范中是這樣描述的：
一個屬性的最終值是四步計算的結果：首先通過規范確定值（指定值），然后解析為一個用于繼承的值（計算值），接下來要是沒有必要，就轉換成絕對值（使用值），最后依據具體場景限制，再做轉換（實際值）。
與此同時，根據規范，和的計算由各類盒模型的規則來決定的。如果下下的值同時為auto，它們的使用值將被解析成0。
當我們把書寫模式設置為垂直方式，似乎在計算的時候會變成水平坐標。我說似乎是因為我并不百分百確定它真是這樣計算的。它讓我覺得解決方案很神奇。
開個玩笑，實際上因為在解決方案中沒有混用書寫模式，所以將各自的值解析成0，并不影響我們想要的居中效果。可能你需要重讀這句話幾次，才能更明白其中的深意。
想要在切換到垂直書寫模式的時候將main元素水平居中，我們需要使用好的切換技巧。
這在，和上可行。不幸的是，Edge上有點毛病，東西都偏于頁面中間的某個地方以及左邊。是時候記下這個Edge的bug。另外，滾動條出現在了左側而不是右側。
處理圖像對齊
是不是有點累了，不過不要停下來，繼續往下。在垂直書寫模式時，希望有兩張圖片的元素堆疊顯示，而在水平書寫模式時，如果空間允許，則并排顯示。理想情況下，元素（圖像和標題）將在各自的書寫模式下居中。
經典屬性
既然我們在一個干凈的頁面上運行，那就讓我們試試最基礎的居中技術：text-align。默認情況下，圖像和文本是內聯元素。給元素設置text-align:， Oh, My God。一切都OK了。神奇吧！
水平和垂直書寫模式下的圖像都已經成功的居中了。我現在非常懷疑一年前我做這個Demo的時候，智力突然為0了。很顯然，為了我的目的和意圖，彈性盒模型是沒有必要的。我首先嘗試了新的技術，這也讓我付出了很高的代價。
在水平書寫模式中，不需要加太多額外的東東。只是一個簡單的-:1em，給之間留點空間。由于空間關系，我確實需要將豎直的圖像旋轉，在這里我使用的來完成。
問題是，當你旋轉一個元素，瀏覽器仍然會記住它原來的寬高，所以在我的Demo中，當視窗變得非常小的時候，它將觸發水平溢出。可能有辦法修復這個問題，但我沒有找到。如果你在這方面有經驗，歡迎指點。
這就是我將為RICG編寫的用例。我的想法是，如果可以通過媒體查詢獲得書寫模式，我就可以使用定義一個垂直的圖像和一個水平的圖像，分別為對應的書寫模式提供不同的圖片。
在垂直書寫模式中，我們通常希望文字整齊，或者至少在短行上對齊半孤立的字符，然后文字的空隙，應該設置為left而不是。
現在我們幾乎可以稱之為圓滿的一天。最終結果已實現了。我還想補充的是，除了我之前提到的Edge缺陷之外，無論方案還是復選框方案，得到的結果都是完全相同的。
使用實現居中
我一度懷疑我使用實現居中的理由，盡管我真的不記得到底為什么會認為這是一個好的方案。很明顯，我不需要的任何特點。那我應該也做個大腦轉儲？
可是我看了我自己的原始代碼，我才發現我給包裹圖像的容器div設置了:flex，這讓圖像成為Flex的子元素，導致的垂直書寫模式渲染混亂。
使用這種方法，效果看上去很美好，而且我測試過，Edge以及的所有版本都是OK的，因此圖像在垂直和水平兩種書寫模式下都居中對齊了。但瀏覽器下不行，切換到垂直書寫模式時，圖片在我的頁面上不可見。
我已經用:flex的div來包裹應該堆疊顯示的圖像，但不知道為什么在的垂直書寫模式下卻有問題。我懷疑這個渲染行為和這些Bug有關：Bug 、Bug 、Bug 、Bug 和Bug 。
與此同時，我很好奇這些圖片已經是容器的子元素（Flex項目）,但在垂直書寫模式下效果就是不好。我百思不得其解，差點就想說，瀏覽器就是一坨粑粑。
拋開垂直書寫模式，我還和@Jen 聊過一些關于在不同瀏覽器中的實現，她發現在所有的瀏覽器中，縮小圖像的處理都是不同的。這個問題仍然在CSS工作組中討論，對這方面感興趣的同學，可以持續關注相關的更新。
這個縮小的問題與內部尺寸的概念有關，尤其是圖像固有長寬比例的圖像。CSS工作組對此進行過相當長的討論，因為這不是一個小問題。
有趣的是，中,Flex容器的寬度受視窗寬度的限制，但目前在其他的瀏覽器上并沒有發現類似的現象。當容器內所有的圖像的寬度之和超過了視窗寬度，就會讓圖像縮小以適應視窗的寬度，但在別的瀏覽器上并不會縮小，只會讓瀏覽器出現一個水平的滾動條。
為了暫時回避這個問題，我要確保我的圖像都不是Flex項目（圖像的容器不是Flex容器）。所有的圖像，無論是單還是雙，都被包裹在div中。元素設置了:flex屬性，讓和包裹圖像的div成為Flex容器的子元素而不是圖像本身。
復選框的方案實現完全是一樣。我從中學到的是，瀏覽器對于元素的區域計算需要下很大的功夫，尤其是具有固有尺寸比例的。
Gird如何？
我們已經遠離了這個布局所需的東西css圖片旋轉之后滿屏，所以我考慮嘗試使用Grid來實現圖像對齊。我們可以嘗試讓每個都成為一個Grid容順，或許可以用上grid-area和fit-這些有趣的屬性，讓事情變得簡單。
不幸的是，我嘗試之后，我整個人都要崩潰了。的Grid調試工具并不能匹配到我頁面上的元素，但也有可能是因為頁面上的東西太多了。
我需要為使用Grid的垂直書寫模式創建一個簡化的測試用例，那將是一個簡單得多的Demo，我還會單獨寫一篇這方面的文章（可能還會有相關的錯誤報告）。
成功的解決方案
我寫的Demo實現的是沒有的復選框解決方案。我將保留復選框的版本，便于追蹤Edge的Bug。對于解決方案，如果你不介意增加額外的容器的話，也是可以的。使用來實現，效果看起來更好一些，因為你將切換器包裹在一個div中，然后再處理它的樣式。
在最后，有很多方法可以實現同樣的效果。從別的地方復制代碼也可以css圖片旋轉之后滿屏，但是出現莫名其妙的問題就蛋疼了。你不必從頭開始寫所有的東西，但要確保里面有沒有使用一些黑魔法。