Although, I think you can make a nice badge-maker or something that’ll churn out decent embed code. That’ll probably make it even easier to embed than editing html attribs.


Brandname


Why not make it a query string? Seems like this particular example was reinventing the wheel.

HTML == SGML and is not strict about undeclared insertions of attributes.

XHTML == strict XML and invalidates undeclared insertions of attributes.

Don’t confuse the two. HTML 4.01 is still good stuff; XHTML is overrated.

@broofa & @sentientholon: Third party script implementations are inherently slow because you need to poll yet another server for content and are completely at the mercy of its present lag conditions. Not only that, but odds are that a site using third party scripts isn’t using just one (analytics script, a couple of badges, etc…) so your level of uncertainty and lag time just multiply in those situations. Worse still, if you drop a script tag in the middle of your page or at the top, and you happen to be trying to access the page during a particularly high traffic period for that service (say Flickr, or Google Analtytics), then you *will* have to wait for that server to respond before your page finishes rendering. And that is very noticeable. Lastly, using non-standard attributes is just bad karma. I’ve found repeatedly in the past that if you break away from the standard, you’re opening yourself up to a wide breadth of unintended consequences. Basically the unknown. You know, somewhere down the line, some conditions arise and you end up with an “oops, didn’t think of that” situation.

Just sayin’…

<script src=”badge.js”></script>
<script>Badge.create(‘small’, ‘blue’, ‘ABC’);</script>
<script>Badge.create(‘big’, ‘red’, ‘XYZ’);</script>

Is this harder to understand?

Issue #1, “looping through script nodes is slow”. Only true if there are 1000′s of nodes in the DOM. Even then, getElementsByTagName is probably very performant compared to the rendering time required for a DOM of that size. I don’t see this as something to be concerned about.

Issue #2, “badge.js is called over and over again”: Only true if the browser doesn’t cache the script. But if you set the HTTP caching headers properly this won’t be an issue. The script is small enough that fetching it _from the cache_ repeatedly should be fairly fast.

Issue #3, “script tags make the rendering engine stop and pull the src”: This is just a restatement of Issues #1 and #2. The engine stops while it fetches the source (see Issue #2) and executes the script (see issue #1).

The “real” problems are…

1. The use of non-standard HTML attributes for the script tag
2. The equally-questionable practice of placing non-script content inside a script block
3. Page rendering depends on 3rd party servers to be performing well

The alternative solutions address the first and second issues, but still require script hosted on external servers. (that said, including the script at the end of the page will moderate the effects of said servers not responding in a timely manner).

In many cases, the best solution to this sort of problem is to provide a “configurator” tool that provides a friendly interface for generating the desired HTML markup, which users then simply paste into their page.

– Explains all the options to users
– Allows them to experiment and preview
– Inline code renders immediately
– Inline code doesn’t require scripting DOM elements
– Inline code doesn’t depend on 3rd party servers