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 <jo...@sicking.cc> wrote: > On Tue, Aug 4, 2015 at 2:55 AM, Anne van Kesteren <ann...@annevk.nl> > wrote: > > On Tue, Aug 4, 2015 at 11:07 AM, James Graham <ja...@hoppipolla.co.uk> > 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 > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
