W3C home > Mailing lists > Public > public-html@w3.org > August 2013

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

From: Chris <chris@cbojar.net>
Date: Thu, 08 Aug 2013 17:47:40 -0400
Message-ID: <520411FC.1070801@cbojar.net>
To: public-html@w3.org
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" 

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).

Received on Friday, 9 August 2013 06:18:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:34 UTC