加入RUN!PC粉絲團
最近新增的精選文章
 
最多人點閱的精選文章
 
 
精選文章 - 開發技術
分享到Plurk
分享到FaceBook
 
跨瀏覽器網站設計者的挑戰(上)
文‧圖/王琨堯 2013/11/4 下午 05:26:13

近10年的網路生態環境,除了寬頻網路速度大幅度的提升,造成各式各樣的網路應用如雨後的春筍般出爐,瀏覽網頁勢必會使用的網頁瀏覽器,也越來越多樣化選擇,從九零年代至今超過20年發展,多樣化的瀏覽器發展使得開發更加棘手。


▲ 圖(一) : 瀏覽器推出年分圖



以使用者的角度來說,多樣的瀏覽器可以選擇自己適合的,以提升使用的品質。但對於網站設計師則是相對的提升了網站製作的困難度。主要的問題在於不同的瀏覽器對於相同網頁標籤語言會有不同的方式解讀,就像是一句法文給兩位不同的人翻譯成英文,雖然意思會是一樣但可能使用了不同的字眼。

在瀏覽器中又包含一些附加的功能,目的是為了增加使用者的方便度,例如Google的Chrome不論在何處使用,只要在瀏覽器上登入自己的帳號,就能使用自己設定好了工具列及相關設定,這對於使用者來說,是很方便的其中一項功能。

企業要求的是穩定,而OS都有內建Browser, 這也就是為何台灣政府單位或企業的內部系統為何大都用IE的原因,但它還是有跨版本的要求,而公開網站就得考慮跨瀏覽器&跨版本。

本文以開發者及使用者的角度來探討跨瀏覽器設計的議題,包含了跨平台開發、網頁程式語言等,並希望能提供開發者在開發時技術面的方向,以幫助網站開發成品能貼近現實環境所需的多樣化。首先透過數據來了解目前不同國家的使用者對於瀏覽器的喜好,開發者在無法滿足所有瀏覽器顯示的前提下,就可能會犧牲相容性,這也是這篇文章的探討主題,有甚麼方法可以兼具。

以開發者來說,目前網頁技術也是有相當多樣的開發技術,光是Java Script就有不同的框架可以使用,開發者如何挑選一個適合開發目標的技術是值得討論的。因此如何讓網站能夠在不同的瀏覽器環境下正常的顯示,是當今開發者所共同面對的問題。


▲ 圖(二): 2010~2013年瀏覽器使用率(資料來源: gs.statcounter.com/)



根據圖(二) 的曲線可以得知,Internet Explorer的使用率雖然逐年降低,但因為他搭配在微軟的作業系統中,很多使用者因為他的穩定性與方便性而直接使用他,並不會再去下載額外的瀏覽器,因此在使用率上仍然佔有一席之地。但造成使用率降低的原因不外乎使用上的品質降低,造成的原因可能是瀏覽某些網頁的功能不支援或是網站版型破裂,這些都是因為在開發時需要被注意的地方,因此本文會以Internet Explorer用來檢驗各項網頁語言支援與否。

在不同瀏覽器造成網頁顯示不同的原因

在試著解決問題前,我們必須先了解為何有跨瀏覽器的問題。身為一個開發者,當你收到客戶抱怨他們在不同瀏覽器下你為他們開發的網站有些不同,不管是樣式有些許的跑掉,或是某些功能該在網頁某時被觸發但卻沒任何動靜,這時你就會發現所以設計的網站需要做點修改。跨瀏覽器的問題簡單來說就是在不同的瀏覽器下,對於某些HTML標籤語言不支援或是不推薦使用,又或者是開發者的HTML、CSS及JavaScript開發技術有待加強。

而深入探討此問題,會發現是因為不同瀏覽器對於文件物件模型(Document Object Module, DOM)的解讀有所不同。文件物件模型是為了HTML及XML所設計的一種應用程式介面(Application Programming Interface),其中定義了網頁的邏輯結構與標籤語言,使得開發者可以利用不同標籤語言拼湊出網頁內容,例如當文章需要斷行時,只需要在句子尾端加上
,透過瀏覽器的翻譯則會變成斷行。文件物件模型是由W3C在1998年所制定的可延伸標記語言,目前已經發展至第三代。

任何瀏覽器背後都有一個引擎來做DOM的排版。Google Chrome及Apple Safari所使用的是開放式語言的Webkit。Firefox所使用的引擎是Gecko,是由Mozila他們自己所開發的。Internet Explorer4.0之後所使用的是Trident,是由微軟所開發的引擎,它並沒有全權遵照W3C的。Opear原本使用的為Presto,但在2013年2月宣布之後的產品將以webkit為主。

我們可以歸納造成網站在不同顯示瀏覽器中顯示不同的原因:

不同的瀏覽器:
不同的瀏覽器對於DOM的解讀及支援度有所不同而造成網站呈現有些許的不同。例如在DOM標籤中都會有個關閉標籤(
),但如果少寫了這個關閉標籤,不同瀏覽器會有不同的處理方式,有的可能仍然會顯示整個表格,也有的是整張表格完全不顯示。

