使用 user agent 和 meta viewport 的目的和造成的影響

對行動瀏覽器和網頁的開發者來說，都希望提供最佳的使用者體驗, 不過彼此在意的事有點不同。

瀏覽器在意的事：

• 用 user agent 告知網站自己是什麼瀏覽器, 讓網站有機會提供最佳的內容。
• 也提供切換 user agent 的選項，若網站自動提供行動版網頁, 而使用者想看桌機版網頁時, 可換用桌機瀏覽器的 user agent 「騙」網站提供桌機版的網頁。
• 如果頁面有用 meta viewport 設定 layout width=device width, 表示網頁有針對 device width 作最佳化, 照著辦就是了。
• 承上, 不過若網頁沒作好, 比方說在頁面裡寫死某個元件寬度, 寫死寬度的元件仍會超出螢幕寬度, 看起來怪怪的。
• 若沒有設 layout width=device with, 表示網頁開發者沒有針對行動裝置作最佳化, 至少要用夠寬的 layout width (>螢幕寬度), 不然網頁內容會縮成一團無法閱讀 (就像在桌機將瀏覽器視窗縮到很窄一樣)。常見的實作寬度是 980px 或 1024px。
• 承上, 因為手機螢幕比 layout width 小, 載入完頁面後使用者無法一眼看到網頁全貌, 瀏覽器會自動縮小 (zoom out) 頁面以貼齊螢幕寬度。預期使用者可以先看見全貌, 找到有興趣的地方，再自行放大 (zoom in) 想看的部份。

網站開發者在意的事：

• 透過 user agent 得知使用者用什麼裝置和瀏覽器。粗略分成行動裝置和桌機 (PC 或筆電) 兩種。後者通常計算能力強、網路快、螢幕大，可提供豐富內容。另外提供前者客制化的網頁，以提供更好的使用體驗。
• 桌機網頁也可使用 Responsive Web Design (RWD), 讓大螢幕有更好的使用體驗 (但不會在意螢幕太小的表現)。不需使用 meta viewport (用了也會被桌機瀏覽器忽略)。layout width 由視窗寬度決定。
• 行動網頁必須使用 meta viewport 要求瀏覽器用 device width 作為 layout width, 不然瀏覽器會用 980px 或 1024px 排版, 結果是字縮得太小 [*1]，使用者得放大縮小外加水平捲動觀看內容, 用起來不方便。最好使用 RWD 應付不同手機的不同寬度。不然就要用比較窄的寬度為基準來排放內容, 然後在兩側或右側留白，看起來比較遜。
• 沒餘力搞兩套網頁就用 RWD 一套通吃。雖然排版難度變高許多, 但不用寫兩套網頁流程, 應該會比較省事? 除了排版技術較深外, 可能因此對手機裝置多傳了些用不到的資料，浪費頻寬甚至拖慢載入速度。

在手機上用 desktop user agent 看到奇怪的排版內容，可能的原因:

• 網站在桌機網頁用了 meta viewport, 但沒處理好 layout width 較窄的情況。可能的原因是同一網址會依 user agent 提供不同內容: 若是手機瀏覽器的 user agent, 就提供行動版網頁, 因此沒有測到「在手機上用 desktop user agent」的情況。
• 網站自己有作好 RWD, 不過嵌入其它家服務的內容 (如廣告) 出槌。出槌的原因是提供內容的網站是看 user agent 決定內容, 因此提供太寬的內容而超出螢幕寬度。若嵌入的內容有依 layout width 提供內容就沒問題了。

參考資料

• Meta viewport - QuirksMode

備註

1. 行動瀏覽器有提供 "text reflow" 的功能, 會在不改變排版的情況下, 自動放大太小的字。好處是在手機上用 980px (或1024px) 排版後，不用放大就可以看清楚主要的內文。壞處是部份內文變得比標題大, 看起來怪怪的。

印象中是 2012 或更早就有的功能, 當時看起來頗酷的也不錯用。不過在 RWD 盛行後, text reflow 大概會愈來愈少發揮效果。在行動瀏覽器 (如 Chrome 或 Puffin) 用 desktop user agent 看 Mobile 01 內文, 會看到 text reflow 的效果了。

說明瀏覽器運作相關的文章

備忘一些不錯的概念文章:

• WebKit for Developers - Paul Irish: 說明各家使用 WebKit 的瀏覽器到底共用的 WebKit 是什麼。另有附一份 slide 說明 "How WebKit Works", 不過 slide 講的內容就很少了。
• How browsers work, 2011 年的文章, 說明瀏覽器運作的每個步驟

https 到 http 沒有 referrer

筆記一下讀到 BobChao the Blogger: HTTPS 的 referrer 狀況筆記 的心得和延伸想法。

近年來強調安全瀏覽, 大網站倡導全程使用 https 連線, 但是從 https 連到 http 時不會傳 referrer, 原因應該是 https 全程加密, 若從 https 連到 http 時有加 referrer, 會讓原本外部不知道的網址流出去。比方我先點 https://a.b.c/, 然後點網頁內連結到 https:/a.b.c/secret.html, 再點連結到外部的 http://x.y.z/, 這樣 x.y.z 網站就會得知 https:/a.b.c/secret.html。

