- From: Chris <chris@cbojar.net>
- Date: Thu, 08 Aug 2013 17:47:40 -0400
- 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"
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 Friday, 9 August 2013 06:18:56 UTC