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

Re: min-max -- That's actually an excellent example of where min/max width can be confusing.  On the surface it is not immediately apparent what the behavior should be in your example when the initial viewport width is less than 1024px.  It turns out that the min- prefix is more strongly guaranteed than the max- prefix so the example works as you intend, but then the converse rule doesn't work as you would expect:
@viewport { min-width: 1024px; max-width: 100%; } /* Content scales down for initial viewports below 1024px, but displays at actual size for initial viewports above 1024px */
@viewport { min-width: 100%; max-width: 1024px; } /* Content always displays at actual size, and does NOT scale up for initial viewports above 1024px */

By contrast, the behavior is more explicitly defined and easier to predict using just media queries:
@viewport { width: 100%; } /* By default content is displayed at actual size */
@media (max-width: 1024px) { @viewport { width: 1024px; } } /* Content scales down for initial viewports below 1024px */
@media (min-width: 1024px) { @viewport { width: 1024px; } }/* Content scales up for initial viewports above 1024px */

Re: "auto" -- perhaps I was just misinterpreting the constraining procedure.  I think I was getting hung up on the usage of "width" to mean resolved width, and since there is no explicit statement about what to do when "width" is unresolved after the procedure completes.  Perhaps it would be helpful to use "resolved-width" as the term and add a statement to the end along the lines of "If both resolved-width and resolved-height are still undefined, the actual viewport width and height are selected by the UA"?

Re: named values -- I think the usage of 100% or 100vw is equally or more magic, much like hard-coding an integer value in place of a named constant in any other programming language.  Is there a downside I am perhaps missing to having an explicit named value that requests "use the initial viewport as my actual viewport"?

Thanks,
-Matt

> -----Original Message-----
> From: Kenneth Rohde Christiansen
> [mailto:kenneth.christiansen@gmail.com]
> Sent: Monday, December 9, 2013 1:24 PM
> To: Matt Rakow
> Cc: www-style@w3.org
> Subject: Re: [css-device-adapt] MSFT feedback on latest editor's draft
> 
> As I understood it, without having reread the latest spec, 'auto'
> should be the same as using the US sheet default, so if your UA sheet says
> @viewport { min-width: 1024px; max-width: 100%; }, auto has the behavior
> that you want. This example also shows the use of the min and max values.
> 
> I don't like magic values like initial-width etc. I rather have the developer
> understand the feature they are using and quickly see when they are doing
> something wrong. It should be quite easy to educate them and tooling (like
> the Chrome Web Inspector etc) can also help.
> 
> Kenneth
> 
> On Mon, Dec 9, 2013 at 10:12 PM, Matt Rakow <marakow@microsoft.com>
> wrote:
> > Although these are functionally equivalent, I still think there is some value
> in providing some more explicit named value which indicates the desired
> behavior.  I don't think percent or vw units seem like a natural go-to for a
> developer who is looking to disable automatic scaling.
> >
> > The other side that I am interested in is that the "auto" value seems to be
> equivalent to "100%" in the latest ED (unless I am misinterpreting steps 6-8 of
> the constraining procedure).
> >
> > Thanks,
> > -Matt
> >
> >> -----Original Message-----
> >> From: Kenneth Rohde Christiansen
> >> [mailto:kenneth.christiansen@gmail.com]
> >> Sent: Monday, December 9, 2013 1:03 PM
> >> To: Matt Rakow
> >> Cc: www-style@w3.org
> >> Subject: Re: [css-device-adapt] MSFT feedback on latest editor's
> >> draft
> >>
> >> These values 100vw and 100% are relative to the initial viewport
> >> (which might be affected by page zoom as defined in CSSOM Views).
> >>
> >> Kenneth
> >>
> >> On Mon, Dec 9, 2013 at 9:55 PM, Kenneth Rohde Christiansen
> >> <kenneth.christiansen@gmail.com> wrote:
> >> > Hi there,
> >> >
> >> > 1. device-width and device-height are being replaced by 100% or
> 100vw/vh.
> >> >
> >> > Kenneth
> >> >
> >> > 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".
> >> >>
> >> >> 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.
> >> >>
> >> >> 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"?).
> >> >>
> >> >>
> >> >> 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.
> >> >>
> >> >> Thanks,
> >> >> -Matt
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Kenneth Rohde Christiansen
> >> > Web Platform Architect, Intel Corporation.
> >> > Phone  +45 4294 9458 ﹆﹆﹆
> >>
> >>
> >>
> >> --
> >> Kenneth Rohde Christiansen
> >> Web Platform Architect, Intel Corporation.
> >> Phone  +45 4294 9458 ﹆﹆﹆
> 
> 
> 
> --
> Kenneth Rohde Christiansen
> Web Platform Architect, Intel Corporation.
> Phone  +45 4294 9458 ﹆﹆﹆

Received on Monday, 9 December 2013 22:13:58 UTC