Web技巧（16）

時間 2019-11-05

標籤 web 技巧欄目 HTML 简体版

原文原文鏈接

上個週末由於本身要寫PPT而沒來得急整理，因此又錯過了一期。在這一期中，大部份內容將圍繞着@Bill Mei的《Top 10 most deadly CSS mistakes made by new and experienced developers》文章中提到觀點來展開。這裏面的一些觀點雖然不徹底對，但仍是有相應的參考價值，取捨由你們本身來決定。若是你在這方面也有相關的經驗，也歡迎在下面的評論中分享。另外在後面會簡單的整理幾個最近以爲有意思的新東西。感興趣的同窗，請繼續往下閱讀。javascript

10個最致命的CSS錯誤

多年來，不少工程師在使用CSS時容易犯一些常見的錯誤，無論是老司機仍是新手。而CSS一直又是簡單但不容易的語言（不直觀和難以使用），真正探究的並很少，而不少常見的錯誤又每每會阻礙項目的開發進程。若是咱們在編寫CSS的時候就能避免這些錯誤，是否是在實際開發的時候能事半功倍。css

如下是編寫CSS中常見的10個錯誤，也是最致命的錯誤。html

接下來的10條內容來自於@Bill Mei的《Top 10 most deadly CSS mistakes made by new and experienced developers》一文。前端

編寫選擇器時太過遵循DOM結構

有一些開發人員喜歡追求一種極簡主義的風格，他們試圖着不在HTML中有大量的類名（class），經過使用DOM結構來做爲CSS的選擇器，這樣他們的選擇器就會遵循DOM樹的結構。好比有這麼一個DOM結構：vue

<body>
    <div class="container">
        <div class="main-content">
            <div class="blog-row">
                <div class="blog-col">
                    <section>
                        <article>
                            <a href="#">This link is not bold</a>
                            <p><a href="#" class="bold">This link is bold</a></p>
                        </article>
                    </section>
                    <section>
                        <a href="#">This link is not bold</a>
                    </section>
                </div>
            </div>
        </div>
    </div>
</body>
複製代碼

有些同窗在給a連接添加樣式的時候，會這樣的操做：html5

body .container .main-content .blog-row .blog-col section article p a {
    font-weight: bold;
}
複製代碼

就算是在使用CSS處理器的時候也無限級的嵌套，經如：java

