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

RE: [css-regions] Reworking getNamedFlows()

From: François REMY <francois.remy.dev@outlook.com>
Date: Thu, 1 Aug 2013 22:38:15 +0200
Message-ID: <DUB120-W283F25AF61C78062C448D0A5500@phx.gbl>
To: Mihai Maerean <mmaerean@adobe.com>, Catalin Grigoroscuta <cataling@adobe.com>, Mihnea-Vlad Ovidenie <mihnea@adobe.com>, Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
> "Stylesheet loads block script execution, so if you have a <script> after
> a <link rel="stylesheet" ...>, the page will not finish parsing - and
> DOMContentLoaded will not fire - until the stylesheet is loaded."

Thanks for sharing, I didn't know that. 

Still, my take is that it's bad practice not to have a sane way to get an element by name without creating a static list of something (which will have to be created then GCed for no good reason). This is similar to the reason why we have querySelectorAll(...)[0] vs querySelector(...), or querySelectorAll("#abc")[0] vs getElementById("abc"), and preferred that to document.all["abc"] (even if document.all is a live list, in fact). 

Also, I maintain that (in the case of a browser that delays style computation until it's required) creating a static list force the browser to perform the computation of the style on the whole page, while asking just for the flow you need could allow him to return you a value from the named flow cache directly.

Finally, I don't like the fact it's possible for a NamedFlow object and its listeners/expando to stay in memory while the developer has no access to it: it's an invisible leak and it's probably not a good idea. We should probably setup an event for when a flow changes of state (and switch to NULL) so that the developer can free memory at that point.

--------------

Anyway, to get some sane semantics to getNamedFlows you technically have to return a sequence<NamedFlow>, so I do think we want another method to get a flow by id, but I'm not going to fight for that one. 		 	   		  
Received on Thursday, 1 August 2013 20:38:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:30 UTC