這是 一篇 2010 年的文章，很老了。翻譯完這篇文章後，我感覺對於移動網頁的開發。我多想了兩個問題：變模糊？字型使用 em 而不是畫素？這根本就不是一開始就應該擔心的事情。作為網頁開發人員，我只要知道能從手機螢幕上得到多大的使用空間就行了，其他問題都會順其自然的發現並解決的。還有一點：當設定新的 iphone 即將面世，它採用 960x640，而不是 480x320。昨天 john gruber 解釋了蘋果為什麼要這麼做。他也想知道這會給網頁開發者帶來什麼後果。
碰巧我最近也在跨瀏覽器地研究手機的寬度和高度。並且可以合理的確定，這些變化對網頁開發者的影響僅有 1%。
這剩下的 1% 是個很棘手的問題，但蘋果可以通過插入乙個中間畫素層（intermediate layer of pixels）來解決這個問題（john 提到在 android 中已經存在這個層了）。
我知道網頁開發者的關注點在**----css 畫素----也就是在 css 宣告裡的"畫素"，比如：width: 300px和font-size: 14px。
其實，css 畫素跟實際的裝置畫素密度（actual pixel density of the device）沒有關係，甚至與中間畫素層都沒有關係。它們本質上是專門為網頁開發者建立的抽象單元（abstract construct）。
我們拿縮放（zooming）來通俗地解釋上面這句話。當使用者做放大操作時，width: 300px的元素會佔據越來越多的螢幕空間，於是使用裝置（物理）畫素測量時就變得越來越寬。但以 css 畫素的角度考慮，元素的寬度始終保持在 300px。這裡的縮放效果根據需要擴張了 css 畫素。
當縮放因子（zooming factor）是 100% 的時候，1 css 畫素等於 1 裝置畫素（雖然即將到來的中間畫素層會取代裝置畫素的位置）。下面的就描述了縮放 100% 的情況，看不到效果的原因，1 css 畫素和 1 裝置畫素完全重疊了。
（需要提醒你的是，"縮放 100%"在 web 開發中沒有什麼意義。縮放級別對我們來說不重要，我們需要知道的是現在有多少 css 畫素容納在螢幕上。）
下面兩張顯示了當使用者做縮小、放大操作時發生的情況。第一張顯示的是當使用者縮小時的裝置畫素（深藍色背景）和 css 畫素（淺藍色前景）----css 畫素變小了，1 裝置畫素交疊了幾個 css 畫素；第二張顯示的是使用者放大時的裝置畫素和 css 畫素----1 css 畫素交疊了幾個裝置畫素。
因此，width: 300px的元素總是 300 css 畫素寬，而它等同於多少裝置畫素則取決於縮放因子。
（在手機上，使用screen.width除以window.innerwidth就可以得到縮放因子。但這存在瀏覽器相容問題，希望在不遠的將來有關於這方面的完整報告出現。作為一名網頁開發者如果對縮放因子不關注的話，但要知道裝置螢幕裡到底可以容納多少（裝置或 css）畫素。）
這個系統不會改變。如果改變了，所有針對 iphone 優化的**都會立即廢掉。這是蘋果不惜一切代價要避免的。
因此，乙個完全縮小的**仍然顯示為 980 css 畫素，它等於多少裝置畫素對我們來說不重要。
有兩個棘手的問題：device-width**查詢（media query）和標籤。這兩者都是與裝置畫素協作的，而不是 css 畫素。因為它表達的是頁面上下文，而不是內部的 css。
device-width**查詢測量裝置寬度，以裝置畫素統計。width**查詢測量的是整個頁面的寬度，以 css 畫素統計，原因我以後解釋，在 iphone 上width至少是 980px。
device-width**查詢的工作方式如下：
div.sidebar
@media all and (max-device-width: 320px)
}
順便提一下，理論上可以使用厘公尺或者英吋來查詢裝置螢幕（@media all and (max-device-width: 9cm)）。不幸的是，包括 iphone 在內的裝置對此的支援都不太好。這兒的問題是，像英吋這樣的物理單位（physical units）通常轉換為 css 畫素。我測試了迄今為止所有的瀏覽器，測出width: 1in基本等於width: 96px。所以這些**查詢是不可靠的。
一般來說很有用。這個標籤最開始是蘋果專有的，現在越來越多的瀏覽器都支援了，它實際的布局檢視（layout viewport）正好適合裝置。
那什麼是布局檢視？瀏覽器使用百分比寬度計算元素尺寸、並且使用 css 畫素計算的一塊區域。例如div.sidebar。它通常比裝置螢幕大些：在 iphone 上是 980px，在 opera 上是 850px，在 android 上是 800px 等。
使用了後，布局檢視的寬度被限制為裝置畫素所表現的裝置寬度。在 iphone 中是 320。
這樣設定後，頁面就會變得足夠窄以適應螢幕大小。下面這張是沒有使用 csswidth語句和標籤的情況，整個裝置螢幕延伸到布局檢視的可用寬度。
這或許不是你想要的，你希望堂文字在螢幕上合適的顯示，這就是要完成的工作----整個視口縮小（在 iphone 中是 320px），文字得以合適的顯示。
現在，蘋果的解析度變化對device-width**查詢和標籤會造成什麼影響？我還不清楚，但我認為對網頁開發人員不會有任何改變。
標籤最容易解釋。蘋果特意發明了它，是為了讓人們能夠在 iphone 螢幕上適用他們的內容，並把它推給了開發者。就是說，現在標籤讀出來的裝置寬度是無法改變的。
事實上，nexus one 已經為蘋果公司開闢了一條新的道路。其官方螢幕寬度（縱向模式）是 480px，但是當你使用標籤查詢時，顯示螢幕寬度 320px，也就是官方寬度的 2/3。如果我理解正確的話，這就是 john gruber 所說的關於 nexus 顯示缺少乙個子畫素，也就是少了 1/3 的畫素。這正好符合 nexus 對` 標籤的準確解釋。
google 已經插入了乙個被稱為 dips 的圖層，即裝置獨立畫素（device-independent pixels）。此層位於官方螢幕大小和 css 畫素（網頁開發人員接觸的）之間。
我期待新版 iphone 複製 nexus 的方式，當使用標籤進行**查詢時，報告出來的螢幕尺寸是 320px（也就是解析度寬度的一半）。之所以不是三分之二，是因為新版 iphone 畫素密度高於 nexus。
這使得device-width**查詢成為唯一的問題區域。在 nexus 上它使用 480px 作為螢幕寬度，但 320px 可能更合適。我們得看看蘋果是怎麼做的。
更為根本的問題是，dips 是否將用於**查詢。總的來說，對於網頁開發者來說，正式的裝置大小不重要，而是想知道我們能從螢幕上得到多少內容，而且 dips 好像是最適合的。
不幸的是，nexus 現在沒那麼做。**查詢的裝置寬度仍顯示 480px，而不是 320px。但也許蘋果可以為網頁開發人員解決這個問題。
所以，現在的情況是，對於正常的乙個 web **我們清楚，對標籤的使用我們也清楚。但遇到**查詢時，我們就不清楚了。
session之此session非彼session
此session非彼session之session理解 問題描述，在j2ee專案開發中我們常常用到session物件，乙個是struts2中的session，乙個是hibernate中session，那麼這些session有什麼區別呢？技術核心 session是一種高效的 實用的快取機制，它是用作不...
overflow屬性，此溢位非彼溢位
有四個值 visible 預設值 scroll，hidden和auto。scroll值能阻止內容溢位，但會增加出滾動條，通過拉動滾動條可以瀏覽所有內容。auto 如果內容溢位被限制，則會新增乙個滾動條，使超出的內容可以通過滾動展示出來。hidden 隱藏掉內容溢位的部分，溢位的內容將不可見。當文字超...
畫素縱橫比基礎知識（正方形畫素，非正方形畫素）
畫素縱橫比是指畫素的寬 x 與高 y 之比。正方形畫素的比例為 1 1，但非正方形 矩形 畫素的高和寬不相同。這一概念類似於幀縱橫比，後者是影象的整個寬度與高度之比。通常，電視畫素是矩形，計算機畫素是正方形。因此，在計算機顯示器上看起來合適的影象在電視螢幕上會變形，顯示球形影象時尤其明顯。在 mic...