body {
    .container{
        .main-content{
            .blog-row{
                .blog-col{
                    section{
                        article{
                            p{
                                a{
                                    font-weight: bold;
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}
複製代碼

特別是在CSS的處理器中，不要說是新手，不少老司機也會出現相似上面這樣的錯誤。react

雖然在編寫HTML結構的時候，不少司機也提倡DOM結構能簡潔就儘可能的簡潔，但並非提倡這種無約束的極簡主義。由於這種極簡主義雖然保持了HTML的乾淨，但會讓CSS變得混亂，使其更難理解、調試和更改。就如上面的示例所示，CSS會變得不靈活，由於長組合的CSS選擇器承擔了複製HTML結構的任務，但這有背於CSS應該作的事情。css3

CSS的任務是提供樣式；HTML的任務是提供結構。這也是Web構建中最基本的原則之一。若是僅僅追求DOM簡潔乾淨，而忽略CSS，不考慮與CSS相互結合，這是錯誤的一種作法。另外這種編寫CSS的方式強度依賴於HTML的DOM結構樹，也會形成不少致命性的錯誤，好比說，你的HTML結構作出調整，那麼CSS選擇器也將作調整，而這種長鏈條的組合是最易於出錯的。這種作法也在無形中增長不少沒必要要的工做。web

相反，我更建議CSS的類和HTML的DOM更應該合理的結合起來。若是你須要從頁面中選擇一個特定的元素，應該在該元素上添加一個類名來完成：

.bold {
    font-weight: bold;
}
複製代碼

就算是你要使用這種長組合的方式來定位到DOM元素，我也強烈建議：

CSS的選擇器不超過三級。

幸運的是，如今有不少方式能夠幫助咱們避免這種方式，好比藉助StyleLint來監控你的CSS代碼，讓選擇器不超三級嵌套。也可使用CSS-in-JS和CSS Modules方式來維護你的CSS代碼。特別今天（截至2019年），這種方式更被普遍的採用。

若是你對CSS-in-JS和CSS Modules感興趣的話，我建議你花點時間閱讀下面的相關文章：

話說回來，咱們在項目中應該避免目標過於明確或指定過多的選擇器，而且要避免使用!important。CSS權重的對比讓咱們更直觀地瞭解爲何選擇器器權重過大是很差的。若是選擇器權重過大，它會更易被採用，若是咱們想要經過另外一個選擇器來覆蓋它，就須要一個權重更大的選擇器。這也是令不少同窗在覆蓋樣式時感到痛苦之處。

CSS選擇器權重的爭奪戰是一直存在你的CSS中，這也是令不少老司機和新手痛苦之處。若是你是新手，那麼掌握CSS選擇器權重是的計算是很是有必要的：

說到CSS選擇器權重之爭，我又要上@Elijah Manor

若是上圖還沒法讓你整明白CSS選擇器權重的計算，那麼下面這個計算器就能夠幫助你更好的理解：

編寫HTML時忽略SEO

搜索引擎優化（SEO）不只僅是你完成編碼後交給營銷團隊來處理。咱們在編碼的時候就須要考慮到SEO的內容，特別是由於一些影響SEO的因素。由於影響SEO因素一旦產生，那麼後續要優化的難度就會更大。好比網站的URL Scheme或服務體系結構。

衆所周知，HTML的語義化標籤是影響SEO的因素之一，由於標籤的選擇會影響搜索引擎對內容的理解和排名。若是你想顯示在搜索結果的頂部附近，那麼就得選擇正確的標籤。

假設你正在寫一篇關於CSS教程的文章。你能夠把全部內容都放在一個<div>中，然而<div>是一個通用的非語義的標籤，它不包含內容中的任何內在的含義。相反，你應該選擇一個更具體的語義標籤，例如<article>來包含文章的內容，<nav>來包含到跳轉到其餘文章的連接。

選擇更具體的語義標籤而不是通常非語義標籤的好處是，你能夠向搜索引擎提供關於你的網站更多的信息，這樣一來，搜索引擎的爬蟲能更好的理解和交付與讀者的搜索查詢相關的內容。

例如，用於文章標題的HTML標籤，它有六個潛在的標題標籤，按最重要的標題到最不重要的標題的順序排列h1~h6（數值越小，表示越重要）。<h1>是你最重要的標題，由於它是一個特殊的信號，搜索引擎會把這個理解爲你內容的標題或者頁面的標題（<title>，大多數搜索引擎二者都會考慮）。此外，若是你的用戶視力受損，而且使用屏幕閱讀器，大多數屏幕閱讀器都知道要當即大聲的朗讀<h1>中的內容，由於它會先假定這是你的內容的標題。

這也意味着，若是你使用<h1>來處理任何不是標題的內容，或者你在一個頁面上有多個<h1>，搜索引擎就會被混淆，你的「真實」標題（想要第一時間讓搜索引擎識別的標題）可能不會出如今搜索結果中。另外的一個狀況是，在不一樣的部分嵌套多個<h1>，好比：

<article>
    <h1>My cool blog post</h1>
    <p>This blog is so cool!</p>
</article>
<footer>
    <h1>Contact Us</h1>
    <p>Tel: 867-5309</p>
</footer>
複製代碼

儘管這個頁面上有兩個<h1>標籤，但第一個是在<article>中，而另外一個是在<footer>標籤中。因爲搜索引擎理解<article>的內容要比<footer>的內容更重要，更有趣；因此它會使用<article>中的<h1>，而不是<footer>中的<h1>看成標題。因此在某種意義上，你的父母是誰，決定了你有多重要。現實生活中也是如此，有個好爹是多麼的重要。

有關於HTML正確的打開姿式，@Daniel Tonon的《How to Section Your HTML》一文就作過這方面深刻的探討：

有關於HTML標籤和SEO之間的關係，更多的內容能夠閱讀下面的文章：

隨着JavaScript框架的崛起，好比Vue，React等。不少同窗平時在使用這些JavaScritp框開發頁面的時候，可能也不太關注什麼SEO相關的事情。事實上在國外有關於Vue，React開發頁面時對SEO方面的討論仍是蠻多的，感興趣能夠閱讀：

另外在Reddit和知乎上也有相關的討論：

最後在給你們推薦一個工具Prerendering，號稱是最好的SEO解決方案：

The best SEO solution, and SSR replacement for JavaScript websites. It’s like SSR with no need of coding.

使用`px`單位

使用px單位並非一個錯誤，但要看使用的場景。真正的錯誤是使用絕對單位而不是相對單位。

有關於CSS單位更多的介紹，能夠閱讀《圖解CSS：CSS 的值和單位》一文或點擊這裏瞭解更多的內容。

咱們更喜歡使用相對測量方法，好比em、%、rem和其餘可能的方法。之確保了網站的縮放比例能根據font-size進行縮放。

// 很差的用法
p {
    font-size: 16px;
    line-height: 20px;
    margin-bottom: 8px;
}

// 好的用法
body {
    font-size: 16px;
}
p {
    font-size: 1rem;
    line-height: 1.25;
    margin-bottom: 0.5em;
}
複製代碼

好比下圖，就是使用em單位好的縮影：

時至今日，使用px這種絕對單位的問題是沒法較好的適配於不一樣終端，特別是在移動終端上，面對的場景更爲複雜。若是使用px單位不能讓你的Web頁面或Web應用程序在任何地方都保持相同的比例，因此你必須嘗試將你的元素放在相對項中，而不是絕對項中。不然，屏幕上的可用空間不能適當地縮放到每一個窗口大小。相對單位使用這種簡單的px鎖定你的設計到特定的縮放級別，使你的設計難以縮放到不一樣的設備。

在移動端的天下，我更建議使用視窗單位來作測量單位，更易於讓你的設計能在不一樣的設備終端達到縮放效果。若是你對這方面感興趣，建議您花點時間閱讀：

試圖實現「像素級」的完美設計

更廣泛地說，在編寫CSS時，「像素級」的完美設計並非一個好的目標。

現代Web頁面或Web應用程序必須跨多種設備（移動設備、桌面設備、平板電腦、TV大屏和手錶）運行，其中有多樣的屏幕大小、屏幕分辨率、操做系統、用戶設置和JavaScript引擎，這些都會干擾渲染「像素級」完美設計的能力。

在我看來，一味地追求「像素級」完美的設計將須要更多額外的代碼來處理，這些額外的代碼將帶來更大的複雜性和潛在的風險。能夠說是「付出與收益不成正比」。

不過有一點須要特別提出，不要將「像素級」的完美設計和優秀的設計混淆。真正偉大的設計是給用戶留下持久的情感影響。這是當他們打開你的產品時所獲得的快樂，也是他們從你的Web應用中獲得的快樂。而這一切並非你選擇16pt字號而不是15pt字號的崇拜。

中斷文檔流

CSS的棘手之處在於使用不一樣的CSS代碼能夠實現相同的視覺效果。例如，要將頁面上的元素水平垂直居中，能夠有不少種方式，使用任何一處均可以讓你的用戶看到相同的效果。

@Amos整理了相關的技巧，可達23種方式來實現垂直居中。

雖然實現同一效果有不少種方式，但我建議咱們在實現效果的時候應該儘可能的避免中斷文檔流。由於過於頻繁地中斷文檔流（例如，過分使用float）會增長對內存的佔用，並且讓別的小夥伴甚至是你本身更難理解。

當有多個方案實現相同的視覺效果時，我更喜歡使用中用內存空間更小的技術。

不將設計和佈局分離

CSS的任務是提供樣式，HTML的任務是提供結構。一般，你應該首先以捕獲頁面信息結構層次的方式編寫HTML。即：

在編寫HTML的時候，應該忽略任何設計關注點。

而後，添加CSS，讓視覺上看起來很好。

雖然HTML提供告終構，但它不能老是將元素定位在你但願它在頁面上出現的準確位置。所以，可使用CSS構建頁面的正確佈局，以便元素出如今正確的位置。一旦一個元素被放置在頁面的正確位置，就能夠很容易地修飾它，使它看起來很漂亮，而不用擔憂它的位置。所以：

CSS佈局（Layout CSS）和CSS美化（Lipstick CSS）是作着不一樣的事情。

簡單的看兩示例：

// 很差的示例
.article {
    display: inline-block;
    width: 50%;
    margin-bottom: 1em;
    font-family: sans-serif;
    border-radius: 1rem;
    box-shadow: 12px 12px 2px 1px rgba(0, 0, 0, .2);
}
.sidebar {
    width: 25%;
    margin-left: 5px;
}

<div class="article"></div>
<div class="article sidebar"></div>

// 好的示例
/* Layout */
.article, .sidebar {
    display: inline-block;
}
.article {
    width: 50%;
    margin-bottom: 1em;
}
.sidebar {
    width: 25%;
    margin-left: 5px;
}

/* Lipstick */
.card {
    font-family: sans-serif;
    border-radius: 1rem;
    box-shadow: 12px 12px 2px 1px rgba(0, 0, 0, .2);
}

<div class="article card"></div>
<div class="sidebar card"></div>
複製代碼

CSS佈局（Layout CSS）和CSS美化（Lipstick CSS）工做的分開也被稱爲關注點分離（Separation of Concerns），這是軟件工程的一個通用原則，有助於保持代碼的可維護性和易於理解。

咱們但願使用合適的工具來完成這項工做，由於以這種方式分離CSS能夠很容易地將一個元素移動到頁面的另外一部分，而不會弄髒Lipstick CSS，還能夠很容易的更改Lipstick，而不會破壞Layout。每次咱們添加一個新特性時，混合使用之兩種方法都會迫使咱們同時作這兩項工做。

移動先行

隨着移動終端的普及率的提升，移動網站（或應用）成爲主流。不少人開始提「移動第一」，在提這個理念的時候也意味着桌面（PC端）是二等公民。相反，「移動優先」的擁護者則表現出相反的行爲，他們首先爲桌面編寫代碼，而後試圖將網站塞進移動端。他們使用@media來處理移動端設備上的異常，但實際狀況是桌面端才應該是異常。

在這個移動端的時代，你的用戶首先經過他們的手機找到你，而後他們要是足夠喜歡你的產品，纔會到桌面端去體驗。但在你的設計師、開發者和產品經理看來，手機真的是第一位嗎？你是否先編寫移動端的代碼，而後再構建桌面端？你的設計師是先爲手機建立線框圖和模型，而後再爲臺式機建立線框和模型嗎？在測試桌面版本以前，你是否在移動端版本上執行A/B測試，並徵求用戶的反饋？

//很差的作法
.container {
    width: 980px;
    padding: 1em;
}

@media (max-width: 979px) {
    .container {
        width: 100%;
        padding: 0.5em;
    }
}

// 好的作法
.container {
    width: 100%;
    max-width: 980px;
    padding: 0.5em;
}

@media (min-width: 980px) {
    .container {
        padding: 1em;
    }
}
複製代碼

另一個主要的緣由是，從移動端上往大屏幕上擴展會更容易；但要從大屏幕上刪除元素使其適合較小屏幕，就會比較棘手。

沒有使用命名方案

Namespaces are one honking great idea – let’s do more of those! — PEP 20: The Zen of Python

在CSS中給元素命名老是很煩人的，若是讓你不要考慮命名方案就直接寫代碼，你必定會很興奮。例如你給一個<img>元素添加類名的時候，你可能會將它命名爲.img、.image、.blog-img、.img-blog等。若是你將它命名爲.blog-img，那以後你還會接受.ad-img和.thumbnail-img的命名？

給元素命什麼樣的名，雖然看起來是一件很小的事情，可是CSS要比其餘語言更難重構，由於咱們目前沒有任何用於CSS的靜態分析工具來執行自動重構或重命名。CSS類可使用JavaScript動態地添加、刪除和構造，所以不可能找到「未聲明」的CSS選擇器 —— 僅僅由於CSS片斷沒有在一個頁面的一個狀態中使用，並不意味着它從示使用過。

另外，若是你的團隊不能就是否將其命名爲.center、.centre、.centered、.text-center或.align-center達成一致，那麼BEM也就沒法解決之個問題。

在一些JavaScript框架中，使用CSS-in-JS能夠部分地解決這個問題，由於這些框架刪除了CSS的全局做用域，並鼓勵你將樣式與其關聯的組件放在一塊兒。然而，CSS-in-JS尚未被普遍採用，並且這方面的爭議也不少。

還有一個主要緣由是，開發人員在刪除任何可能破壞網站的內容時老是會猶豫不決。所以你們寧肯謹慎行事，也可願增長垃圾代碼，也不敢去冒險。更糟糕的是，除非你很努力的推廣和清晰地溝通你的設計系統，不然它可能會被忽視，由於你的同事會避免閱讀你的文檔，繼續他們的老習慣。

不閱讀文檔

這看起來彷佛很簡單。好比說使用Bootstrap，不少同窗認爲只要安裝了就能夠了。不幸的是，若是你不真正理解CSS框架（CSS Framework），而且不當心違背了它的原則，那麼它經常會致使比引用它來解決問題更多的問題出現。不管你使用的是Bootstrap、Material Design、Foundation等開源設計系統，仍是你本身團隊開發的設計系統。

所以，在使用任何一個框架或系統以前，頗有必要花必定的時間去閱讀相關的文檔。

認真閱讀文檔是很重要的，由於許多框架要求你取消從之前的框架中提取的肌肉記憶，並且只有閱讀了整個手冊，你才能知道其缺陷在哪裏。例如，組件繼承是較老的前端框架中的一種常見模式。然而，React這樣的新框架在使用組合而不是繼承時工做是最好的。若是跳過文檔的閱讀，你極可能就不會意識到這一點，你可能就會默認使用你習慣的繼承模式。

更廣泛地說，你被從舊技術發展而來的肌肉記憶所困住是很危險的，這會致使咱們犯最後一個致命的錯誤。

沒有按照計劃系統地學習CSS

技術是不斷革新的，保持相關性的惟一方法是遵循一個持續學習和改進的計劃。

從教條中死記硬背知識是很危險的。一些有經驗的開發人員一聽到「內聯樣式（Inline Style）」就有着一種本能的反感，由於在他們的職業生涯的早期就被教導**「樣式和結構的分離；永遠不要使用內聯樣式」**。

事實上，「永遠不要使用內聯樣式」是好久之前的最佳實踐。那是當時的背景下會使HTML難以閱讀、調試和更新。然而，這項技術的進展緩慢，最終顛覆了致使這些「最佳實踐」的假設。新的假設導至新的最佳實踐。

內聯樣式只有在行內寫樣式纔是真正的痛苦，但若是使用CSS-in-JS的庫來管理你的內聯樣式時，這些所謂的缺點就消失了，而你的優點也就只剩下代碼模塊化，自動化測試和簡單的管理工做等。

若是你固守着「永遠不要使用內聯樣式」的教條，那麼當最初的假設發生變化時，你就不會有好奇心去探究它意味着什麼。使用系統的，結構化的計劃從頭開始學習CSS是很重要的，而不是僅僅搜索來尋找一些只關注表面實踐的教程。

不幸的是，我嘗試着尋找免費的在線資源來幫助你結構化、系統化的學習CSS，但並無找到任何好的資源。現有的CSS資源要麼過於技術化，而且假設你已經瞭解了瀏覽器渲染原理，要麼它們只提供一些簡單的技巧，而沒有教給你一些有關於CSS的基本原理。

由於沒有好的資源可讓你對CSS從內心就有一個可靠的心理模型，因此不少時候碰到問題都是依賴搜索，而後複製和粘貼來解決。這使得不少人對CSS的知識都是東拼西湊的，只知道解決出現的特定的Bug就足夠了，可是當面對一個看起來須要花費數小時才能修復的，又難以理解的Bug時，會立馬感到徹底無助。

並且一直以來，在整個前端社區有一種不成文的理解。

CSS很是的簡單，正由於其簡單，才以爲很容易。瞭解它的屬性就會使用。

也正因這樣的誤導，你們以爲CSS很容易，沒有任何學習成本。甚至有一些同窗會認爲，CSS就是手到擒來的東西。

而我想再次表達一個不一樣的觀點是：CSS是簡單，但毫不容易：

Unlike a programming language that requires knowledge of loops, variables, and other concepts, CSS is pretty easy to pick up. Maybe it’s because of this that it has gained the reputation of being simple. It is simple in the sense of 「not complex」, but that doesn’t mean it’s easy. Mistaking 「simple」 for 「easy」 will only lead to heartache.

上面羅列的一些觀點不必定全對，但仍是蠻有參考價值的。雖然不是什麼技巧，但能夠幫助我學習更多的技巧。

使用`backdrop-filter`實現磨砂玻璃效果

See the Pen Frosted glass effect by Facundo Corradini ( @facundocorradini) on CodePen.

磨砂玻璃的效果最先來自於蘋果手機設備上的效果。

早在2015年的《CSS3 Filter的十種特效》和《高級CSS filters》介紹濾鏡使用的時候就知道background-filter這個屬性。那個時候僅在Safari上才能看到效果，但從Chrome 76開始也能看到background-filter帶來的磨砂玻璃效果。

HTML的`output`元素

或許不少人聽過input元素，但對於output元素據說過的應該不多吧。

其實在W3C的HTML5工做草案12（2019年02月）就添加了output元素。在此工做草案以前，它在HTML5中被引用，直接是Web Forms 2.0中的定義。

從HTML規範中的原始定義到如今，output的一些細節已經發生了變化，可是元素始終在表單元素的家族中。如今對output的定義從「output元素表示計算結果」到「output元素表示應用程序執行的計算結果或用戶操做的結果」轉變。

來看一個簡單的使用用例：

<form oninput="added.value=parseInt(i1.value)+parseInt(i2.value)">
    <input type="number" min="0" name="i1" value="0"> +
    <input type="number" min="0" name="i2" value="0"> =
    <output name="added">0</output>
</form>
複製代碼

有關於output元素更多的介紹能夠閱讀：

你所不知道的`:not()`

在《初探CSS 選擇器Level 4》一文中有詳細介紹過:not()這個函數僞類的使用。

否認僞類:not()是一個函數僞類，以選擇器列表作爲參數，它表示的元素不是由其參數表示的。:not()選擇器能夠用來作爲判斷的一個選擇器，比如JavaScript中的非。其主要做用就是將符合規則的元素剔除，將樣式規則應用於其餘元素上。事實上，在CSS Selector Level 3就有:not()的身影，只不過當初的功能比較弱，好比:not(p)用來選擇不是<p>的元素。但在新版本的中，其功能變得更爲強大，能夠應用更爲複雜的規則，可是一樣地不容許嵌套使用，好比:not(:not(...))。

咱們平時開發項目的時候，時常會碰到列表這樣的效果，列表項之間有一個margin-bottom，而每每想在最後一項中不設置margin-bottom。好比像下圖這樣的效果：

若是要避免多個類的時候，能夠將它們鏈接起來，由於:not()沒有邏輯組合符的操做，因此咱們能夠這樣作：

body:not(.home):not(.away):not(.page-50) {

}
複製代碼

前幾天@張鑫旭老師在《CSS :not僞類可能錯誤的認識》一文中也詳細闡述了咱們對:not()使用時容易搞錯的幾個點。好比，搞不清楚其優先級、不支持複雜選擇器、容易搞不清楚的否認邏輯關係等。

從字符串中刪除最後一個字符

JavaScript中從字符串中刪除最後一個字符的兩種方法：

// 使用`slice`
let input = "w3cplus.com"

function removeLastCharacter(str){
    let charcter_arr = str.split('');
    return charcter_arr.slice(0, charcter_arr.length - 1).join('');
}

let output = removeLastCharacter(input);
console.log(`Output is ${output}`);  // => Output is w3cplus.co

// 使用substring方法
let input = "w3cplus.com"

function removeLastCharacter(str){
    return str.substring(0, str.length - 1);
}

let output = removeLastCharacter(input);
console.log(`Output is ${output}`); // => Output is w3cplus.co
複製代碼

幾張動圖幫你更好的理解CSS Grid中的幾個屬性

這兩年有關於CSS Grid Layout的相關討論在社區中很是的火爆。強大到只須要添加一行代碼就能夠實現響應式的佈局（一些特定場景）。

這一行代碼就是：

grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
複製代碼

代碼中用到了repeat()、auto-fit、minmax()和fr。接下來用@Per 文章中的幾張GIF圖來向你們展現他們的做用：

<!-- HTML -->
<div class="container">  
    <div>1</div>  
    <div>2</div>  
    <div>3</div>  
    <div>4</div>  
    <div>5</div>  
    <div>6</div>  
</div>

// CSS
.container {  
    display: grid;  
    grid-template-columns: 100px 100px 100px;  
    grid-template-rows: 50px 50px;  
}
複製代碼

看到的效果以下：

把100px換上1fr：

.container {  
    display: grid;  
    grid-template-columns: 1fr 1fr 1fr;  
    grid-template-rows: 50px 50px;  
}
複製代碼

效果以下：

使用repeat()可讓代碼更乾淨：

.container {  
    display: grid;  
    grid-template-columns: repeat(3, 100px);  
    grid-template-rows: repeat(2, 50px);  
}
複製代碼

使用auto-fit作自動填充：

.container {  
    display: grid;  
    grid-gap: 5px;  
    grid-template-columns: repeat(auto-fit, 100px);
    grid-template-rows: repeat(2, 100px);  
}
複製代碼

加上minmax()用一行代碼在一些場景中就能夠達到響應式效果：

.container {  
    display: grid;  
    grid-gap: 5px;  
    grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
    grid-template-rows: repeat(2, 100px);  
}
複製代碼

有關於repeat()、auto-fit、minmax()和fr更多的介紹，能夠閱讀：

小結

文章圍繞@Bill Mei的《Top 10 most deadly CSS mistakes made by new and experienced developers》進行展開。在Chrome78開始可使用backdrop-filter實現磨砂玻璃的效果，HTML新增的output元素能夠用來表示應用程序執行的計算結果或用戶操做的結果；CSS的:not()雖然沒有邏輯符來，但能夠經過多操做符來組合，達到相似邏輯組合的效果。最後使用@Per製做的幾張Gif圖簡單粗暴的告訴你們如何使用CSS Grid Layout中的repeat()、fr、auto-fit和minmax()，從而使用一行代碼達到響應式的效果。經常使用於列表佈局的場景中。

最後，但願這一期的內容你們會喜歡。若是你有更好的建議或相關的積累，歡迎在下面的評論中與咱們一塊兒分享。