譯文 此畫素非彼畫素,非彼畫素

2022-07-24 11:00:16 字數 4317 閱讀 8992

這是 一篇 2010 年的文章,很老了。翻譯完這篇文章後,我感覺對於移動網頁的開發。我多想了兩個問題:變模糊?字型使用 em 而不是畫素?這根本就不是一開始就應該擔心的事情。作為網頁開發人員,我只要知道能從手機螢幕上得到多大的使用空間就行了,其他問題都會順其自然的發現並解決的。還有一點:當設定後,1 css 畫素等於 1 裝置畫素了,也就是說 css 畫素基本就等同於裝置畫素了。

新的 iphone 即將面世,它採用 960x640,而不是 480x320。昨天 john gruber 解釋了蘋果為什麼要這麼做。他也想知道這會給網頁開發者帶來什麼後果。

碰巧我最近也在跨瀏覽器地研究手機的寬度和高度。並且可以合理的確定,這些變化對網頁開發者的影響僅有 1%。

這剩下的 1% 是個很棘手的問題,但蘋果可以通過插入乙個中間畫素層(intermediate layer of pixels)來解決這個問題(john 提到在 android 中已經存在這個層了)。

我知道網頁開發者的關注點在**----css 畫素----也就是在 css 宣告裡的"畫素",比如:width: 300pxfont-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)

}

現在側邊欄是 300 css 畫素寬,當裝置寬度小於 320px 時,就變成 100 css 畫素寬了。

順便提一下,理論上可以使用厘公尺或者英吋來查詢裝置螢幕(@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...