HTML發展與UI組件設計進化_html/css

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名稱大家有沒有覺得在哪里見過？

“好像是在哪兒見過？”

“好像個鬼啊，是之前根本就沒見過！”

5.現在大家閉上眼睛，還記不記得這些API名稱是什么？假設一周以后呢，你還記不記得。是不是你要去翻API文檔了？使用成本啊~

6.想象這樣的場景，項目啟動了，負責組件的前端和負責業務的前端一起開工，誰知突然，負責組件的前端的老婆突然要臨盆，不得不去陪產。此時負責業務的前端該怎么搞？會不會像這樣一樣在心中馬景濤：“時間選擇組件還沒完成，這里的日期交互依賴組件，這不是丟鍋給我接嗎?。俊笨梢钥吹剑瑑扇说拈_發被牽制了！兩種結果，一是自己上，二是這塊工作暫停。 所以大家發現沒，組件和業務耦合在一起，不利于協作啊。比方說上面截圖代碼的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的實例方法，理想狀況下，我們只要綁定初始化一下，類似這樣：

new DateTime($("[type=date]");

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

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

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

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

::-webkit-clear-button,::-webkit-inner-spin-button,::-webkit-calendar-picker-indicator { display:none;}[type="date"]::-webkit-datetime-edit-text { color: transparent;}[type="date"]::-webkit-datetime-edit-text::before { content: '-'; position: absolute;}::-webkit-datetime-edit-text,::-webkit-datetime-edit-year-field,::-webkit-datetime-edit-month-field,::-webkit-datetime-edit-day-field,::-webkit-datetime-edit-hour-field,::-webkit-datetime-edit-minute-field,::-webkit-datetime-edit-ampm-field { background: none;}

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

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

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

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

new DatePicker($("#date"), { type: "date", initDate: .., beginDate: .., endDate: .., onSelected: $.noop});

對比：

我們是不是可以找到之間的關系？沒錯，這位同學好生眼力，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功能也是原生的。

例如：

1.title提示<.li>

2.選擇日期

3.點擊提交的表單驗證

UI雖然原始，但是功能卻是很健全的。

例如：

1.男女款式、城市以及運費險對價格的影響

2.表單提交事件

下面，見證奇跡的時刻到了，點擊demo頁面（下圖所示）的按鈕進行QQ公眾平臺UI組件資源的加載和初始化：

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

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

例如：

1.title提示

2.選擇日期

3.點擊提交的表單驗證

而，最最重要，和 最最神奇的事情是 ：我們僅僅是引入了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組件元素上做文章。

③. 專注HTML控件本身，而不是組件

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

$("input").change(function() {});

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

$("input").attr({ "min": "2015-12-27", "max": "2016-12-27" });

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前進的道路上邁出一大步。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com