W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Script-related feedback

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 9 Jan 2013 22:22:43 +0100
Message-ID: <CADnb78iivU17_tTYGf7hVc89mHyL7UpedYYG2VoMFurcScn7Vg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg@whatwg.org, Adam Barth <w3c@adambarth.com>
On Wed, Jan 9, 2013 at 9:32 PM, Ian Hickson <ian@hixie.ch> wrote:
> Advantages of putting this in JS over multipart:
>  - it's backwards-compatible
>  - it's easier to parse a static barrier than a multipart/*'s wacky
>    syntax.
>  - it doesn't impact any of the current fetching logic, since it's
>    still just one resource instead of introducing a layer in between
>    <script>'s logic and the JS logic.
>  - it automatically works anywhere you can use JS, not just where HTTP is
>    involved.
>  - it can be shimmed more easily (if you trust the JS not to have
>    arbitrary injection and be written with the shim in mind, especially).
>  - it doesn't run into weird problems like what if a part has the wrong
>    MIME type.
>  - it's way easier to deploy (authors hate having to set MIME types).
>  - it doesn't run into the problem that all UAs have historically ignored
>    the MIME type of script.

Adding magic meaning to certain JavaScript comments seems like a
pretty big downside though. Furthermore, multipart logic, however
weird, is a sunk cost both on consumer and producer side, whereas
introducing /*@BREAK*/ seems like a very steep uphill battle. And
actually <img> is a precedent for checking a MIME type before
sniffing/executing and it hasn't been much of a problem. (The problems
there were mostly figuring out how SVG should work.)

Received on Wednesday, 9 January 2013 21:23:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:52 UTC