順勢而為，HTML發展與UI元件設計進化

在閱讀本文之前，建議先閱讀之前的一篇文章：“面向設計的半封裝web元件開發”，便於理解文章的一些解惑。

一、現狀

1. 前端發展現狀
前端這幾年的發展都是有目共睹的，然而，如果按照已經落地投入實踐的標準梳理下，會發現，基本上都是偏後的JS開發層面的，比方說Node.js下的前後端分離，MV*庫，React.js，各種包管理工具及前端整合解決方案等。

而往前，Shadow DOM, Web Components規範和標準雖然也出現了，給大家看到了方向和未來，但由於相容性的問題（參見下表），或者可能缺乏優秀團隊的強勢引領，我們在實際的專案中鮮有看到。

 

就算有webcomponents.js這樣的polyfills處理，也只有IE11+才完全支援。

難道我們就這樣乾等著，直到Web Components一統江山的時候，我們才開始在HTML側發力嗎？這麼多年HTML5的發展就這麼白費了？我們做PC端的就因為一些過時的瀏覽器而止步不前？

2. UI元件現狀
成熟的團隊都有自己的一套元件庫，以便各種專案來的時候，都能從容應對。

為了能夠從容應對，我們必然要考慮周全，企業級，能應對大型專案，各種複雜場景，充分發揮元件的複用性。往往最終，會讓元件變得比較重，邏輯比較複雜，API數量也比較多。我們不妨可以看下kissy 5.0的DatePicker的元件使用示意：

如果我們單看功能，確實很強大，禁用日期可以任意自定義，可以輕鬆定義各個操作欄是否顯示，確實是企業級的web元件，看上去能適應各種複雜場景。

但是，在我看來，問題卻非常多。

1. 諸位靜下心來想想看，我們所經歷的專案，是不是絕大多數都不復雜，我們是否有必要使用企業級的大而重的產品？就好比你一個展示性為主的網站，卻使用AngularJS MVVM來高大上。截趾適屨，敦雲其愚。
2. 看上去能適應各種場景，但是，眼下現代web技術飛速發展，UI層變化日新月異，你確定你這個元件能跟得上這些變化。怕是最後演變成，元件支援跟不上，而否決了設計師的一些想法。本末倒置了！
3. 程式碼中出現了GregorianCalendar, GregorianCalendarFormat這樣的方法或物件，請問在座的各位你知道這是個什麼鬼嗎？你知道他是幹嘛用的嗎？學習成本啊~~
4. render, showWeekNumber, showClear, showToday, disabledDate這些API名稱大家有沒有覺得在哪裡見過？
   “好像是在哪兒見過？”
   “好像個鬼啊，是之前根本就沒見過！”
   現在大家閉上眼睛，還記不記得這些API名稱是什麼？假設一週以後呢，你還記不記得。是不是你要去翻API文件了？使用成本啊~
5. 想象這樣的場景，專案啟動了，負責元件的前端和負責業務的前端一起開工，誰知突然，負責元件的前端的老婆突然要臨盆，不得不去陪產。此時負責業務的前端該怎麼搞？會不會像這樣一樣在心中馬景濤：“時間選擇元件還沒完成，這裡的日期互動依賴元件，這不是丟鍋給我接嗎！？”可以看到，兩人的開發被牽制了！兩種結果，一是自己上，二是這塊工作暫停。
   所以大家發現沒，元件和業務耦合在一起，不利於協作啊。比方說上面截圖程式碼的picker.on('select', function(e) {});，元件不弄好，根本就沒法使用啊！要麼就自己先搞搞，回頭再改，都是很煩的。

二、探索

正是由於當下有這些不如意的現狀，所以我就一直在思考，有沒有什麼辦法可以做出改變，不一定是大跨越式的一步到位，至少能指明柳暗花明的另一條路。

我們還是拿時間選擇器舉例，想想看，HTML5有沒有為我們帶來native的UI元件？對吧，有的，應該都知道的：

date型別的input輸入框，天然可以選擇時間。

我們可以使用min/max屬性限制可以選擇的時間範圍，使用value確定當前選擇日期。也就是說，從原始功能角度而言，原生的date時間選擇可以滿足絕大多數的業務需求。

這些符合標準，業界規範的HTML特性要是可以直接在實際專案中應用該多好啊！

然而，問題在於，瀏覽器原生的介面往往跟我們站點的設計風格有些不協調，說白了，就是設計師覺得醜，而且不能自由定義某些功能，例如清除。

還有一個很現實的問題是相容性，包括IE11在內的IE瀏覽器都沒有type="date"元件行為， 這個補刀直接剮在了心頭。

怎麼辦呢？

我們此時不妨梳理下：

type/min/max/value這些原生標準的HTML屬性並沒有問題，有問題的只是點選出現的那個長相簡陋的選擇浮層。所謂對症下藥，哪個有問題就搞哪個，我們只要想辦法把醜陋的浮層搞漂亮就可以了。

考慮到相容性，我們其實可以和傳統的時間選擇器元件一樣，對浮層內容進行自定義，注意，我們僅自定義浮層，HTML還是原始的。

