On Tue, Dec 17, 2013 at 9:29 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Dec 9, 2013 at 1:33 AM, Yoav Weiss <yoav@yoav.ws> wrote:
> >> > > or
> >> > > something else. Like you said, I think it's a conversation we need
> to
> >> > > have with the HTML people.
> >> >
> >> >
> >> > I’ll investigate a bit more. I’ve added a bug here:
> >> > https://github.com/w3c/manifest/issues/91
> >> >
> >> > I’ll just note that having <link rel=manifest> and <script type>
> >> > manifest would kinda suck… if we can just have:
> >> >
> >> > * <script type=“application/manifest+json”
> src=“manifest.json”></script>
> >> > * <script type=“application/manifest+json”>{}</script> that would be
> >> > great.
> >
> > Implementations would probably have to be careful and exclude this kind
> of
> > scripts from the usual script handling (e.g. blocking of the HTML parser,
> > triggering the preloader, etc), to reduce the impact on the critical
> path.
>
> This is a good point. Would this have performance implications for
> down-level browsers? I don't know if prescanners etc in contemporary
> browsers are smart enough to ignore <script> tags that use a non-JS
> type attribute.
>
Great point regarding legacy browsers. WebKit/Blink's preloadScanner
doesn't currently look at the type when triggering fetching of scripts.
While it can be easily modified to do that, the tons of WebKit based legacy
browsers out there (mostly old androids) would fetch these scripts as part
of the critical path for no good reason.
OTOH, <link> tags' resources are preloaded only for "rel=stylesheet", so
<link> has a huge advantage over <script> in that aspect.
Received on Wednesday, 18 December 2013 12:49:19 UTC