關心網路發展趨勢的朋友一定知道, W3C 聯盟 (World Wide Web Consortium) 己在近日 (2012/12/17) 宣布完成了 HTML5 和 Canvas 2D 的規格定義, 接著將展開互通性 (Interoperability) 與效能方面的測試, 來確保 HTML5 能與各大瀏覽器達到最大的相容。W3C 除了在這一天推出 HTML5 規格的侯選推薦版本 ((Candidate Recommendation, CR) 之外, 並將按計畫於 2014 年推出 HTML5 最終規範, 正式讓 HTML5 成為網頁撰寫標準語言。不過, 為避免不同標準對推出的時程造成交互影響, Canvas、Web Sockets 和 Web 儲存等技術將會被獨立出來, 各自訂定計畫, 將不再納入 HTML5.x 發佈計畫裡面。
在此同時, W3C 也同時宣布了 HTML 5.1 以及 Canvas 2D, Level 2 的第一份規格草案 (First Public Working Draft, FPWD) 。雖然這個版本最快也要等到 2016 才有可能正式公布, 我們還是可以先來關心一下未來 HTML5 的走向。
<main> 元素
在目前的 HTML5 規格中, 己經定義了像 <header>, <footer>, <nav>, <article>, <aside> 以及 <section> 等等語意標籤, 它們可以很有效的運用在排版, 或者被各種輔助技術 (Assistive Technologies, AT) 所運用 (例如盲人專用的發聲瀏覽器, 可以跳過一些與主題無關的文字不唸)。但是, 是否還少了什麼?
由 Steve Faulkner 提議的 main 元素補足了缺少的那一部份。如果我們在網頁中加入 <main> 區段, 就表示這個區段既不是表頭、不是邊欄、不是表尾, 也不是廣告; 它是唯一會隨每個網頁而變化的主體。
熟悉 ASP.NET 的程式設計師應該了解這個概念, 因為這個元素就等於套用了 Master Page 的 Content Page。像表頭、邊欄、表尾、廣告等等, 很可能在每個網頁中都可以看到, 唯獨這個 <main> 區段是每一頁都不一樣的。
如果多了 <main> 區段, 未來 HTML 網頁不但可以很輕易做到 Master Page 功能, 也可以方便讓印表機只印出最重要的內容、減少搜尋引擎的負擔、增加網頁內容收藏的便利性等等, 更可以讓行動裝置的排版更有智慧、更有彈性。
指標事件 API (Pointer Events API)
Apple 其實老早就為自己的 iPhone 和 iPad 製訂了一套觸控 API。但是 Apple 從來就沒打算憑空把這組 API 釋出給其它公司免費使用, 所以這組 API 目前看來走不出 Apple 的大門。
微軟則是另外製定了一組指標事件 API, 並以 Working Draft 方式提議給 W3C。微軟自己己經把它使用在 IE10 上面。
無疑的, 微軟所訂的這組 API 比較具有彈性; 因為它不只適用於觸控裝置, 它基本上可以使用在任何指向裝置上面。不過, 由於各大公司都在互相角力, 未來這組 API 能否成為業界標準, 恐怕還要看 Google 將如何表態。
螢幕方向 API (Orientation API)
這組 API 很簡單, 基本上, 開發者可以使用 screen.orientation 取得螢幕的方向, 或者使用如下的語法以加入事件處理常式:
screen.addEventListener("orientationchange", show, false);
開發者也可以使用 lockOrientation() 方法強制鎖定螢幕方向, 或者使用 unlockOrientation() 解開。
對於開發行動裝置 App 的開發人員而言, 這應該是一個蠻方便的功能。
Push API
對於 ASP.NET 的開發者而言, 由於在 ASP.NET 4.5 中導入了 SignalR, 他們應該對於網頁推播技術並不陌生。終於, HTML5 版本的 Push API 也在 10/18 被列入為 FPWD。
當然, 對 ASP.NET 4.5 的使用者而言, HTML5 版的 Push API 或許並沒有吸引力, 況且最快也要等到 2014 年才能看到初步的成果; 但不管如何, 長期而言, 對於廣泛的網站/網頁開發者而言, 這都是一個好消息。
動畫 API (Animations API)
這組 API 實際上還蠻龐大的。如果你使用過任何 Animation Authoring Tool (例如 Director, Authorware, Flash 等等) 的話, 那麼或許你就不會對這組複雜的 API 感覺到恐懼或者不耐煩。
這組 API 將和既有的 CSS Transitions、CSS Animations 和 SVG 共同運作。換句話說, 它並不是用來取代這三者。相反的, 它是用來取代 SMIL Animation (用以定義 SVG 的動畫) 的。由於目前 CSS Transitions、CSS Animations 和 SVG 的動畫描述規格彼此並不相容, 而 Animation API 則採用較為廣泛而抽象的方式來定義動畫規格; 未來我們或許可以期望這組新的 API 能整合上述這三套動畫規格。
關於這組 API, Webkit 動作蠻快的, 它可能會是第一個實作這組 API 的瀏覽器。或許再過不了多久, 我們就可以在 Chrome 上面做測試了。
CSS 遮罩 (CSS Masking)
這是由 Adobe 遞交的規格建議, 其主要目的在於提供網頁物件的遮蔽及裁剪功能, 可以透過 CSS 或 SVG 將各元素進行遮罩作業, 例如加上透明或者漸層著色的圖層。
不過, 對於警覺性比較高的人而言, 可能會對於這種功能抱持某種質疑, 尤其是 Windows Store App 才剛發生過有居心不良的開發者試圖把 XAML 控制項蓋到 WebView 內容以企圖盜取客戶密碼的情事 (所以現微軟己強制讓 WebView 控制項永遠維持在最上層, 無法被覆蓋)。
不過, 規格原本就有規範其安全性(見原規則中 Security 一節), 或許我們可以不必擔這個心。
固定縮放與自動縮放 (Intrinsic & Extrinsic Sizing)
開發網頁的老手一定知道, 使用 HTML+CSS 來調整物件大小是一件很基本, 卻從一開始就很令人討厭的事情。照理說, 瀏覽器一定知道容器、圖形和文字的取度資訊, 但是網頁開發者從來無法輕易獲取這些資訊, 使得一些原本應該很簡單的事情(例如物件置中、填滿等等), 得用迂迴而麻煩的方法才能辦得到(或者根本辦不到, 例如調整容器的大小, 讓它剛好符合文字的寬高, 而無需顥示水平和垂直捲動軸)。
CSS Intrinsic & Extrinsic Sizing Module 這個新規格應該可以解決很多設計者的不便(或許並不是全部)。基本上這不一定是件簡單的事情, 例如, 如果我們動態地載入一段文字或者圖片之後, 我們是不是應該等待一段時間之後, 才能向瀏覽器詢問這段文字或圖片將佔用多大的空間? 瀏覽器不可能在物件確實載入之前就回報確實的資訊給你, 所以不要把整件事情視作自然。
幸好, 有了這個新規格之後, 至少有幾件事情會變得容易一點。例如我們可以讓內容文字或圖片自動隨容器的大小而縮放至填滿; 或者單獨指定內容圖片的高度為容器的百分之百, 而寬度則縮持原有比例; 諸如此類。
Selectors 4 新成員
至少有三個新成員被提議加入 Selectors:
- :active-drop-target – 指將被拖曳至的容器物件
- :valid-drop-target - 可以接受被拖曳物件的容器物件
- :invalid-drop-target - 不可以接受被拖曳物件的容器物件
不過上述名稱都尚未確定; 可能最後會改成更短而易記的名稱。
參考資料:
沒有留言:
張貼留言