我們構建一個名叫DateTime的例項方法，理想狀況下，我們只要繫結初始化一下，類似這樣：

然後duang，時間選擇器浮層直接美化成設計師需要的模樣，那該多完美啊！

夢想總是有的，萬一實現了呢？

既然使用自定義的浮層，那就需要幹掉瀏覽器原生的浮層，怎麼弄呢？我們可以讓input框readonly只讀，這樣，就不會出現原始的輸入框了。

那input框內建的三角(需要隱藏)和斜槓(需要使用短橫)該怎麼辦呢？ 這部分是支援自定義的，類似：

就可以把webkit下的時間輸入框改造成我們想要的樣子了，而IE等不支援date輸入框的瀏覽器，保持原來的樣子就可以。

於是乎，通過CSS和JS的配合，我們就可以實現基於原生HTML5標準的時間選擇器了。

“稍等，怎麼就實現了？”有人可能會有這樣的疑問。

下面這段是我年輕時候使用過的一套元件庫的初始化示意：

對比：

我們是不是可以找到之間的關係？沒錯，這位同學好生眼力，HTML中的type屬性對應JS中的type API, value屬性值對應initDate值, min/max分別對應beginDate/endDate。其實內部實現跟傳統的元件沒什麼差別。

那onSelected呢？onSelected是個回撥方法，解讀下就是當選擇日期之後，幹嘛幹嘛。其實我們原生的input框有類似的事件，什麼呢？change事件。既然，我們這裡使用的是原生的HTML輸入框，那我們就可以使用其原生的change事件。所以，什麼onSelected回撥，完全不需要。我們只要在元件內部，當賦值的同時trigger下原生的change事件。

於是乎，我們就得到了一個HTML是原生，API也是原生，事件也是原生，UI自定義的時間選擇控制元件。真真切切將HTML5應用到了實際專案中，同時，就算是是10年前的IE6也是可以相容。

完美！

然而，一定會有小夥伴提出質疑，你這個功能也太侷限了吧，如果遇到特殊需求，例如，所有的週末都不能選擇，你怎麼整？

OK，此時就需要“面向設計的半封裝web元件開發”的這篇文章出馬了？

之所以有人會提出上面的質疑，還是按照了傳統元件的思維方式去思考。沒錯，確實有些專案的時間元件要求週末不能選擇。但是，你現在做的這個專案，有這個需求嗎？你好好想想。

CSS3現在發展越來越成熟，UI層的變化越來越迅速和不可預知，這種趨勢，要求我們的UI元件要輕快，靈活，隨時可以根據上層變化做調整。而那種妄圖考慮各種場景，程式碼又大又冗餘的元件開發方式已經越來越不適應未來的潮流了。

如果你真的遇到“週末都不能選擇”的需求，我告訴你怎麼辦？自定義一個名為”date-no-weekend“的type型別，內部的JS程式碼當然該重用的重用，該模組化的模組化：

還是覺得難以接受，仔細品味後面這句話：元件要面向設計，落地專案，追求品質。

好，我們現在實現了基於HTML5時間選擇元件落地實踐生產，加以推廣，勢必對HTML5標準在國內的學習與普及帶來幫助。

然而，就單單一個元件，勢單力薄，怕是針落大海，激不起一點水花，其他些元件是不是也可以找這種面向HTML的思路去開發呢？

有！

告訴大家，QQ公眾平臺的UI元件體系貫穿始終，就是基於面向HTML標準開發的思想實現，同時藉助面向設計的開發思想，讓元件極致體驗，同時輕便快捷，風一吹就可以飛到天上去。

三、實踐

QQ公眾平臺的UI元件實現，和傳統實現是完全不同的設計思想。從JS層進一步往下沉澱了一個層次，基於原生的HTML實現。

多說無益，眼見為實（狠擊下面）。

demo-點選這裡-demo

點選上面的demo, 進入一個平凡的靜態頁面，引入眼簾的是一個普通的表單，裡面的UI都是系統預設的，HTML功能也是原生的。

• title提示
  
• 選擇日期
  
• 點選提交的表單驗證
  

• 男女款式、城市以及運費險對價格的影響
  
• 表單提交事件
  

結果，一瞬間，上面原始粗糙的介面一下子變成了這樣子：

妥妥的醜小鴨變成了白天鵝，包括之前原生的HTML功能。

• title提示
  
• 選擇日期
  
• 點選提交的表單驗證
  

而，最最重要，和最最神奇的事情是：我們僅僅是引入了QQ公眾平臺的UI元件，對，僅僅是引入和一點初始化，沒有動之前一點點一絲絲的業務JS. 但是，之前的各種互動功能，卻完全不受影響，反而體驗更上兩層樓！

請看下面的gif截圖演示：

真是一場意外之旅，發現沒，面向HTML開發，實際上不是簡單推動了HTML5等現代web技術落地實踐，對我們的開發流程等也帶來了巨大幫助——UI元件可以和業務JavaScript完全分離，可以實現無縫對接。就是因為整個元件體系基於原生HTML開發的設計理念，讓UI元件迴歸了其本質或者說本職作用——UI.

四、優勢

