易犯的 RWD 網站製作失誤
自從 Google 在 2016 年宣布將調整手機 Google 中行動版網站的搜尋結果排名Mobile-first Indexing，各大網頁設計公司的業務人員就開始以此當噱頭、勸業主改版，因為這又是一個收費的大好機會。腳步比較遲緩的企業，也在老闆發現自己家的網站用手機打不開，而競爭對手的網站在手機上很好用，而開始提出需求將自家的網站做行動版的優化。
讓資料可以優美舒服的顯示在行動裝置顯示解決方案有很多，響應式網頁設計(RWD, Responsive web design)是其中之一，RWD 的特點是用一些 JS 與 CSS 的技術，讓同一個頁面可以好好的顯示在行動裝置跟電腦，不會有兩個網址，後端程式只要寫一次，其他都是~~美工~~視覺與前端的事情。本文介紹一些網頁設計人員在製作 RWD 網站時常犯的失誤。
1.把自己的裝置解析度當成大家的裝置解析度
想看網頁實際上在小螢幕上看起來如何，於是網頁設計人員就用自己的手機來預覽與修改，把網頁上的 UI 輸入框、圖文編排、文字段落，在自己的手機上調整顯示得剛剛好，覺得很完美，但只是一場夢，用其他手機看卻跑版、跳行、內容突出螢幕外、字句斷得可怕，為什麼呢?
事實上手機螢幕的解析度一直在改變，iOS 陣營的螢幕解析度是越來越大，Android 陣營的則是廠商客製自由度高，造成解析度破碎化，從 4 吋的手機到 7 吋的通話平板、11吋的雙系統平板，12.9 吋的 iPad Pro 還有 4:3、16:10、16:9 等各種螢幕比例。
假設你在解析度 480*853 (Samsung) 的手機上製作頁面，把大部分的東西都設定最小寬度或是固定寬度 400px 以上，那在解析度 320*568 的 iPhone 5s 上看起來可是很慘烈的。
所以調整 RWD 網頁要記住第一個原則，買一支跟老闆和客戶一樣的手機，或是把老闆和客戶的手機螢幕解析度背起來….啊不是啦！
1.多用百分比之類的寬度，寬度不要設定太多固定數值。畫設計稿時也不要把網頁元件排得太寬，如下圖超簡易的範例。
2.有時候可用圖示、placeholder、blur 自動驗證之類的功能，來取代按鈕，或是太多的提示文字。
要看網頁在行動裝置上長怎樣，可以利用一些模擬器，最容易安裝與使用的應該算是 Chrome Developer Tools 裡面的 Device Mode 。也可嘗試一些線上工具，如 Screenfly 或 Mobile phone emulator (by COWEMO)，要看 iOS 可以用 iOS simulator，不過模擬器畢竟是模擬器，系統的中英文字體顯示、不支援的元件、翻轉螢幕、輸入文字時鍵盤跑出來、觸控行為、跟實際用手機瀏覽的感覺還是很有差異。
我的話通常會使用瀏覽器的 device mode 工具，縮放網頁的寬度與高度，看看會不會在任一寬度產生不美觀的畫面，或是重大操作問題？然後在 iPad 跟 Android 手機實際各走一遍流程。
2.orientation:landscape 不是螢幕方向打橫
製作 RWD 網站最常用的技巧之一就是 CSS 媒體查詢指令(media query)，讓瀏覽器碰到符合條件的媒體裝置時，執行對應的 CSS，常用的如寬度大於多少(min-width)、高度小於多少(max-height)…等等。
會遇到一個屬性叫 orientation:portrait 與 orientation:landscape，有些網路上淺顯易懂的中文網頁設計教學會簡易的說它是「螢幕方向」是垂直或水平，但如果查閱 W3C 或 MDN 中的屬性定義，它並不是真的表示裝置方向/螢幕旋轉方向，而是「螢幕可視區域的高比寬還大(The viewport is in a portrait orientation, i.e., the height is greater than or equal to the width.)」或「螢幕可視區域的高比寬還小」。
嗯? 螢幕可視區域跟整個螢幕差不多吧，不就是螢幕打直跟水平嗎? 身為資訊人，永遠要考慮例外情況、故障情況會發生什麼事。
例如這個情況，造成手機裝置方向是直立的，卻是 landscape 的情況，螢幕可視區域的高比寬還小，你想到了嗎?
點擊輸入框，彈出鍵盤時，會造成手機是直的，卻觸發 orientation:landscape
3.別忘了使用者會修改瀏覽器設定
有時候會在文字段落區塊或容器區塊設定固定高度，讓區塊不論內容多寡，都可以整齊顯示成一樣的高度，不會忽高忽低。但會發生使用者反應「兩行字疊在一起啦」「字顯示到一半就被吃掉啦」，自己試了又沒有，到底為什麼呢? 有些把顧客當白癡的公司，或是深諳業務技巧的人員會說這是「手機壞了」「個案」，但真的是這樣嗎?
如果有平面出版相關經驗的人，可能都會聽過書本一頁幾行字，雜誌一頁幾行字的說法。但是在資訊時代，卻比較少聽過這種潛規則，頂多只有文字或按鈕不要小於多少尺寸，哪有人在講電子書、網頁、手機一行要有幾個字? 因為資訊產品的螢幕尺寸太多，而且通常都可以自訂顯示文字大小、自訂顯示背景色與文字顏色，或設定系統配色為高對比。
問題就出在「自訂顯示文字大小」這回事上面。
華碩瀏覽器
Chrome for Android
例如一些瀏覽器都有「字型縮放」跟「最小字型大小」的設定，前者是將整個網頁不論大小的文字強制放大，後者是將小於多少點數的字強制放大，若使用者設定這些選項之後，就會造成所謂的「兩行字疊在一起啦」「字顯示到一半被吃掉啦」之類的現象。
那如何排除因為調整瀏覽器設定，而造成字疊在一起的情況呢?
– 行距不要設固定px
– 區塊不要設固定高度
– 不要用太多 overflow:hidden
那要如何避免文字因為瀏覽器的設定而被強制放大呢? 無解。
以前可能聽過用 pt 單位設定 font-size，或是設定 text-size-adjust:100% 的秘方，但後來除了 iOS，其他的也已漸漸不支援了。或是還有用 transform : scale 來把放大的字再縮回去的祕法，但是你得先知道使用者把字放到多大。
還有一招最不是方法的方法，就是把字通通做成圖片，就沒有什麼因為調整「最小字型大小」而導致跑版的情況。
但畢竟能隨意放大才是體貼使用者的行為，美觀只是一回事，能讓使用者看清楚網頁上要傳達的文字訊息才是真的。但是工程師替使用者著想，誰來替工程師著想? 下次又遇到此問題時，除了請使用者把「最小字型大小」調回預設值，或是一些奇巧的業務嘴說法，還有別招嗎?
有時候會碰到更精緻的需求「這邊的文字斷行落了一個字」「不能設定一行固定多少字嗎?」「這個文字 size 要跟我的設計稿一樣大」，我們剛剛才講過行動裝置解析度破碎化，而且使用者可以自己調整瀏覽器字型顯示設定，所以如果編輯人員將文章強制斷行，或是一行固定多少字，會發生以下情況…
以一則新聞網的文章為例，也許在某種螢幕解析度時斷行斷得剛剛好，但是在手機上閱讀起來卻亂七八糟。
以用手機瀏覽一個電子刊物網站為例，因為傳統的雜誌排版不可能做到自適應自動排版，所以在手機上顯示起來，也是一行固定多少字，所以使用者在手機上看這文章必須要一直縮放、平移，體驗非常的差。
當然因為刊物是花錢訂閱的，而且只有在這平台才有得看，所以使用者還是會摸摸鼻子乖乖找大螢幕來看。如果內容沒有獨一無二，操作體驗也很差，真的不知道要用什麼東西來留住使用者吶。
4.以前電腦網頁常用的輔助輸入元件，在行動裝置可能很難用
現代的網頁/web程式常常都有一些輔助輸入的網頁元件，例如小日曆、自動完成功能、離開輸入框焦點時自動驗證、彈出訊息、modal box 前景小操作視窗 …之類的功能。
如果未對這些輔助輸入元件在行動裝置版面做處理，將會導致表單難以輸入，差一點的頂多是畫面顯示多餘的功能，或是伺服器請求的浪費，但要是發生操作元件阻擋主要畫面，或是重要的警示訊息顯示在畫面外，讓使用者無法完成造成操作流程，這些都是災難性的。
自動完成功能的在手機瀏覽環境下較難點選
一些日曆元件在手機瀏覽環境下較難點擊，可以換成 html5 input type
例如 JQuery UI 的小日曆在手機上較難點擊，我們可以用 modernizr.js 或是簡易的 js UserAgent 查詢指令，在行動裝置上不執行小日曆，然後將 input type 改成 date，讓使用者用系統內建的日曆元件來完成日期的輸入(如上圖右)。
if (/Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent)) {
$(“#date”).datepicker(“destroy”);
$(“#date”).prop(“type”, “date”);
//(請注意日期格式要調整成跟 JQ UI 的 datepicker 日期格式一樣)
}
使用系統 UI 元件的缺點，就是每個系統的顯示方式都不一樣，造成使用者體驗不一致(如下圖範例)，甚至有些合約驗收標準是畫面要顯示得跟合約一樣，這都容易造成麻煩。
由上至下: Safari/ android browser/ chrome on android
說到輸入，html5 增加了一些 input type(更新的瀏覽器要用 inputmode) ，input 使用正確的 type 或 inputmode，可以讓輸入電話、email 之類的欄位跳出對應的鍵盤，而不是跳出完整的字母鍵盤。如使用 type=”tel”，會跳出數字鍵盤，使用 type=”email”，會跳出帶有.com 跟 @ 的字母鍵盤。
另外有一些手機輸入法太過聰明，常常會自動校正、自動首字轉大寫、自動加空格，在某些輸入情境下相當痛苦(如輸入帳號或驗證碼時)，可以在 input 加入 autocapitalize=”off” 與 autocorrect=”off”，關閉自動大寫與自動校正(但是有些瀏覽器跟輸入法不吃這一套，遇到了就知道)。
雖然資訊系統的終極目標是指紋掃一下、條碼掃一下，甚至語音輸入，就完成所有步驟。但是在那一天到來之前，還有很大一段路要走。在現階段，只能想辦法盡量減少痛苦的輸入流程。
5.行動裝置也有瀏覽器相容性問題
經驗豐富的網頁設計師，通常都熟知所謂 CSS hack，conditional comment 之類的用法，因為在電腦的瀏覽環境，明明是同一段符合W3C的標準語法，卻可能在 IE6、IE7、IE8、IE8 相容性模式、Vista 與 Win7 的 IE8、IE9、IE9 相容性模式、IE10、IE10 相容性模式、Win7 的IE10，IE11、IE11相容性模式、Modern IE、Win7 的 IE11，Win8 的 IE11，Win8.1 的 IE11，Firefox，Chrome，Safari in Mac OS，Opera，360 瀏覽器……上面產生異常的瀏覽情況。
後來手機與平板的出現終於讓網頁界的大環境又再次推進，不能再以「反正IE8又不支援」「IE 的使用者怎麼辦?」當藉口，因為行動裝置的瀏覽器基本上都支援 CSS3 等新的網頁語法，而且行動裝置的的淘汰週期比電腦更快。開始逐漸變成「啊你用 ES6 或 display:grid 的東西，IE11 的使用者怎麼辦？」
學習網頁設計的新人，反而有些知道如何用 css 畫台灣國旗，卻不知道公司舊客戶網站裡的\0\9*_ 之類的 IE css hack 是幹嘛用的。
講相容性問題之前，我們還是先來定義一下所謂行動裝置的瀏覽器，大致上有六大類:
1.各大裝置的主流瀏覽器，如 iOS Safari ，Google Chrome on Android，使用者也有乖乖更新到最新版(作夢)。
2.InApp browser (UI webview)，例如從 Line / Wechat / FB app 點網頁，會在 app 裡面開一個像網頁瀏覽器，但許多細節又跟一般網頁瀏覽器不一樣。這種瀏覽器會隨使用者是否有更新 APP 而有不同相容性問題，或是在一些 Javascript 相關操作、HTML5 API(如要地理資訊、相機鏡頭)，或是網頁元件的預設樣式與操作(如 select )發生一些特別的問題。可見我遇到的另一個案例 你知道你的網站可能在 InAppBrowser/webview 無法使用嗎?
3.是主流瀏覽器，但是作業系統很舊，所以卡著沒法更新，例如可能 iOS 6.x, 7.x 的 Safari，Android 4.x 的 Chrome，既然是N 年前的軟體，當然不太可能支援新的網頁語法。
4.非主流裝置，如 Windows phone、黑莓機，Firefox OS 、智慧電視之類，可能一般主流智慧型手機看起來正常的網頁，會在這些非主流裝置有狀況，只能有遇到再想辦法修。
5.其他第三方廠商客製的瀏覽器，例如有人為了在手機上看 Flash ，可能會裝海豚瀏覽器，另外各家 Android 手機廠都會在裝置內建自家的瀏覽器，例如華碩有華碩瀏覽器，三星的手機也有三星瀏覽器，或是一些匪區的瀏覽器(UC瀏覽器、百度瀏覽器之類的)。這種瀏覽器的特色是使用一些主流瀏覽器的內核引擎，但是版本沒有用到最新的(或是使用者也沒到 app 市集去更新)，然後一些操作方式有大幅的客製化，都可能讓網頁發生超乎預期的顯示狀況。
除了上述的地雷，行動裝置一樣有瀏覽器相容性問題，例如 android 4.x 不支援 calc，android 4.3 以下不支援 Viewport units，iOS 則是使用 Viewport units 與 html body overflow:hidden 時會有怪情況，也不支援 background-attachment: fixed 與 window.open()，所以如果看到合約上有限制瀏覽器版本、作業系統版本什麼的，也別訝異，不然會做到死。
還有一種不是瀏覽器相容性問題，而是使用者端的裝置有特殊情況:
1.安裝 Blahker 或各種擋廣告的 app
2.使用者有改手機字型大小、字型縮放比例，也會影響到網頁區塊的顯示方式。
3.改系統字型，有些手機需要越獄或 root 才能改，有些手機是內建的功能。
4.或是裝藍光濾波器，或是螢幕有調整到特殊設定，顏色看起來跟一般的手機不一樣
5.手機中毒、儲存空間已滿，造成該顯示的東西顯示不出來
這些都可能造成明明同一個網頁，大家看都好好的，「剛好」有人不能看的情況…
這些只能靠經驗，或是使用任何先進的語法前，先去查查此語法在哪些瀏覽器會有問題。網頁版面越複雜、用的語法越新、要求的精緻度或互動性越高，就可能踩到越多的雷。
除了瀏覽器相容性，還有如上圖的瀏覽器預設樣式問題。比如說同樣有一個 select 下拉選單，設定寬 80px，在自己的 Android 手機上看起來好好的，就收工了，不過實際上 iOS Safari 的 select 箭頭按鈕非常大，如果下拉選單字太多，是會被切掉看不到的，所以寬度要再加大一點。還有 input button，iOS 按鈕的圓角看起來會比 Android 來得圓，必須再額外設定 border-radius。此兩例可以用 CSS reset，讓預設樣式通通消失，或是設定 -webkit-appearance:none 相關屬性，讓這些表單元件的預設樣式通通消失。
iOS14 的 SyntaxError: Invalid non-latin character in RexExp… JavaScript錯誤
這陣子開始遇到一些前人遺留的舊網頁程式，在 iOS14 Safari 上無法使用，但是在 iOS11/12/Android/Windows 上面都是正常的。
iPhone/iPad 實機接上 Mac Safari，或是在 Big Sur 的 Mac Safari 上面也能重現，竟然有個特別的 js 錯誤…SyntaxError: Invalid non-latin character in RexExp…導致整頁 JS 壞光光。
一開始以為是 JS 宣告 var wtf= /^-?\d+$/ 沒加分號？但其實是結尾藏有不知哪來的全形空白。解法1是把全形空白刪掉，解法2是在全形空白前乖乖加分號就好了var wtf= /^-?\d+$/;，解法3是把 js 檔抓去壓縮打包的處理，讓程式自動把一些小問題處理掉，但是如果壓縮後有問題，看是哪個衰鬼要負責處理。
6.使用太多「滑鼠移入」事件，或是亂用事件
以前的網頁很常見所謂的「滑鼠移入後會彈出子選單、移到某項目又跳出第三層選單」或是「點一下是進到內頁，滑鼠移過去是顯示下一層」的選單設計模式，但是在行動裝置上的操作方式只有點一下(click)、長按(hold click/taphold)、滑動(swipe)、縮放(zoom)、捲動(scroll)，跟電腦完全不一樣。要是sitemap 或是內頁次分類選單規劃得不好，有些頁面在手機上根本一輩子都點不進去。所以應該盡量避免規劃這種「滑鼠移入」才能跑出重要功能/訊息的功能。
事實上在手指點一下的時候，還能觸發 js mouseenter 事件，只是沒有 mouseleave 事件，所以東西會卡在畫面上藏不起來。hover 事件則完全不行。應急的話可把 hover 事件改成 mouseenter 事件。
另外現在很多購物或型錄網站，會在產品圖片製作所謂「放大鏡(zoomin)」功能，這種東西在行動裝置上用起來也是很痛苦，不如直接設定 user-scalable=yes，讓整個頁面可以放大。
所以這年代如果明知您的網頁都會用行動裝置、觸控螢幕瀏覽，還在提需求做一些「滑鼠移入」才能執行或顯示重要資訊的功能，要嘛就是想花錢然後做一個許多使用者都看不到的東西，或是想整使用者。
然後 RWD 網頁設計不是只仰賴螢幕大小做判斷，例如 iPad Pro 這麼大一台，但他還是不會有「滑鼠移入」(後來有囉！請見本文最下方本站相關文章)，之前流行什麼小筆電、EeePC，就是很小台的非觸控筆電，他卻有「滑鼠移入」，螢幕尺寸只是一個通則，詳細來說還是要考量裝置或瀏覽器是否支援某功能而定。
再偷偷補充一個 RWD 網頁設計常見的前端問題，遇到同事問這問題，瀏覽器還開著這篇文章，但我剛好沒提！例如網頁上用了一個 html select 元件，可能是付款方式、運送方式，選擇不同選項會讓頁面上跑出其他的訊息或 UI 內容，於是寫 select 偵聽事件 click 的時候判斷值，再執行剛剛講的跑出其他的訊息或 UI 內容，用滑鼠操作時看似相安無事，用瀏覽器開發者工具的模擬器操作，一樣很正常，但是用智慧型手機實機操作，怎麼選了選項之後，該跑的東西沒有跑出來？select, input radio, input checkbox, input file 請乖乖用 change/onchange，避免用鍵盤 tab 鍵操作、在行動裝置上，遇到各種怪現象。
7.只會自幹，不善用 Framework
有些開發人員喜歡享受自幹的成就感，自己寫 media query，定一堆 breakpoint，自己寫元件樣式，自己控制每種裝置上的容器寬度，什麼東西都能掌握在自己控制下的感覺是很好，但有時候可以用一些現成 framework。
如 JQuery Mobile, Bootstrap，裡面都有 grid system，或是一些刻好的現成元件，還幫你顧到一些基本的瀏覽器相容性問題，也蠻方便的。compass 或 sass 也可以引入一些別人做好的東西，不用通通自幹(前提是你知道引入的東西是幹嘛用的)。如有機會，可以用看看。
8.只會用 Bootstrap
有些開發人員半路出家，只會用 Bootstrap 之類的 Framework 來做出好像符合合約需求，但不知其原理，出問題也不知道如何排除，為了超乎 framework 的需求，硬幹改出上維護性與續用性非常差的網頁，埋下日後的地雷。用 Framework 沒關係，但要知道原理，例如為什麼 hidden-xs 會在螢幕寬 < 768 的時候藏起來，那為什麼是 768 而不是 689? 要改的話要去哪邊改?
這年頭網頁架構越來越龐大，網頁公司其實很少需要碰到從無到有做一個網站的情況，每個公司通常都有幾個充滿技術債的系統，例如「學校班級內容管理系統」「XX 行業網站內容建置系統」「OO 預約系統』「購物車含線上 ERP 電子商務系統」，有些很賺錢，有些是很賺錢的垃圾，有些是垃圾。通常內容都是一些民國初年就已經切好版的頁面內容，常常 framework 也套不上去，如要維護這些舊系統，當然還是要懂得相關的網頁技術。
當然如果要砍掉重寫的、團隊沒有歷史包袱的、沒有在接「舊網頁調整維護案」的、沒有考慮 IE11 使用者的、沒有考慮使用者還在用 iOS11、Windows XP的，網頁跑版無法正常顯示假日不會被 call 的，就盡量去用最新最酷的技術來寫網頁，OK的！
9.DRY原則
軟體領域有一個 Don’t repeat yourself（不要重複你自己，簡稱DRY）的開發原則，這個在網頁部分也稍許適用。
例如有些開發人員對於 CSS 的繼承、覆蓋觀念較弱，於是會發生控制平板區間螢幕寬度的 CSS，在手機上又寫一段一模一樣的，如有修改，就要一次修改好幾處，造成人力與時間的浪費。
善用 CSS 基本的一些繼承與覆蓋概念，可減少一些重複編寫的內容。如有幸遇到架構完整的系統，還可以將區塊配置(layout)、配色主題(theme)、功能性 UI元件的 CSS/SCSS 或功能模組完全分開，每次要用什麼就可以從之前寫好的地方引用進來，達成事半功倍、能者多勞、事情越快做完，就能得到越多工作量的效果。
10.效能問題
有些網頁為了趕流行，會製作一頁式網頁，或是使用 parallex scrolling 之類的效果，圖片非常多、載入流量非常大的網頁，或是中國流行的 H5 活動頁面，但成品製作出來後，會發現滑起來有頓感，或是頁面載入時間非常久，有時候可以唬爛說「Android 手機不夠頂級」、「Android 就是頓」「大陸手機才這樣，很快壞」「這邊遠傳的訊號不好」「伺服器該升級了」，但是當出錢的人拿的是最新款的 iPhone，出現頓感是不被允許的，這些責怪手機、責怪系統、把客戶當白痴的說法就不攻自破。
RWD 的概念之一就是同一份網頁程式，透過不同的樣式檔與媒體查詢指令，在不同裝置顯示不同樣貌的網頁。那必定在有些情況會有多餘的圖片、多餘的 JS 、多餘的 CSS、多餘的 HTML，多餘的 DOM，這些都要仰賴使用者端的網路去下載，仰賴使用者端的瀏覽器與硬體去計算並顯示，重繪(repaint)、重排(reflow)的次數一多，很容易造成網頁瀏覽卡頓。
例如古代常見的連結圖片取代法 text-indent:-9999px，會在網頁上產生一個寬 9999px 的容器，拖累效能。有些東西雖然是 display:none，但還是有被下載、執行，只是看不到。
常見的優化方法有以下幾種:
– 使用 lazyload 之類的程式，避免網頁一開始就下載所有內容。(缺點是有時候網路稍慢，文章都看完了，lazyload 的圖還在下載)
– 使用 Picturefill, Picture srcset 之類的技巧，避免小螢幕的裝置下載用不到的超大張圖片。
– 一些已知會造成效能問題的 css 不要再用 (如 text-indent:-9999px)
– 避免使用容易造成瀏覽器重繪/重排的寫法。(回流与重绘 « 张鑫旭-鑫空间-鑫生活)
– 製作動畫特效時，使用瀏覽器的開發者工具，比較一下 CSS3 或 JS 哪個執行效能較高。(MZhou’s blog – CSS vs JS动画：谁更快？)
– 部分內容改由伺服器後端 (server side) 產生，而不要把所有東西通通顯示在網頁上，再用客戶端語法去隱藏。可以讓你家工程師從 Detect Mobile Browsers 開始使用，要抓到平板記得加 |android|ipad|playbook|silk
– 像 Flipboard 的行動網頁版一樣，使用 Canvas 重新製作介面。(创新高性能移动 UI 框架-Canvas UI 框架)
還有常遇到的另一個例子，明明同一個網頁，3 年前的 android 低階手機滑起來很順，但是用當代最新款的 iPhone safari 卻覺得很難滑動、很卡、有黏滯感，不妨先在 body，或是覺得滑動不順的區塊，加上 -webkit-overflow-scrolling: touch;
11.position:fixed 的捲動抖動與頁面縮放問題
通常在上導覽列、下導覽列，或是一些側邊廣告，或是彈出區塊的背景圖層，會使用 position:fixed 的 CSS 語法，讓頁面不論滾動到何處，區塊都會固定在同一地方。
但是發現頁面快速滑動時，或是用手指壓著螢幕，上下移動頁面時，position:fixed 的區塊會亂跑，但是一鬆手，又會回到原處，可以在元素上加入 -webkit-transform: translateZ(0); 改善此抖動問題。
zoom in Bootstrap navbar-fix-top example
另外有一些網頁的內容會存在非常大張的圖片，所以會把網頁的 meta viewport 屬性設定為 user-scalable=yes，但是把網頁用手指一放大，會發生 position:fixed 的元素也跟著被放大，並蓋住網頁內容的情況(如上圖)。現今一般解法是用 JS 去偵測網頁 zoomin 事件，然後把 position:fixed 的元素縮回正常大小，但你知道的嘛，前端，一些奇巧淫技可能今天有用，一兩年後再回來看:「這誰寫的，一點用都沒用! 」
12.把選單通通藏起來就叫行動版網頁?
有些人喜歡套公式，覺得行動版網頁的「公式」就是把所有東西變成寬 100%，然後把按鈕、輸入框、連結間距通通變成超大，然後選單通通藏在三條線的圖案(hamburger icon)裡面。如果您的客戶都是 200 元作網站 / 500 元購物車開店等級的，那這三招就夠了，但是如果要達成行動網頁的完美體驗，這些是大大不足的。
行動版網頁一定要把選單通通藏起來嗎? 不妨先看看一些國外的研究案例，有人把選單通通藏起來，結果流量掉了超多
圖片來源: LukeW | Obvious Always Wins http://www.lukew.com/ff/entry.asp?1945
把選單項目通通藏起來有什麼不好呢? 有時候找不到想看的東西，會讓「點選單>等選單滑出來>捲動選單找呀找>點擊>等待載入…」這個流程重複發生，但如果把一些常用的連結放在外面，許多時候可以減少這種惱人的行為。也可以直接讓使用者看到這網站有哪些重點項目。
另外行動網頁的選單設計千變萬化，比如有水平滾動選單，網路上還有許多創意很棒的案例，多看，多學，多思考，別老想著一輩子套公式。
13.同一個 RWD 網頁，想要在行動裝置上顯示電腦版?
有些手機版網頁的設計模式會把網頁功能簡化，讓手機版網頁第一眼看起來高端大氣，但若規畫得不好，可能造成使用者今天可能在電腦上看過某頁，改天在外面用手機或平板該網站，卻怎麼找都找不到某內容。第一眼看起來簡潔大方，實際上用起來痛苦萬分，大概就像在台灣開跑車上路，結果刮到底盤的感覺。
有些網站比較早期做的，團隊的 RWD 技術可能不這麼純熟，或是網站架構龐大，要調整起來會變成政治問題，所以手機版跟電腦版是不同的網址、不同的程式，網頁最底下還有連結可以切換電腦版/手機版。既然 RWD 網頁是依照螢幕寬度來顯示對應的 CSS，是不是就無法做到切換電腦版/手機版的功能呢?
事實上還是可以的，RWD 網頁的開發人員，都知道起手式是設一個 meta viewport 屬性，根據這個原理，我們可以在「切換電腦版」的連結上寫觸發事件，以jQuery為例:
$(‘head’).append(‘< meta name=”viewport” content=”width=1280, initial-scale=0.5, maximum-scale=3.0, user-scalable=1″>’);
這樣瀏覽器會忽略原本的 < meta name=”viewport” content=”width=device-width…，改用後來 append 的內容。這樣網頁又會變成那種畫面超級小、需要一直縮放才能看的網頁。但是換頁的時候會跑掉，所以還要用 cookies 或其他方式去紀錄使用者是否曾經切換為電腦版。
這樣調整的目的通常是「讓慣用電腦版網頁的使用者，不需要重新學習網站的操作介面與版面配置」，但這樣做有時候毫無意義，有些網站裡面的選單內容是「滑鼠移過去才會顯示」，在觸控裝置上還是根本沒法用。或是網頁上有些功能是根據 UserAgent 去切換的，這樣並不會完全變回電腦版，還得要求使用者配上行動裝置瀏覽器的「要求電腦版網頁」來做 UserAgent 的切換。
14.網站版面 RWD 了，那後台建置的內容呢?
上述談的大半是網頁的版面、版型功能，都是網頁開發人員、設計人員的事。但現在常見的電子商務網站，或是一些經常需要更新內容，或是 SEO 內容行銷的網站，網頁裡有一大部分會需要從後台建置的，但企業內的網頁維護人員可能只會用表格工具來排版，或是只會用 phptoshop 的網頁切片工具、影像地圖之類的，或是把內容做成整張圖放上去，就會發生「版面在電腦上看起來好好的，可是在手機上就亂掉了啊!」的狀況。
解決方法百百種，常見的如
– 付錢給網頁公司，花錢消災，請他們幫你上資料
– 找新的網頁公司重作網站(true story)
– 擺爛不管它
– 請編輯人員自己去學 HTML 與 CSS
– 開一個什麼都要會的職缺，然後用面試找免費勞工調網頁。
但有些編輯器非常陽春，media query 的 css 存檔時會被過濾掉，更是難以排成自己想要的樣子。那直接做一整張圖放上去好了? 但是圖片在 iPad 上面看起來糊糊的，還會讓網頁載入很久，更會被人說不利於 SEO，到底該怎麼辦呢?
淘寶後台商品介紹編輯畫面，分為電腦端與手機端，兩邊的編輯器工具列也完全不同。
事實上現在一些比較進步的 CMS 或購物車系統，都會有手機版與電腦版的資料分開建置的功能，有人會想說「同一份資料要上兩次，是要增加我的工作量嗎?」但比起可能手機版調好了，電腦版又亂了，或是老是在把瀏覽器視窗拉大拉小測試。
還有如上圖左邊這種情況，電腦上看也許很漂亮，但在手機上完全不知道圖片裡寫了啥，手機上顯示的內容當成 DM 來做，然後畫面還不能縮放。反觀右邊的詐騙廣告在手機上就看得簡單清楚。看完這個案例，還要堅持大螢幕小螢幕用同一張圖片?
為了讓載入速度最佳化，版面顯示最佳化，兩邊分別建置資料會是更為理想的作業流程。像淘寶、開店 123 都有這種功能。那些只會用表格排資料的人員，終於可以告別資料在電腦上看起來漂漂亮亮，在手機上看起來大爆炸的夢魘了。
15.手機上的圖片被擠壓變形
一般人還是很難接受資料要上兩份這件事，所以最後還是一魚兩吃，這時候可能有一張圖片是長這樣 <img src="abc.jpg" style="width:1200px'height:600px">
但是在手機上看，圖片完全跑到畫面外了！
於是我們請文章編輯人員上圖片時不要設定寬高，或是請他上稿的時候，每張圖片要再加上 class=”img-responsive”，甚至在文章區加上 CSS article img{width:100%}
跟您保證，這些叫上稿人員自己加東加西的方法都很爛，最後還是網頁人員要出來收拾殘局。
比較一勞永逸的做法是加 img {max-width:100%;height:auto !important}
讓大張圖片寬度變成 100%，小張圖片還是原來的大小，讓圖片高度等比例縮放。
不只是 img，還有 table, iframe 也都要做相關的思考與處理。
16.電話號碼造成網頁在 iOS 跑版
首先要知道一個小功能，聰明 iOS 會自動將網頁上的電話號碼轉為可點擊的超連結，Android 比較沒有這麼智慧，電話號碼不會變成超連結的樣式，但是如果用手指去點，作業系統一樣會詢問「您是否要撥打電話?」
這個聰明的小功能會造成網頁在 iPhone 上面發生神秘的情況，但是在電腦上、在 Android 手機上，Google Chrome 的行動裝置模擬器看起來很正常，例如：
1.網頁是黑底白字，結果用 iPhone 一看，有電話號碼的地方變成藍色，而且有底線，看起來就跟預設的超連結樣式一樣，在此案例中，黑底藍字的對比度讓易讀性變得非常差，還讓網頁出現非預期的顏色，所以務必要記得再額外定義 a 的 css。 所以如果行動版網頁會有電話號碼資訊，避免混淆或誤點，還是記得把電話號碼純文字改成超連結，然後加一下 CSS 樣式。
2.html 的 markup 包法跟命名、或是 css selector 寫得有待加強，可能是網頁新手，或是客戶的歷史遺毒常發生，例如 css 直接下 .footer 裡面的 a 為 display:block，可能是要幫 .footer 裡的 go-top 按鈕設個樣式之類的，在電腦上、在 Android 手機上，Google Chrome 的行動裝置模擬器都好好的，但是用 iPhone 看網頁，.footer 裡面聯絡資料竟然發生了超乎預期的斷行？這又是同一個問題，footer 裡的電話號碼或某些數字被轉為 a tag，然後吃到 footer a 的 display:block…
3.網頁上有一串數字，可能是傳真號碼、訂單編號、產品型號、規格資訊、瀏覽人次、通關密語……總之就不是電話號碼，但又被系統自做主張硬加上電話的超連結，點了就可以撥號打出去，要如何解決呢? 可以在 meta 加入 < meta name=”format-detection” content=”telephone=no”>，停用這種自作聰明的轉換。然後網頁編輯人員再幫真的電話號碼，手工加上超連結。
結語
網頁設計基本上是一個得同時兼顧舊裝置，又得不斷學習新技術的行業，開發人員的失誤，可能造成團隊與公司的損失，也可能造成使用者的流失，不可不慎。
除了技術面的問題，還有使用者體驗面，也就是 Mobile Friendly 的問題，一個網頁是否真的好用? 不妨親自操作一遍看看用起來有多痛苦。但是有些人會問，一個網頁好用不是基本的嗎? 為什麼使用者體驗還要另外要求? 給多少錢，做多少事啊!
另一個問題是許多網站或商業產品，背後是一大個團隊經過許多歷程和時間打造出來的。然後今天叫外包公司出一兩個人力，給幾毛錢和一丁點時間，就想達到同樣的水準?
延伸閱讀
- Google 行銷人士寶典：25條行動網站設計的必備原則
- URL Schemes 使用详解
- UIPatterns.io | Curated list of interactive mobile design patterns