在閱讀本文之前，建議先閱讀之前的一篇文章：“面向設(shè)計(jì)的半封裝web組件開發(fā)”，便于理解文章的一些解惑。

一、現(xiàn)狀

1. 前端發(fā)展現(xiàn)狀
前端這幾年的發(fā)展都是有目共睹的，然而，如果按照已經(jīng)落地投入實(shí)踐的標(biāo)準(zhǔn)梳理下，會發(fā)現(xiàn)，基本上都是偏后的JS開發(fā)層面的，比方說Node.js下的前后端分離，MV*庫，React.js，各種包管理工具及前端集成解決方案等。

而往前，Shadow DOM, Web Components規(guī)范和標(biāo)準(zhǔn)雖然也出現(xiàn)了，給大家看到了方向和未來，但由于兼容性的問題（參見下表），或者可能缺乏優(yōu)秀團(tuán)隊(duì)的強(qiáng)勢引領(lǐng)，我們在實(shí)際的項(xiàng)目中鮮有看到。

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

難道我們就這樣干等著，直到Web Components一統(tǒng)江山的時(shí)候，我們才開始在HTML側(cè)發(fā)力嗎？這么多年HTML5的發(fā)展就這么白費(fèi)了？我們做PC端的就因?yàn)橐恍┻^時(shí)的瀏覽器而止步不前？

2. UI組件現(xiàn)狀
成熟的團(tuán)隊(duì)都有自己的一套組件庫，以便各種項(xiàng)目來的時(shí)候，都能從容應(yīng)對。

為了能夠從容應(yīng)對，我們必然要考慮周全，企業(yè)級，能應(yīng)對大型項(xiàng)目，各種復(fù)雜場景，充分發(fā)揮組件的復(fù)用性。往往最終，會讓組件變得比較重，邏輯比較復(fù)雜，API數(shù)量也比較多。我們不妨可以看下kissy 5.0的DatePicker的組件使用示意：

如果我們單看功能，確實(shí)很強(qiáng)大，禁用日期可以任意自定義，可以輕松定義各個(gè)操作欄是否顯示，確實(shí)是企業(yè)級的web組件，看上去能適應(yīng)各種復(fù)雜場景。

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

1. 諸位靜下心來想想看，我們所經(jīng)歷的項(xiàng)目，是不是絕大多數(shù)都不復(fù)雜，我們是否有必要使用企業(yè)級的大而重的產(chǎn)品？就好比你一個(gè)展示性為主的網(wǎng)站，卻使用AngularJS MVVM來高大上。截趾適屨，敦云其愚。
2. 看上去能適應(yīng)各種場景，但是，眼下現(xiàn)代web技術(shù)飛速發(fā)展，UI層變化日新月異，你確定你這個(gè)組件能跟得上這些變化。怕是最后演變成，組件支持跟不上，而否決了設(shè)計(jì)師的一些想法。本末倒置了！
3. 代碼中出現(xiàn)了GregorianCalendar, GregorianCalendarFormat這樣的方法或?qū)ο螅垎栐谧母魑荒阒肋@是個(gè)什么鬼嗎？你知道他是干嘛用的嗎？學(xué)習(xí)成本啊~~
4. render, showWeekNumber, showClear, showToday, disabledDate這些API名稱大家有沒有覺得在哪里見過？
   “好像是在哪兒見過？”
   “好像個(gè)鬼啊，是之前根本就沒見過！”
   現(xiàn)在大家閉上眼睛，還記不記得這些API名稱是什么？假設(shè)一周以后呢，你還記不記得。是不是你要去翻API文檔了？使用成本啊~
5. 想象這樣的場景，項(xiàng)目啟動了，負(fù)責(zé)組件的前端和負(fù)責(zé)業(yè)務(wù)的前端一起開工，誰知突然，負(fù)責(zé)組件的前端的老婆突然要臨盆，不得不去陪產(chǎn)。此時(shí)負(fù)責(zé)業(yè)務(wù)的前端該怎么搞？會不會像這樣一樣在心中馬景濤：“時(shí)間選擇組件還沒完成，這里的日期交互依賴組件，這不是丟鍋給我接嗎！？”可以看到，兩人的開發(fā)被牽制了！兩種結(jié)果，一是自己上，二是這塊工作暫停。
   所以大家發(fā)現(xiàn)沒，組件和業(yè)務(wù)耦合在一起，不利于協(xié)作啊。比方說上面截圖代碼的picker.on('select', function(e) {});，組件不弄好，根本就沒法使用啊！要么就自己先搞搞，回頭再改，都是很煩的。

二、探索

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

我們還是拿時(shí)間選擇器舉例，想想看，HTML5有沒有為我們帶來native的UI組件？對吧，有的，應(yīng)該都知道的：

