整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
天小編再一次給大家推薦一款Visual Studio Code的插件這款插件的名字叫
HTML Boilerplate,它的作用就是可以很快的生成HTML5的基本結構，可以提高我們日常開發中的效率。下來就先看看效果吧
操作描述
效果展示
它便會自動生成HTML5的基本結構以及對瀏覽器的一些判斷，可以說是對前端開發者十分友好了，至于安裝步驟十分之簡單
喜歡的小伙伴們點贊加關注哦。
著移動市場的逐步擴大及相關技術的日趨完善，對前端開發提出了新的崗位要求，在繼承前人成果的基礎上需要在新的歷史條件下有新的創新。移動端的開發，雖然沒有IE6眾多問題的折磨，但是多平臺，多設備的兼容，也是如惡夢般存在。不過話說回來，著重還是考驗基礎的css 2.x的功底，只要基礎扎實了，應付移動端的兼容也是手到擒來。當然css3.x, html5新增加的標簽還是需要學習，具體的推薦：
一. css
http://book.douban.com/subject/20390374/
http://book.douban.com/subject/6025285/
包括html5,css3完整的基礎入門書籍
二.js
https://github.com/jtyjty99999/mobileTech
99移動端知識集合
https://github.com/AlloyTeam/Mars
AlloyTeam-Mars
http://www.oschina.net/translate/mobile-app-optimization-and-performance
優化移動體驗的HTML5技巧
https://github.com/hoosin/mobile-web-favorites
移動前端開發大雜燴
http://html5boilerplate.com/
http://www.zhihu.com/question/19551815
http://www.ruanyifeng.com/blog/2012/05/responsive_web_design.html
自適應網頁設計
HTML5 Boilerplate
http://eightmedia.github.io/hammer.js/
移動端事件庫
http://webix.com
支持移動端的框架
http://www.xueui.cn/ui-tutorial-collection/
移動端UI入門知識大集合
http://www.cnblogs.com/iamzhanglei/
當耐特
他出了一本書叫：html5實驗室-Canvas世界
http://book.douban.com/subject/23820912/
這書前半部分是canvas基礎，后半部分是游戲的示例。
http://book.douban.com/subject/5402708/
根據目錄大家可能也看出來了，這是一本基礎入門的書籍。
3). 移動web手冊 移動Web第一書 前端國際大牛PPK最新力作
本書徹底厘清移動Web開發與傳統PC網站開發的本質區別
互聯網產品移動端活躍用戶數超越PC端已大勢所趨
多界面設備測試
Opera多終端界面模擬
其它輔助工具
webstorm
自isobar
概述
本文檔包含了Isobar公司的創意技術部（前端工程）開發web應用的規范。現在我們把它開放給任何希望了解我們迭代過程最佳實踐的人。
編寫本文檔的主要驅動力是兩方面： 1) 代碼一致性 以及 2) 最佳實踐。 通過保持代碼風格和傳統的一致性，我們可以減少遺留系統維護的負擔，并降低未來系統崩潰的風險。而通過遵照最佳實踐，我們能確保優化的頁面加載、性能以及可維護的代碼。
前端開發核心思想
對于所有編程語言，我們要求縮進必須是軟tab（用空格字符）。在你的文本編輯器里敲 Tab 應該等于 4個空格 。
對于維護現有文件，我們認為可讀性比節省文件大小更重要。大量空白和適當的ASCII藝術都是受鼓勵的。任何開發者都不必故意去壓縮HTML或CSS，也不必把Javascript代碼最小化得面目全非。我們會在服務器端或build過程中自動最小化并gzip壓縮所有的靜態客戶端文件，例如CSS和JS。
任何網頁的首要組件就是基于標簽的HTML標記語言。超文本標記語言 (HTML) 曾有一段不堪回首的歷史，但最近幾年已經是 皇 上 回 宮 了。經過對它基于XML的XHTML變種的漫長試驗之后，整個行業終于接受了HTML代表web的未來這一事實。
標記定義了文檔的結構和綱要，并提供結構化的內容。除了最基本的概念（例如標題、段落和列表）之外，標記并不是用來定義頁面上內容的外觀和體驗的。HTML的表現屬性都已經被廢棄了，有關樣式的定義應該被包含在 樣式表 中。
HTML5 是HTML 和 XHTML 的新版本。 在 HTML5 草案 的規范中定義了可以用 HTML 和 XML編寫的單一的語言，意在解決在之前HTML的迭代中發現的一些問題并滿足web應用的需求，這是以前HTML沒有充分覆蓋到的領域（來源 ） 。
在合適的時候，我們會使用HTML5 Doctype 和 HTML5 特性。
我們會對照 W3C 校驗器 測試我們的標記，以確保標記是結構良好的。我們的目標并不是100%的合法代碼，但是校驗肯定對于編寫可維護的站點以及調試代碼都大有幫助。 Isobar公司不保證代碼都是100%合法，而是確信跨瀏覽器體驗會相當一致 。
對HTML5文件，我們使用 H5BP 針對我們自己項目需求修改的一個分支。 你也可以從這里Fork H5BP。
標記中必須總是使用合適的Doctype來指示瀏覽器觸發標準模式. 永遠要避免Quirks模式。
HTML5特別好的一個方面就是它簡化了Doctype需要的代碼。無意義的屬性被棄用了，DOCTYPE 聲明也被顯著地簡化了。另外，也無需再用 CDATA 對內聯JavaScript代碼進行轉義，而這在此之前為了讓XHTML符合XML的嚴密性是必需的。
HTML5 Doctype
1.<!DOCTYPE html>
所有標記必須通過UTF-8編碼傳遞，因為這種編碼方式是對國際化最友好的。必須在HTTP的header和HTML文檔的head部分都指定這種編碼。
設定字符編碼是通過 <meta> 標簽進行。
1.<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
如果是HTML5，則只需要寫：
1.<meta charset="utf-8">
下面是編寫HTML標記的總體原則。提醒大家一點，在創建的HTML文檔里總是要使用能夠代表內容語義的標記。
在HTML5規范里并沒有嚴格要求屬性值兩邊加引號。但考慮到一些屬性可以接受空白值，為了保持一致性，我們要求所有屬性值必須加上引號。
1.<p class="line note" data-attribute="106">This is my paragraph of special text.</p>
網頁的第二個組件就是在層疊樣式表（CSS）中包含的表現信息。Web瀏覽器成功實現CSS后，整整一代web開發者對他們網站的外觀和體驗擁有了全部的控制權。
正如網頁信息在語義方面由 HTML 標記 描述， CSS 從表現方面則是通過對視覺屬性的定義來描述網頁。 CSS 的強大之處在于，這些屬性可以混合并通過各種標示符匹配，它可以通過樣式規則的分層（”層疊“）來控制頁面的布局和視覺特征。
深入學習和理解CSS及基于瀏覽器的盒子模型，對于掌握CSS布局的基礎是非常必要的。
3D CSS 盒子模型示意圖， 由 Jon Hicks 繪制。
我們一般不用 W3C 校驗器。
最低要求：選擇器單獨占一行，每個屬性占一行。屬性聲明要有縮進。
作為提高的要求，關聯或孩子樣式要增加2-4個空格的縮進。這樣有利于分層查看和組織，產生（對某些人來說）可讀性更好的樣式表。
另外，在給一個樣式指定多個選擇器的時候，把每個選擇器單獨放一行是個好主意。這樣可以避免一行變得太長，也能提高可讀性及版本控制流程。
01..post-list li a{
02.color:#A8A8A8;
03.}
04..post-list li a:hover{
05.color:#000;
06.text-decoration:none;
07.}
08..post-list li .author a,
09..post-list li .author a:hover{
10.color:#F30;
11.text-transform:uppercase;
12.}
在多個開發者協作環境下，避免用單行CSS格式，因為這樣會給版本控制帶來問題。
如果你對性能情有獨鐘， 對CSS屬性進行字母排序有利于在GZIP壓縮中識別大量可重復的特征。
對于所用的樣式只出現一次的元素，給它設一個id屬性。這個屬性只會應用于該元素，不會用到其他地方。Class屬性則可以用到多個具有相同樣式屬性的元素上。具有相同外觀和表現的元素可以具有相同的class名。
1.<ul id="categories">
2.<li class="item">Category 1</li>
3.<li class="item">Category 2</li>
4.<li class="item">Category 3</li>
5.</ul>
無論是 ID 還是 class，對任何東西最好總是根據 它是什么 而不是 它看上去是什么樣子 來命名。 比如一個頁面上的特別提示的 class 名是 bigBlueText （大藍字），可它的樣式早就被改成紅色小字體，這個名字就沒意義了。使用更聰明的慣例如 noteText （提示文字）就好多了，因為即使視覺樣式改變了，它也還是管用的。
CSS3 選擇器 規格引入了一整套對于更好地選擇元素極其有用的 CSS 選擇器。
偽類 使你能動態地修飾網頁內容的樣式。有些偽類從CSS1 （:visited, :hover等） 和 CSS2 （:first-child, :lang）那時候開始就有了。CSS3又往列表里加入了16個新的偽類，這些偽類對于動態地修飾網頁內容的樣式特別有用。 學習如何深度使用偽類。
組合選擇器 提供了為特定元素選擇其后代元素、孩子元素或兄弟元素的快捷方式。
屬性選擇器 適用于具有特定屬性 和/或 特定值的元素。正則表達式的知識對屬性選擇大有幫助。
瀏覽器會通過 計算選擇器的明確度 來決定應用哪個CSS規則。如果兩個選擇器都適用于同樣的元素，具有更高明確度的那個會勝出。
ID 選擇器比屬性選擇器明確度高，class 選擇器比任何數量的元素選擇器明確度高。盡量使用 ID 選擇器來提高明確度。有時候我們可能會想方設法給一個元素應用一條CSS規則，但用盡方法也不能如愿。這種情況有可能是因為我們使用的選擇器比另外一個的明確度低，所以明確度高的另一個選擇器里的屬性就比我們想應用的選擇器優先了。這種情況在更大或更復雜的樣式表里更為常見。在小一些的項目里，通常這不是大問題。
當你在一個很大很復雜的樣式表上干活的時候，知道如何計算選擇器的明確度會有很大幫助，會節約你的時間，并讓你的選擇器更有效率。
明確度的計算方式是對你的CSS的各種組件計數，并用 (a,b,c,d) 格式表達出來。
不過，也許使用現成的明確度計算器更好一些。
使用 !important 會覆蓋掉所有的明確度，不管它有多高。因此我們傾向于避免使用它。大部分時候是沒必要用它的。即使你需要覆蓋某個你訪問不到的樣式表里的選擇器，往往也會有其他的辦法去覆蓋。盡可能避免使用它。
我們使用 px 作為定義 font size 的度量單位，因為它能提供對文本的絕對控制。我們知道為字體大小使用 em 單位一度很流行，這樣可以解決 IE6 無法改變基于像素的文本大小的問題。不過，現在所有的主流瀏覽器（包括 IE7 和 IE8）都支持基于像素單位的文本大小 和/或 整頁縮放。既然 IE6被廣泛認為已廢棄，用像素定義文本尺寸更好。另外，無單位的 line-height 也應該優先考慮，因為它不會從父元素繼承一個百分比值，而是基于 font-size 的一個乘數。
正確
1.#selector {
2.font-size: 13px;
3.line-height: 1.5; /* 13 * 1.5 = 19.5 ~ Rounds to 20px. */
4.}
不正確
1./* Equivalent to 13px font-size and 20px line-height, but only if the browser default text size is 16px. */
2.#selector {
3.font-size: 0.813em;
4.line-height: 1.25em;
5.}
不可避免地，當所有其他瀏覽器看起來都正常工作的時候，各種版本的IE瀏覽器就會冒出一些莫名其妙的bug，讓部署一拖再拖。雖然我們鼓勵排除問題，產出無需打補丁就能在所有瀏覽器上運行的代碼，有時候為了在樣式表中使用CSS鉤子，還是有必要用到CSS if IE 條件注釋。從 paulirish.com 了解更多信息。
修復 IE
1.<!--[if lt IE 7 ]> <body class="ie6"> <![endif]-->
2.<!--[if IE 7 ]> <body class="ie7"> <![endif]-->
3.<!--[if IE 8 ]> <body class="ie8"> <![endif]-->
4.<!--[if IE 9 ]> <body class="ie9"> <![endif]-->
5.<!--[if !IE]><!--> <body> <!--<![endif]-->
1..box { float: left; margin-left: 20px; }
2..ie6 .box { margin-left: 10px; }
如果你在用HTML5（以及 HTML5 Boilerplate）， 我們推薦使用 Modernizer JavaScript庫和下列模式：
1.<!--[if lt IE 7]> <html class="no-js ie ie6" lang="en"> <![endif]-->
2.<!--[if IE 7]> <html class="no-js ie ie7" lang="en"> <![endif]-->
3.<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
4.<!--[if IE 9]> <html class="no-js ie9" lang="en"> <![endif]-->
5.<!--[if gt IE 9]><!--><html class="no-js" lang="en"><!--<![endif]-->
一般情況下要優先使用CSS速記格式，一是因為它的簡潔，二是用它也可以擴充已有的值，例如margin和padding的情況。 開發者必須注意TRBL 縮寫，它表示元素的各邊按順時針方向定義的順序：上、右、下、左。如果bottom沒有定義，它就會從top繼承值。同理，如果left未定義，它從right繼承值。如果只有top的值有定義，所有的邊都會繼承那一個值。
下面是關于減少樣式表代碼冗余和使用CSS速記格式的更多內容：
近些年來越來越流行使用web上的定制字體和字型。隨著本地瀏覽器對其支持度的攀升，以及一些支持它的服務和API的出現，這個領域發展的勢頭很猛。這些方法都各有利弊。項目啟動前最好是在技術和版權限制方面先做一些研究，以便為特定項目選擇合適的方法。
所有這些方法都有代碼開銷、開發時間和性能（時間計算和用戶感受）的不足。你需要熟悉這些問題，并和團隊成員及用戶溝通，這樣會減少項目后期的大量問題。
下面列出一些內嵌定制字體的流行手段，按我們實施時的優先級排序。
@font-face 規則 允許你自定義字體。它最早是在CSS2 規范里定義的，但從CSS2.1被刪除了。現在，它是CSS3草案中的推薦稿。
對于web定制字體，我們的首選和最偏愛的選擇都是 @font-face ，就是因為它被列入了CSS字體模塊工作草案的一部分，這意味著它會隨著瀏覽器支持的提升變得越來越流行，并且隨著它不斷改善變得更穩定，使用起來也更簡單。
就現在而言，使用 @font-face 的時候，建議為每種字體格式定義它的source。這很重要 -- 如果你想讓它在大多數瀏覽器中有效 -- 雖然這不是使用它的必要條件。
在規范中包括的字體格式有：
為了實現完全的瀏覽器兼容性，可以使用 Fontsprings 的新版 防彈 @font-face 語法 （2011年2月21日的最新版本）。
01.@font-face {
02.font-family: 'MyFontFamily';
03.src: url('myfont-webfont.eot'); /* IE9 Compat Modes */
04.src: url('myfont-webfont.eot?iefix') format('eot'), /* IE6-IE8 */
05.url('myfont-webfont.woff') format('woff'), /* Modern Browsers */
06.url('myfont-webfont.ttf') format('truetype'), /* Safari, Android, iOS */
07.url('myfont-webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
08.font-weight: <font-weight>;
09.font-style: <font-style>;
10.// etc.
11.}
這里有一個使用上述技術實現的 演示 。
Safari, IE 6-9, IE 9 兼容模式, Firefox, Chrome, iOS, Android, Opera
有時候 IE 會在用戶不知道的情況下自作主張切換到兼容模式。要阻止你的站點缺省進入兼容模式，可以在站點的<head> 部分加入下列代碼：
1.<meta http-equiv="X-UA-Compatible" content="IE=edge">
優點
不足
使用 Google Webfonts 有兩套可選方案。這兩套方案當然也各有其弊端，但它們也可以用得和 @font-face 一樣好，這全取決于項目的需要。
Google的 Webfonts API 本質上和 @font-face 做的是同樣的事情，只是它把所有困難的工作都幫你做好了，提供了更廣泛的瀏覽器支持。這個方案主要的缺點是它使用的字體庫非常小。使用它的時候你只需要引入下面這套樣式表并指定字體名。
1.<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Font+Name">
然后給你想應用的選擇器定義一個樣式即可：
1.CSS selector {
2.font-family: 'Font Name', serif;
3.}
Google 提供的另一個備選方案是 Webfont 加載器 ，它是一個 JavaScript 庫，提供比字體 API 更多的控制。你也可以像Typekit那樣使用多套web字體。 使用這套方案需要把下面的script引入你的頁面：
01.<script type="text/javascript">
02.WebFontConfig = { google: { families: [ 'Tangerine', 'Cantarell' ]} };
03.(function() {
04.var wf = document.createElement('script');
05.wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
06.'://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
07.wf.type = 'text/javascript';
08.wf.async = 'true';
09.var s = document.getElementsByTagName('script')[0];
10.s.parentNode.insertBefore(wf, s);
11.})();
12.</script>
用這種方式引入 webfont.js 文件速度更快，如果沒有用到前面的Ajax接口的話。否則你應該用下面的方法：
1.<script type="text/javascript" src="https://www.google.com/jsapi"></script>
2.<script type="text/javascript">
3.google.load("webfont", "1");
4.google.setOnLoadCallback(function() {
5.WebFont.load({ google: { families: [ 'Tangerine', 'Cantarell' ]} });
6.});
7.</script>
通過使用這套 Webfont 加載器，你具備更多的定制能力，包括使用更多的字體，而不局限于不大的Google Webfont字庫。不過，這種方案需要加載Javascript，這就是為了便利付出一些其他的犧牲了。
優點
不足
如果你選擇使用 Cufon，我們強烈推薦你使用 Cufon 壓縮版。你會需要用 生成器 來轉換你的字體。
1.<script src="cufon-yui.js" type="text/javascript"></script>
2.<script src="YourFont.font.js" type="text/javascript"></script>
3.<script type="text/javascript">
4.Cufon.replace('h1'); // Works without a selector engine
5.Cufon.replace('#sub1'); // Requires a selector engine for IE 6-7
6.</script>
我們推薦慎重使用 Cufon ，因為如果應用到大量的文本上，它會產生很多開銷。訪問 Cufon Wiki可以獲取更多相關信息。
優點
不足
當選擇給網站添加定制字體的時候，使用 Typekit 有它不容忽視的優勢。它具備很強的平臺集成，并且是可擴展和流行的服務。 它可以和 Google Webfonts 一起使用，并且易于加入到以 WordPress, Posterous, Typepad, 和其他類似的 CMS 實現的網站上。
但是，要完整地應用 Typekit 也不是無本生意。如果你需要把它用到超過2個站點，或用在一個瀏覽量很高的站點上，你需要每年付49.99美元費用，對于百萬以上瀏覽量的站點費用會加倍。不過，如果你的網站有這么大瀏覽量，對這點成本你應該是不差錢的。如果不是這樣，你可能需要重新考慮你的商業模式了。
優點
不足
我們不推薦使用這種方法，但是因為它的廣泛使用，我們覺得還是有必要介紹它，以便你在選擇定制web字體方法時做出胸有成竹的決定。
即使它在web設計師中廣為流行，而且它在大多數瀏覽器中也有很好的支持，使用它的缺點還是大過它的便利性。 棄用 sIFR 的最大也是最明顯的原因是它需要使用Flash這一事實。而且，即便是為了讓Flash正常工作就需要 JavaScript，而且在你使用此方法渲染的文本能在頁面上可見之前，相關的腳本必須都先被加載。更不用說，它會增加頁面加載時間，并會讓一個慢網站變得更慢。
我們會讓你對這些問題算算細賬。
優點
不足
即使你可以把任何字體轉換為web字體文件，你還是應該確認這樣做是否合法。很多廠商更新了他們關于字體在web上使用的條款。查看 字體版權和保護的細則 獲取更多信息。
利用CSS3規范中增加的特性，你可以做很多新奇的事情，不過里邊很多新特性還沒有得到所有主流瀏覽器的完全支持。不過這也不是說它們現在就不能用。對于這些支持不好的特性，有一些回退的庫可用，或者有一些其他補丁，用來填補在瀏覽器對新特性缺乏支持時出現的空白。
還有一些瀏覽器特定的屬性或前綴也可以用來修飾樣式。為跨瀏覽器支持起見，我們推薦使用 Prefixr.com 來確保你加入了所有針對不同瀏覽器的前綴屬性。
JavaScript 是網頁的第三個主要部件。在網頁上適當地應用JavaScript 代碼，通過綁定事件和控制整體行為層，能夠增強整體的用戶和基于瀏覽器的體驗。
隨著功能強勁的新瀏覽器撐起基于瀏覽器的完整web應用，JavaScript 在近年的流行度爆棚。另外，對Javascript的細致運用為全面操控另外兩個部件 -- HTML 標記 和 CSS -- 提供了手段。現在，在無需刷新整個頁面的情況下，頁面結構和頁面視覺樣式都可以被實時操控。
我們開發新應用主要會用到 jQuery，不過我們對原生 JavaScript 和所有現代 javascript 庫也具有專業經驗。
總的來說，使用留空應該遵循源遠流長的英語閱讀慣例。 例如，每個逗號和冒號（以及適用的分號）后面要空一格，但在括號內部的左側和右側都不要加空格。另外，大括號應該總是和他們前面的參數出現在同一行。
來看看下面的 JavaScript for循環的例子...
正確
1.for (var i = 0, j = arr.length; i < j; i++) {
2.// Do something.
3.}
不正確
1.for ( var i = 0, j = arr.length; i < j; i++ )
2.{
3.// Do something.
4.}
也不正確
1.for(var i=0,j=arr.length;i<j;i++){
2.// Do something.
3.}
從 H5BP 開始我們看到了兩個文件， plugins.js 和 script.js。本節概述這兩個文件的基本用法。
Plugins.js 的用處是存放網站的所有插件代碼。相比鏈接到很多不同的文件，我們可以把插件代碼統一放到這個文件里，從而改善性能。這種用法會有也應該有例外。例如，一個超級大的插件，又只是用在一個很少被訪問到的頁面上，放在單獨的一個下載鏈接里就會更好，這樣只會在目標頁面被打開的時候才會被訪問。不過，大部分情況下，直接把所有插件的最小化版本粘貼到這里以便訪問是靠譜的。
下面就是一個樣例文件，包括一個小目錄。它可以作為所用到插件的隨身指南，包括文檔URL，使用它們的思路，諸如此類。
01./* PLUGIN DIRECTORY
02.本文件中出現的插件 [按出場順序排序]
04.1.) Animate Background Position - http://plugins.jquery.com/project/backgroundPosition-Effect
05.2.) jQuery Easing Plugin - http://gsgd.co.uk/sandbox/jquery/easing/
06.3.) jQuery Ajax Form plugin - http://jquery.malsup.com/form/#download
07.4.) jQuery validation plugin (form validation) - http://docs.jquery.com/Plugins/Validation
08.-password strength
09.5.) Styled Selects (lightweight) - http://code.google.com/p/lnet/wiki/jQueryStyledSelectOverview
10.*/
12./**
13.* 1.) Animate Background Position - http://plugins.jquery.com/project/backgroundPosition-Effect
14.* @author Alexander Farkas
15.* v. 1.21
16.*/
17.(function($) {
18.if(!document.defaultView || !document.defaultView.getComputedStyle){ // IE6-IE8
19.//SNIPPED
20.};
21.})(jQuery);
24./**
25.* 2.) jQuery Easing Plugin (we're not using jQuery UI as of yet) - http://gsgd.co.uk/sandbox/jquery/easing/
26.*/
28.// t: current time, b: begInnIng value, c: change In value, d: duration
29.jQuery.easing['jswing'] = jQuery.easing['swing'];
31.jQuery.extend( jQuery.easing,
32.{
33.//SNIPPED
35.});
36.;(function($) {
37.$.fn.ajaxSubmit = function(options) {
38.//SNIPPED
39.}
40.})(jQuery);
42./*
43.* jQuery Styled Select Boxes
44.* version: 1.1 (2009/03/24)
45.* @requires jQuery v1.2.6 or later
46.*
47.* Examples and documentation at: http://code.google.com/p/lnet/wiki/jQueryStyledSelectOverview
48.*
49.* Copyright (c) 2008 Lasar Liepins, liepins.org, liepins@gmail.com
50.*
51.* Permission is hereby granted, free of charge, to any person obtaining a copy
52.* of this software and associated documentation files (the "Software"), to deal
53.* in the Software without restriction, including without limitation the rights
54.* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
55.* copies of the Software, and to permit persons to whom the Software is
56.* furnished to do so, subject to the following conditions:
57.*
58.* The above copyright notice and this permission notice shall be included in
59.* all copies or substantial portions of the Software.
60.*
61.* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
62.* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
63.* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
64.* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
65.* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
66.* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
67.* THE SOFTWARE.
68.*
69.*/
71.jQuery.fn.styledSelect = function(settings) {
72.//SNIPPED
73.return this;
74.};
Script.js 的用處是存放網站或應用的代碼代碼。再次說明，這種方式并不總是最佳解決方案，因為更大的團隊 和/或 規模更大、功能更多的項目可以得益于將應用代碼分解為模塊或功能特性相關的文件。不過，對于較小較簡單的應用，以及最初的原型開發，把所有工作集中到 scripts.js 還是靠譜的。
下面是一個簡化了的例子，用到了 基于標記的低調全面的DOM-ready執行 模式（【譯者注】這里的‘低調’原文是Unobtrusive ，是一種將Javascript從HTML結構抽離的設計概念，避免在HTML標簽中夾雜一堆onchange、onclick……等屬性去掛載Javascript事件，讓HTML與Javascript分離，依MVC的原則將功能權責清楚區分，使HTML也變得結構化容易閱讀。），看起來會類似于這樣：
01./* Name: Demo
02.Author: Demo King */
03./*demo namespace*/
04.demo = {
05.common : {
06.init : function(){
07.//initialize
08.},
09.finalize : function(){
10.//finalize
11.},
12.config : {
13.prop : "my value",
14.constant : "42"
15.}
16.},
17.mapping : {
18.init : function(){
19.//create a map
20.},
21.geolocate : function(){
22.//geolocation is cool
23.},
24.geocode : function(){
25.//look up an address or landmark
26.},
27.drawPolylines : function(){
28.//draw some lines on a map
29.},
30.placeMarker : function(){
31.//place markers on the map
32.}
33.}
34.}
所有的 JavaScript 變量必須寫成全小寫或駝峰法。一個例外是構造器函數，按慣例是首字母大寫。所有CSS里的 id 和 class 聲明都必須只用小寫。不允許用連接符或下劃線。
在分配低調（unobtrusive）的事件監聽器時，通常可接受的做法是把事件監聽器直接分派給那些會觸發某個結果動作的元素。不過，偶爾也會有多個元素同時符合觸發條件，給每個元素都分配事件監聽器可能會對性能有負面影響。這種情況下，你就應該改用事件代理了。
從性能角度考慮，jQuery的 delegate() 優于 live()。
即使采用了最好的校驗器，瀏覽器的怪異性也會不可避免地產生一些問題。有幾個堪稱無價之寶的工具可以幫助優化代碼的健全性和加載速度。很重要的一點是，你手頭準備好了這些工具，不管你主要用來開發的瀏覽器是哪個。我們推薦先在Firefox和Safari上做開發，然后用Google Chrome和Opera，最后針對IE用條件判斷做一些額外的微調。下面列出的是一些有幫助的調試器和速度分析器：
Stoyan Stefanov 的博文包含了以上原則 并有詳細說明（【譯者注】這篇博文值得一看）。
美國政府相關法規508節： 局域網和互聯網信息及應用標準。
— 本公司開發的接口必須符合相關法規508節的要求。
W3C 的易用性檢查點清單。
— 本公司開發的接口必須符合第一優先級指南。
— WCAG 1.0 指南。
當我們持續把web的能力發揮到極致的時候，讓網頁在最小開銷或等待時間下可用依然是同樣重要的問題。下面的章節說明如何優化網頁使用戶滿意。
在生產環境傳輸CSS和Javascript，必須采用很多優化措施：
在頁面加載的時候，通常會有很多腳本等待執行，但你可以設定優先級。下面的順序就是基于用戶反饋設定的優先級：
CSS 精靈（Sprites） 基本上就是把一批圖片資源合并成單個圖片文件。然后每個部分用 CSS background-position 來展現。典型的 CSS 看起來是這樣的
1.a.expandbox { display:block; width: 75px; height: 15px; text-indent: -999px; overflow:hidden;
2.background: url(../img/sprite.png) no-repeat -50px -5px; }
接力 sprites 實現 :hover 懸停效果是很普遍的。這種情況下你會看到類似于這樣的定義：
1.a.expandbox:hover { background-position: -50px -20px; }
使用 sprites 可以減少頁面大小，也減少了HTTP連接數，這會加速頁面加載。 在 css-tricks.com 上有更多總體性的技術和概述。盡可能地利用CSS 精靈總體來說是一項最佳實踐。
除了主要的sprite之外，很多開發者還會使用一個垂直方向的sprite。這個垂直方向的sprite的寬度（以及高度）會小于或等于100px，包含了通常一個挨著一個的圖標，諸如列表元素的著重號或對應功能的鏈接和按鈕。Yahoo 就用到了一些，例如這個。
有個注意事項就是別把sprite弄得太大，不管是高還是寬超過1000px都會導致用掉大量內存。你可以學習一下 使用sprite的時機及內存占用，如果需要了解更多關于創建sprite的總體性提示和技巧，請參閱 Mozilla 開發博客。
你應該會用到四種主要的圖片格式，細節如下：
關于PNG格式、瀏覽器支持以及各種格式優缺點的詳細信息可以在 這篇優秀的文章 中找到。
如需進一步優化所有這些格式，從 Yahoo的 Smush.It 查看圖片可以發現縮小它們的辦法。
對于靜態內容，瀏覽器應該把文件在本地緩存，在合理的前提下，保留盡可能長的時間。應該較長遠期緩存的內容包括：
為了最佳緩存效果，利用http頭部的Expires。下面是一個遠期的Expires頭，它告訴瀏覽器這個響應在2015年5月15日之前都無需更新：
Expires: Thu, 15 Apr 2015 20:00:00 GMT如果你的服務器是Apache，可以使用 ExpiresDefault 指令設置相對當前日期的失效日期。下面的例子設置失效日期為請求時間的一年之后：
ExpiresDefault "access plus 1 year"http頭部的 Expires 必須設為據現在一個月到一年（遠期）之間的值。緩存只適用于那個指定的URL，所以文件名或任何資源的改變都會產生一個新的拷貝。很多開發者使用build過程來給它們的資源增加一個版本號或時間戳。每個隨后的build會開始一個全新的緩存版本，讓你在使用遠期緩存日期時無需擔心。 Google 的這篇文章里有更多關于瀏覽器緩存的細節信息。
靜態內容當然應該由不同于HTML所在服務器的另一個域提供訪問。這是優化的方案，這樣 對所有靜態內容的請求就無需額外的cookies頭。而且為整個域編寫緩存規則也就容易得多了。（同時，當前域的任何子域會繼承當前域的cookies，所以使用全新的域是值得的）。
不過，對于足夠多的資源（特別是圖片），請求數的增加足以讓頁面加載變慢。很多瀏覽器對于他們從每個域能并發下載的資源數有比較低的限制。（在IE6和IE7，這個數字僅僅是2）。在這種情況下，我們可以把資源存放在多個子域，例如：
Google Speed 上更多有關域分片的信息
Iframe 是能添加到指定頁面的各種元素中上開銷最大的一個。它們會阻塞頁面讓它無法觸發onload事件，直到它們加載完成。有時候它們被其他機構用來處理追蹤腳本。例如 Doubleclick floodlight 標簽就是一個 iframe，管理員可以從他們的管理面板向里面增加追蹤像素。在加入iFrame的任何情況下，它應該在window的onload事件被觸發之后再動態加入到DOM中。 更多細節請參閱 Yahoo 的性能站點。
我們推薦在頁面加載完成（DOM ready 事件或 window 的 load事件）之后，再用 Javascript 把 Omniture Javascript 代碼加入DOM中。通過使用這個技術，可以避免外部域腳本的依賴性，這種依賴性會減慢（并可能掛起）頁面加載過程。
在所有情況下， Flash 的位置必須有備選的HTML內容，以使SEO值最大化。對于 XML 驅動的 Flash，備選 HTML 內容必須利用同一個 XML 文件，以確保數據的一致性。
所有替換內容必須使用 SWFObject ，但不應加入內聯腳本標簽。 SWFObject 的初始化必須在 DOM Ready 事件后觸發。最小的播放器版本必須設置為最小 v9，以確保 AS3 兼容性。
談到瀏覽器體驗，有兩個主要的事實：
那么，基于這兩條人生真諦，我們需要通過什么樣的步驟讓大家滿意呢？
這些指標必須針對你的客戶和項目來定制，在線框圖布局階段之前完成。這些目標從技術角度必須是合理的，也是可測試的。
可能適用的一些目標
對于加載時間的目標，定義基準系統是很重要的。類似于 PageTest 的工具是個好的選擇。另外，目標也可以分開多個頁面來定義，例如：訪問量最大的兩個目標網頁（比如主頁和支持頁面）。
如果客戶對于意向設計有比合理目標更激進的目標，就必須在整個項目決策委員會中統一期望值，并讓項目組了解性能指標是最關鍵的。
內部
在 IA、IxD 和視覺設計階段，前端工程師是負責溝通性能對于交互特性的影響或在目標瀏覽器上采用特定的視覺技術的角色。要給出設計師的限制條件：“如果我們使用Cufon，每個頁面上用到定制字體的元素就不能超過10個。”
外部
需要設定期望值： 并不是所有的瀏覽器都有相同的體驗。它們的表現不會彼此相同，指望它們的特性完全一樣也不現實。在IE7的體驗中放棄一些新的特性也許是合理的。會考慮被放棄的一些特性可能是： 陰影、過渡、圓角、透明度、漸變色。
當溝通某件事的影響時
選擇那些性能優化的庫和插件。基于性能目標做出明智的架構決定。同時在可能的前提下盡量減少 DOM 操作，設計樣式要讓頁面在加載和初始化的時候 避免視覺變化 。
QA 團隊也應該把性能相關的因素和視覺、功能和可用性問題放在一起來確定優先級。開發者和 QA 必須確定如何分配優先級。在 QA 過程中，成功的指標必須定期測試。
測試用的工具
如果性能指標沒有達到，有三個選擇：
我們認為，通過這個方法，在應對性能挑戰的過程中，項目相關各方都有更好的機會統一期望，共同前進，并形成更加行之有效的工作流程。
今天的用戶可以從相當大的范圍中選擇web瀏覽器，每種瀏覽器都提供了略微（或相當）不同的體驗。作為開發者，我們的責任恰恰是選擇我們創建的網頁展示給用戶的方式。本節描述我們是如何做出這當中的一些決定的。
Isobar 支持任何 Yahoo 瀏覽器支持分級 中列出的A級瀏覽器，除了Opera之外。對此也可能會有其他的例外，基于地區市場和它們特定的指標。
我們會努力支持任何客戶指定的其他任務關鍵瀏覽器 (IE 5.5, Opera, Konqueror, Safari 3 on PC, 等等)，雖然我們不能保證所有功能都可能實現。
全面的瀏覽器測試對于每個web項目都是必須的。必須付出大量精力進行跨瀏覽器和平臺測試，以確保質量和一致的用戶體驗。配置測試環境會是一項挑戰，卻是值得去做的。
由于不可能在一臺PC上安裝多于一個IE瀏覽器，IE的測試是個挑戰。幸好微軟最終提供了老版本IE的開發版下載。這些運行拆解版Microsoft Windows的虛擬磁盤時不時地失效（過期）。通常隔幾個月就需要重新設置它們。從你的MSD版權（如果有）獲取的Microsoft Windows開發版也會是一個選擇，取決于你能夠獲取到的東西。
此外，其他不是那么有效的IE測試選項（通常是不推薦的）包括了 IETester，它還是好于 Multiple_IE 和 IE7 standalone。
Google Chrome 會自動更新，正常情況下絕大部分用戶都會有最新版本。要是每種瀏覽器都這樣多好啊。對于Google Chrome就不需要擔心舊版本的問題了。
對于核心的Mac OSX 瀏覽器，Mozilla Firefox, Google Chrome和Apple Safari 提供的瀏覽體驗基本和它們的Windows版本一樣。盡管如此，某些操作系統級的差異還是會出現，網站必須在兩個平臺上進行測試。典型的差異是關于字體渲染，所以有時候會冒出間距問題。
在 Mac OSX 上測試基于Windows的瀏覽器有幾種選擇。首先，Mac 提供了一個 "boot camp" 分區，它允許你在Mac 上啟動一個Microsoft Windows分區。這是一個復雜但完整的測試環境。一旦你用Windows啟動，就可以用通常 Windows 環境下的測試方法。
其他選擇包括在 Mac OSX 內部虛擬化 Windows，讓你可以在Mac OS內部運行Windows。
Microsoft 虛擬磁盤 在這里的大部分選擇中是可以打開或轉換的，這樣就能在一定程度上利用Windows 用戶可以用到的那些測試方法。即使你也可以同時在Mac上測試，有些人還是會認為這樣更加靈活...
正如在Windows 上一樣，你可以在一臺Mac 上安裝和運行 Mozilla Firefox 的多個拷貝，雖然通過配置管理器設置多個配置更為復雜一些。盡管如此，你可以通過一些小技巧，通過Automator程序創建分開的配置并順利運行它們。
注意：IE6 standalone 版在某些情況下對透明度的實現是有bug的。這會導致任何應用于CSS 過濾器的透明度（例如alpha透明度或者24位PNG）失效。在這種情況下必須測試透明度，你會需要本地安裝的IE6。
還有人發現安裝在Vista 平臺上的IE7 和Windows XP 上的IE7 確實有差異，所以，你可能會希望確保團隊中的某個人也有這種配置。IETester 修復了一批這樣的問題，和Xenocode 瀏覽器的做法類似。
除了適應各種瀏覽器，開發者還必須持續注意用戶的屏幕分辨率。隨著顯示器屏幕越來越大，分辨率的廣度也隨之增加。下面是關于分辨率的一些工作準則。
1024px 分辨率
關于窗口大小的當前統計
不過，系統分辨率和瀏覽器尺寸并不是一樣的
良好的web設計和開發的一個重要部分就是SEO 。要想確保一個網頁不僅能讓搜索引擎合適地索引到，而且能讓那些只有有限的web能力的人訪問到，結構良好的代碼是其中的關鍵。
你必須使用語義化的標記，在關閉 Javascript 和 CSS 之后它仍然是可讀和邏輯的。所有頁面內容必須是HTML 形式；我們不希望使用iframe 或 Javascript 來加載初始的可索引內容。
所有鏈接都必須指向 HTML
1.<a href="/shelf/jordan/page/2">
而不是這種
1.<a href="javascript：loadPage(2);">
這樣既能被搜索引擎正確索引，也能讓用戶在新窗口或新標簽中打開鏈接。
每個頁面的 title 標簽應該突出目標關鍵字。每個頁面的 title 應該是獨特的。標題（h1,h2,等等）應該構成文檔的輪廓并代表該頁面最重要的關鍵字。URL 應該是人類可讀的，其中包含主要的目標關鍵字：
http://domain.com/mens-shoes/basketball/jordan/jordan-mens-ajf-6-basketball-shoe/vs
http:// domain.com/ecomm.cfm?view=prod&prodId=23425總是為 flash 使用備選HTML 內容。所有廣告促銷圖片應該使用基于 CSS 的替代圖片而不僅僅設定 alt 屬性。
>對不支持flash 版本的應變
1.<a href="/nike/morethanagame/" id="morethan">
2.<h4>Nike: More Than A Game</h4>
3.<h5>Experience the movement and view apparel</h5>
4.</a>
1.a#more than { background:url(/promos/nikegame.jpg) no-repeat; width: 200px; height: 100px;2.text-indent: -999px; overflow:hidden; display:block; }
Google 的 SEO報告卡 是給 Google 的產品團隊提供關于通過簡單易接受的優化改進他們的產品頁面的思路的一項措施。這些優化手段不僅僅是為了幫助搜索引擎更好地理解他們頁面的內容，也是改進他們的用戶體驗。
訪問他們的站點時，諸如修復404錯誤和無效鏈接、簡化URL 選項、提供易于理解的標題以及頁面摘錄等簡單的步驟，其實對用戶和搜索引擎都是有利的。
代碼審查是確保系統質量和用戶體驗的正式流程中的基石。這涉及到召開一個由標記編寫者、審查者和其他相關人員參加的會議，在會上提交有關材料，產生后續的代碼修改要求。簡單地說，我們鼓勵進行代碼審查，磨刀不誤砍柴工嘛。
為啥俺要參加代碼審查涅？
代碼審查是用于降低項目風險的戰略性時間投資。
經常地，接口開發者被要求根據線框圖或視覺構圖編寫標記。不過，有可能設計的屏幕不能輕易轉換為標記，或者轉換后質量有損失。代碼審查為在頁面投入生產之前發現并解決這些風險提供了一個機會。
代碼審查能夠提升跨項目的整體知識水平
既然代碼審查涉及到項目內外的成員，這有利于在整個團隊中分享技術和最佳實踐。
代碼審查能在bug從一些模板繁衍到多個頁面之前就封殺它們
理想情況下，代碼審查是在開發過程的早期進行的，早于頁面開始全面投入生產。當模板被團隊審查并在多個校驗工具和瀏覽器運行，潛在的bug就會冒出來。這是修復bug的理想時機。
代碼審查給不熟悉項目的外部成員提供了發現代碼中問題的機會
項目外部的審查者比在代碼上工作了更長時間的標記編寫者更容易發現問題。
哪些人應該參加代碼審查？
歸根到底，項目的前端工程主管要負責確保代碼審查遵循合適的流程。
理想情況下，一位部門主管應該作為代碼審查的主持人，除非部門主管自己正好是被審查代碼的接口開發者。在這種情況下，由一位項目經理進行主持。
審查小組應該包括至少兩位來自接口技術團隊精通開發和最佳實踐的資深成員。
代碼審查中有哪些要求？
在進行代碼審查之前，需要審查的模板必須整體完成開發、經過校驗、并針對項目需要用到的瀏覽器和平臺進行了測試。
部門主管 和/或 接口開發者必須在代碼審查前至少48小時 分發以下材料：
很典型的情況是，直到代碼審查進行之前，代碼還在不斷地修改。不幸的是，這樣就沒有足夠的時間來校驗和測試了。如果這種情況發生了，最好是重新安排代碼審查的時間以確保其效果。
另外，部門主管 和/或 接口開發者應該預定一間會議室和電話會議號碼并提供給所有參與者，因為有可能某些項目組或審查組成員不在現場。用一個小時來審查兩三個模板應該足夠了；不過，需要的時間也隨模板的大小和復雜度而不同。
在代碼審查過程中，一位部門主管 和/或 接口開發者應該主持會議，而部門主管或項目經理做記錄并分配行動事項。審查者應該在事前審閱過代碼并準備好提問或提供反饋意見。
記錄和行動事項（包括負責人）應該在代碼審查后分發給所有參與者。如果代碼審查產生了本質性的變更，或沒有完成對所有代碼的審查，就有必要安排第二次代碼審查。不過，這必須在項目組內討論以確定其可行性。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
