(And note that it would be trivial to implement a programmatic promise-y API on top of this as a library, if people want that).
On Tue, Aug 4, 2015 at 10:06 AM, Bobby Holley <[email protected]> wrote: > How about a scheme in which there can be N such <meta> elements, and the > painting only happens when all of them are gone (or some timeout occurs)? > That solve the common case that Jonas is talking about, and allows > libraries to insert their own paint blocker into <head> if they really want > to block painting? The a nice side-bonus of this scheme is that the > existence of blockers is clearly visible in the DOM, so that a buggy > library that leaves a paint blocker active is more noticeable. > > On Tue, Aug 4, 2015 at 9:00 AM, Jonas Sicking <[email protected]> wrote: > >> On Tue, Aug 4, 2015 at 2:55 AM, Anne van Kesteren <[email protected]> >> wrote: >> > On Tue, Aug 4, 2015 at 11:07 AM, James Graham <[email protected]> >> wrote: >> >> I am extremely wary of designing a solution like this where there's a >> single >> >> master switch that any code can unilaterally flip; if the assumption >> that >> >> libraries will never want to delay rendering turns out to be false it >> will >> >> force page authors to deal with N library-specific protocols to >> indicate >> >> that they are no longer blocking rendering, and give any one component >> that >> >> ability to override all others. >> > >> > Agreed, I also don't want us to repeat a <meta name=viewport>-style >> > design. I thought it was agreed that was unfortunate last time around. >> >> I'm open to counter proposals. But blocking scripts are also bad. As >> is requiring inline scripts since they don't work with websites that >> want to use CSP. >> >> / Jonas >> _______________________________________________ >> dev-platform mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-platform >> > > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