<input type="date"> 

date類型的input輸入框，天然可以選擇時(shí)間。

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

這些符合標(biāo)準(zhǔn)，業(yè)界規(guī)范的HTML特性要是可以直接在實(shí)際項(xiàng)目中應(yīng)用該多好啊！

然而，問題在于，瀏覽器原生的界面往往跟我們站點(diǎn)的設(shè)計(jì)風(fēng)格有些不協(xié)調(diào)，說白了，就是設(shè)計(jì)師覺得丑，而且不能自由定義某些功能，例如清除。

還有一個(gè)很現(xiàn)實(shí)的問題是兼容性，包括IE11在內(nèi)的IE瀏覽器都沒有type="date"組件行為，[[162397]] 這個(gè)補(bǔ)刀直接剮在了心頭。

怎么辦呢？

我們此時(shí)不妨梳理下：

<input type="date" min="2016-01-01" max="2016-12-31" value="2016-02-14"> 

type/min/max/value這些原生標(biāo)準(zhǔn)的HTML屬性并沒有問題，有問題的只是點(diǎn)擊出現(xiàn)的那個(gè)長相簡陋的選擇浮層。所謂對癥下藥，哪個(gè)有問題就搞哪個(gè)，我們只要想辦法把丑陋的浮層搞漂亮就可以了。

考慮到兼容性，我們其實(shí)可以和傳統(tǒng)的時(shí)間選擇器組件一樣，對浮層內(nèi)容進(jìn)行自定義，注意，我們僅自定義浮層，HTML還是原始的。

我們構(gòu)建一個(gè)名叫DateTime的實(shí)例方法，理想狀況下，我們只要綁定初始化一下，類似這樣：

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

然后duang，時(shí)間選擇器浮層直接美化成設(shè)計(jì)師需要的模樣，那該多完美啊！

夢想總是有的，萬一實(shí)現(xiàn)了呢？

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

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

::-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下的時(shí)間輸入框改造成我們想要的樣子了，而IE等不支持date輸入框的瀏覽器，保持原來的樣子就可以。

于是乎，通過CSS和JS的配合，我們就可以實(shí)現(xiàn)基于原生HTML5標(biāo)準(zhǔn)的時(shí)間選擇器了。

“稍等，怎么就實(shí)現(xiàn)了？”有人可能會有這樣的疑問。

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

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

對比：

<input type="date" min="2016-01-01" max="2016-12-31" value="2016-02-14"> 

我們是不是可以找到之間的關(guān)系？沒錯，這位同學(xué)好生眼力，HTML中的type屬性對應(yīng)JS中的type API, value屬性值對應(yīng)initDate值, min/max分別對應(yīng)beginDate/endDate。其實(shí)內(nèi)部實(shí)現(xiàn)跟傳統(tǒng)的組件沒什么差別。

那onSelected呢？onSelected是個(gè)回調(diào)方法，解讀下就是當(dāng)選擇日期之后，干嘛干嘛。其實(shí)我們原生的input框有類似的事件，什么呢？change事件。既然，我們這里使用的是原生的HTML輸入框，那我們就可以使用其原生的change事件。所以，什么onSelected回調(diào)，完全不需要。我們只要在組件內(nèi)部，當(dāng)賦值的同時(shí)trigger下原生的change事件。

于是乎，我們就得到了一個(gè)HTML是原生，API也是原生，事件也是原生，UI自定義的時(shí)間選擇控件。真真切切將HTML5應(yīng)用到了實(shí)際項(xiàng)目中，同時(shí)，就算是是10年前的IE6也是可以兼容。

完美！

然而，一定會有小伙伴提出質(zhì)疑，你這個(gè)功能也太局限了吧，如果遇到特殊需求，例如，所有的周末都不能選擇，你怎么整？

OK，此時(shí)就需要“面向設(shè)計(jì)的半封裝web組件開發(fā)”的這篇文章出馬了？

之所以有人會提出上面的質(zhì)疑，還是按照了傳統(tǒng)組件的思維方式去思考。沒錯，確實(shí)有些項(xiàng)目的時(shí)間組件要求周末不能選擇。但是，你現(xiàn)在做的這個(gè)項(xiàng)目，有這個(gè)需求嗎？你好好想想。

CSS3現(xiàn)在發(fā)展越來越成熟，UI層的變化越來越迅速和不可預(yù)知，這種趨勢，要求我們的UI組件要輕快，靈活，隨時(shí)可以根據(jù)上層變化做調(diào)整。而那種妄圖考慮各種場景，代碼又大又冗余的組件開發(fā)方式已經(jīng)越來越不適應(yīng)未來的潮流了。

