Non-standard script type attributes

3 posts / 0 new
Log in to post comments
Last post
Felix Giannelia
Joined: 02/23/2012
Thu, 02/23/2012 - 16:57
Non-standard script type attributes

I'm kind of an old-hat web developer, and I recently started work on a project that has some LinkedIn integration. I had never seen a script tag with a type like "IN/login" before, and have been trying to figure out what exactly that is/means.

Of course, I know that I can just copy and paste the code from the API documentation and I know that it works, but I'm the sort who also wants to know why and how it works.

The only thread I've found so far that directly addresses this style of script type attribute is this one:

https://developer.linkedin.com/forum/profile-plugin-stopped-working

where someone reports that this type value causes problems with a version of WordPress, and the problem is blamed on WordPress and the assertion is made that:

"we use the script node's type attribute to specify the type of plugin. The browser won't try to execute a script node with a type of anything other than "text/javascript". This allows us to convert these nodes into plugins without leaving behind a visible node, while still being entirely standards compliant (and even pretty semantic too)."

That first bit is the important bit for me, as it at least explains exactly what "IN/login" means. Great. But as for this being "entirely standards compliant," as far as I can tell, no, it most certainly isn't. The attributes of every HTML tag are pretty rigorously standardized and defined, as are the allowable values of those attributes. The specs:

http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1

say that "type" for a script element is an attribute of type "content-type". "content-type" is in turn defined:

http://www.w3.org/TR/html4/types.html#type-content-type

...as a media type as per RFC2045/RC2046.

The salient part of all that is that a media type isn't something you're supposed to just make up. It's supposed to be unique, so that no two people happen to make up the same media type to describe two different types of data. You're right that most browsers and applications *probably* will ignore the content of a script tag with a totally made up media type, but I don't think it's a good idea to rely on that.

The fact that LinkedIn is doing this at all means that the developers who came up with the idea in the first place haven't read those RFC documents, and also probably don't know about this site:

http://www.iana.org/assignments/media-types/index.html

which is the official gigantic list of formally registered media types. That means that there's a chance that one day one of the plugin names might conflict with something else on that list, and that might cause interesting problems. Or not -- it's worth pointing out that "IN" isn't at all like the valid content types "application", "audio", "example", "image", "message", "model", "multipart", "text", and "video". The "IN" prefix seems to be along the same lines as having a ".microsoft" or ".apple" top-level domain name alongside ".com", ".net", ".edu", etc. -- i.e. commercializing/owning/branding something that was supposed to have only an informational meaning.

"IN" is also a poor choice because it's not very unique -- if it's OK for LinkedIn to define its JavaScript type this way, what happens if some other website happens to pick the same one? Suppose there were a network called "FriendInnovate" or something, and they also started using IN/ prefixes (thinking that "surely no one else has thought of this, so it should be totally fine"). Someone writes an app that works on both of them, and oh snap; LinkedIn's JavaScript is trying to parse FriendInnovate's and vice versa. Oops. This is why media types are supposed to be registered and standard.

So, in short, yes, it's possible to get away with using completely invalid values for all kinds of things in HTML, but no one should be claiming that this is in any way "standards compliant," and I strongly suggest that someone on the LinkedIn developer staff read the RFC's and the HTML specs and find a way of describing plugin types that actually is standards compliant.

~Felix.

Eugene O'Neill
Eugene O'Neill's picture
Developer Advocate
Joined: 01/07/2011
Thu, 02/23/2012 - 19:02

Thanks for the thorough writeup! Definitely refreshing to see a developer with such a unwavering and passionate disposition for standards. You sir, rock!

The proprietary IN/Share notation was in place when I joined the team. That said, it's no excuse, but I still stand by my initial statement that it follows the standards. While we don't use a valid registered MIME-type, I think it still follows the standards. Nevertheless, there's definitely room for improvement in our framework. We don't intent to make something propriety (anyone remember fbml?), but we're trying to do something sufficiently unique that lets us easily supports a copy paste solution.

What about something like <script type="text/x-linkedin-share"></script>, which strictly follows the discrete-type/subtype notation.

we could even build in reasonable support for custom namespacing:

1
2
3
4

<script type="text/javascript" src="http://platform.linkedin.com/in.js">
  typePrefix: text/x-whatever-
</script>
<script type="text/x-whatever-share"></script>
 
1
2
3
4

<script type="text/javascript" src="http://platform.linkedin.com/in.js">
  typePrefix: what-are-standards?
</script>
<script type="what-are-standards?share"></script>

we actually something like this for data- namespacing:

1
2
3
4

<script type="text/javascript" src="http://platform.linkedin.com/in.js">
  dataNamespace: LinkedIn
</script>
<script type="IN/Share" data-LinkedIn-url="http://www.google.com"></script>

Thanks for the thought provoking, and humbling, feedback! Much appreciated.

- Eugene

Jeremy Johnstone
Jeremy Johnstone's picture
Developer Advocate
Joined: 04/17/2011
Tue, 02/28/2012 - 16:22

Hi Felix,

While I 100% echo Eugene's comments and want to thank you profusely for the detailed and thoughtful post, I did want to expand upon one point. As someone who is very intimately familiar with all the referenced RFCs (and more that are related to this area), I think LinkedIn's implementation follows the spirit of the spec, despite failing to comply with the letter. Specifically I am going to call out RFC2045 and it's discussion around media types.

The wording of RFC2045 is very specific on the "type" / "subtype" and their semantic meaning. Quoting from the RFC:

In general, the top-level media type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data.

In the case of what the team did, "LI" (while I would have chosen "LinkedIn" personally had I been involved, specifically for the collision potential reasons you point out, but alas it was before my time as well) does fit into the definition of being a "general type" of data, as LI describes "data pertaining to LinkedIn". It also meet the requirement of informing the browser with enough information to tell whether it knows how to handle that content type directly. Further, our "subtypes" of "Share", "MemberProfile", etc further refine and provide the specific format for the type of data, which again meets the spirit and letter of the definition.

The problem, and where we most diverge from the letter of the RFC, is this section here:

This set of top-level media types is intended to be substantially
complete. It is expected that additions to the larger set of
supported types can generally be accomplished by the creation of new
subtypes of these initial types. In the future, more top-level types
may be defined only by a standards-track extension to this standard.
If another top-level type is to be used for any reason, it must be
given a name starting with "X-" to indicate its non-standard status
and to avoid a potential conflict with a future official name.

Because "LI" or "LinkedIn" is not one of the standard approved "types", to fully comply with the RFC, we would be forced to use the "X-" prefix. I likely would have argued that point internally had I been around and would have pushed for something like "X-LinkedIn/Share" for the content-type (assuming we still went with this same approach and not an alternative), but it's not possible to change the past at this point, just improve upon it for the future.

Anyway, I want to thank you again for sharing your insights in this area. I just felt that since you spent the time to do this detailed writeup, I should also put forth the effort for a detailed response in return. :)

-Jeremy