- From: John Mellor <johnme@chromium.org>
- Date: Thu, 6 Jun 2013 11:47:33 +0100
- To: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
- Cc: Simon Pieters <simonp@opera.com>, Tobie Langel <tobie@w3.org>, public-webapps <public-webapps@w3.org>, Mounir Lamouri <mounir@lamouri.fr>, David Bruant <bruant.d@gmail.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Message-ID: <CAG_kaUYYu3upm0rFxpQ0hs5C5jesoavYSAbkmeQzMp3ubhCfkA@mail.gmail.com>
I think what I'm trying to say is that "CSS px units ... independently of the document scale" should be termed "DIPs", and "CSS px units ... given the current document scale" should be termed "CSS pixels", and that it's clearer to think of these as two separate pixel units. And regardless of naming, specs (especially CSSOM View) should clarify which of the two they mean when they talk about CSS pixels. On Thu, Jun 6, 2013 at 11:37 AM, Kenneth Rohde Christiansen < kenneth.christiansen@gmail.com> wrote: > You can say that screen.width expresses the screen size in CSS px > units and independently of the document scale, unlike > window.innerWidth which expresses the amount of CSS px units > (horizontally) of the document which you see given the current > document scale. > > Maybe you have suggestions for how to clarify this in the specs? > > On Thu, Jun 6, 2013 at 12:32 PM, John Mellor <johnme@chromium.org> wrote: > >> The innerWidth is showing how many CSS units you are seeing of the > >> contents inside the viewport > > > > I agree. My point was that screen.width is measured in DIPs not CSS > pixels, > > and hence screen.width often returns different values from > window.innerWidth > > -- depending on zoom and viewport -- even though screen.width and > > window.innerWidth are both measuring the same distance: the width of the > > device. > > > >> not device units > > > > Indeed, nothing exposed to the web should be in device pixels (the very > > existence of device pixels should only be detectable using the device > pixel > > ratio, which exposes the ratio between device pixels and DIPs, and things > > like CSS4 image-set). > > > > > > On Thu, Jun 6, 2013 at 11:21 AM, Kenneth Rohde Christiansen > > <kenneth.christiansen@gmail.com> wrote: > >> > >> Hi there > >> > >> On Thu, Jun 6, 2013 at 12:15 PM, John Mellor <johnme@chromium.org> > wrote: > >> > There is a distinction to be made between DIPs and CSS pixels. Take a > >> > portrait iPhone 4 for example: > >> > - screen is 640 device pixels wide > >> > - device pixel ratio is 2 > >> > > >> > CSS pixels are affected by pinch zooming: > >> > > >> > If you use <meta name="viewport" content="width=device-width, > >> > initial-scale=1"> then: > >> > - screen.width is fixed at 320 DIPs > >> > - document.documentElement.clientWidth is fixed* at 320 CSS pixels > >> > - window.innerWidth is initially 320 CSS pixels, but decreases when > the > >> > user > >> > pinch zooms in, since zooming in makes CSS pixels larger, and hence > less > >> > of > >> > them fit onscreen at once. > >> > >> The units are still in CSS units. If you query the > >> (-webkit-device-pixel-ratio) it will still be 2. The innerWidth is > >> showing how many CSS units you are seeing of the contents inside the > >> viewport,, and that is still calculated in CSS units, not device > >> units. > >> > >> > CSS pixels are also affected by viewports: > >> > > >> > If you have no meta viewport or @viewport rule, then mobile browsers > >> > will > >> > set your page width to a fallback value of around 980 CSS pixels, and > >> > so: > >> > - screen.width is still fixed at 320 DIPs > >> > - document.documentElement.clientWidth is fixed* at 980 CSS pixels > >> > - window.innerWidth is initially 980 CSS pixels, but decreases when > the > >> > user > >> > pinch zooms in. When zoomed to a scale of 1, CSS pixels are the same > >> > size as > >> > DIPs, window.innerWidth is 320, and content is now as legible as it > >> > would > >> > have been if width=device-width had been used. > >> > > >> > *: the reason that document.documentElement.clientWidth remains fixed, > >> > even > >> > though it's unit is CSS pixels, is that when you zoom you're no longer > >> > measuring the same distance, instead the distance being measured (the > >> > page > >> > width) scales in proportion to the page. > >> > > >> > > >> > On Thu, Jun 6, 2013 at 10:04 AM, Kenneth Rohde Christiansen > >> > <kenneth.christiansen@gmail.com> wrote: > >> >> > >> >> As I understand it, the CSS specs never refer to device pixels, but > >> >> always to CSS pixels which are basically your DIPs, so the confusion > >> >> only arises from the fact that browsers did DPI adjustment (upscaled > >> >> the content to use real CSS values in CSS units - aka DIPs) but > forgot > >> >> to do it for everything. > >> >> > >> >> As Apple did the upscaling in their core system/toolkit, everything > >> >> stayed in CSS units from day one, where as other browsers such as > >> >> Android and Qt (Nokia N9) did the upscaling in the browser itself and > >> >> forgot to adjust all web facing values. > >> >> > >> >> Kenneth > >> >> > >> >> On Wed, Jun 5, 2013 at 4:34 PM, John Mellor <johnme@chromium.org> > >> >> wrote: > >> >> > Sounds reasonable. I think the main things that are missing are > >> >> > explanations > >> >> > of the knock-on effects of Device Adaptation (and the meta viewport > >> >> > tag). > >> >> > > >> >> > For example the CSSOM View module claims that all its dimensions > are > >> >> > in > >> >> > CSS > >> >> > pixels. But if you look at what mobile browsers return for > something > >> >> > like > >> >> > screen.width, they either return Device Independent Pixels (DIPs) > or > >> >> > physical device pixels. It's only for things like window.innerWidth > >> >> > that > >> >> > mobile browsers actually return a value in CSS pixels. Now, > returning > >> >> > DIPs > >> >> > does in fact best match the intent of the spec for screen.width > >> >> > (indeed > >> >> > the > >> >> > definition of a CSS pixel is actually the definition of a DIP, and > >> >> > they > >> >> > used > >> >> > to be the same thing until pinch zoom and viewports made them scale > >> >> > independently); but the CSS specs need to accept that there are > more > >> >> > kinds > >> >> > of pixels than there used to be, and fix these ambiguities, if we > >> >> > want > >> >> > mobile browsers to converge on a single behaviour. > >> >> > > >> >> > > >> >> > On Wed, Jun 5, 2013 at 2:59 PM, Kenneth Rohde Christiansen > >> >> > <kenneth.christiansen@gmail.com> wrote: > >> >> >> > >> >> >> I think it should be. You think anything is missing? > >> >> >> > >> >> >> Kenneth > >> >> >> > >> >> >> > >> >> >> On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters <simonp@opera.com> > >> >> >> wrote: > >> >> >>> > >> >> >>> On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen > >> >> >>> <kenneth.r.christiansen@intel.com> wrote: > >> >> >>> > >> >> >>>> I support adding some CSSOM API's for CSS Device Adaptation, > but I > >> >> >>>> would > >> >> >>>> not do so for the viewport meta tag, which has its share of > >> >> >>>> issues. > >> >> >>> > >> >> >>> > >> >> >>> There's currently > >> >> >>> http://dev.w3.org/csswg/css-device-adapt/#dom-interfaces > >> >> >>> > >> >> >>> Is that sufficient? > >> >> >>> > >> >> >>> -- > >> >> >>> Simon Pieters > >> >> >>> Opera Software > >> >> >>> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Kenneth Rohde Christiansen > >> >> >> Senior Engineer, WebKit, Qt, EFL > >> >> >> Phone +45 4294 9458 / E-mail kenneth at webkit.org > >> >> >> > >> >> >> ﹆﹆﹆ > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Kenneth Rohde Christiansen > >> >> Senior Engineer, WebKit, Qt, EFL > >> >> Phone +45 4294 9458 / E-mail kenneth at webkit.org > >> >> > >> >> ﹆﹆﹆ > >> > > >> > > >> > >> > >> > >> -- > >> Kenneth Rohde Christiansen > >> Senior Engineer, WebKit, Qt, EFL > >> Phone +45 4294 9458 / E-mail kenneth at webkit.org > >> > >> ﹆﹆﹆ > > > > > > > > -- > Kenneth Rohde Christiansen > Senior Engineer, WebKit, Qt, EFL > Phone +45 4294 9458 / E-mail kenneth at webkit.org > > ﹆﹆﹆ >
Received on Thursday, 6 June 2013 10:48:19 UTC