Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Thursday, July 4, 2013 at 4:20 PM, Mounir Lamouri wrote: On 24/04/13 11:13, Tobie Langel wrote: While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. (First, I am so sorry for the huge delay...) Np. Thanks for getting back to me on this. :) I think we should not use CSS Device Adaptation to set the orientation. I am actually not sure how well CSS would handle media queries to have rules based on the orientation and setting the orientation from CSS. Wouldn't we risk to end up in an infinite loop? Seems this is handled in section 7 of the spec[a]. Honestly, I don't have enough background in this area to assess how well. In addition, with the current work of having manifest files applying to regular web pages [1], we can hope that web pages that want to have a specific orientation could simply use a manifest file. I think using a manifest could be a good solution for that kind of use cases [2]. I don't really have an opinion here, except I'd love to see implementors converge on a solution and implement it. :) This said, how do you expect the orientation to work when set declaratively? Should the declaration be set as soon as authorised (on Firefox Android, that means being fullscreen [3])? It might provide an odd user experience. An alternative would be to only fulfil the declarative orientation if the page is allowed to set it at load time. If authorization is required, I'd imagine the app would be launched fullscreen with a modal dialog / overlay requiring user authorization. If denied the browser would fallback the regular display mode (with chrome). Best, --tobie --- [a]: http://dev.w3.org/csswg/css-device-adapt/#media-queries
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Wed, Apr 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen kenneth.r.christian...@intel.com wrote: Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. 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. I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. IMO, this would be a much more clean and easy to understand solution than providing a separate API for orientation lock. It would also remove 1 unknown element when game developers try to juggle mappings between xyz-accelerometer data vs media query orientation vs device normal orientation (as some propose to have natural landscape and natural portrait devices - something I really think would just add to the confusion). Allow me to quote myself from an earlier other thread on a proposed orientation lock API: As long as both MediaQueries, xyz-accelerometer data, orientation lock and more *all* are aligned, this could work. However, we need to have this tested with a bunch of developers - to see where they make mistakes caused by possible confusion. My own opinion on this is still to keep it in a specific orientation also (e.g. portrait up) as 0 degrees, as it makes everything more easy to handle when the basics are kept static. I can tell you that even inside the same company (mobile phone manufacturer), I have seen mistakes in the mapping of the xyz-accelerometer values *alone* between units coming from slightly different branches. This was because some were landscape devices and some were portrait and everything have to match from the low level HW to the high level javascript API. If we make sure that a device - no matter how the rest of the UI is turning - is always considered 0 degrees when held - e.g. portrait up, (x,y,z) = (0,1,0), then: 1. non-game developers can be happy with lock to landscape and never need to worry about the inner workings and 2. game developers (using the accelerometer) won't have to reinvent strange mappings when juggling media queries, accelerometer and orientation lock. If we allow natural landscape units and natural portrait units - then in some cases, when in a landscape locked game, the gravity goes in the direction of negative X - and in some cases it goes in the direction of negative Y. And it gets worse if you don't even know which landscape (left or right up) you got. If we enforce that the device always has 0 degrees when held portrait up (Y positive pointing at 90 degrees) - then lock to landscape right up always gives gravity in negative X. The problem might sound like a small one - but as a web game developer, I would MUCH rather develop for devices, where I know that in my landscape-left game, natural UP is X+ than being forced to buy and test on all thinkable devices out there because the spec allows for manufacturers to have natural landscape units, where full screen portrait could be anything (really) when mapping the xyz accelerometer data to my game. br Lars Cheers Kenneth On Wed, Apr 24, 2013 at 12:13 PM, Tobie Langel to...@w3.org wrote: Hi, Screen orientation lock is critical to a whole set of mobile games (especially those which rely on the accelerometer to control the gameplay). It's great that it is now considered for specification and implementation. I had collected some use cases a while back[1], some of which led to use-cases[2], requirements[3] and suggestions[4] in the Coremob report. While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. The current proposal[7] only targets the dynamic setting through a JS API and leaves the more declarative approach to other specs[8]. It mentions the Web Application Manifest Format and Management APIs[9] and CSS Device Adaptation[10]. Now, CSS Device Adaptation, as used in the Viewport META element[11] is ubiquitous on mobile. It seems like a natural fit for a declarative orientation lock, so much so that it's already specified in the spec[12]. However, the syntax to dynamically read or modify the Viewport META element is cumbersome and error prone (you're talking document.cookie-like string splitting/concatenation with unspecified separators, etc.[12]). Instead of providing a dedicated API to
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, On Mon, Jun 10, 2013 at 10:58 AM, Lars Knudsen lar...@gmail.com wrote: IMO, this would be a much more clean and easy to understand solution than providing a separate API for orientation lock. It would also remove 1 unknown element when game developers try to juggle mappings between xyz-accelerometer data vs media query orientation vs device normal orientation (as some propose to have natural landscape and natural portrait devices - something I really think would just add to the confusion). That is good to hear; it is very important that all this feel natural to developers without digging into a lot of spec details. Kenneth
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
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 joh...@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.christian...@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 sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@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 ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
In order for CSS Device Adaptation and Fullscreen to work better
together and work with orientation lock in fullscreen mode, I suggest
(idea by Rune) we extend the view-mode media feature with the
following syntax
@media all and (view-mode: fullscreen(#element1)) {
@viewport {
orientation: portrait;
}
}
@media all and (view-mode: fullscreen(#element2)) {
@viewport {
orientation: landscape;
}
}
This way a page can have multiple fullscreen enabled elements which
each their viewport configuration which will be applied when they
enter fullscreen.
Cheers
Kenneth
On Thu, Jun 6, 2013 at 11:04 AM, Kenneth Rohde Christiansen
kenneth.christian...@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 joh...@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.christian...@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 sim...@opera.com wrote:
On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
kenneth.r.christian...@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
﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
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. 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.christian...@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 joh...@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.christian...@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 sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@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 ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@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.christian...@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 joh...@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.christian...@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 sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@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 ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
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.christian...@gmail.com wrote: Hi there On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@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.christian...@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 joh...@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.christian...@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 sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@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?
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
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 joh...@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.christian...@gmail.com wrote: Hi there On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@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.christian...@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 joh...@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.christian...@gmail.com wrote: I think it should be. You think anything is missing? Kenneth On Wed, Jun 5, 2013 at
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
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.christian...@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 joh...@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.christian...@gmail.com wrote: Hi there On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@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.christian...@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 joh...@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
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@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
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
I think it should be. You think anything is missing? Kenneth On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christiansen@intel.**com kenneth.r.christian...@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-interfaceshttp://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 ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
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 http://dev.w3.org/csswg/cssom-view/ module claims that all its dimensions are in CSS pixelshttp://dev.w3.org/csswg/cssom-view/#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 http://dev.w3.org/csswg/css-values/#reference-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.christian...@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 sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christiansen@intel.**com kenneth.r.christian...@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-interfaceshttp://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 ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, On Wed, Apr 24, 2013 at 2:35 PM, Tobie Langel to...@w3.org wrote: On Wednesday, April 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen wrote: Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. *Sigh* MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. 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. Understandably given the above. Outside of the IE10 implementation mentioned above, have other implementors committed to implement the CSS part of CSS Device Adaptation? We are looking at enabling it for Chromium, no ETA on that though, as there seems to be some interest from Android and Opera as well. I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Agreed. These should work together as much as possible. Thanks for your comments. --tobie -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
[screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi, Screen orientation lock is critical to a whole set of mobile games (especially those which rely on the accelerometer to control the gameplay). It's great that it is now considered for specification and implementation. I had collected some use cases a while back[1], some of which led to use-cases[2], requirements[3] and suggestions[4] in the Coremob report. While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. The current proposal[7] only targets the dynamic setting through a JS API and leaves the more declarative approach to other specs[8]. It mentions the Web Application Manifest Format and Management APIs[9] and CSS Device Adaptation[10]. Now, CSS Device Adaptation, as used in the Viewport META element[11] is ubiquitous on mobile. It seems like a natural fit for a declarative orientation lock, so much so that it's already specified in the spec[12]. However, the syntax to dynamically read or modify the Viewport META element is cumbersome and error prone (you're talking document.cookie-like string splitting/concatenation with unspecified separators, etc.[12]). Instead of providing a dedicated API to cater strictly for the screen orientation lock use case, wouldn't it make more sense and be more consistent to provide a CSSOM[14] API for the whole Viewport META element, and use matchMedia listeners[15] instead of orientationchange events? This would allow declarative setting through the Viewport META element, dynamic modification through the CSSOM API, and event handling through the matchMedia interface, all of which are well known and commonly used by developers. Thanks for your time. --tobie --- [1]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html [2]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#play-a-2d-game [3]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#req-orientation-lock [4]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#screen-orientation [5]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html#game-within-a-game-experience [6]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0078.html [7]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html [8]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html#declarative-orientation-locking [9]: https://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html [10]: http://dev.w3.org/csswg/css-device-adapt/ [11]: http://dev.w3.org/csswg/css-device-adapt/#viewport-meta [12]: http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor [13]: https://developer.mozilla.org/en-US/docs/Mobile/Viewport_meta_tag#Background [14]: http://dev.w3.org/csswg/cssom/ [15]: http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. 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. I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Cheers Kenneth On Wed, Apr 24, 2013 at 12:13 PM, Tobie Langel to...@w3.org wrote: Hi, Screen orientation lock is critical to a whole set of mobile games (especially those which rely on the accelerometer to control the gameplay). It's great that it is now considered for specification and implementation. I had collected some use cases a while back[1], some of which led to use-cases[2], requirements[3] and suggestions[4] in the Coremob report. While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. The current proposal[7] only targets the dynamic setting through a JS API and leaves the more declarative approach to other specs[8]. It mentions the Web Application Manifest Format and Management APIs[9] and CSS Device Adaptation[10]. Now, CSS Device Adaptation, as used in the Viewport META element[11] is ubiquitous on mobile. It seems like a natural fit for a declarative orientation lock, so much so that it's already specified in the spec[12]. However, the syntax to dynamically read or modify the Viewport META element is cumbersome and error prone (you're talking document.cookie-like string splitting/concatenation with unspecified separators, etc.[12]). Instead of providing a dedicated API to cater strictly for the screen orientation lock use case, wouldn't it make more sense and be more consistent to provide a CSSOM[14] API for the whole Viewport META element, and use matchMedia listeners[15] instead of orientationchange events? This would allow declarative setting through the Viewport META element, dynamic modification through the CSSOM API, and event handling through the matchMedia interface, all of which are well known and commonly used by developers. Thanks for your time. --tobie --- [1]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html [2]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#play-a-2d-game [3]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#req-orientation-lock [4]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#screen-orientation [5]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html#game-within-a-game-experience [6]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0078.html [7]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html [8]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html#declarative-orientation-locking [9]: https://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html [10]: http://dev.w3.org/csswg/css-device-adapt/ [11]: http://dev.w3.org/csswg/css-device-adapt/#viewport-meta [12]: http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor [13]: https://developer.mozilla.org/en-US/docs/Mobile/Viewport_meta_tag#Background [14]: http://dev.w3.org/csswg/cssom/ [15]: http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface -- - Intel Denmark Aps Langelinie Alle 35, DK-2100 Copenhagen CVR No. 76716919 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Wednesday, April 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen wrote: Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. *Sigh* MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. 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. Understandably given the above. Outside of the IE10 implementation mentioned above, have other implementors committed to implement the CSS part of CSS Device Adaptation? I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Agreed. These should work together as much as possible. Thanks for your comments. --tobie
