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

this proposal is no different (semantically speaking) from defining a URN
and a URN resolver (to URLs), e.g., urn:resolver:library:version



On Sat, Aug 10, 2013 at 1:24 AM, Steve Fenton <whatwg@stevefenton.co.uk>wrote:

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