但令我不解的是 https 連到不同網域 https 時, 還是會送 referrer, 所以上述的推論要修正成: 防範的對像不是 x.y.z, 而是其它用 http 的網站 (??) 以及竊聽封包的人。全程使用 https 不會被竊聽到網址, 而最後一步從 https 到 http 時, 若有設 referrer, 就會被竊聽得知。這是我目前想得到唯一合理的解釋了, 雖說我還是覺得沒什麼道理, 挺多 a.b.c 要連到別的網站時, 即使有 https 可用, 仍可選擇 http 以避免送出 referrer, 但這顯然和現今大家關心的方向相反。

於是, 為了兼顧安全性, 以及網站能正確統計 referrer, Google 和 Facebook 會先跳到內部同網址的 http 連結, 再轉到外面 http 的連結。雖然會多加一個 click 增加內部成本, 但為了能讓其它網站了解本站 (Google / Facebook) 為他們帶來的可觀流量, 仍是值得花的代價。

設定 viewport 的寬度為 device-width 以支援各種 mobile browser

好歹也是花了一些時間看的東西, 備忘一下。

《The orientation media query》

• orientation (landscape or portrait) 不是重點, 重點是螢幕寬度到底是幾 pixel
• 結論: 用 device-width

《Mobile web design viewport size vs screen resolution - viewport META tag》

• 詳述 viewport 為何, 覺得重述一次意思會不對, 還是請大家看原文吧
• mobile device 的 viewport 大小不見得和 screen 大小一樣 (桌機則是一致)
• 有些 mobile browser 像 mobile Safari 藉由讓 html 畫在較寬的 viewport 上, 再將它縮放到符合螢幕寬度, 藉此顯示整個網頁的大概樣子 (有時稱為 overview mode)。也就是說, 網頁會依 viewport 的寬度來 render, 而不是 screen 寬度。對桌機來說兩者寬度一樣, 所以不會混淆
• 各家 mobile browser 預設的 viewport 大小不同, 造成寫網頁的人的困擾
• 可用 <meta name="viewport"content="width=1100"/> 改變預設 viewport 寬度
• 可用 <meta name="viewport"content="width=device-width"/> 將 viewport 設為 device 寬度
• 舊手機不支援上述語法, 該連結有提到其它備案

《device-width and how not to hate your users》

• 可用 CSS 3 新語法 media-query 針對螢幕寬度決定使用的 CSS rules。對於桌機不同的螢幕寬度來說, 這是個好解法, 不用擔心使用者用 24" 寬螢幕還是 19" 一般螢幕。
• mobile device 另有 viewport 大小不同 screen 大小的特色, 所以使用 media-query 的話, 要再配合限制 viewport 寬度為 device-width, 才可確保用對 CSS rules

試改 Chrome Extension

extension Create Link 滿好用的, 可以自定取出網址和網頁標題的格式, 方便貼到 blog 或是 plurk。美中不足的是, 它沒支援短網址。有不少 extension 提供短網址服務, 可惜沒提供像 CreateLink 那樣自制的格式, 讓我能按一個鍵就取出短網址並以我想要的格式排版。比方說按個鍵產生 "SHORT_URL (TITLE)", 就能直接貼到 plurk 上了。

看了一下 Shorten URLs 和 Create Link 的程式碼後, 決定抽出 Shorten URLs 產生短網址的程式碼, 加到 CreateLink 裡。比想像中簡單許多, 懂 JavaScript 的話, 只要了解 Chrome Extension 的規範, 就能輕易上手。不過不知是不是 Chrome 的問題, 有時 Extension 會沒反應, 但重開 Chrome 就好了。

改完的結果在這裡, 整個修改流程如下:

1. 閱讀 Chrome Extension 的入門教學。照著做一遍就會了, 再看一下如何除錯就能上工了。
2. 在 github 上 Fork CreateLink 的專案, open source 真好啊。
3. 在 Windows 上用 TortoiseGit 連 github, 這一步花掉我最久的時間, 實在是很挫折的事。參考官網說明。途中遇到不少問題, 最後不知怎麼弄對了, 懶得理了。下回考慮用 andLinux 連 github。不過這樣得溫習 git 的指令, 原本就是懶得查指令, 結果讓 TortoiseGit 能和 github 連線, 反而花了更多時間...。
4. 載入本機未封裝的 CreateLink, 改一下 manifest.json, 確定自己的修改有發揮作用。個人認為改程式時, 這是最重要的第一步, 愈早完成愈好。
5. 看一下 Shorten URLs 的程式明白怎麼用 XmlHttpRequest 透過 GET 連網站, 再查一下相關參數說明, 將 async 設成 false 即可。將程式寫成等三秒沒結果就放棄短網址改用原網址。原本有考慮用 jQuery 做, 看到原作者全部檔案加起來都比 jquery-1.4.2.min.js 小 (34.2KB vs. 70.4KB), 就打消這個念頭了。
6. 為了能用 JavaScript 連 tinyurl 使用它的 API, 得在 Chrome Extension 裡允許 cross site javascript, 參考官網說明輕鬆解決。
7. Create Link 程式寫得很乾淨, 改起來很容易。最後卻是花了不少時間將改完的結果 push 回 github。

第一次改別人的程式並 push 回 open source repository (雖說只是 push 回自己的啦), 還有寫瀏覽器擴充套件, 滿有意思的。最後, 就用剛才改好的 CreateLink 產生連結貼到微網址吧!!