W3C home > Mailing lists > Public > www-style@w3.org > March 2013

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

From: François REMY <francois.remy.dev@outlook.com>
Date: Fri, 22 Mar 2013 23:36:38 +0100
Message-ID: <DUB002-W5248AD2FB35A2F00331640A5D40@phx.gbl>
To: Elliott Sprehn <esprehn@gmail.com>
CC: Boris Zbarsky <bzbarsky@mit.edu>, Tab Atkins Jr. <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>
> 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 don't want to be pessimistic, but your approach seems even worse to me than a more complex layout process. Suppose that the document contains "N" local viewports. Firstly, an initial layout is done (this layout will be wrong since the classes will not be initialized). 

At this point, the frame is rendered, then the resize events of the local viewports are going to be fired. When the first one is handled, the offsetWidth call will probably be cheap, since the layout will likely be conserved accross frames (but I can imagine that in the case of animations, this may not be the case)).

However, as soon as you modify the class, you make the layout dirty. When the next resize event is called, getting 'offsetWidth' will trigger a new layout. Then adding a class will make it unworth. Then again for the N-2 next ones. This means that every single layout must be done "N" times.

This is the approach developers are going to take anyway (except that the resize events aren't standardized yet and they will use polyfills, so the quality will vary from browser to browser) but I don't think this is particularly good. Also, you can't put any guarantee on what is being done, developers could well do unfortunate things without knowing it, like changing the layout of a parent element and triggering a lot of subsidiary relayouts.



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

This is my objective as well. To achieve this, we could possibly rely on historical values in the cases that are difficult to evaluate, or restrict them. If named flows are a problem, we could restrict them so that they can't be inserted across the boundaries of a viewport. 

However, I don't see any issue with insertion points since Shadow DOM happens before any layout and is completely static.

There's a real need for :min-width/:max-width for web components and local viewports is the most promising approach till now. But I agree that if it's not to have good performances, it isn't worthwhile. 		 	   		  
Received on Friday, 22 March 2013 22:37:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:07 GMT