(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 <bobbyhol...@gmail.com> 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 <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

Reply via email to