Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Tobie Langel]

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?

[Mounir Lamouri]

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].

Hi Tobie,

(First, I am so sorry for the huge delay...)

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? This one of the reasons
why, for form controls, we ended up with specifying the orientation on
the attribute instead of doing that in CSS.

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].

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.

[1] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0639.html
[2] http://mounir.lamouri.fr/2013/05/the-web-manifest.html

Thanks,
--
Mounir

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Kenneth Rohde Christiansen]

Hi there,

On Mon, Jun 10, 2013 at 10:58 AM, Lars Knudsen  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?

[Lars Knudsen]

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  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 s

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[John Mellor]

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  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
> >  wrote:
> >>
> >> Hi there
> >>
> >> On Thu, Jun 6, 2013 at 12:15 PM, John Mellor 
> 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  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
> >> >  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 
> >> >> 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 Independen

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Kenneth Rohde Christiansen]

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  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
>  wrote:
>>
>> Hi there
>>
>> On Thu, Jun 6, 2013 at 12:15 PM, John Mellor  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  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
>> >  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 
>> >> 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 We

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[John Mellor]

> 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  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  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
> >  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 
> 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
> >> >  wrote:
> >> >>
> >> >> I think it should be. You think anything is missing?
> >> >>
> >> >> Kenneth
> >> >>
> >> >>
> >> >> On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters 
> wrote:
> >> >>>
> >> >>> On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
> >> >>>  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.
> >> >>>
> >

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Kenneth Rohde Christiansen]

Hi there

On Thu, Jun 6, 2013 at 12:15 PM, John Mellor  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  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
>  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  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
>> >  wrote:
>> >>
>> >> I think it should be. You think anything is missing?
>> >>
>> >> Kenneth
>> >>
>> >>
>> >> On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters  wrote:
>> >>>
>> >>> On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
>> >>>  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?

[John Mellor]

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  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  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
> >  wrote:
> >>
> >> I think it should be. You think anything is missing?
> >>
> >> Kenneth
> >>
> >>
> >> On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters  wrote:
> >>>
> >>> On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
> >>>  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?

[Kenneth Rohde Christiansen]

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
 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  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
>>  wrote:
>>>
>>> I think it should be. You think anything is missing?
>>>
>>> Kenneth
>>>
>>>
>>> On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters  wrote:

 On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
  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?

[Kenneth Rohde Christiansen]

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  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
>  wrote:
>>
>> I think it should be. You think anything is missing?
>>
>> Kenneth
>>
>>
>> On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters  wrote:
>>>
>>> On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
>>>  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?

[John Mellor]

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  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
>
> ﹆﹆﹆
>

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Kenneth Rohde Christiansen]

I think it should be. You think anything is missing?

Kenneth


On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters  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

﹆﹆﹆

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Simon Pieters]

On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen  
 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?

[Kenneth Rohde Christiansen]

Hi there,

On Wed, Apr 24, 2013 at 2:35 PM, Tobie Langel  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

﹆﹆﹆

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Tobie Langel]

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

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Kenneth Rohde Christiansen]

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  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.

[screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Tobie Langel]

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