Re: [css-device-adaptation] Progress?

> On Feb 26, 2015, at 12:00 PM, Yoav Weiss <yoav@yoav.ws> wrote:
> 
> 
> 
>> On Thu, Feb 26, 2015 at 7:55 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>>> On Feb 26, 2015, at 8:52 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>> 
>>> 
>>> 
>>>> On Thu, Feb 26, 2015 at 5:10 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Feb 26, 2015, at 2:18 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>>> 
>>>>> A standard based note is not likely to have high visibility. A console warning might be more effective.
>>>>>  
>>>> [...]
>>>>>> 
>>>>> All in all, I see that there's a valid use case for permitting @viewport rules in external styles other than mere convenience.
>>>>> So, perhaps limiting @viewport rules to be one of the first rules in an external style (along with @charset and @import) would be enough,
>>>> 
>>>> Well, let's see: since there could be more than one @media with @viewport inside it, your restriction could theoretically say that @viewport cannot appear outside a dimension-based or zoom-based @media (or similarly restricted linked style sheet in html) unless the @viewport came before that. And that @viewport would be invalidated by any 'image-set()' property (or html with image-set attribute) that came before it in the same level of @media embedding. Or something like that. 
>>>> 
>>>> But I don't think it's worth it to have such a complicated restriction, and too draconian to restrict it even more generally. It's just going to break the author's design in ways the author won't understand or appreciate. 
>>>> 
>>>> And I think the value of such restrictions would be pretty limited anyway. Image loading from image-set should happen after complete style sheet parsing and cascading anyway, and multiple width-based @media rules are already parsed and held in memory anyway on UAs that have resizable windows. 
>>>> 
>>>> At most, an author might defeat some small optimization in a mobile UA with only two default viewport sizes (one for vertical and one for horizontal). That UA might just have to hold onto the other @media blocks during the parsing stage, and at worst might pull in some more style sheets via @import inside @media. But that is no worse than letting an author include dozens of @import calls to the server in existing practice, or having a super large stylesheet full of countless overrides, neither of which is currently restricted by CSS. 
>>> 
>>> Just so we're clear, the performance cost I'm talking about is not related to image-set or to CSS background images. It's related to content images (using srcset `w` and <picture>) and to a lesser extent, the style sheets themselves. (And any future resource which loading would depend on viewport dimensions)
>> 
>> I still don't see the problem of just not loading the images until after the CSS has been parsed and cascaded.
> 
> Waiting until all the page's CSS would be downloaded, parsed and cascaded before starting to download images would cause prohibitive page load time as well as visual speed regressions. That's not how browsers load images today, and we've went through great lengths to make sure that they won't have to start doing that when responsive images were introduced.

Hmm. I guess I can see this point, then, if there is no optimization to prescan the stylesheets for an @viewport mentions as one of the first steps of parsing. Or do UAs not even wait for CSS downloading before downloading images?

If the page is zoomable, wouldn't it download the size for 100% zoom level anyway, rather than the smaller one you'd get if the actual viewport is bigger than the initial viewport, so that when the user does zoom in, they see full resolution? (I hope I am using those terms correctly. I mean when the page is zoomed out to fit on the screen.) If so, how does  @viewport affect which images are downloaded? Or is this specifically about when user zoom is disabled?

>> At that point, you would know which images to fetch. If you are pre-loading based on viewpoint assumptions, then just stop once the  assumptions prove false. 
>> 
>> PS: the length of the vw, vh, etc. units don't need to be resolved until after the cascade stage either. 
>  
> That is far from being true. `vw` units are used in `sizes` in order to determine the image density regardless of the external CSS downloaded.

So, they don't use the initial viewport for that?

> They can also be used in Media Queries inside `media` attributes.

Hmmm. For media attributes on linked style sheets or @media, I would think you'd have to use the initial viewport to avoid circular dependencies.