Re: [css-om] Issues with width and resolution media queries

On Sat, Dec 7, 2013 at 2:31 PM, Peter-Paul Koch <pp.koch@gmail.com> wrote:
>
>> > For mobile browsers, that always take up the full screen width, the
>> > distinction is pointless. Ideal viewport === width of screen in unscaled
>> > CSS
>> > pixels.
>>
>> It is not for height. The initial (before viewport adaptation, coming
>> from fallback 980px layout or the viewport meta, etc) viewport width
>> is usually === screen width because most mobile browsers do not have
>> any chrome horizontally, they usually do vertically though.
>
>
> In all mobile browsers, the height of the ideal viewport pretends the
> browser chrome isn't there.

Isn't that not just browsers who have non-fixed chrome (ie. the Chome
disappears when scrolling?) It at least didn't use to be this way,
because I looked at that back in the Nokia N9 days. When the Chrome
can do away, it makes sense to look at the value without the Chrome
present.

>>
>> > - In order to do so, they should use the
>> > document.documentElement.clientWidth value for the width media query,
>> > like
>> > the mobile browsers do.
>>
>> You know that there is no code difference here for Chrome on desktop
>> and Chrome on mobile. You can check the code yourself.
>
>
> Nonsense. Chrome on Android uses document.documentElement.clientWidth, and
> Chrome on desktop uses window.innerWidth.

In that case the Android port applies patches.

Blink has:

static bool widthMediaFeatureEval(CSSValue* value, RenderStyle* style,
Frame* frame, MediaFeaturePrefix op)
{
    FrameView* view = frame->view();

    int width =
view->layoutSize(ScrollableArea::IncludeScrollbars).width(); // I
expanded this code.
    if (value) {
        if (RenderView* renderView = frame->document()->renderView())
            width = adjustForAbsoluteZoom(width, renderView); //
basically width / renderView.effectiveZoom() with some rounding.
        int length;
        return computeLength(value,
!frame->document()->inQuirksMode(), style, length) &&
compareValue(width, length, op);
    }

    return width;
}

Thus it uses the layout viewport (which includes DPR and scroll bar
size which is zero for overlay scrollbars (used on Android))

Then it removes the DPR from the equation and ends up with the width
of the "actual viewport" in CSS units.


innerWidth is:

adjustForAbsoluteZoom(view->visibleContentRect(ScrollableArea::IncludeScrollbars).width(),
m_frame->pageZoomFactor());

visibleContentRect is the visible viewport (incl. scrollbars but
already excluding the deviceScaleFactor). Then the pageZoomFactor is
removed, and you end up with the "visible viewport" in CSS units.


clientWidth is basically (cut some code for other elements):

         if (FrameView* view = document().view()) {
             if (RenderView* renderView = document().renderView())
                 return
adjustForAbsoluteZoom(view->layoutSize().width(), renderView);
         }

So that seems to be the document layout size (without
deviceScaleFactor) with the pageScaleFactor removed. Thus the "actual
viewport" in CSS units.

Now that said,

> Nonsense. Chrome on Android uses document.documentElement.clientWidth, and
> Chrome on desktop uses window.innerWidth.

So basically both Chrome on desktop and Android uses the actual
viewport, ie. MQ width == clientWidth.

On Desktop without considering pinch zoom, the visible viewport is
always the same as the actual viewport. That also fits with the
definition of page zoom, it affects the viewport, ie keeps the visible
viewport (at pinch zoom scale 1.0) equal to the actual viewport. As I
haven't tested pinch zoom on ChromeOS, there might be bugs.

>> There is no reason that desktop browsers cannot support both, and IE
>> does in Metro mode and so does Chrome on the Pixel or the new Acer
>> C720P, and maybe even on Windows? You will see pinch zoom coming to
>> more and more desktop browsers, while still having page zoom support
>> as well.
>
>
> This is interesting. I didn't know about the Pixel.
>
> Now the question is: is it possible for a user to zoom in using both kinds
> of zoom simultaneously, without changing settings or anything?

Sure, one (page zoom) you set using the Chrome zoom menu, the other
you can only change using your fingers (or by using the viewport meta
tag). Keep in mind that viewport meta is not enabled on ChromeOS by
default, but Bokan is working on it. It might be that it will never
support the meta but support the @viewport rule instead.

> And if it is, should both kinds of zoom trigger the same response? That is,
> should a 200% zoom cause a DPR of 2, no matter what kind of zooming the user
> uses?

pinch zoom never changes the actual viewport nor DPR.

> If it should, mobile browsers should also change their DPR on pinch zoom.

No.

> If it should not, the two kinds of zoom should be treated in separate
> properties, media queries etc.

You could say yes, but pinch zoom (this kind of pinch zoom scaling the
page without changing the actual viewport) is not exposed to web
developers for a reason.

Kenneth

>
>
> --
> --------------------------------------------
> ppk, mobile platform strategist
> http://quirksmode.org/about/
> +.31.6.29585782
> --------------------------------------------



-- 
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆

Received on Saturday, 7 December 2013 14:08:09 UTC