相關文檔
Safari:https://developer.apple.com/library/safari/navigation/index.html
Chrome:http://docs.webplatform.org/wiki/Main_Page/zh-hans
IE:http://msdn.microsoft.com/zh-cn/ie/
Mozilla:https://developer.mozilla.org/zh-CN/
文檔里面的內容很多很雜,一般用法是想知道啥直接進去搜索。
響應式
Ethan Marcotte在2010年5月份提出的一個概念,旨在讓一個網站同時兼容多種設備,而不是為不同設備定制不同的版本。如果把我們的網站看做一個程序的話,響應式設計要求網站能提供更多用戶端可選的參數,讓用戶擁有更多的控制權。
字體大小響應
這里的字體大小指的是用戶自己設置或者設備的默認字體大小。同樣是12px大小的字符在不同設備上對用戶的觀感是不一樣的,但是設備總會提供一個觀感還不錯的默認字體大小(或者用戶自己指定的)。所以為了讓我們的網站的文字在不同設備上也能有不錯的觀感,網站應該使用em代替px。em定義的是一個相對大小,設計者通過它可以定義哪些地方的字應該大一些,哪些地方的字應該小一些,但是不規定哪些地方的字必須多大。
屏幕尺寸響應
屏幕尺寸是我們主要需要響應的地方,屏幕的尺寸大小,寬高比等因素都會影響我們的布局,內容的的大小等。比較常用用來解決尺寸的布局方式有固定布局,流動布局,柵格布局,這些布局方式常常混合使用。
- 固定布局:頁面居中,兩邊留白,他能適應大於某個值一定范圍的寬度,但是如果太寬就會有很多留白,太窄會出現滾動條,在PC頁面上很常見。
- 流動布局:屏幕尺寸在一定范圍內變化時,不改變模塊布局,只改變模塊尺寸比例。比固定布局更具響應能力,兩邊不留白,但是也只能適應有限的寬度變化范圍,否則模塊會被擠(拉)得不成樣子。
- 自定義布局:上面幾種布局方式都無法跨域大尺寸變化,所以適當時候我們需要改變模塊的位置排列或者隱藏一些次要元素。
- 柵格布局:這種布局方式使得模塊之間非常容易對齊,易於模塊位置的改變用於輔助自定義布局。
屏幕精度響應
屏幕間的像素精度差異導致固定像素在不同設備上實際尺寸會有比較大的差別,為了解決這個問題我們使用彈性布局,彈性布局采用em作為單位,其原因和“字體大小響應”中提到的一樣。但是由於使用了em作為單位,使得我們實際上是無法得知界面實際尺寸的,這回導致頁面上的圖片有可能過大(浪費帶寬)或者過小(模糊),所以對於圖片我們需要根據實際需要的大小選擇性加載對應的尺寸版本。另外在最新(ipad3,iphone4)的IOS設備上,1px實際上會占4px(由於像素密度高),所以圖片精度對於這些問題都要單獨處理。
交互方式響應
不同的設備支持不同的交互方式,可能是觸屏或者鼠標操作,再可能是按鍵操作。這里可以采用“漸進增強”的方式,為用戶定義基本的操作方式,而在先進的設備上提供更接地氣的操作(比如手勢)。
網絡狀況響應
用戶在慢速網絡的情況下可以選擇不下載一些消耗帶寬的資源。
其他功能響應
比如GPS,陀螺儀,電話等功能
使用場景響應
比如用戶在車上,還是在走路,可以根據這些情況提供給用戶不同的操作體驗。
用戶偏好響應
不同的用戶有着不同的偏好,比如左右手,操作習慣,反映速度,眼睛辨別能力,網站都可以考慮做出響應。
響應式的誤區
我要響應哪些設備?
設計響應式的目的是為了應付現在的設備或者將來未知的設備,像最開始的比喻,如果網站是個程序,那么響應式網站可以提供更多參數選項。並且,如果你提供了這個參數,那么就要做好它可能是任何值的准備,至少是心理准備。設計師在設計的時候可以拿一些典型設備做參照,但是最后你要忘掉這些設備。
是不是響應的設備類型越多越好?
響應式設計是一個抽象,有挑戰性的工作,在設計中為了兼容不同的設備需要權衡舍棄一些原本在特定設備上更好的設計。並且在前端上為了要兼容不同設備,也需要做大量兼容性處理。響應得設備類型越多意味着設計的限制越多,前端需要做的工作越多,成本越高,而體驗卻只降不升。所以根據產品需求響應得適可而止就行了。
移動端用到的前端技術
Media Query
用於查詢設備是否符合某一特定條件,它可以在css中,link標簽屬性中,js中使用。這些特定條件包括屏幕尺寸,是否可觸摸,屏幕精度,橫屏豎屏等信息。我們可以根據這些信息來對頁面做一些特殊處理從而達到響應目的。
相關鏈接和用法:http://www.w3.org/TR/css3-mediaqueries/,http://www.w3.org/TR/cssom-view/
在ie8及以下不支持Media Query,可以通過https://github.com/scottjehl/Respond兼容。
使用em做尺寸單位
用於文字大小的響應和彈性布局。
禁止頁面縮放
原本IOS手機頁面為了兼容pc的頁面默認屏幕寬度為800,並進行了縮小。但是作為專門為移動端設計的頁面我們並不需要這種處理,所以通過如下代碼去除縮放。這個代碼被主流移動瀏覽器兼容。
<meta name="viewport" content="initial-scale=1, width=device-width, maximum-scale=1, user-scalable=no" />
去除點擊高亮
在移動端點擊一個可點擊元素默認會出現一個元素大小的半透明顏色覆蓋到元素上。這是為了讓用戶感覺到這個元素已經被點擊了。但有時候這個效果不是我們希望的,可以通過如下全局css設置把它去掉
-webkit-tap-highlight-color: rgba(0, 0, 0, 0);
該屬性在webkit內核瀏覽器上有效,參考鏈接:https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//appleref/doc/uid/TP30001266-webkit_taphighlightcolor
但在移動端IE10上,需要如下代碼才能去除
<meta name="msapplication-tap-highlight" content="no" />
參考:http://msdn.microsoft.com/zh-cn/library/ie/bg182645
滾動回彈特效
通過overflow:scroll可以使內容可以滾動,但是沒有物理彈性,比較生硬,沒有滾動條。如果想要IOS那種彈性的滾動效果可以使用css
-webkit-overflow-scrolling:touch;
但是加上這個css后會產生滾動條(通常不顯示,滾動才顯示)。非要去掉滾動條只能通過JS模擬,通過這個Kissy組件可以做到:https://github.com/hongru/kissy-mscroller,需要直接引用fakescroller,如果直接引用index會在IOS平台自動變成-webkit-overflow-scrolling。
觸摸事件
四種基本觸摸事件
目前Safari只支持TouchEvent和GestureEvent,其他手勢需要自己定義。TouchEvent主要有touchstart,touchmove,touchend,touchcancel四種。參考鏈接:https://developer.apple.com/library/safari/documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html
觸摸屏上的鼠標事件
同時Safari幫你模擬了鼠標事件,但是click事件會有明顯的延遲。一般采用封裝好的手勢框架去模擬tap操作代替click。Kissy的Event模塊帶有tap事件。但是在點擊一個綁了tap事件的元素時,周圍有可以點擊(click)的元素,那么手指可能會觸碰到這個元素,導致tap事件和click事件均被觸發。但是click事件觸發會在tap事件之后,所以我臨時的解決方案是在tap事件發生后阻止document上所有的click事件一段時間(500毫秒)。
觸摸屏上的偽類
另外在Safari上使用hover和active位類時,手指點擊一次鏈接,那么那個鏈接的hover會被一直觸發,如果長按一個鏈接,那么他的active會被一直觸發。所以目前看來使用css偽類是不保險的,只能通過js模擬。
video元素在Safari上對觸摸事件的影響
iphone平台的video元素所在區域會被屏蔽所有觸摸事件,而且是和DOM結構無關的區域性屏蔽,一個元素被絕對定位到video元素區域也會被屏蔽事件,並且video被overflow:hidden之后同樣。所以想在iphone上做一個視頻點擊播放這種效果,只能自己弄張圖片和一個播放按鈕,然后點擊后調用一個舞台外的video元素播放。 ipad平台同樣存在這個問題,但是如果把video標簽的controls屬性去掉就能恢復正常。這意味着想要解決這個問題必須自定義UI而不能使用系統UI。 我認為這個問題應該是IOS平台自帶的UI造成的,只是iphone無法通過controls屬性去掉UI。
scroll與touchmove
在Safari上scroll事件不如PC上發生得那么頻繁,只有在頁面滾動動畫結束之后才會很吝嗇得發生一次。如果需要比較實時得檢測用戶把頁面拖動到什么位置了,建議使用touchmove事件。
