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

On Wed, Dec 11, 2013 at 10:44 PM, Matt Rakow <marakow@microsoft.com> wrote:
> 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 */

There is a prescriptive UA stylesheet for small screens in 12.2.

If you want consistent behavior, and UAs have different default
behavior, you need to override regardless of whether the different
behavior is different in interpretation of initial value or different
UA styles.

> It also means there's no way to "nullify" an already-present viewport rule on the page.

That is similar to a CSS property set in a UA stylesheet. If e.g. a
margin is set on an element in the UA stylesheet, and there's an
author rule overriding that, it's not possible to nullify that without
knowing the UA styles.

> 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 don't find that not odd at all. "div { display: inline }" has a
different effect from not setting display at all because there's a
"div { display:block }" in the UA stylesheet, even if the initial
value is inline.

What's odd are the different default behaviors, the legacy, that we
need to work around here.

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

FWIW it's similar to resolving rem against the initial font and not
the root element font for media queries.

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

Height is 'auto' in the default stylesheet for small screens (12.2),
so step 8 resolves height to a px length in that case. Then you have
author rules specifying 'auto' for width or height, of course.

-- 
Rune Lillesveen

Received on Monday, 16 December 2013 13:52:35 UTC