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

This is an interesting concept but something else to consider: what is to
prevent someone from from "lying" about which script they are referencing?

e.g. <script library="jQuery" version="1.0"
src="/somethingNotjQuery.js<http://codeorigin.jquery.com/jquery-1.10.2.min.js>
"></script>



On Thu, Aug 8, 2013 at 5:47 PM, 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<http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js>and
> http://codeorigin.jquery.com/**jquery-1.10.2.min.js<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<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.
>
>
>


-- 

~ For every man there is a purpose which he sets up in his life.
Let yours be the doing of all good deeds. ~


Chris@chrisadams-studios.com
ph: 614.654.4119
http://www.chrisadams-studios.com

-------------------------------------------------------------------------------------------------

This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.

Please contact the sender if you believe you have received this email in error.