Re: The :min-width/:max-width pseudo-classes

On Fri, Mar 22, 2013 at 3:06 PM, François REMY <
francois.remy.dev@outlook.com> wrote:

> > But fundamentally, this would just give the layout behavior of <iframe>
> > without the separate Window and without the ugliness of <iframe srcdoc>,
> > right? Are we trying to avoid the former, the latter, or both? ;)
>
> The <iframe> layout behavior is exactly what I'm trying to achieve so
> that's not that strange ^_^
>
> The reason why the <iframe> tag doesn't do the trick for many uses cases
> are multiple, but includes the memory pressure induced by the new script
> context and the new document, the fact you can't reuse the same named flow
> and css regions across frames and that it's impossible to use Web
> Components's insertion points inside an iframe embedded document. The last
> thing is that you can't cross-match elements using CSS from the outer
> document.
>
> I feel like this is compelling enough to be worth pursuing.
>

I don't think this is going to gain you anything in terms of performance
though (actually I think it makes it much worse). You're going to force
serial style calculations, serial layout, and cause repeated style
recalculations on each viewport as layout is being done and you still cause
another layout after the fact because your insertion points and named flows
are evaluated after all viewports have been through layout.

You'd be better off just using script on end of micro task to catch the
resize and then swapping in a new class like:

if (element.offsetWidth >= 500)
   element.classList.add("width-500");
else if (element.offsetWidth >= 200)
   element.classList.add("width-200");
else
   element.classList.add("width-default");

I'd oppose this feature unless we could figure out how to make it scoped
such that you can layout all non-nested viewports in parallel (just like
iframes).

- E