CSS3 transform 對HTML文檔流帶來的影響

html 總是那麼的驚奇

來自「硬體加速」

年初的一個筆記，閒時整理出來。

很多網路文章都說建議打開瀏覽器的硬體加速，這樣頁面渲染速度、動畫流暢性會提高。這幾乎成了很多人頁面製作的標配，管實際上有沒有用都來一個：

    html，body {
        transform: translate3d(0,0,0);
    }

但這在很多情況下會引起 html 層級文檔流的「異常」。
W3C spec 中有如下描述:

In the HTML namespace, any value other than none for the transform results in the creation of both a stacking context and a containing block.  
.

意思是：
在HTML 內，沒有比對一個即是層疊物件又是容器區塊的DOM 進行transform 變換更沒有意義的了。
這類物件也扮演著 positioned(主要是 absolute/fixed ) 子孫元素容器的角色。

。 。 。翻譯能力有限，不懂的人估計這句話看了後更暈，下面詳述。

標準文檔流

頁面中的dom 元素按照其在HTML 中的標籤位置順序進行從上到下、從左往右的排布過程

想必必對這個基礎的定義已經很熟悉了吧。但是，這個究竟在實際中有什麼體現呢？

如果你在頁面中放置一大堆 display: inline-block 的元素，它們會很乖巧的 上 -> 下 左 -> 右 排的很整齊。這就是標準文檔流的基礎體現。

當你用position、float等屬性使其脫離文檔流時，就會又產生一個頁 層級 的概念。 (扯遠了...)

transform 改變定位預設屬性

範例程式碼如下：

    
        <header>header</header>
        <p></p>
        <footer>footer</footer>
    

點擊查看範例

dom 元素的預設定位屬性是position: static; 這也是標準文件流的標準定位方式。

例子中，不管 p 怎麼上下滾動，header 和 footer 會永遠置於螢幕的最上和最下部。

但是如最初所述，給body 或html 加上一個transform: translate3d(0,0,0);，你去試試，就會發現，原本position: fixed; 的;

的兩個元素都不聽話了，會隨著螢幕進行捲動。

實際上，position: fixed; 的參考對象並不是大家所說的屏幕，而是一個 viewport 的html對象，一般地一個頁面(document.documentElement

)會產生一個 viewport。

你用 document.documentElement.clientHeight你用 document.documentElement.clientHeight

就可以的看到實際 viewport 的高度，其中

fixed 的元素都是以此為容器進行定位的。 body(或html) 加了transform 屬性以後，整個body DOM 既會產生對應的變換，但此時的「整個」僅是指body 下標準文檔流元素，對於那些position: absolute ;

/

position: fixed; 元素，因為已經脫離了body 所屬的文檔流，所以無法憑藉body 的變換使自己也自然的達到相應的變換效果。 此時，瀏覽器為了讓此類DOM 得到相應的變化，會產生一個新的viewport，這個viewport 作為定位元素的容器存在，會響應body 的transform

變換效果，從而讓裡面那些脫離文檔流的

positioned 元素也能進行變換。 這個viewport 會嚴重影響position: fixed; 的定位，當它隨著「本尊」dom同步滾動的時候，會帶著fixed

元素一塊滾，此時會產生一種類似

absolute 的詭異效果：fixed 元素似乎變成了absolute

，存在於一個和

document.documentElement

大小一致的「看不見」容器內。

引申情況

在一些行動端裝置(或APP)上，給

標籤的播放預設開啟的硬解碼，此時也會產生上述現象，影片會"浮"在頁面上面，不會隨頁面元素正常捲動。

還有一些低版行動裝置瀏覽器上，也會出現類似的情況，可依此思路嘗試解決。

總結其實上面的情況不僅會發生在 body

上，一個任意的 dom 添加了

transform

之後都會生產一個類似 viewport 的效果，有興趣可以去嘗試。

引用:

http://www.php.cn/

html 總是那麼的驚奇