如果你真的遇到“周末都不能選擇”的需求，我告訴你怎么辦？自定義一個(gè)名為”date-no-weekend“的type類型，內(nèi)部的JS代碼當(dāng)然該重用的重用，該模塊化的模塊化：

<input type="date-no-weekend"> 

還是覺得難以接受，仔細(xì)品味后面這句話：組件要面向設(shè)計(jì)，落地項(xiàng)目，追求品質(zhì)。

好，我們現(xiàn)在實(shí)現(xiàn)了基于HTML5時(shí)間選擇組件落地實(shí)踐生產(chǎn)，加以推廣，勢必對HTML5標(biāo)準(zhǔn)在國內(nèi)的學(xué)習(xí)與普及帶來幫助。

然而，就單單一個(gè)組件，勢單力薄，怕是針落大海，激不起一點(diǎn)水花，其他些組件是不是也可以找這種面向HTML的思路去開發(fā)呢？

有！

告訴大家，QQ公眾平臺的UI組件體系貫穿始終，就是基于面向HTML標(biāo)準(zhǔn)開發(fā)的思想實(shí)現(xiàn)，同時(shí)借助面向設(shè)計(jì)的開發(fā)思想，讓組件極致體驗(yàn)，同時(shí)輕便快捷，風(fēng)一吹就可以飛到天上去。

三、實(shí)踐

QQ公眾平臺的UI組件實(shí)現(xiàn)，和傳統(tǒng)實(shí)現(xiàn)是完全不同的設(shè)計(jì)思想。從JS層進(jìn)一步往下沉淀了一個(gè)層次，基于原生的HTML實(shí)現(xiàn)。

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

demo-點(diǎn)擊這里-demo

點(diǎn)擊上面的demo, 進(jìn)入一個(gè)平凡的靜態(tài)頁面，引入眼簾的是一個(gè)普通的表單，里面的UI都是系統(tǒng)默認(rèn)的，HTML功能也是原生的。

例如：

• title提示
  
• 選擇日期
  
• 點(diǎn)擊提交的表單驗(yàn)證
  

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

例如：

• 男女款式、城市以及運(yùn)費(fèi)險(xiǎn)對價(jià)格的影響
  
• 表單提交事件
  

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

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

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

例如：

• title提示
  
• 選擇日期
  
• 點(diǎn)擊提交的表單驗(yàn)證
  

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

請看下面的gif截圖演示：

真是一場意外之旅，發(fā)現(xiàn)沒，面向HTML開發(fā)，實(shí)際上不是簡單推動了HTML5等現(xiàn)代web技術(shù)落地實(shí)踐，對我們的開發(fā)流程等也帶來了巨大幫助——UI組件可以和業(yè)務(wù)JavaScript完全分離，可以實(shí)現(xiàn)無縫對接。就是因?yàn)檎麄€(gè)組件體系基于原生HTML開發(fā)的設(shè)計(jì)理念，讓UI組件回歸了其本質(zhì)或者說本職作用——UI.

四、優(yōu)勢

下面總結(jié)下面向HTML的UI組件開發(fā)的優(yōu)勢。

1. HTML/CSS側(cè)的現(xiàn)代產(chǎn)物落地實(shí)踐
基于HTML標(biāo)準(zhǔn)來開發(fā)我們的UI組件，通過技術(shù)跨越各種兼容問題，使得我們前端技術(shù)在HTML層也乘上了現(xiàn)代web技術(shù)的快車，標(biāo)準(zhǔn)的HTML5規(guī)范和屬性提前很多年在廣受眾的傳統(tǒng)PC頁面呈現(xiàn)，我覺得是非常有意義的一件事情。

2. 規(guī)避了傳統(tǒng)組件的很多問題

1. 更強(qiáng)的語義化，可訪問性，SEO等；
2. 學(xué)習(xí)和使用成本低；
3. 專注HTML控件本身，而不是組件；
4. 可以一次性全局處理；

①. 語義化，可訪問性

畢竟是基于原生HTML來開發(fā)的，這一塊必定杠杠的。

例如，時(shí)間選擇：

<input type="date"> 

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

<input type="text"> 

又如基于checkbox/radio類型的input框模擬的單復(fù)選框自然要比傳統(tǒng)p元素模擬的無論是語義、設(shè)備可訪問性都要高很多。

②. 更低的學(xué)習(xí)和使用成本

不會出現(xiàn)類似GregorianCalendar, GregorianCalendarFormat一眼不知道干嘛的對象和方法。

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

而學(xué)習(xí)成本低對于跨團(tuán)隊(duì)合作非常有幫助。你說kissy上手快，還是只需要寫寫標(biāo)準(zhǔn)HTML就OK上手快！