不同的瀏覽器版本:
各種瀏覽器隨著時間推陳出新,但在不同版本之間會有支援度不同的問題,例如在Internet Explorer 9 以前的版本不支援HTML5, 若使用了9以前的版本有些功能則不會運作。比較保險的是讓網站至少能支援目前主流瀏覽器前兩版較舊的版本。

不同的字型格式:
在CSS3推出之前,因為網頁文字格式顯示使用的是系統資源,因此網頁上的文字只能設定成系統內有的字型,大部分中文網站設定都為新細明體,若設定其他不同的字體,在網頁上仍然只會顯示為新細明體,造成跟原本設計的樣式有所不同。

不同的瀏覽平台:
在2010年開始智慧型裝置開始快速發展,到今日已經是人手一機的情況下,使用者大都使用小螢幕的手機瀏覽網站,因此網站若沒有適合手機大小的解析度模式,對於瀏覽者需要使用品質勢必會下降。

瀏覽器大戰

90年代瀏覽器大戰初期,為Internet Explore及Netscape的大戰,在那個微軟作業系統開始蓬勃發展的年代,Internet Explore瀏覽器為內建瀏覽器,為求穩定大部分的使用者因此選擇它來瀏覽網頁。微軟內建瀏覽器的競爭者Netscape出現於1998年,經歷過那年代的使用者都會發現當時作業系統中都會有兩個瀏覽器,但經過一段時間後,因為發現到Netscape瀏覽有些網站會發生不支援的情況,這是微軟為了打贏戰爭所使用的伎倆。微軟開始多方的發展網頁上的技術,而這些技術必須使用IE瀏覽器才能支援瀏覽,於是漸漸很多頁面都無法正常瀏覽的Netscape只能從這場瀏覽器大戰中煞羽而歸了。

經過20年發展後的今天,瀏覽器戰爭不再只是兩家軟體公司之間的戰爭,而是多方軟體大廠間的戰爭,但競爭的內容不變的是看誰相容性高,看誰支援新技術的程度高或是誰的周邊功能多。

跨平台網站設計

網站瀏覽平台在近10年除了面臨多樣化瀏覽器的挑戰外,智慧型裝置的快速發展,使的開發適合智慧型裝置的網站需求量大增,人手一機的行動裝置擁有很大的行銷市場,很多公司索性從智慧型裝置出發,進而開發適合電腦瀏覽的網站。


▲ 圖(三):不同解析度的螢幕



手持式裝置的螢幕解析度通常都比一般電腦螢幕小,因此開始一個網站專案前必須先了解規劃好在不同平台的呈現方式。而在不同的平台最大的不同就屬螢幕解析度了(圖三),可以將它分為三大類:一般電腦螢幕、平板電腦及智慧型手機螢幕。
如果網站能自己知道目前用多大解析度,那麼就不用因為做出兩三種版本來支援不同解析度,有幾個方法可以達到這樣的目的。首先可以在網頁的最上方加入一行Meta標籤:



這行設定了網頁的Viewport會依照不同的裝置寬度做調整,如此當使用較小的解析度瀏覽網站時,網站會自動調整成適當的解析度。當然這需要搭配適當的版面設計。在CSS3中提供Media Types屬性來公開發者使用,Firefox 3.5+, Opera 7+, Safari 3+ and Chrome的瀏覽器已經支援,但在這之前的版本可以載入css3-mediaqueries.js來加入支援。
使用Media Types前我們需要先設定一下網站瀏覽的寬度,例如我們設定三個寬來讓網站顯示不同樣式,分別寬度為980px、650px、480px及900px,因此在CSS中可以使用以下的寫法。



在Media Queries設計概念中寬度單位使用百分比,使的版面較彈性,例如: height: 95%。另外網站的版面也可搭配HTML5最新制定的
標籤來,較低版本的瀏覽器可以在網頁上加載Html5.js即可有此功能。

最後做幾個結論:
在不支援Media Queries的瀏覽器中可以使用css3-mediaqueries.js。
支援的瀏覽器有: Firefox 3.5+, Opera 7+, Safari 3+ 及 Chrome
不支援的瀏覽器為: IE 5+, Firefox 1+ and Safari 2



設計一個較有彈性的網站版面,建議將網頁中版面的長與寬值設為Auto,如此可以依照瀏覽解析度做不同的伸縮。



iPhone 和 Android 的瀏覽器都使用webkit,在手機上縱向 (Portrate mode) 和橫向 (Landscape mode) 模式皆有自動調整字體大小的功能。控制它的就是 CSS 中的 -webkit-text-size-adjust。這功能若關掉,文字將不會隨著螢幕解析度大小而變,因此可能造成當網頁被整個放大後,只剩文字還小小的,所以最好設定成100%。



IPhone4解析度為640×960,320DPi。因為Safari支援Media Query,因此很多網站會特別創造一個CSS樣式給適合iPhone。



使用於iPad上的Safari與iPhone上的大部分是一模一樣的,唯一不同的地方是在iPad上的CSS宣告方式是基於方向性的(orientation),因此在media的部分需宣告如下。







跨瀏覽器網站設計者的挑戰(上)
跨瀏覽器網站設計者的挑戰(中)
跨瀏覽器網站設計者的挑戰(下)