RE: [css-device-adapt] MSFT feedback on latest editor's draft

Thanks for your response Rune!

Re: "auto" -- It seems that this auto behavior + UA stylesheet will then require the developer to reset all viewport properties in order to guarantee a consistent experience across UAs (since there is no prescriptive default stylesheet) -- e.g.

@viewport { height: 480px; } /* Potentially insufficient, if the UA has set a default width */
@viewport { height: 480px; width: auto; } /* auto width is required to ensure there aren't any lingering UA styles that might come into play */

It also means there's no way to "nullify" an already-present viewport rule on the page.  Hopefully there aren't too many scenarios where this is required, but it does seem odd that specifying the default values for the property doesn't have the same effect as never specifying the property:

@viewport { width: auto; height: auto; } /* despite "auto" being the default value, this is not equivalent to never specifying a @viewport! */

I'm curious if this matches the interpretation Kenneth offered in his previous mail as well.

Re: % and vw -- Although the spec does define that these units should be interpreted based on the initial viewport for this feature (which I agree is the correct behavior if we are to consider these valid units for viewport sizing), this is the only case where they are interpreted this way instead of against the actual viewport.  A clearly named value like "initial-viewport-width" or "initial-width" would offer developers a less-ambiguous option, to help clarify which viewport was being referred to.

Re: min/max vs. @media -- Fantasai, how would you feel about removing the min/max option in favor of media query usage?  Are there particular scenarios you had in mind originally that would be interesting to consider here?

Re: steps 6-8 -- I think I understand based on this information.  Then the UA's stylesheet would have already kicked in for steps 4/5, and steps 6-8 would only apply to UAs with no default style present, correct?

Thanks,
-Matt

> -----Original Message-----
> From: Rune Lillesveen [mailto:rune@opera.com]
> Sent: Tuesday, December 10, 2013 12:16 AM
> To: Matt Rakow
> Cc: www-style@w3.org
> Subject: Re: [css-device-adapt] MSFT feedback on latest editor's draft
> 
> On Mon, Dec 9, 2013 at 9:49 PM, Matt Rakow <marakow@microsoft.com>
> wrote:
> > Hi all,
> >
> > I've been getting caught up recently on the edits made to the Device
> Adaptation ED and wanted to provide some feedback.
> >
> > 1. Explicit values for initial viewport width and height In the latest
> > ED the named values of "device-width" and "device-height" have been
> removed, and instead declaring a width or height of "auto" is intended to
> provide equivalent behavior.  However, "auto" is already the default value,
> indicating that the UA's default behavior may apply - the behavior just
> changes if you explicitly set the width or height to "auto".
> 
> 'auto' width means the value will be deduced from the height (using aspect
> ratio of the initial viewport) and vice versa. 'auto' will be resolved to initial
> viewport width/height if all min/max-width/height are 'auto'. The difference
> between 100% and 'auto' is that 100% will not be affected by the length in
> the other direction.
> 
>   @viewport { min-width: 200%; height: auto; } /* height resolves to 200% of
> initial viewport height */
>   @viewport { min-width: 200%; height: 100%; } /* height resolves to initial
> viewport height. */
> 
> There is no difference between an initial 'auto' value and an explicit 'auto'
> value. 'auto' should not reflect the default behavior of the browser if the
> browser sets a default width that is different from the initial viewport width.
> That should be expressed as an @viewport rule in the UA stylesheet instead.
> For instance:
> 
>   @viewport { min-width: 1024px; }
> 
> > IE uses "auto" to reflect the default behavior of the browser (i.e. actual
> viewport is minimum 1024px by default), whereas "device-width" and
> "device-height" map to the dimensions of the initial viewport (matching the
> current WD).  I'd like to add the named values back so we can keep these
> concepts distinct, and so that "auto" only has a single meaning.
> >
> 
> As mentioned above, 'auto' should not have different meanings, and a
> default width different from the initial viewport width should be expressed
> in the UA stylesheet.
> 
> > I agree that device-width/device-height are probably not the right
> vocabulary to use though.  Perhaps a renaming would be appropriate
> ("initial-viewport-width"?  "window-width"?  "css-pixel-width"?).
> 
> Initial viewport width/height can be expressed as 100vw or 100vh.
> Since vw/vh are valid units for <length> in CSS Values and Units we shouldn't
> need an additional keyword.
> 
> > 2. min- and max- width and height
> > Currently, there are two ways to provide a viewport "range."  These are
> the min- and max- prefixes for the width and height properties, and the
> interaction of @viewport with width and height media queries.  Having both
> of these mechanisms adds a pretty significant amount of complexity to the
> ways this feature can be applied, especially if both are used simultaneously.
> >
> > I'd argue that the min- and max- prefixes for the width and height
> properties are not necessary for the scenarios developers are interested in,
> and that equivalent functionality can be built using only media queries for
> range constraints.  For example, consider the two following rules:
> >
> > /* Example A */
> > @viewport {
> >     min-width: 640px;
> >     max-width: 960px;
> > }
> >
> > /* Example B */
> > @media (min-width: 640px) and (max-width: 960px) {
> >     @viewport { width: device-width; } }
> >
> > Both of these rules suggest the author has done the work necessary to
> ensure their site works well for widths between 640 and 960px, and both are
> equivalent for initial viewports within that range.  However, outside of that
> range the behavior differs.  The primary difference is that Example A forces
> scaling for all window sizes outside of the designed-for range, while Example
> B leaves the UA in charge of what happens to those sizes.  I see Example B as
> the better option, as the potentially unbounded scaling of Example A will
> likely end up with an unintended result for extreme viewport sizes.  Consider
> the ~200% scaling that would occur on a 1080p monitor, for example.
> >
> > I'd be interested in removing the min/max option from the spec, if there is
> not a particular scenario they are required for.
> >
> 
> In Example B, you will get an actual viewport of 1024px for initial viewports <
> 640px when you have a UA default of 1024px. So you would probably want to
> add an @viewport rule for the widths < 640px too.
> 
> The original spec proposal didn't have min/max values. Fantasai wanted
> min/max values and, IIRC. The use case was to express that you made a site
> that could adapt to viewports above a certain size but cap to a minimum-
> width. For instance: @viewport { width: 640px auto; }
> 
> Without min/max support I see that you can express that as:
> 
>   @viewport { width: auto; }
>   @media (max-width: 640px) {
>     @viewport { width: 640px }
>   }
> 
> --
> Rune Lillesveen

Received on Wednesday, 11 December 2013 21:44:42 UTC