其他團(tuán)隊(duì)同學(xué)樂于使用你的東西，介入快，實(shí)現(xiàn)效果好，大家都開心。反之，API千差萬別，每次使用都要去翻文檔，肯定影響合作。

不過，實(shí)踐下來，有一點(diǎn)學(xué)習(xí)成本我沒考慮到，就是轉(zhuǎn)換思維方式的學(xué)習(xí)成本。實(shí)際上只要面向元素的HTML元素開發(fā)就可以了，但是有遇到小伙伴，還是按照老的思維方式，在生成的UI組件元素上做文章。 [[162402]]

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

舉個(gè)例子，日期選擇器，當(dāng)日期修改了，我們要干嘛干嘛，直接：

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

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

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

UI組件會自動同步。沒有任何組件相關(guān)的JS代碼，也沒有什么故弄玄虛，沒有所謂的高屋建瓴，全是很簡單基礎(chǔ)的HTML操作。是不是這樣的開發(fā)反而很省心，連小白用戶也能上手？

于是乎，在多團(tuán)隊(duì)聯(lián)合協(xié)作開發(fā)的時(shí)候，前端開發(fā)的進(jìn)度并不會受UI組件開發(fā)影響，面向HTML，專心自身業(yè)務(wù)開發(fā)就可以了。

負(fù)責(zé)組件開發(fā)的前端去休陪產(chǎn)假了，負(fù)責(zé)業(yè)務(wù)的前端，直接按照標(biāo)準(zhǔn)的HTML控件元素是實(shí)現(xiàn)自己的業(yè)務(wù)邏輯，什么回調(diào)啊都直接使用原生的事件和方法。等負(fù)責(zé)組件開發(fā)的前端，回來了，哪怕拖了個(gè)把星期，只要組件完成，公共JS一初始化，業(yè)務(wù)JS沒有任何修改，無縫對接。

于是乎，實(shí)現(xiàn)了一個(gè)聽上去很了不得的東西：前端分離。

這對于整個(gè)開發(fā)流程和效率也帶來了巨大的提升。

不僅如此，廠子里有很多開發(fā)，負(fù)責(zé)內(nèi)部項(xiàng)目，會寫JS擅長業(yè)務(wù)功能實(shí)現(xiàn)，但是，UI這塊是個(gè)軟肋。OK，此時(shí)，我們這里面向HTML開發(fā)的UI組件體系就是其救星，對吧，直接引入CSS和JS，簡單全局初始化一下（可能還有一些簡單的微調(diào)），結(jié)果，頁面立馬高大上了，是不是很有用！

④. 可以一次性全局處理

傳統(tǒng)實(shí)現(xiàn)，每個(gè)具體業(yè)務(wù)的腳本里面要參與UI組件的具體API參數(shù)設(shè)置。而面向HTML的實(shí)現(xiàn)，API落地與具體的業(yè)務(wù)頁面，于是乎，只要在項(xiàng)目的common.js中全局初始化一下，如下拉Select.init(), 具體的業(yè)務(wù)JS文件（絕大多數(shù)情況下）中就無需再出現(xiàn)UI組件相關(guān)的JS代碼。

UI層的JS代碼和業(yè)務(wù)層JS代碼分離，實(shí)現(xiàn)進(jìn)一步的「前端分離」，去耦合。對于日后的維護(hù)、升級等要比傳統(tǒng)組件更輕松。

五、結(jié)果

面向HTML的UI組件開發(fā)貫穿于整個(gè)QQ公眾平臺UI組件體系。包括上面沒出現(xiàn)過的range范圍選擇，自定義滾動效果等等。

從實(shí)踐的結(jié)果來看，前端同事嘖嘖稱贊過（功能層），我們設(shè)計(jì)中心這邊leader希望這套可以推到其他team去（體驗(yàn)層）。

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

六、結(jié)語

一個(gè)type="date"的input框?qū)嶋H上就是一個(gè)終極的Web Components，一小段<input>就是一個(gè)可以被import的模塊，然后就可以出現(xiàn)界面復(fù)雜的組件效果(shadow DOM)，而API就是HTML的原生屬性。

QQ公眾平臺UI組件離Web Components到底有多遠(yuǎn)？如果說傳統(tǒng)的web組件距離是1條長安街的話，那QQ公眾平臺UI組件只有0.5條長安街的距離。

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

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

本文主講設(shè)計(jì)思想，至于具體的技術(shù)細(xì)節(jié)，以后有機(jī)會會慢慢分享，能夠講的點(diǎn)非常非常多，越是簡單的成品越是需要足夠的積累。

以上，希望本文的內(nèi)容能夠?qū)Υ蠹矣幸稽c(diǎn)啟示。