下面總結下面向HTML的UI元件開發的優勢。

1. HTML/CSS側的現代產物落地實踐
基於HTML標準來開發我們的UI元件，通過技術跨越各種相容問題，使得我們前端技術在HTML層也乘上了現代web技術的快車，標準的HTML5規範和屬性提前很多年在廣受眾的傳統PC頁面呈現，我覺得是非常有意義的一件事情。

2. 規避了傳統元件的很多問題

1. 更強的語義化，可訪問性，SEO等；
2. 學習和使用成本低；
3. 專注HTML控制元件本身，而不是元件；
4. 可以一次性全域性處理；

畢竟是基於原生HTML來開發的，這一塊必定槓槓的。

例如，時間選擇：

顯然語義要比下面的text型別要好：

又如基於checkbox/radio型別的input框模擬的單核取方塊自然要比傳統div元素模擬的無論是語義、裝置可訪問性都要高很多。

不會出現類似GregorianCalendar, GregorianCalendarFormat一眼不知道幹嘛的物件和方法。

不需要記住類似showWeekNumber, showClear, showToday, disabledDate這樣千差萬別的JS API名稱，記住標準的HTML5屬性即可，只要記住一次，終身受用，放心，不會變的，HTML5文案已經定稿了。

而學習成本低對於跨團隊合作非常有幫助。你說kissy上手快，還是隻需要寫寫標準HTML就OK上手快！

其他團隊同學樂於使用你的東西，介入快，實現效果好，大家都開心。反之，API千差萬別，每次使用都要去翻文件，肯定影響合作。

不過，實踐下來，有一點學習成本我沒考慮到，就是轉換思維方式的學習成本。實際上只要面向元素的HTML元素開發就可以了，但是有遇到小夥伴，還是按照老的思維方式，在生成的UI元件元素上做文章。

舉個例子，日期選擇器，當日期修改了，我們要幹嘛幹嘛，直接：

想要修改日期範圍，直接：

UI元件會自動同步。沒有任何元件相關的JS程式碼，也沒有什麼故弄玄虛，沒有所謂的高屋建瓴，全是很簡單基礎的HTML操作。是不是這樣的開發反而很省心，連小白使用者也能上手？

於是乎，在多團隊聯合協作開發的時候，前端開發的進度並不會受UI元件開發影響，面向HTML，專心自身業務開發就可以了。

負責元件開發的前端去休陪產假了，負責業務的前端，直接按照標準的HTML控制元件元素是實現自己的業務邏輯，什麼回撥啊都直接使用原生的事件和方法。等負責元件開發的前端，回來了，哪怕拖了個把星期，只要元件完成，公共JS一初始化，業務JS沒有任何修改，無縫對接。

於是乎，實現了一個聽上去很了不得的東西：前端分離。

這對於整個開發流程和效率也帶來了巨大的提升。

不僅如此，廠子裡有很多開發，負責內部專案，會寫JS擅長業務功能實現，但是，UI這塊是個軟肋。OK，此時，我們這裡面向HTML開發的UI元件體系就是其救星，對吧，直接引入CSS和JS，簡單全域性初始化一下（可能還有一些簡單的微調），結果，頁面立馬高大上了，是不是很有用！

傳統實現，每個具體業務的指令碼里面要參與UI元件的具體API引數設定。而面向HTML的實現，API落地與具體的業務頁面，於是乎，只要在專案的common.js中全域性初始化一下，如下拉Select.init(), 具體的業務JS檔案（絕大多數情況下）中就無需再出現UI元件相關的JS程式碼。

UI層的JS程式碼和業務層JS程式碼分離，實現進一步的「前端分離」，去耦合。對於日後的維護、升級等要比傳統元件更輕鬆。

五、結果

面向HTML的UI元件開發貫穿於整個QQ公眾平臺UI元件體系。包括上面沒出現過的range範圍選擇，自定義滾動效果等等。

從實踐的結果來看，前端同事嘖嘖稱讚過（功能層），我們設計中心這邊leader希望這套可以推到其他team去（體驗層）。

大家有興趣，不妨速度加入QQ公眾平臺，也來體驗下，歡迎反饋以及提出寶貴意見。

六、結語

一個type="date"的input框實際上就是一個終極的Web Components，一小段就是一個可以被import的模組，然後就可以出現介面複雜的元件效果(shadow DOM)，而API就是HTML的原生屬性。

QQ公眾平臺UI元件離Web Components到底有多遠？如果說傳統的web元件距離是1條長安街的話，那QQ公眾平臺UI元件只有0.5條長安街的距離。

HTML和API利用了原生的Web Components模式，非Web Components模式的僅僅是自定義的浮層這一塊，但是，設計思想和思路都是朝著Web Components模式前進的。

換句話說，雖然無法一步直達Web Components，但是，我們可以利用HTML的發展，通過一些策略和設計，對UI元件進行一些變革，讓其在朝著Web Components前進的道路上邁出一大步。

本文主講設計思想，至於具體的技術細節，以後有機會會慢慢分享，能夠講的點非常非常多，越是簡單的成品越是需要足夠的積累。

以上，希望本文的內容能夠對大家有一點啟示。