Re: [Feature Proposal] New attributes "library" and "version" on script tags

It would be interested to hear a browser vendor take on this. They would have to ship a browser with how many versions of how many libraries? They would also have to add new versions as they became available. There might not be much implementor support for this kind of thing.

Also, the library name would need some kind of control to avoid two browsers coming up with a different name for the same library, for example if one implementor called something jquery.ui and another jqueryui.

That isn't to say the attributes suggestion is good or bad.

Steve

On 8 Aug 2013, at 22:47, Chris <chris@cbojar.net> wrote:

> Hello everyone,
> 
> I would humbly like to propose a new feature that has been rolling around in my head recently: new attributes "library" and "version" on script tags.
> 
> Javascript libraries have proliferated like rabbits in recent years, but a few notable examples have risen to the top, earning a place in the head tags of many websites. These libraries are powerful, but often hefty. This effect is most noticeable on mobile devices and/or slow connections, but are still able to be felt even on the fastest downlinks. They also can be fragmented, different versions spread across different CDNs or websites, all pointing to essentially the same library, but no way to know whether http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js and http://codeorigin.jquery.com/jquery-1.10.2.min.js are the same library without downloading them.
> 
> I would then suggest adding the library and version attributes to the script tag to alleviate some of these problems. First and for clarity's sake, they would be of the following form:
> 
>    <script library="jQuery" version="1.10.2" src="http://codeorigin.jquery.com/jquery-1.10.2.min.js"></script>
> 
> Such a form provides a two-fold benefit. First, there is now a semantic metadata associated with the script. We can see directly which library and version are being used, and can associate the specific src URL with an abstract library. That is nice, but there is a second benefit that can be derived from such data: a browser may come installed with a pre-determined set of popular libraries, and, if it recognizes a library and version as pre-installed, may use that in place rather than needing to issue a new request, download, and cache a new file, even if it may already be cached from a different location. Thus, such as in the example given above, a browser may recognize this script reference as a pre-installed library, and call it from local storage /on the very first visit/ rather than across the network. Of course, if the library is not recognized, the script would be downloaded as normal.
> 
> Older browsers appear to ignore what they consider extraneous attributes in the script tag, and thus would treat this as a normal script tag and download accordingly, meaning there should not be any backwards-compatibility issues.
> 
> Here are the caveats I've considered already:
>    The library tag should be interpreted without regard to case. In the real world, people will use all kinds of combinations, but jQuery, jquery, Jquery, and JQuery should all be interpreted to be the same.
> 
>    The version tag to do best greatest matching to what is available locally. A version="1" in the example above should call the latest 1.x version of the script available (in this case at the present time, 1.10.2). A version="1.9" should call the latest 1.9.x version of the script available (in this case at the present time, 1.9.2). If the version tag is omitted completely, the library used will default to the latest locally available version. It is the responsibility of developers to ensure that their script can interoperate properly down the version line if they use this.
> 
>    The version tag may be used without the library tag (though with obviously diminished usefulness). Sometimes developers may want to version their own internal libraries. Browsers should just ignore the attribute in this case.
> 
>    Browsers with pre-installed versions of libraries can no only improve performance by saving RTT, but may also improve performance by compressing, optimizing and tuning for the particular environment, removing unnecessary cross-browser compatibilities, and precompiling (if applicable). They would only need to maintain API compatibility, but could reimplement internals if they so chose.
> 
> 
> If you got all the way here, thanks for reading and let me know what you think (or what I'm missing).
> 
> Regards,
> -Chris.
> 
>

Received on Saturday, 10 August 2013 07:24:52 UTC