iWeb會場搶先:直擊HTML5!
每天早晨,我都例行公事般地喝咖啡、收郵件和刷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元素將內容組織到精確的語義塊而不是通用容器中。把它們當做文檔中獨立且清晰存在的一部分。在下一個例子中,sections將包含不同國家地區的新聞報道,每一篇報道與國家地區都是相關的。請注意,每一個部分都是獨立的,所以我們將在每個部分中加入描述性標題。
如果有必要,我們可以添加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區域的引言,或者二者混合使用。
這個規范將header元素描述成“導航輔助或組引導的容器”。讓我們可以自由地包含搜索表單、時間日歷組件。頁面或者段落都將以此開始。
我在2004年對一些元素的使用情況進行過調研,Google也做過類似的調研,我們都發現:大多數設計師都會標注頁腳,通常包含聯系人和版權信息——這就是頁腳。
在典型的HTML4.01和XHTML1.0文檔中,頁腳通常會是一個div并帶有一個值為footer的class屬性。
我們甚至可以使用footer元素來替換蹩腳的div布局。
像我喝的咖啡一樣順滑流暢,現在我們來添加一些aside,來包含《My Gun Is Quick》的信息。
有了導航,瀏覽網站變得更加簡單。當我們構建頁面時,導航通常看起來是這樣的。
我們已經習慣了使用列表標記導航,但我們還使用列表標記其他事情。那么問題來了,瀏覽器如何區分不同的列表?
好在我們現在有了nav元素,來實現頁面上的一個或多個“主要導航塊”。不是所有的鏈接或者鏈接區塊都是頁面主導航,所以我們應該保留nav元素,以便幫助人們快速區分出哪里才是頁面導航
導航可能會包含跳轉最重要頁面的鏈接列表,它可能在header中,可能在側邊欄,也可能在footer中。接下來,我們將使用充滿語義的nav元素,取代以前的div布局。
當訪客通過搜索來尋找內容時,我們在nav中添加一個搜索表單。如果我們包含跳轉鏈接,這些也可以作為無障礙技術的主要導航區域。
我通常會在印刷品、圖片、圖表、簡圖中配上一些說明文字。與其糾結使用什么樣的元素來做圖注,不如直接使用figure和figcaption元素,就像下面這樣。
當我們需要注釋一組元素時,我們可以嵌套多個圖片、圖表示意圖,然后用一個figcaption來標記。
HTML5時間和日期
你可以想象,在HTML里寫日期如此簡單。
但問題是,軟件很難知道這串數字是一個日期。另一方面,人們對相同的數字可能會有不同的解讀,如果你來自英國,這些數字代表2015年5月6日,但如果你生活在美國,你可能認為它表示6月5日,2015年。
為了解決這個問題,time元素必須對人是可讀的——不管是6may2015,還是May6th,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的input類型,來表述這些email地址。
我們已經習慣了使用軟鍵盤處理手頭工作,如上圖所示,iPad鍵盤已經包含了一個可以便捷輸入email的設置鍵。
現在你可以使用各種各樣的有趣的功能,比如檢查電郵地址的有效性,以及是否包含@符號等。在一個email類型輸入框中輸入時,Safari會自動調出虛擬鍵盤,@符號很直觀地出現在鍵盤下方。
當我們使用URL類型的輸入框時——為了幫助用戶專注和精準的輸入網址url——iOS軟鍵盤會為此類型輸入框提供斜杠/、句點以及.com這樣的按鍵。
提升網站表單的體驗,有助于讓人們愿意完成輸入。當使用url時,iPhone的鍵盤會自動在下方調取出.com按鈕。
如果我們使用tel輸入框,iOS會自動調出數字鍵盤。
iOS做了很多細致且卓越的工作,以使鍵盤輸入更加便捷。
搜索search 如果網站內容太多,我們就得使用搜索框來找到所需的內容。剛好有一個輸入框表單類型可以用于搜索。
在iOS系統的Safari瀏覽器上,search輸入框的邊角更加圓潤;而在Mac OS X系統的Safari瀏覽器上(在別的桌面瀏覽器上也同樣),search和普通文本框的外觀別無二致,直到我們與之交互。在Chrome、Safari和Opera這些瀏覽器上,搜索查詢體驗會更加便捷,它們會自動在搜索框內增加一個圖標,當用戶點擊這個圖標時,就會清除已經在搜索框內輸入的內容。
通過添加一些小的額外屬性,可以讓你定制的輸入框更有范兒。比如添加autosave屬性,為其添加一個唯一值,在我們的例子中,我們寫上"gethardboiled",然后在Safari中奇跡出現了,搜索框中不僅會添加一個放大鏡圖標,而且在點擊它的時候,會出現一個列表,其中是近期搜索過的關鍵詞。無論頁面是否刷新,這個列表都會保存。此外,可以使用results屬性來控制記錄多少個最近搜索的關鍵詞,在下例中,我們的表單將保存最近搜索的10個關鍵詞。
search輸入框在樣式處理上簡直是臭名昭著,而其結果列表的樣式在不同瀏覽器下也是千差萬別。所以我的建議是,把這些交給瀏覽器來處理,不必太過渲染輸入框。
如果我們使用number輸入類型,iOS會自動調出一個只有數字的鍵盤。但在大多數桌面瀏覽器中,更有趣的事情發生了。Chrome,Firefox、Opera和Safari,在number輸入框右側增加了輸入箭頭或旋鈕。按下這些箭頭,或使用鍵盤上的方向鍵,或者使用鼠標滾輪向上或向下滾動,即可調整輸入的號碼。
如果你并不需要這些箭頭,你可以在Chrome、Firefox、Opera以及Safari中,使用一段非標準,但是卻非常好用的CSS代碼。
這樣一來,number的功能保持不變,人們仍然可以使用鍵盤的方向鍵或鼠標滾輪來調整數字。
當人們在航空公司、租車服務或酒店網站上選擇日期的時候,總是要耗費極大的精力和時間。HTML的原生日期選擇器將會讓我們不再那么痛苦。
表單標簽總會給人帶來各種麻煩。我總想為沒有標簽文本的表單元素制作一個可視化提示。placeholder屬性,會將提示信息添加到任何為空且失去焦點的input中;而不支持這個屬性的瀏覽器會忽略這個提示文本。
label并不是必需的,當表單內容很簡單的時候,它可以被標題或者明確的標題按鈕所替代。
像大多數人一樣,當我使用Google搜索的時候,光標會自動聚焦在搜索框內;而與很多普通人不同,作為設計師,我會注意這些小的體驗改進。在過去,我們必須使用腳本才能達到這樣的效果,但現在完全可以使用autofocus屬性,來以原生的方式讓瀏覽器幫助我們實現。不支持autofocus屬性的瀏覽器將會自動忽略它:
自動完成autocomplete 使用autocomplete屬性,可以以原生的方式實現自動補充的效果。
使用autocomplete的時候需要注意安全性,尤其在某些場景下最好不要使用,比如涉及到信用卡或其他財務信息的時候。
列表list和數據列表datalist
通常,幫助訪客完成表單輸入的最好方式,就是讓他們回答問題、給出建議,或做出選擇。我們來看下list屬性,它包含一個datalist,在一個文本輸入框上復合了一個select框,這樣可以方便快捷地選擇輸入內容。
想象一下,當我們在表單中問訪客最喜歡的偵探是誰時,為了幫助用戶快速做出選擇,可以在datalist里提供一些偵探的名字,然后給一個text類型的input添加一個list屬性,并通過給緊鄰的datalist設置相同的id,將二者聯動起來。 。
訪客既可以自己輸入,也可以從datalist中選擇可用的選項。如果瀏覽器不支持此屬性,則忽略它們,只顯示出普通文本輸入框。
在某些電商網站,購物數量被設定為一個最小值;而有的則需要設置為更大的值。添加min和max屬性,就可以對數據的上下限進行控制。
值得注意的是,不管在哪個瀏覽器中,min和max屬性不能和required屬性同時使用。事實上,我們不能把required屬性和數字輸入框一起用。
編寫表單驗證腳本是我最不喜歡的工作之一。如果可能,我寧可花錢雇人干這個臟活兒。雖然JavaScript庫讓這樣的工作輕松了一些,但我敢打賭,即使最鐵桿的JavaScript程序員,也不喜歡去開發這些腳本。如果瀏覽器能處理表單驗證豈不更好。這不僅讓開發者更輕松,還可以讓那些繞過表單里的通過JS驗證輸入是否合法的人無從下手(因單純為使用JS驗證輸入是否合法,是可以被用戶人為繞過的,比如禁止掉瀏覽器的JS功能) (要繞過JavaScript驗證,其實只需關閉瀏覽器的JavaScript即可)。好消息是,在新的HTML標準中,已經包括了這些看起來很簡單的特性,使客戶端表單驗證成為輕而易舉之事。
HTML5添加required屬性后,將阻止表單提交,直到所有的屬性都已正確輸入。
如果你不喜歡添加瀏覽器驗證,簡單地加一個novalidate標簽就可以了。
打破傳統
HTML5把標記帶入了Web應用的時代,而實際情況遠比本書所介紹的更多。例如,可以使用很多方式脫離瀏覽器插件來支持播放音視頻文件,甚至可以離線交互等。你能走多遠,取決于你的工作和人們的需求。但有一點是很明確的,HTML就在那里,如果我們想在互聯網浪潮中保持領先,那就應該盡可能地利用這一開放的新技術。
本文節選自《超越平凡的Web設計(iWeb會場搶先版)》
內容簡介
本書結構清晰合理、內容深入淺出,無論您是有一定經驗的前端開發工程師,還是Web設計與開發的愛好者,本書都值得您仔細品味,反復吸收。
本文轉載自異步社區
HTML5 容器 HTML
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。