來源於「硬體加速」

年初

🎜🎜🎜來源於「硬體加速」🎜 。 🎜

很多網路文章都說建議打開瀏覽器的硬體加速，這樣頁面渲染速度、動畫流暢性會提高。這幾乎成了很多人頁面製作的標配，管實際上有沒有用都來一個：

    html，body {
        transform: translate3d(0,0,0);
    }

但這在很多情況下會引起 html 層級文檔流的「異常」。
W3C spec 中有如下描述:

In the HTML namespace, any value other than none for the transform results in the creation of both a stacking context and a containing block.  
.

意思是：
在HTML 內，沒有比對一個即是層疊物件又是容器區塊的DOM 進行transform 變換更沒有意義的了。
這類物件也扮演著 positioned(主要是 absolute/fixed ) 子孫元素容器的角色。

。 。 。翻譯能力有限，不懂的人估計這句話看了後更暈，下面詳述。

標準文檔流

頁面中的dom 元素按照其在HTML 中的標籤位置順序進行從上到下、從左往右的排布過程

想必必對這個基礎的定義已經很熟悉了吧。但是，這個究竟在實際中有什麼體現呢？

如果你在頁面中放置一大堆 display: inline-block 的元素，它們會很乖巧的 上 -> 下 左 -> 右 排的很整齊。這就是標準文檔流的基礎體現。

當你用position、float等屬性使其脫離文檔流時，就會又產生一個頁 層級 的概念。 (扯遠了...)

transform 改變定位預設屬性

範例程式碼如下：

    
        <header>header</header>
        <p></p>
        <footer>footer</footer>
    

點擊查看範例

dom 元素的預設定位屬性是position: static; 這也是標準文件流的標準定位方式。

例子中，不管 p 怎麼上下滾動，header 和 footer 會永遠置於螢幕的最上和最下部。

但是如最初所述，給body 或html 加上一個transform: translate3d(0,0,0);，你去試試，就會發現，原本position: fixed; 的;

的兩個元素都不聽話了，會隨著螢幕進行捲動。

實際上，position: fixed; 的參考對象並不是大家所說的屏幕，而是一個 viewport 的html對象，一般地一個頁面(document.documentElement

)會產生一個 viewport。

你用 document.documentElement.clientHeight你用 document.documentElement.clientHeight

就可以的看到實際 viewport 的高度，其中

fixed 的元素都是以此為容器進行定位的。 body(或html) 加了transform 屬性以後，整個body DOM 既會產生對應的變換，但此時的「整個」僅是指body 下標準文檔流元素，對於那些position: absolute ;

/

position: fixed; 元素，因為已經脫離了body 所屬的文檔流，所以無法憑藉body 的變換使自己也自然的達到相應的變換效果。 此時，瀏覽器為了讓此類DOM 得到相應的變化，會產生一個新的viewport，這個viewport 作為定位元素的容器存在，會響應body 的transform

變換效果，從而讓裡面那些脫離文檔流的

positioned 元素也能進行變換。 這個viewport 會嚴重影響position: fixed; 的定位，當它隨著「本尊」dom同步滾動的時候，會帶著fixed

元素一塊滾，此時會產生一種類似

absolute 的詭異效果：fixed 元素似乎變成了absolute

，存在於一個和

document.documentElement

大小一致的「看不見」容器內。

引申情況

在一些行動端裝置(或APP)上，給

標籤的播放預設開啟的硬解碼，此時也會產生上述現象，影片會"浮"在頁面上面，不會隨頁面元素正常捲動。

還有一些低版行動裝置瀏覽器上，也會出現類似的情況，可依此思路嘗試解決。

總結其實上面的情況不僅會發生在 body

上，一個任意的 dom 添加了

transform

之後都會生產一個類似 viewport 的效果，有興趣可以去嘗試。

更多CSS3 transform 對HTML文檔流帶來的影響相關文章請關注PHP中文網！ 🎜🎜🎜