整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
誰敢說自己沒用過省市區(qū)選擇的？沒有吧，這就證明了其地位。
準備工作：
{
path: '/area',
name: 'area',
component: ()=> import('./views/Area.vue')
}
<a href="javascript：void(0)" @click="$router.push('/area')">
<van-col span="6" class="marb20">
<van-icon name="location" />
<div>Area省市區(qū)</div>
</van-col>
</a>
至今為止呢，我們的首頁顯示的樣式子是這樣滴?不知道不覺間我們已經(jīng)學完了12個組件了！哇噢，為自己歡呼一下吧！如果想看更多的內(nèi)容，歡迎關(guān)注我，每天都有更新哈。
代碼演示Area 省市區(qū)選擇：
Area省市區(qū)選擇同樣不能自動彈出，需要與彈出層結(jié)合使用，與DatetimePicker組件有些類似。有些不同的地方是，Area需要引入完整數(shù)據(jù)。官網(wǎng)上有完整數(shù)據(jù)，可以自行下載。需要將這個數(shù)據(jù)保存成area.js。將這個文件保存在根目錄下，在js中首先引入這個數(shù)據(jù)：
import areaList from '../../areaList.js'
Area省市區(qū)選擇的基本用法：
<van-field v-model="myAdress" label="請輸入省市區(qū)" placeholder="請輸入省市區(qū)" @focus="onClick" /> <van-popup v-model="isShow" position="bottom"> <van-area :area-list="areaList" /> </van-popup>
area接收一個area-list屬性，這個屬性是省市區(qū)數(shù)據(jù)。就是我們剛剛引入的數(shù)據(jù)。data里如下：
data() {
return {
isShow: false,
myAdress: '',
areaList: areaList
}
},
與DatetimePicker組件一樣，也有comfirm, cancel, change事件。我們拿confirm事件來做實例，confirm確定后返回數(shù)據(jù)格式為一個數(shù)組，數(shù)組內(nèi)包含所有顯示列的數(shù)據(jù)，每一組數(shù)據(jù)對應每一列的code和name：
如果將所選的輸入框顯示在頁面上，需要循環(huán)數(shù)組得出每一列的name值，再拼接成省市區(qū)返回：
confirm(value) {
let name=''
value.forEach((item)=> {
name +=item.name + ' '
this.myAdress=name.trim()
return this.myAdress
})
this.isShow=false
},
我們的省市區(qū)就顯示在輸入框里了。如果想改變默認值，需要修改其組件的value值。只要定義其值是code值。
今天就到這里啦。休息休息一會兒吧?明天繼續(xù)加油噢！加油
言：在各類網(wǎng)站論壇上,沒有找到與工作比較貼切的技能,所以特此寫一些對剛步入工作或者工作中沒有重視的技能與問題,各位大牛請及時關(guān)閉文章.
ps：即使你是一個后端工程師,前端必備技能的學習一樣很重要,雖然我不是特別牛逼的前端,但常用的前端知識還是略懂一二的,我的文章內(nèi)容是希望讓已經(jīng)步入工作但尚未"修煉升仙"的同學們得到一些幫助,純屬個人原創(chuàng)見解,若不正確,請各位批評指正.
HTML4常用標簽
標題圖
為什么不介紹HTML5標簽呢,因為呢,我們現(xiàn)在工作中所做的項目還需考慮兼容性問題,目前還沒有完全普及HTML5,所以我們還是把HTML4中的常用標簽熟悉起來才是重中之重
下面我根據(jù)功能分類介紹常用的標簽(我只介紹沒有兼容性問題的并且十分常用的標簽,非常用標簽一律不介紹,我相信工作中你也用不到)
基礎(chǔ)標簽示例
上圖代碼的效果圖如下:
效果圖
總結(jié)基礎(chǔ)標簽:
html:我們頁面的總包商
head:頭部定義一些總體內(nèi)容,比如瀏覽器標題,編碼格式,樣式文件引用
title:定義瀏覽器標題
meta:定義關(guān)于 HTML 文檔的元信息,諸如例子中的編碼格式,IE渲染模式(可以解決大部分IE兼容問題)
link:鏈接外部資源,如上圖中鏈接瀏覽器標題旁的小圖標,也經(jīng)常用來鏈接css樣式文件
style:在標簽內(nèi)定義css樣式
body:我們?nèi)庋劭吹降膬?nèi)容顯示區(qū)域
script:在標簽內(nèi)定義js代碼
br:換行符
h1~h6:不同字體大小的標題標簽(塊元素,什么是塊元素?下篇文章詳細介紹)
p:段落標簽(塊元素)
hr:水平分割線(塊元素)
了解了基本元素,你就已經(jīng)可以畫一個簡單網(wǎng)頁了,但網(wǎng)頁可能很單調(diào),所以請繼續(xù)閱讀
格式標簽
上圖代碼的效果圖如下:
效果圖
總結(jié)格式標簽:
b:字體加粗(行元素,什么是行元素?下篇文章詳細介紹)
strong:字體加粗,同b標簽(行元素)
blockquote:引用標簽,如果你的頁面中需要引用一些文章內(nèi)容時,使用該標簽(塊元素,細心的同學已經(jīng)發(fā)現(xiàn)了塊元素與行元素的一點區(qū)別了)
del:刪除標簽,標記廢除的內(nèi)容,通常用來標記原價,而優(yōu)惠價則正常顯示(行元素)
ins:下劃線填寫標簽,標記可變的內(nèi)容,或需要輸入的內(nèi)容(行元素)
em:斜體標簽,用來強調(diào)(行元素)
i:斜體標簽,同em(行元素)
看到這里,說明你確實想好好學習html,小編已經(jīng)將工作常用的標簽都羅列了出來,所以你不再需要通篇的閱讀w3c中的內(nèi)容,有了對格式標簽的了解,你就可以編寫一個攜帶樣式的網(wǎng)頁了,但你的網(wǎng)頁可能缺少與用戶的交互,那么請繼續(xù)堅持閱讀下去吧
表單標簽
上圖代碼效果圖如下:
效果圖
總結(jié)表單標簽:
form:表單包裹標簽,里面的內(nèi)容一般都是表單元素,通常結(jié)合table一并使用(塊元素)
table:表格標簽(table比較特殊,單獨屬于table元素,效果與塊元素差不多)
thead:表格頭部
tbody:表格主體內(nèi)容部分
tr:表格行
th:表格單元格,一般用于顯示標題,默認加粗樣式
td:表格單元格,一般用于存放信息或輸入框
input:各類表單輸入元素,如上圖中的輸入框,單選框,復選框,隱藏的輸入框以及按鈕(行元素)
select:下拉框,比如用于選擇省市區(qū),民族等(行元素)
textarea:多行輸入框,一般提供給用戶輸入簡介,理由,多行文本等(行元素)
label:表單的提示信息,一般還用于包裹單選框,復選框使用,讓用戶點擊文字也能實現(xiàn)勾選,即點擊上圖中的男,女文字一樣可以勾選文字前面的勾選框(行元素)
學會了表單元素,我們就可以與用戶互動了,讓用戶能夠在我們網(wǎng)頁中輸入信息以及點擊按鈕,但我們的網(wǎng)頁還不夠豐富,我們繼續(xù)介紹其他常用的標簽
下面我們把其他常用的標簽一并進行介紹
其他標簽示例
上圖代碼效果圖如下:
效果圖
1.圖像
img:圖片標簽,這個很簡單,就是引用一個圖片資源進行展示,如上圖展示百度的圖片(行元素)
2.鏈接
a:超鏈接標簽,點擊a標簽包裹的內(nèi)容,即可跳轉(zhuǎn)到我們事先定義的網(wǎng)絡(luò)路徑,如上圖中點擊百度圖片則可跳轉(zhuǎn)到百度的網(wǎng)址(行元素)
3.列表
ul:無序列表標簽,內(nèi)部只能是li標簽(塊元素)
li:列表項內(nèi)容標簽,包裹在ul中
dl:全稱definition list,定義列表,即有一個標題,有一些解釋信息的標簽,如上圖中的北京是標題,下面兩行是解釋(塊元素)
dt:結(jié)合dl標簽,一般用于顯示標題
dd:結(jié)合dl標簽,一般位于dt下面,用于解釋dt包裹的標題內(nèi)容
可能有同學會問:還有個有序列表呢,我想說:有序列表實在太丑,已經(jīng)被淘汰,所以小編只介紹我們工作中可能用到的標簽,不常用以及不推薦使用的標簽不作為本文重點
ul與dl的應用場景區(qū)別:
總的來說:
ul適合樣式類似的列表,如導航欄,新聞列表等場景,如下圖:
ul場景
dl適合有一個標題的列表場景,如下圖:
dl場景
4.通用標簽
div:最典型并常用的塊元素
span:最典型并常用的行元素
這兩個最常見的元素,小編最后才介紹是有深意的,正因為他們經(jīng)常用,所以我們更需要了解其他的標簽,而不是一味的使用這兩個標簽實現(xiàn)所有的頁面展示效果,我們應該使用最合適的標簽展示對應的效果,這也是為什么上面著重介紹了ul與dl標簽
結(jié)尾總結(jié):
由淺入深的理解與熟悉小編列出的所有常用標簽,如有缺失,請留言評論
認真琢磨各標簽的應用場景,而非全部使用div與span(這樣才不枉費小編的辛苦總結(jié),哈哈)
自isobar
概述
本文檔包含了Isobar公司的創(chuàng)意技術(shù)部（前端工程）開發(fā)web應用的規(guī)范。現(xiàn)在我們把它開放給任何希望了解我們迭代過程最佳實踐的人。
編寫本文檔的主要驅(qū)動力是兩方面： 1) 代碼一致性 以及 2) 最佳實踐。 通過保持代碼風格和傳統(tǒng)的一致性，我們可以減少遺留系統(tǒng)維護的負擔，并降低未來系統(tǒng)崩潰的風險。而通過遵照最佳實踐，我們能確保優(yōu)化的頁面加載、性能以及可維護的代碼。
前端開發(fā)核心思想
對于所有編程語言，我們要求縮進必須是軟tab（用空格字符）。在你的文本編輯器里敲 Tab 應該等于 4個空格 。
對于維護現(xiàn)有文件，我們認為可讀性比節(jié)省文件大小更重要。大量空白和適當?shù)腁SCII藝術(shù)都是受鼓勵的。任何開發(fā)者都不必故意去壓縮HTML或CSS，也不必把Javascript代碼最小化得面目全非。我們會在服務(wù)器端或build過程中自動最小化并gzip壓縮所有的靜態(tài)客戶端文件，例如CSS和JS。
任何網(wǎng)頁的首要組件就是基于標簽的HTML標記語言。超文本標記語言 (HTML) 曾有一段不堪回首的歷史，但最近幾年已經(jīng)是 皇 上 回 宮 了。經(jīng)過對它基于XML的XHTML變種的漫長試驗之后，整個行業(yè)終于接受了HTML代表web的未來這一事實。
標記定義了文檔的結(jié)構(gòu)和綱要，并提供結(jié)構(gòu)化的內(nèi)容。除了最基本的概念（例如標題、段落和列表）之外，標記并不是用來定義頁面上內(nèi)容的外觀和體驗的。HTML的表現(xiàn)屬性都已經(jīng)被廢棄了，有關(guān)樣式的定義應該被包含在 樣式表 中。
HTML5 是HTML 和 XHTML 的新版本。 在 HTML5 草案 的規(guī)范中定義了可以用 HTML 和 XML編寫的單一的語言，意在解決在之前HTML的迭代中發(fā)現(xiàn)的一些問題并滿足web應用的需求，這是以前HTML沒有充分覆蓋到的領(lǐng)域（來源 ） 。
在合適的時候，我們會使用HTML5 Doctype 和 HTML5 特性。
我們會對照 W3C 校驗器 測試我們的標記，以確保標記是結(jié)構(gòu)良好的。我們的目標并不是100%的合法代碼，但是校驗肯定對于編寫可維護的站點以及調(diào)試代碼都大有幫助。 Isobar公司不保證代碼都是100%合法，而是確信跨瀏覽器體驗會相當一致 。
對HTML5文件，我們使用 H5BP 針對我們自己項目需求修改的一個分支。 你也可以從這里Fork H5BP。
標記中必須總是使用合適的Doctype來指示瀏覽器觸發(fā)標準模式. 永遠要避免Quirks模式。
HTML5特別好的一個方面就是它簡化了Doctype需要的代碼。無意義的屬性被棄用了，DOCTYPE 聲明也被顯著地簡化了。另外，也無需再用 CDATA 對內(nèi)聯(lián)JavaScript代碼進行轉(zhuǎn)義，而這在此之前為了讓XHTML符合XML的嚴密性是必需的。
HTML5 Doctype
1.<!DOCTYPE html>
所有標記必須通過UTF-8編碼傳遞，因為這種編碼方式是對國際化最友好的。必須在HTTP的header和HTML文檔的head部分都指定這種編碼。
設(shè)定字符編碼是通過 <meta> 標簽進行。
1.<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
如果是HTML5，則只需要寫：
1.<meta charset="utf-8">
下面是編寫HTML標記的總體原則。提醒大家一點，在創(chuàng)建的HTML文檔里總是要使用能夠代表內(nèi)容語義的標記。
在HTML5規(guī)范里并沒有嚴格要求屬性值兩邊加引號。但考慮到一些屬性可以接受空白值，為了保持一致性，我們要求所有屬性值必須加上引號。
1.<p class="line note" data-attribute="106">This is my paragraph of special text.</p>
網(wǎng)頁的第二個組件就是在層疊樣式表（CSS）中包含的表現(xiàn)信息。Web瀏覽器成功實現(xiàn)CSS后，整整一代web開發(fā)者對他們網(wǎng)站的外觀和體驗擁有了全部的控制權(quán)。
正如網(wǎng)頁信息在語義方面由 HTML 標記 描述， CSS 從表現(xiàn)方面則是通過對視覺屬性的定義來描述網(wǎng)頁。 CSS 的強大之處在于，這些屬性可以混合并通過各種標示符匹配，它可以通過樣式規(guī)則的分層（”層疊“）來控制頁面的布局和視覺特征。
深入學習和理解CSS及基于瀏覽器的盒子模型，對于掌握CSS布局的基礎(chǔ)是非常必要的。
3D CSS 盒子模型示意圖， 由 Jon Hicks 繪制。
我們一般不用 W3C 校驗器。
最低要求：選擇器單獨占一行，每個屬性占一行。屬性聲明要有縮進。
作為提高的要求，關(guān)聯(lián)或孩子樣式要增加2-4個空格的縮進。這樣有利于分層查看和組織，產(chǎn)生（對某些人來說）可讀性更好的樣式表。
另外，在給一個樣式指定多個選擇器的時候，把每個選擇器單獨放一行是個好主意。這樣可以避免一行變得太長，也能提高可讀性及版本控制流程。
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.}
在多個開發(fā)者協(xié)作環(huán)境下，避免用單行CSS格式，因為這樣會給版本控制帶來問題。
如果你對性能情有獨鐘， 對CSS屬性進行字母排序有利于在GZIP壓縮中識別大量可重復的特征。
對于所用的樣式只出現(xiàn)一次的元素，給它設(shè)一個id屬性。這個屬性只會應用于該元素，不會用到其他地方。Class屬性則可以用到多個具有相同樣式屬性的元素上。具有相同外觀和表現(xiàn)的元素可以具有相同的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，對任何東西最好總是根據(jù) 它是什么 而不是 它看上去是什么樣子 來命名。 比如一個頁面上的特別提示的 class 名是 bigBlueText （大藍字），可它的樣式早就被改成紅色小字體，這個名字就沒意義了。使用更聰明的慣例如 noteText （提示文字）就好多了，因為即使視覺樣式改變了，它也還是管用的。
CSS3 選擇器 規(guī)格引入了一整套對于更好地選擇元素極其有用的 CSS 選擇器。
偽類 使你能動態(tài)地修飾網(wǎng)頁內(nèi)容的樣式。有些偽類從CSS1 （:visited, :hover等） 和 CSS2 （:first-child, :lang）那時候開始就有了。CSS3又往列表里加入了16個新的偽類，這些偽類對于動態(tài)地修飾網(wǎng)頁內(nèi)容的樣式特別有用。 學習如何深度使用偽類。
組合選擇器 提供了為特定元素選擇其后代元素、孩子元素或兄弟元素的快捷方式。
屬性選擇器 適用于具有特定屬性 和/或 特定值的元素。正則表達式的知識對屬性選擇大有幫助。
瀏覽器會通過 計算選擇器的明確度 來決定應用哪個CSS規(guī)則。如果兩個選擇器都適用于同樣的元素，具有更高明確度的那個會勝出。
ID 選擇器比屬性選擇器明確度高，class 選擇器比任何數(shù)量的元素選擇器明確度高。盡量使用 ID 選擇器來提高明確度。有時候我們可能會想方設(shè)法給一個元素應用一條CSS規(guī)則，但用盡方法也不能如愿。這種情況有可能是因為我們使用的選擇器比另外一個的明確度低，所以明確度高的另一個選擇器里的屬性就比我們想應用的選擇器優(yōu)先了。這種情況在更大或更復雜的樣式表里更為常見。在小一些的項目里，通常這不是大問題。
當你在一個很大很復雜的樣式表上干活的時候，知道如何計算選擇器的明確度會有很大幫助，會節(jié)約你的時間，并讓你的選擇器更有效率。
明確度的計算方式是對你的CSS的各種組件計數(shù)，并用 (a,b,c,d) 格式表達出來。
不過，也許使用現(xiàn)成的明確度計算器更好一些。
使用 !important 會覆蓋掉所有的明確度，不管它有多高。因此我們傾向于避免使用它。大部分時候是沒必要用它的。即使你需要覆蓋某個你訪問不到的樣式表里的選擇器，往往也會有其他的辦法去覆蓋。盡可能避免使用它。
我們使用 px 作為定義 font size 的度量單位，因為它能提供對文本的絕對控制。我們知道為字體大小使用 em 單位一度很流行，這樣可以解決 IE6 無法改變基于像素的文本大小的問題。不過，現(xiàn)在所有的主流瀏覽器（包括 IE7 和 IE8）都支持基于像素單位的文本大小 和/或 整頁縮放。既然 IE6被廣泛認為已廢棄，用像素定義文本尺寸更好。另外，無單位的 line-height 也應該優(yōu)先考慮，因為它不會從父元素繼承一個百分比值，而是基于 font-size 的一個乘數(shù)。
正確
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，讓部署一拖再拖。雖然我們鼓勵排除問題，產(chǎn)出無需打補丁就能在所有瀏覽器上運行的代碼，有時候為了在樣式表中使用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]-->
一般情況下要優(yōu)先使用CSS速記格式，一是因為它的簡潔，二是用它也可以擴充已有的值，例如margin和padding的情況。 開發(fā)者必須注意TRBL 縮寫，它表示元素的各邊按順時針方向定義的順序：上、右、下、左。如果bottom沒有定義，它就會從top繼承值。同理，如果left未定義，它從right繼承值。如果只有top的值有定義，所有的邊都會繼承那一個值。
下面是關(guān)于減少樣式表代碼冗余和使用CSS速記格式的更多內(nèi)容：
近些年來越來越流行使用web上的定制字體和字型。隨著本地瀏覽器對其支持度的攀升，以及一些支持它的服務(wù)和API的出現(xiàn)，這個領(lǐng)域發(fā)展的勢頭很猛。這些方法都各有利弊。項目啟動前最好是在技術(shù)和版權(quán)限制方面先做一些研究，以便為特定項目選擇合適的方法。
所有這些方法都有代碼開銷、開發(fā)時間和性能（時間計算和用戶感受）的不足。你需要熟悉這些問題，并和團隊成員及用戶溝通，這樣會減少項目后期的大量問題。
下面列出一些內(nèi)嵌定制字體的流行手段，按我們實施時的優(yōu)先級排序。
@font-face 規(guī)則 允許你自定義字體。它最早是在CSS2 規(guī)范里定義的，但從CSS2.1被刪除了。現(xiàn)在，它是CSS3草案中的推薦稿。
對于web定制字體，我們的首選和最偏愛的選擇都是 @font-face ，就是因為它被列入了CSS字體模塊工作草案的一部分，這意味著它會隨著瀏覽器支持的提升變得越來越流行，并且隨著它不斷改善變得更穩(wěn)定，使用起來也更簡單。
就現(xiàn)在而言，使用 @font-face 的時候，建議為每種字體格式定義它的source。這很重要 -- 如果你想讓它在大多數(shù)瀏覽器中有效 -- 雖然這不是使用它的必要條件。
在規(guī)范中包括的字體格式有：
為了實現(xiàn)完全的瀏覽器兼容性，可以使用 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.}
這里有一個使用上述技術(shù)實現(xiàn)的 演示 。
Safari, IE 6-9, IE 9 兼容模式, Firefox, Chrome, iOS, Android, Opera
有時候 IE 會在用戶不知道的情況下自作主張切換到兼容模式。要阻止你的站點缺省進入兼容模式，可以在站點的<head> 部分加入下列代碼：
1.<meta http-equiv="X-UA-Compatible" content="IE=edge">
優(yōu)點
不足
使用 Google Webfonts 有兩套可選方案。這兩套方案當然也各有其弊端，但它們也可以用得和 @font-face 一樣好，這全取決于項目的需要。
Google的 Webfonts API 本質(zhì)上和 @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，這就是為了便利付出一些其他的犧牲了。
優(yōu)點
不足
如果你選擇使用 Cufon，我們強烈推薦你使用 Cufon 壓縮版。你會需要用 生成器 來轉(zhuǎn)換你的字體。
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 ，因為如果應用到大量的文本上，它會產(chǎn)生很多開銷。訪問 Cufon Wiki可以獲取更多相關(guān)信息。
優(yōu)點
不足
當選擇給網(wǎng)站添加定制字體的時候，使用 Typekit 有它不容忽視的優(yōu)勢。它具備很強的平臺集成，并且是可擴展和流行的服務(wù)。 它可以和 Google Webfonts 一起使用，并且易于加入到以 WordPress, Posterous, Typepad, 和其他類似的 CMS 實現(xiàn)的網(wǎng)站上。
但是，要完整地應用 Typekit 也不是無本生意。如果你需要把它用到超過2個站點，或用在一個瀏覽量很高的站點上，你需要每年付49.99美元費用，對于百萬以上瀏覽量的站點費用會加倍。不過，如果你的網(wǎng)站有這么大瀏覽量，對這點成本你應該是不差錢的。如果不是這樣，你可能需要重新考慮你的商業(yè)模式了。
優(yōu)點
不足
我們不推薦使用這種方法，但是因為它的廣泛使用，我們覺得還是有必要介紹它，以便你在選擇定制web字體方法時做出胸有成竹的決定。
即使它在web設(shè)計師中廣為流行，而且它在大多數(shù)瀏覽器中也有很好的支持，使用它的缺點還是大過它的便利性。 棄用 sIFR 的最大也是最明顯的原因是它需要使用Flash這一事實。而且，即便是為了讓Flash正常工作就需要 JavaScript，而且在你使用此方法渲染的文本能在頁面上可見之前，相關(guān)的腳本必須都先被加載。更不用說，它會增加頁面加載時間，并會讓一個慢網(wǎng)站變得更慢。
我們會讓你對這些問題算算細賬。
優(yōu)點
不足
即使你可以把任何字體轉(zhuǎn)換為web字體文件，你還是應該確認這樣做是否合法。很多廠商更新了他們關(guān)于字體在web上使用的條款。查看 字體版權(quán)和保護的細則 獲取更多信息。
利用CSS3規(guī)范中增加的特性，你可以做很多新奇的事情，不過里邊很多新特性還沒有得到所有主流瀏覽器的完全支持。不過這也不是說它們現(xiàn)在就不能用。對于這些支持不好的特性，有一些回退的庫可用，或者有一些其他補丁，用來填補在瀏覽器對新特性缺乏支持時出現(xiàn)的空白。
還有一些瀏覽器特定的屬性或前綴也可以用來修飾樣式。為跨瀏覽器支持起見，我們推薦使用 Prefixr.com 來確保你加入了所有針對不同瀏覽器的前綴屬性。
JavaScript 是網(wǎng)頁的第三個主要部件。在網(wǎng)頁上適當?shù)貞肑avaScript 代碼，通過綁定事件和控制整體行為層，能夠增強整體的用戶和基于瀏覽器的體驗。
隨著功能強勁的新瀏覽器撐起基于瀏覽器的完整web應用，JavaScript 在近年的流行度爆棚。另外，對Javascript的細致運用為全面操控另外兩個部件 -- HTML 標記 和 CSS -- 提供了手段。現(xiàn)在，在無需刷新整個頁面的情況下，頁面結(jié)構(gòu)和頁面視覺樣式都可以被實時操控。
我們開發(fā)新應用主要會用到 jQuery，不過我們對原生 JavaScript 和所有現(xiàn)代 javascript 庫也具有專業(yè)經(jīng)驗。
總的來說，使用留空應該遵循源遠流長的英語閱讀慣例。 例如，每個逗號和冒號（以及適用的分號）后面要空一格，但在括號內(nèi)部的左側(cè)和右側(cè)都不要加空格。另外，大括號應該總是和他們前面的參數(shù)出現(xiàn)在同一行。
來看看下面的 JavaScript for循環(huán)的例子...
正確
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。本節(jié)概述這兩個文件的基本用法。
Plugins.js 的用處是存放網(wǎng)站的所有插件代碼。相比鏈接到很多不同的文件，我們可以把插件代碼統(tǒng)一放到這個文件里，從而改善性能。這種用法會有也應該有例外。例如，一個超級大的插件，又只是用在一個很少被訪問到的頁面上，放在單獨的一個下載鏈接里就會更好，這樣只會在目標頁面被打開的時候才會被訪問。不過，大部分情況下，直接把所有插件的最小化版本粘貼到這里以便訪問是靠譜的。
下面就是一個樣例文件，包括一個小目錄。它可以作為所用到插件的隨身指南，包括文檔URL，使用它們的思路，諸如此類。
01./* PLUGIN DIRECTORY
02.本文件中出現(xiàn)的插件 [按出場順序排序]
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 的用處是存放網(wǎng)站或應用的代碼代碼。再次說明，這種方式并不總是最佳解決方案，因為更大的團隊 和/或 規(guī)模更大、功能更多的項目可以得益于將應用代碼分解為模塊或功能特性相關(guān)的文件。不過，對于較小較簡單的應用，以及最初的原型開發(fā)，把所有工作集中到 scripts.js 還是靠譜的。
下面是一個簡化了的例子，用到了 基于標記的低調(diào)全面的DOM-ready執(zhí)行 模式（【譯者注】這里的‘低調(diào)’原文是Unobtrusive ，是一種將Javascript從HTML結(jié)構(gòu)抽離的設(shè)計概念，避免在HTML標簽中夾雜一堆onchange、onclick……等屬性去掛載Javascript事件，讓HTML與Javascript分離，依MVC的原則將功能權(quán)責清楚區(qū)分，使HTML也變得結(jié)構(gòu)化容易閱讀。），看起來會類似于這樣：
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 變量必須寫成全小寫或駝峰法。一個例外是構(gòu)造器函數(shù)，按慣例是首字母大寫。所有CSS里的 id 和 class 聲明都必須只用小寫。不允許用連接符或下劃線。
在分配低調(diào)（unobtrusive）的事件監(jiān)聽器時，通常可接受的做法是把事件監(jiān)聽器直接分派給那些會觸發(fā)某個結(jié)果動作的元素。不過，偶爾也會有多個元素同時符合觸發(fā)條件，給每個元素都分配事件監(jiān)聽器可能會對性能有負面影響。這種情況下，你就應該改用事件代理了。
從性能角度考慮，jQuery的 delegate() 優(yōu)于 live()。
即使采用了最好的校驗器，瀏覽器的怪異性也會不可避免地產(chǎn)生一些問題。有幾個堪稱無價之寶的工具可以幫助優(yōu)化代碼的健全性和加載速度。很重要的一點是，你手頭準備好了這些工具，不管你主要用來開發(fā)的瀏覽器是哪個。我們推薦先在Firefox和Safari上做開發(fā)，然后用Google Chrome和Opera，最后針對IE用條件判斷做一些額外的微調(diào)。下面列出的是一些有幫助的調(diào)試器和速度分析器：
Stoyan Stefanov 的博文包含了以上原則 并有詳細說明（【譯者注】這篇博文值得一看）。
美國政府相關(guān)法規(guī)508節(jié)： 局域網(wǎng)和互聯(lián)網(wǎng)信息及應用標準。
— 本公司開發(fā)的接口必須符合相關(guān)法規(guī)508節(jié)的要求。
W3C 的易用性檢查點清單。
— 本公司開發(fā)的接口必須符合第一優(yōu)先級指南。
— WCAG 1.0 指南。
當我們持續(xù)把web的能力發(fā)揮到極致的時候，讓網(wǎng)頁在最小開銷或等待時間下可用依然是同樣重要的問題。下面的章節(jié)說明如何優(yōu)化網(wǎng)頁使用戶滿意。
在生產(chǎn)環(huán)境傳輸CSS和Javascript，必須采用很多優(yōu)化措施：
在頁面加載的時候，通常會有很多腳本等待執(zhí)行，但你可以設(shè)定優(yōu)先級。下面的順序就是基于用戶反饋設(shè)定的優(yōu)先級：
CSS 精靈（Sprites） 基本上就是把一批圖片資源合并成單個圖片文件。然后每個部分用 CSS background-position 來展現(xiàn)。典型的 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 實現(xiàn) :hover 懸停效果是很普遍的。這種情況下你會看到類似于這樣的定義：
1.a.expandbox:hover { background-position: -50px -20px; }
使用 sprites 可以減少頁面大小，也減少了HTTP連接數(shù)，這會加速頁面加載。 在 css-tricks.com 上有更多總體性的技術(shù)和概述。盡可能地利用CSS 精靈總體來說是一項最佳實踐。
除了主要的sprite之外，很多開發(fā)者還會使用一個垂直方向的sprite。這個垂直方向的sprite的寬度（以及高度）會小于或等于100px，包含了通常一個挨著一個的圖標，諸如列表元素的著重號或?qū)δ艿逆溄雍桶粹o。Yahoo 就用到了一些，例如這個。
有個注意事項就是別把sprite弄得太大，不管是高還是寬超過1000px都會導致用掉大量內(nèi)存。你可以學習一下 使用sprite的時機及內(nèi)存占用，如果需要了解更多關(guān)于創(chuàng)建sprite的總體性提示和技巧，請參閱 Mozilla 開發(fā)博客。
你應該會用到四種主要的圖片格式，細節(jié)如下：
關(guān)于PNG格式、瀏覽器支持以及各種格式優(yōu)缺點的詳細信息可以在 這篇優(yōu)秀的文章 中找到。
如需進一步優(yōu)化所有這些格式，從 Yahoo的 Smush.It 查看圖片可以發(fā)現(xiàn)縮小它們的辦法。
對于靜態(tài)內(nèi)容，瀏覽器應該把文件在本地緩存，在合理的前提下，保留盡可能長的時間。應該較長遠期緩存的內(nèi)容包括：
為了最佳緩存效果，利用http頭部的Expires。下面是一個遠期的Expires頭，它告訴瀏覽器這個響應在2015年5月15日之前都無需更新：
Expires: Thu, 15 Apr 2015 20:00:00 GMT如果你的服務(wù)器是Apache，可以使用 ExpiresDefault 指令設(shè)置相對當前日期的失效日期。下面的例子設(shè)置失效日期為請求時間的一年之后：
ExpiresDefault "access plus 1 year"http頭部的 Expires 必須設(shè)為據(jù)現(xiàn)在一個月到一年（遠期）之間的值。緩存只適用于那個指定的URL，所以文件名或任何資源的改變都會產(chǎn)生一個新的拷貝。很多開發(fā)者使用build過程來給它們的資源增加一個版本號或時間戳。每個隨后的build會開始一個全新的緩存版本，讓你在使用遠期緩存日期時無需擔心。 Google 的這篇文章里有更多關(guān)于瀏覽器緩存的細節(jié)信息。
靜態(tài)內(nèi)容當然應該由不同于HTML所在服務(wù)器的另一個域提供訪問。這是優(yōu)化的方案，這樣 對所有靜態(tài)內(nèi)容的請求就無需額外的cookies頭。而且為整個域編寫緩存規(guī)則也就容易得多了。（同時，當前域的任何子域會繼承當前域的cookies，所以使用全新的域是值得的）。
不過，對于足夠多的資源（特別是圖片），請求數(shù)的增加足以讓頁面加載變慢。很多瀏覽器對于他們從每個域能并發(fā)下載的資源數(shù)有比較低的限制。（在IE6和IE7，這個數(shù)字僅僅是2）。在這種情況下，我們可以把資源存放在多個子域，例如：
Google Speed 上更多有關(guān)域分片的信息
Iframe 是能添加到指定頁面的各種元素中上開銷最大的一個。它們會阻塞頁面讓它無法觸發(fā)onload事件，直到它們加載完成。有時候它們被其他機構(gòu)用來處理追蹤腳本。例如 Doubleclick floodlight 標簽就是一個 iframe，管理員可以從他們的管理面板向里面增加追蹤像素。在加入iFrame的任何情況下，它應該在window的onload事件被觸發(fā)之后再動態(tài)加入到DOM中。 更多細節(jié)請參閱 Yahoo 的性能站點。
我們推薦在頁面加載完成（DOM ready 事件或 window 的 load事件）之后，再用 Javascript 把 Omniture Javascript 代碼加入DOM中。通過使用這個技術(shù)，可以避免外部域腳本的依賴性，這種依賴性會減慢（并可能掛起）頁面加載過程。
在所有情況下， Flash 的位置必須有備選的HTML內(nèi)容，以使SEO值最大化。對于 XML 驅(qū)動的 Flash，備選 HTML 內(nèi)容必須利用同一個 XML 文件，以確保數(shù)據(jù)的一致性。
所有替換內(nèi)容必須使用 SWFObject ，但不應加入內(nèi)聯(lián)腳本標簽。 SWFObject 的初始化必須在 DOM Ready 事件后觸發(fā)。最小的播放器版本必須設(shè)置為最小 v9，以確保 AS3 兼容性。
談到瀏覽器體驗，有兩個主要的事實：
那么，基于這兩條人生真諦，我們需要通過什么樣的步驟讓大家滿意呢？
這些指標必須針對你的客戶和項目來定制，在線框圖布局階段之前完成。這些目標從技術(shù)角度必須是合理的，也是可測試的。
可能適用的一些目標
對于加載時間的目標，定義基準系統(tǒng)是很重要的。類似于 PageTest 的工具是個好的選擇。另外，目標也可以分開多個頁面來定義，例如：訪問量最大的兩個目標網(wǎng)頁（比如主頁和支持頁面）。
如果客戶對于意向設(shè)計有比合理目標更激進的目標，就必須在整個項目決策委員會中統(tǒng)一期望值，并讓項目組了解性能指標是最關(guān)鍵的。
內(nèi)部
在 IA、IxD 和視覺設(shè)計階段，前端工程師是負責溝通性能對于交互特性的影響或在目標瀏覽器上采用特定的視覺技術(shù)的角色。要給出設(shè)計師的限制條件：“如果我們使用Cufon，每個頁面上用到定制字體的元素就不能超過10個。”
外部
需要設(shè)定期望值： 并不是所有的瀏覽器都有相同的體驗。它們的表現(xiàn)不會彼此相同，指望它們的特性完全一樣也不現(xiàn)實。在IE7的體驗中放棄一些新的特性也許是合理的。會考慮被放棄的一些特性可能是： 陰影、過渡、圓角、透明度、漸變色。
當溝通某件事的影響時
選擇那些性能優(yōu)化的庫和插件。基于性能目標做出明智的架構(gòu)決定。同時在可能的前提下盡量減少 DOM 操作，設(shè)計樣式要讓頁面在加載和初始化的時候 避免視覺變化 。
QA 團隊也應該把性能相關(guān)的因素和視覺、功能和可用性問題放在一起來確定優(yōu)先級。開發(fā)者和 QA 必須確定如何分配優(yōu)先級。在 QA 過程中，成功的指標必須定期測試。
測試用的工具
如果性能指標沒有達到，有三個選擇：
我們認為，通過這個方法，在應對性能挑戰(zhàn)的過程中，項目相關(guān)各方都有更好的機會統(tǒng)一期望，共同前進，并形成更加行之有效的工作流程。
今天的用戶可以從相當大的范圍中選擇web瀏覽器，每種瀏覽器都提供了略微（或相當）不同的體驗。作為開發(fā)者，我們的責任恰恰是選擇我們創(chuàng)建的網(wǎng)頁展示給用戶的方式。本節(jié)描述我們是如何做出這當中的一些決定的。
Isobar 支持任何 Yahoo 瀏覽器支持分級 中列出的A級瀏覽器，除了Opera之外。對此也可能會有其他的例外，基于地區(qū)市場和它們特定的指標。
我們會努力支持任何客戶指定的其他任務(wù)關(guān)鍵瀏覽器 (IE 5.5, Opera, Konqueror, Safari 3 on PC, 等等)，雖然我們不能保證所有功能都可能實現(xiàn)。
全面的瀏覽器測試對于每個web項目都是必須的。必須付出大量精力進行跨瀏覽器和平臺測試，以確保質(zhì)量和一致的用戶體驗。配置測試環(huán)境會是一項挑戰(zhàn)，卻是值得去做的。
由于不可能在一臺PC上安裝多于一個IE瀏覽器，IE的測試是個挑戰(zhàn)。幸好微軟最終提供了老版本IE的開發(fā)版下載。這些運行拆解版Microsoft Windows的虛擬磁盤時不時地失效（過期）。通常隔幾個月就需要重新設(shè)置它們。從你的MSD版權(quán)（如果有）獲取的Microsoft Windows開發(fā)版也會是一個選擇，取決于你能夠獲取到的東西。
此外，其他不是那么有效的IE測試選項（通常是不推薦的）包括了 IETester，它還是好于 Multiple_IE 和 IE7 standalone。
Google Chrome 會自動更新，正常情況下絕大部分用戶都會有最新版本。要是每種瀏覽器都這樣多好啊。對于Google Chrome就不需要擔心舊版本的問題了。
對于核心的Mac OSX 瀏覽器，Mozilla Firefox, Google Chrome和Apple Safari 提供的瀏覽體驗基本和它們的Windows版本一樣。盡管如此，某些操作系統(tǒng)級的差異還是會出現(xiàn)，網(wǎng)站必須在兩個平臺上進行測試。典型的差異是關(guān)于字體渲染，所以有時候會冒出間距問題。
在 Mac OSX 上測試基于Windows的瀏覽器有幾種選擇。首先，Mac 提供了一個 "boot camp" 分區(qū)，它允許你在Mac 上啟動一個Microsoft Windows分區(qū)。這是一個復雜但完整的測試環(huán)境。一旦你用Windows啟動，就可以用通常 Windows 環(huán)境下的測試方法。
其他選擇包括在 Mac OSX 內(nèi)部虛擬化 Windows，讓你可以在Mac OS內(nèi)部運行Windows。
Microsoft 虛擬磁盤 在這里的大部分選擇中是可以打開或轉(zhuǎn)換的，這樣就能在一定程度上利用Windows 用戶可以用到的那些測試方法。即使你也可以同時在Mac上測試，有些人還是會認為這樣更加靈活...
正如在Windows 上一樣，你可以在一臺Mac 上安裝和運行 Mozilla Firefox 的多個拷貝，雖然通過配置管理器設(shè)置多個配置更為復雜一些。盡管如此，你可以通過一些小技巧，通過Automator程序創(chuàng)建分開的配置并順利運行它們。
注意：IE6 standalone 版在某些情況下對透明度的實現(xiàn)是有bug的。這會導致任何應用于CSS 過濾器的透明度（例如alpha透明度或者24位PNG）失效。在這種情況下必須測試透明度，你會需要本地安裝的IE6。
還有人發(fā)現(xiàn)安裝在Vista 平臺上的IE7 和Windows XP 上的IE7 確實有差異，所以，你可能會希望確保團隊中的某個人也有這種配置。IETester 修復了一批這樣的問題，和Xenocode 瀏覽器的做法類似。
除了適應各種瀏覽器，開發(fā)者還必須持續(xù)注意用戶的屏幕分辨率。隨著顯示器屏幕越來越大，分辨率的廣度也隨之增加。下面是關(guān)于分辨率的一些工作準則。
1024px 分辨率
關(guān)于窗口大小的當前統(tǒng)計
不過，系統(tǒng)分辨率和瀏覽器尺寸并不是一樣的
良好的web設(shè)計和開發(fā)的一個重要部分就是SEO 。要想確保一個網(wǎng)頁不僅能讓搜索引擎合適地索引到，而且能讓那些只有有限的web能力的人訪問到，結(jié)構(gòu)良好的代碼是其中的關(guān)鍵。
你必須使用語義化的標記，在關(guān)閉 Javascript 和 CSS 之后它仍然是可讀和邏輯的。所有頁面內(nèi)容必須是HTML 形式；我們不希望使用iframe 或 Javascript 來加載初始的可索引內(nèi)容。
所有鏈接都必須指向 HTML
1.<a href="/shelf/jordan/page/2">
而不是這種
1.<a href="javascript：loadPage(2);">
這樣既能被搜索引擎正確索引，也能讓用戶在新窗口或新標簽中打開鏈接。
每個頁面的 title 標簽應該突出目標關(guān)鍵字。每個頁面的 title 應該是獨特的。標題（h1,h2,等等）應該構(gòu)成文檔的輪廓并代表該頁面最重要的關(guān)鍵字。URL 應該是人類可讀的，其中包含主要的目標關(guān)鍵字：
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 內(nèi)容。所有廣告促銷圖片應該使用基于 CSS 的替代圖片而不僅僅設(shè)定 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 的產(chǎn)品團隊提供關(guān)于通過簡單易接受的優(yōu)化改進他們的產(chǎn)品頁面的思路的一項措施。這些優(yōu)化手段不僅僅是為了幫助搜索引擎更好地理解他們頁面的內(nèi)容，也是改進他們的用戶體驗。
訪問他們的站點時，諸如修復404錯誤和無效鏈接、簡化URL 選項、提供易于理解的標題以及頁面摘錄等簡單的步驟，其實對用戶和搜索引擎都是有利的。
代碼審查是確保系統(tǒng)質(zhì)量和用戶體驗的正式流程中的基石。這涉及到召開一個由標記編寫者、審查者和其他相關(guān)人員參加的會議，在會上提交有關(guān)材料，產(chǎn)生后續(xù)的代碼修改要求。簡單地說，我們鼓勵進行代碼審查，磨刀不誤砍柴工嘛。
為啥俺要參加代碼審查涅？
代碼審查是用于降低項目風險的戰(zhàn)略性時間投資。
經(jīng)常地，接口開發(fā)者被要求根據(jù)線框圖或視覺構(gòu)圖編寫標記。不過，有可能設(shè)計的屏幕不能輕易轉(zhuǎn)換為標記，或者轉(zhuǎn)換后質(zhì)量有損失。代碼審查為在頁面投入生產(chǎn)之前發(fā)現(xiàn)并解決這些風險提供了一個機會。
代碼審查能夠提升跨項目的整體知識水平
既然代碼審查涉及到項目內(nèi)外的成員，這有利于在整個團隊中分享技術(shù)和最佳實踐。
代碼審查能在bug從一些模板繁衍到多個頁面之前就封殺它們
理想情況下，代碼審查是在開發(fā)過程的早期進行的，早于頁面開始全面投入生產(chǎn)。當模板被團隊審查并在多個校驗工具和瀏覽器運行，潛在的bug就會冒出來。這是修復bug的理想時機。
代碼審查給不熟悉項目的外部成員提供了發(fā)現(xiàn)代碼中問題的機會
項目外部的審查者比在代碼上工作了更長時間的標記編寫者更容易發(fā)現(xiàn)問題。
哪些人應該參加代碼審查？
歸根到底，項目的前端工程主管要負責確保代碼審查遵循合適的流程。
理想情況下，一位部門主管應該作為代碼審查的主持人，除非部門主管自己正好是被審查代碼的接口開發(fā)者。在這種情況下，由一位項目經(jīng)理進行主持。
審查小組應該包括至少兩位來自接口技術(shù)團隊精通開發(fā)和最佳實踐的資深成員。
代碼審查中有哪些要求？
在進行代碼審查之前，需要審查的模板必須整體完成開發(fā)、經(jīng)過校驗、并針對項目需要用到的瀏覽器和平臺進行了測試。
部門主管 和/或 接口開發(fā)者必須在代碼審查前至少48小時 分發(fā)以下材料：
很典型的情況是，直到代碼審查進行之前，代碼還在不斷地修改。不幸的是，這樣就沒有足夠的時間來校驗和測試了。如果這種情況發(fā)生了，最好是重新安排代碼審查的時間以確保其效果。
另外，部門主管 和/或 接口開發(fā)者應該預定一間會議室和電話會議號碼并提供給所有參與者，因為有可能某些項目組或?qū)彶榻M成員不在現(xiàn)場。用一個小時來審查兩三個模板應該足夠了；不過，需要的時間也隨模板的大小和復雜度而不同。
在代碼審查過程中，一位部門主管 和/或 接口開發(fā)者應該主持會議，而部門主管或項目經(jīng)理做記錄并分配行動事項。審查者應該在事前審閱過代碼并準備好提問或提供反饋意見。
記錄和行動事項（包括負責人）應該在代碼審查后分發(fā)給所有參與者。如果代碼審查產(chǎn)生了本質(zhì)性的變更，或沒有完成對所有代碼的審查，就有必要安排第二次代碼審查。不過，這必須在項目組內(nèi)討論以確定其可行性。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
