本節書摘來自異步社群《超越平凡的web設計——html5+css3專業應用之道 （iweb會場搶先版）》一書中的第7章,作者： [英] andy clarke 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
超越平凡的web設計——html5+css3專業應用之道 （iweb會場搶先版）
每天早晨，我都例行公事般地喝咖啡、收郵件和刷twitter。我在instagram上浏覽照片，檢視螢幕截圖，然後上傳到dribbble。我還使用diggreader來閱讀rss訂閱，然後在swarm上看看附近的小夥伴。這些站點都與傳統意義上的網站不同，它們更像是桌面軟體，而不是web應用。
web應用已經變得越來越強大和複雜，但是标記語言與早期相比沒什麼變化。html以及後來更嚴格的xml、xhtml，這些是用來建構網頁的工具，而不是建構應用的工具。是以html5應運而生——我們先來介紹一點曆史知識。
在html4.0釋出之後，w3c關閉了html工作組。html結束了。他們認為未來是屬于xml的，而不是html。在2004年的時候，w3c舉辦了一場研讨會，幾個浏覽器大廠都參加了。他們考慮設計一款文檔語言用來開發web應用。
mozilla和opera給出了自己的建議，但是w3c忽略了他們......
目前w3c不打算為html和css的web應用投入任何資源。
但在真實世界中，浏覽器廠商才有決定權，而不是w3c這樣的标準組織。是以，當w3c拒絕了廠商提出的建議後，這些廠商自己組建了一個whatwg工作組。這是一個松散、非官方且開放的協作式工作組，其成員包括蘋果、google、mozilla和opera。微軟最初沒有加入這個組織。whatwg稱其規範為webapplications1.0。
與此同時，w3c的工作也在繼續，他們把重心放在了文檔語言xhtml2上面。雖然他們雄心勃勃，然而沒有這些浏覽器大廠的支援，他們的命運是注定的。正如markpilgrim所說“赢家是順應潮流的人。”
在web标準的制定上，浏覽器廠商握有重要的牌。各廠商都在不遺餘力地支援html5，快速開發制定規範，結果呢？html不僅被廣泛采用，而且成為了标準，即使w3c到2022年也不認可它。
我們是要等到那時才能使用html5？幸好我們沒那麼做，如果選擇了等待，那我們就創造不出令人激動的網站和應用了。
有人肯定會問“如果規範變了，我是不是還得修改我的html？”是的。無論怎樣我們都要改變。
html不會冰封，改寫html5标記是其進化過程中的一部分。
html5建立在已有的标記之上，它不是一門新語言，而是在原有的基礎之上加了一些強大的特性。學習html5不是很難，我們現在就開始吧。
簡述
從最簡單的開始吧。首先用簡短的html寫一個文檔類型的聲明。
沒有版本号、沒有語言、沒有uri，隻是一個普通的html。
文檔類型doctype是不區分大小寫的，是以也可以寫為： 、或者。
你知道嗎，最新版本的html甚至不需要寫doctype，你甚至可以不聲明它，頁面仍然有效。但不建議這樣做。
不僅doctype變短了，字元編碼也變短了。下面是一個寫在html裡面的meta元素。
我們不需要指定每一個link上面的每個stylesheet值，我們可以簡寫成這樣。
因為浏覽器不需要知道，我們不必要包含text/javascript，我們可以簡寫成這樣。
html不計較我們怎麼寫标記。是否大小寫，是否大小寫混用，是否忘記閉合标簽，html都不介意。浏覽器也不介意，是以按照自己的喜好來寫吧。
html中的語義元素
html5引入了一組新的元素，提高了頁面的建構能力。你的文檔可能仍然充滿了div——html4.01規範中描述其為“附加結構機制”——對相關内容進行語義分組。
以上标簽中的任何一個屬性語義都是比較隐晦的，也不是機器可讀的。在實踐中，爬蟲會認為you-dumb-mug和content__main毫無差別。
将來，添加id和class屬性将隻是簡單地描述可視化布局，而不會承擔語義化的任務。
我們可以替換一些語義更精确的結構元素來幫助減少對可視化的依賴。結果是，我們的可視化布局将會變得更簡單。
2005年，google調查了30億的網頁，從中找出設計師最常用的id和class屬性。這些發現後來成為了html5的基本元素。
section
article
aside
header
footer
nav
這個清單并不全面，因為本書并不是一本html參考書。參考書我推薦jeremy keith的《html5+css3網頁設計入門必讀》。
挑選一個典型的web頁面的結構，我們就會發現div。這些元素組織起相關内容，幫助我們建立css布局。我們看一下一個老手建構的頁面。
這樣壘代碼是非常有效的。然而，雖然我們能了解每個div代表了頁面上的一小塊，浏覽器卻無法将它們和任何匿名塊級元素區分開。
相反，section元素将内容組織到精确的語義塊而不是通用容器中。把它們當做文檔中獨立且清晰存在的一部分。在下一個例子中，section将包含不同國家地區的新聞報道，每一篇報道與國家地區都是相關的。請注意，每一個部分都是獨立的，是以我們将在每個部分中加入描述性标題。
如果有必要，我們可以添加id屬性，以便通過片段辨別符尋址。
向bem轉換
如果你多年來關注我的作品，你會發現我一直癡迷于html的命名規則和盡量少寫class。編寫最簡潔的html是我的信仰。
過去，我盡可能使用較短的class命名，比如我會像下面這樣，使用css的屬性選擇器來替代class的顯示聲明。
我使用子選擇器（配合>使用）直接定義元素子集的樣式，在這個例子中，ul無序清單就是 header元素的子集。
當然，我使用了很多相鄰兄弟選擇器。這種選擇器可能已不再安全，它會把樣式規則作用在近鄰指定元素後方的元素上。比如下面的例子會對h1一級标題後的header元素增加一個藍色的邊框。
甚至有一次，我制作了一個完全沒有包含任何類屬性的頁面，什麼都沒有。每每想到這裡，就很同情那些不得不靠很多class來建構頁面的開發人員。
在過去的幾年裡，我們公司參與了幾個大項目，這讓我意識到，良好的代碼結構、html和css元素之間的關系，對于項目傳遞是很重要的。bem文法或者命名公約的作用就在于此。
區塊、元素、裝飾器
仔細看之前例子，你就會注意到，許多元素的屬性值都有兩條下劃線或者倆個連字元。這些連字元和下劃線是bem系統的一部分，它們經常像下面這樣使用。
.block用作高階元素，包含了其他的内容和風格。例如在本書第一部分裡，一個具有container的class裡面将包含一些子元素，包含一些主内容和互補内容。這個container就是典型的bem區塊。
.block__element代表這個元素是我們的子容器。主内容和互補内容邊界就是很好的例子。用兩個帶下劃線的元素就能描述它們的邊界：.container__main和.container__complementary。子元素或者特定的段落（如.container__lead）也可包含标題（如.container__heading）。
.block--modifier描述了對一個區塊元素的改變。在本書網站的首頁中，主容器是一個淺色背景，然而，一些屬性改變了，它就程式設計了深色背景。我們可以通過有兩個連字元的屬性來做到，比如container--dark。
使用這個約定可以幫助精确定義不同元素之間的關系。開發人員可以通過檢查html結構或者通過閱讀我的樣式表來了解。.container__main顯然是容器的子元素。容器标題就是container__heading。開發人員不需要了解.container__dark的目的，因為bem文法告訴他們，這是.container的一個标準替代。
使用bem已經改變了我的工作，盡管我仍然追求簡潔的html代碼，但我可以為此犧牲一部分嚴謹的代碼風格。
讓我們繼續增加一些文章來建構文檔。
當我們為部落格、線上雜志或新聞網站寫稿時，我們就是在釋出文章。在html中，每篇文章都是一個獨立的故事，就算沒有網頁中的上下文，它也應該能被人們了解。這聽起來類似于section，但有很大的差别。article代表了一個故事，可以獨立存在，而section是頁面中完整的一部分，它包含多個相關文章。
檢查article标記是否運用得當的方法是：看其内容本身是否有意義。例如，将之導入ipad的pocket應用裡，看它是否還具備完整的意義。
如果你有ipad，使用pocket是閱讀文章的好方式。在pocket裡，内容是獨立的，并且沒有廣告和導航等。mac osx和ios中的safari也提供類似的功能。
如果你仍然對section和article的差別有所困惑，doctor brucelawson的文章"html5 articles and sections: what's the difference?"可以供你參考。
讓我們給本書歸檔頁的大綱的每個部分各自添加一段文章。
section可以包含article，article也可以包含section。你想輕輕松松地學習新的html元素？不可能吧？
我來幫你梳理一下對article和section的困惑，那不是你的問題，在以下例子中，article元素中分為三個部分，每個都對應一個知名作家。
頁面的标志區域或報頭可以用header元素來描述，通常這些标題放在頁面的頂端，當然也可以放在底部或者其他地方。我們用一個更合适的header元素來替換經典的banner。
我們可以在section或者article裡面添加header元素，而且在頁面裡面可以有多個header。這意味着我們有多種使用header的方式：作為整頁的标志；作為介紹section和article區域的引言，或者二者混合使用。
下面我們試試在article中加上“本書作者”的header描述。
這個規範将header元素描述成“導航輔助或組引導的容器”。讓我們可以自由地包含搜尋表單、時間月曆元件。頁面或者段落都将以此開始。
我在2004年對一些元素的使用情況進行過調研，google也做過類似的調研，我們都發現：大多數設計師都會标注頁腳，通常包含聯系人和版權資訊——這就是頁腳。
在典型的html4.01和xhtml1.0文檔中，頁腳通常會是一個div并帶有一個值為footer的class屬性。
我們甚至可以使用footer元素來替換蹩腳的div布局。
雖然它的名字叫做頁腳，但我們沒必要将它放在頁面、section或者article的底部。事實上，在任何一個容器元素中都可以放一個。就像header一樣，我們可以使用footer來定義任何section或article中的meta資訊。在article内部，頁腳應該包含作者資訊或者釋出時間。而section的頁腳應該包含文章的更新時間或新文章的添加時間等相關資訊。
mickey spillane是一名多産的小說家，如果我們要寫一篇關于他工作生活的傳記，我們應該在傳記裡包含相關的資訊，比如他的小說《my gun is quick》。反而言之，如果我們要寫這本書的書評，那我們應該捎帶上作者簡介。html5使用 aside 來定義這種類似的關系。
我們可以用aside來描述和文章相關，但對于了解文章又不是非常重要的内容。下面讓我們寫一段mickey spillane的簡介，其中header包含了标題，footer包含作者名字，以及article的釋出日期。
像我喝的咖啡一樣順滑流暢，現在我們來添加一些aside，來包含《my gun is quick》的資訊。
也許我們的頁面包含其他小說作家的資訊。對于我們的作者簡介來說，這個容器内容不是特别相關，是以我們應該把aside置于文章之外。在這種情況下，我們也應該在section元素包裹article和aside、使其申明這兩個是相關的。
有了導航，浏覽網站變得更加簡單。當我們建構頁面時，導航通常看起來是這樣的。
我們已經習慣了使用清單标記導航，但我們還使用清單标記其他事情。那麼問題來了，浏覽器如何區分不同的清單？
好在我們現在有了nav元素，來實作頁面上的一個或多個“主要導航塊”。不是所有的連結或者連結區塊都是頁面主導航，是以我們應該保留nav元素，以便幫助人們快速區分出哪裡才是頁面導航
導航可能會包含跳轉最重要頁面的連結清單，它可能在header中，可能在側邊欄，也可能在footer中。接下來，我們将使用充滿語義的nav元素，取代以前的div布局。
當訪客通過搜尋來尋找内容時，我們在nav中添加一個搜尋表單。如果我們包含跳轉連結，這些也可以作為無障礙技術的主要導航區域。
figure
我通常會在印刷品、圖檔、圖表、簡圖中配上一些說明文字。與其糾結使用什麼樣的元素來做圖注，不如直接使用figure和figcaption元素，就像下面這樣。
當我們需要注釋一組元素時，我們可以嵌套多個圖檔、圖表示意圖，然後用一個figcaption來标記。
html5時間和日期
你可以想象，在html裡寫日期如此簡單。
但問題是，軟體很難知道這串數字是一個日期。另一方面，人們對相同的數字可能會有不同的解讀，如果你來自英國，這些數字代表2015年5月6日，但如果你生活在美國，你可能認為它表示6月5日，2015年。
為了解決這個問題，time元素必須對人是可讀的——不管是6 may 2015,還是may 6th, 2015——這些參數必須格式化。
time元素是由兩個版本的日期或日期/時間屬性構成的。首先是一個人類可讀的、自然語言的日期；第二個是名為datetime的機器可讀屬性，它遵從iso标準日期格式：yyyy-mm-ddthh:mm:ss。年月日後跟着的是小時、分鐘和秒（如果我們需要精确的話）。
time元素有一段曲折的曆史。在2011年首次引入html5中的時候，它曾遭html規範的抛棄，被一個更通用、且在我看來缺乏語義的data元素替代。好在當年晚些時候time元素又被加入到規範中，并增加了一些有用的額外功能。比如此前的datetime格式要求精确，而新支援的iso标準格式則允許使用模糊日期。
當需要描述一個事件持續多長時間時，可以使用datetime屬性和字首p。添加字尾d表示天、h表示小時、m表示分鐘、s表示秒。如果你想标記為了買火車票排了一天隊的話，像下面這樣寫就好了。
下一個事件持續了1天6小時10分鐘30秒。發現了嗎？額外的t（時間）字首表示一個更為精确的時間。
通過結合精确、結構化的日期格式，日期和時間得以借助自然語言來設定，同時實作了一個對于人類和機器都可讀的通用格式。
表單元素
哪種網站或app将由一兩個表單構成？無論你喜不喜歡，如果網站中沒有表單，那着實讓人難以接受。html5引入十多個input類型和屬性，這令實作複雜的控制和功能——如滑塊、日期選擇器和用戶端驗證——變得更加簡單。這些元素包括email、url、tel和search。不要擔心老舊的浏覽器，因為當浏覽器無法了解這些input類型的時候，會自動降級為文本框。
電子郵件email
很多場景下都需要填寫電郵位址，比如聯系人表單、評論表單、注冊、登記表單等。選擇email的input類型，來表述這些email位址。
我們已經習慣了使用軟鍵盤處理手頭工作，如上圖所示，ipad鍵盤已經包含了一個可以便捷輸入email的設定鍵。
現在你可以使用各種各樣的有趣的功能，比如檢查電郵位址的有效性，以及是否包含@符号等。在一個email類型輸入框中輸入時，safari會自動調出虛拟鍵盤，@符号很直覺地出現在鍵盤下方。
網址url
當我們使用url類型的輸入框時——為了幫助使用者專注和精準的輸入網址url——ios軟鍵盤會為此類型輸入框提供斜杠/、句點以及.com這樣的按鍵。
https://yqfile.alicdn.com/fd4a386d705c90fbbcd5833e4da20082fa6f9b91.png" >
提升網站表單的體驗，有助于讓人們願意完成輸入。當使用url時，iphone的鍵盤會自動在下方調取出.com按鈕。
電話tel
如果我們使用tel輸入框，ios會自動調出數字鍵盤。
https://yqfile.alicdn.com/e60418cfc8ab6c88cd03e427c66d1bb3bf80559f.png" >
ios做了很多細緻且卓越的工作，以使鍵盤輸入更加便捷。
搜尋search
如果網站内容太多，我們就得使用搜尋框來找到所需的内容。剛好有一個輸入框表單類型可以用于搜尋。
在ios系統的safari浏覽器上，search輸入框的邊角更加圓潤；而在mac os x系統的safari浏覽器上（在别的桌面浏覽器上也同樣），search和普通文本框的外觀别無二緻，直到我們與之互動。在chrome、safari和opera這些浏覽器上，搜尋查詢體驗會更加便捷，它們會自動在搜尋框内增加一個圖示，當使用者點選這個圖示時，就會清除已經在搜尋框内輸入的内容。
通過添加一些小的額外屬性，可以讓你定制的輸入框更有範兒。比如添加autosave屬性，為其添加一個唯一值，在我們的例子中，我們寫上"gethardboiled"，然後在safari中奇迹出現了，搜尋框中不僅會添加一個放大鏡圖示，而且在點選它的時候，會出現一個清單，其中是近期搜尋過的關鍵詞。無論頁面是否重新整理，這個清單都會儲存。此外，可以使用results屬性來控制記錄多少個最近搜尋的關鍵詞，在下例中，我們的表單将儲存最近搜尋的10個關鍵詞。
search輸入框在樣式處理上簡直是臭名昭著，而其結果清單的樣式在不同浏覽器下也是千差萬别。是以我的建議是，把這些交給浏覽器來處理，不必太過渲染輸入框。
數字number
如果我們使用number輸入類型，ios會自動調出一個隻有數字的鍵盤。但在大多數桌面浏覽器中，更有趣的事情發生了。chrome，firefox、opera和safari，在number輸入框右側增加了輸入箭頭或旋鈕。按下這些箭頭，或使用鍵盤上的方向鍵，或者使用滑鼠滾輪向上或向下滾動，即可調整輸入的号碼。
如果你并不需要這些箭頭，你可以在chrome、firefox、opera以及safari中，使用一段非标準，但是卻非常好用的css代碼。
這樣一來，number的功能保持不變，人們仍然可以使用鍵盤的方向鍵或滑鼠滾輪來調整數字。
https://yqfile.alicdn.com/01761577b874596a824e2d4ee13981202e5a480f.png" >
本地日期選擇器native date picker
當人們在航空公司、租車服務或酒店網站上選擇日期的時候，總是要耗費極大的精力和時間。html的原生日期選擇器将會讓我們不再那麼痛苦。
占位符文本placeholder
表單标簽總會給人帶來各種麻煩。我總想為沒有标簽文本的表單元素制作一個可視化提示。placeholder屬性，會将提示資訊添加到任何為空且失去焦點的input中；而不支援這個屬性的浏覽器會忽略這個提示文本。
label并不是必需的，當表單内容很簡單的時候，它可以被标題或者明确的标題按鈕所替代。
自動焦點autofocus
像大多數人一樣，當我使用google搜尋的時候，光标會自動聚焦在搜尋框内；而與很多普通人不同，作為設計師，我會注意這些小的體驗改進。在過去，我們必須使用腳本才能達到這樣的效果，但現在完全可以使用autofocus屬性，來以原生的方式讓浏覽器幫助我們實作。不支援autofocus屬性的浏覽器将會自動忽略它:
自動完成autocomplete
使用autocomplete屬性，可以以原生的方式實作自動補充的效果。
使用autocomplete的時候需要注意安全性，尤其在某些場景下最好不要使用，比如涉及到信用卡或其他财務資訊的時候。
清單list和資料清單datalist
通常，幫助訪客完成表單輸入的最好方式，就是讓他們回答問題、給出建議，或做出選擇。我們來看下list屬性，它包含一個datalist，在一個文本輸入框上複合了一個select框，這樣可以友善快捷地選擇輸入内容。
想象一下，當我們在表單中問訪客最喜歡的偵探是誰時，為了幫助使用者快速做出選擇，可以在datalist裡提供一些偵探的名字，然後給一個text類型的input添加一個list屬性，并通過給緊鄰的datalist設定相同的id，将二者關聯起來。 。
https://yqfile.alicdn.com/5522a583b07048d80ddabe812d0aa2b35c428c4b.png" >
訪客既可以自己輸入，也可以從datalist中選擇可用的選項。如果浏覽器不支援此屬性，則忽略它們，隻顯示出普通文本輸入框。
最小min和最大max
在某些電商網站，購物數量被設定為一個最小值；而有的則需要設定為更大的值。添加min和max屬性，就可以對資料的上下限進行控制。
值得注意的是，不管在哪個浏覽器中，min和max屬性不能和required屬性同時使用。事實上，我們不能把required屬性和數字輸入框一起用。
用戶端驗證
編寫表單驗證腳本是我最不喜歡的工作之一。如果可能，我甯可花錢雇人幹這個髒活兒。雖然javascript庫讓這樣的工作輕松了一些，但我敢打賭，即使最鐵杆的javascript程式員，也不喜歡去開發這些腳本。如果浏覽器能處理表單驗證豈不更好。這不僅讓開發者更輕松，還可以讓那些繞過表單裡的通過js驗證輸入是否合法的人無從下手（因單純為使用js驗證輸入是否合法，是可以被使用者人為繞過的，比如禁止掉浏覽器的js功能） （要繞過javascript驗證，其實隻需關閉浏覽器的javascript即可）。好消息是，在新的html标準中，已經包括了這些看起來很簡單的特性，使用戶端表單驗證成為輕而易舉之事。
必填required
html5添加required屬性後，将阻止表單送出，直到所有的屬性都已正确輸入。
無需驗證novalidate
如果你不喜歡添加浏覽器驗證，簡單地加一個novalidate标簽就可以了。
打破傳統
html5把标記帶入了web應用的時代，而實際情況遠比本書所介紹的更多。例如，可以使用很多方式脫離浏覽器插件來支援播放音視訊檔案，甚至可以離線互動等。你能走多遠，取決于你的工作和人們的需求。但有一點是很明确的，html就在那裡，如果我們想在網際網路浪潮中保持領先，那就應該盡可能地利用這一開放的新技術。