W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [css-device-adapt] @viewport and "desktop" browsers

From: Rune Lillesveen <rune@opera.com>
Date: Thu, 07 Mar 2013 09:23:59 +0100
To: "L. David Baron" <dbaron@dbaron.org>
Cc: "www-style list" <www-style@w3.org>
Message-ID: <op.wtkhl9zi8isf1p@id-c1005.oslo.osa>
On Sun, 03 Mar 2013 05:53:26 +0100, L. David Baron <dbaron@dbaron.org>  
wrote:

> On Friday 2013-03-01 16:30 +0100, Rune Lillesveen wrote:
>> This issue was added for the FPWD:
>>
>> "ISSUE 1 in the current ED "dbaron: The question is, what does this
>> do on the desktop browser? (And what's a desktop browser)"."
>>
>>
>> Perhaps the term "desktop browser" is misleading. Currently the term
>> is used in the Introduction and in the UA stylesheets sections.
>> "desktop browser" in this context is a browser with an initial
>> viewport width greater than a certain width (Something similar said
>> in section 13 UA stylesheets).
>
> I don't think that's the only relevant distinction.
>
> I think the much more important distinction is whether the browser
> displays pages using the desktop model where the viewing area is the
> same as the CSS viewport, or using the mobile model where the user
> can pan and zoom within the CSS viewport so they are viewing only
> part of it (with this panning and zooming also replacing the
> function of any scrolling on the viewport).  In other words, is the
> user's viewport the same as the CSS viewport, or are there two
> different viewports?

> The purpose of <meta viewport>, and presumably also @viewport, is to
> describe behavior that applies in the second case but not the
> first.  It describes the size of the CSS viewport and the
> relationship between the two viewports on implementations where the
> two viewports can differ; it should be ignored when the viewports
> are tied together (as they are in desktop browsers).

The difference between supporting @viewport or not in a desktop browser  
would typically be for documents that sets a max-width different from  
auto. For a document insisting on a width, say both min/max set to 320px,  
support for @viewport means it will either be layed out in the corner of  
your window or, if zoom is supported, blown up to fill the window.

I think the recommended way for an author should be to use a responsive  
design with media queries and @viewport widths/heights set to 'auto' or at  
least with a min/max-range that covers a wide range of form factors. When  
a page is authored this way, @viewport support is not really relevant  
until we have really wide windows where max-width starts to kick in.

>> So what happens if a document with @viewport styles is shown in a
>> "desktop browser"? Basically the same as in a small screen browser
>> modulo the UA styles. One difference could be that between browsers
>> which have magnifying-glass type zoom and those who don't. The
>> Conformance section says a UA still can conform without support for
>> actually changing the zoom factor.
>
> I think a desktop browser with magnifying-glass type zoom is still
> substantially different from a mobile browser.  In the desktop
> browser with magnifying-glass type zoom, the viewports are still the
> same by default, which is not the case in a typical mobile browser
> (where, when a page is loaded, there is typically at least one of
> pixel scaling or two viewports, if not both).

Are you arguing that @viewport support should not be implemented in  
browsers where the actual viewport would match the initial viewport by  
default, regardless of the presence of magnifying-glass zoom UI?

I think this also depends on what you mean by a typical mobile browser. I  
consider a 10in tablet a mobile device. Today they also often run the  
exact same browser as a small screen mobile device. If you run in  
landscape mode with a 1280px width (css pixels) I would expect the  
viewports to be the same by default. That is also what you get with the UA  
styles in 13.2:

   @viewport {
     min-width: 980px;
   }

Since only min-width is set, max-width is auto which means the actual  
viewport width will be 1280px.

Now consider the same tablet in portrait mode with 800px. In this case,  
the @viewport UA rule will give a different viewport by default. So, this  
can vary even for the same device running in portrait or landscape.

This is probably clear to you, but just to recap min/max descriptors:

The way min/max-width works is that it defines a range the author says the  
site is designed for. 'auto' means infinitely small for min-width and  
infinitely large for max-width. When the initial viewport width is inside  
that min/max range, the actual viewport width will be the same as the  
initial viewport width. If not, set the actual viewport width to whichever  
is closest to the initial viewport width of the min and max values.

I think small-screen browsers without zoom capabilities still should  
implement @viewport. This is in fact how Opera mobile browsers used to be  
in the pre-zoom era. We had two modes, the small-screen rendering which  
tried to fit the content within the width of the screen through  
degenerating the CSS. For the other mode (desktop mode, I think we called  
it) we did something resembling @viewport with min-width where the user  
would have to scroll to see the whole page, not necessarily being able to  
zoom.

Even if we will not see such browsers again, I think it proves the point  
that zooming capabilities or scrollbars vs panning is not what should  
decide if @viewport should be implemented or not.

I think it is sensible, if not necessary, to implement @viewport for all  
form factors, so I don't think there is a need to restrict it, but since  
the spec is already talking about desktop browsers we possibly need to  
rephrase or clarify those parts.

-- 
Rune Lillesveen
Received on Thursday, 7 March 2013 08:24:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT