Page 3 of 3

Link element load event support for CSS Style Sheet includes, finally!

In the long history of developer attempts at creating a method of loading CSS Style Sheets via LINK tags with load event support, there has been a lot of FAIL and almost no WINNING! Oddly enough, Internet Explorer has supported a load event on LINK tags for as long as I can remember, but Firefox and the Webkit bunch…not so much.

What are people doing currently to service this need? Well here’s an example of half-baked solutions that have surfaced over the last couple of years on Stack Overflow (I have added my solution to the list, so up-vote it!). Most developer have been reduced to loops that look for the new sheet in the StyleSheet object at short intervals or even loading the link tag in an iframe and using the frame’s onload event, two methods that cause me to puke on my shoes on principle.

The Solution

Well web devs, today is the day. Yup, CSS Style Sheet loading via LINK tags with pretty damn legit load event support is a reality:

var loadCSS = function(url, callback){
    var link = document.createElement('link');
        link.type = 'text/css';
        link.rel = 'stylesheet';
        link.href = url;

    document.getElementsByTagName('head')[0].appendChild(link);

    var img = document.createElement('img');
        img.onerror = function(){
            if(callback) callback(link);
        }
        img.src = url;
}

The code above creates a LINK tag for your CSS file and inject it into the head of the document, there's certainly nothing odd about that. Next comes the interesting part, it creates an IMG tag and adds your CSS file location as src parameter of the element then injects it into the page. The browser parser downloads the file and attempts to parse it, which predictably fails as it is the wrong MIME type. That failure triggers the error event on the image element. We know the file is present at that point, so the load event you pass to the function is fired from inside the image element error event, the image element is then deleted from the document. Whether cached or not, this method will fire your load event for any CSS file you include, when the file is in the cache it is called immediately - which is a huge benefit.

Try it out!

Here it is a live demo, I have added an alert as the load event default for example sake:

Opera Added to the Browser Add-on API Coverage Table

I have received quite a few feedback responses on the Add-on API Table. A curiously large percentage of the responses were from folks asking me to add support for Opera’s new extension APIs. Well I committed to updating this thing, so here you go, Opera extensions APIs are now included 😉

The Opera extension API docs were pretty tough to traverse. They are quite verbose and some sections seem like a mixture of a tutorial or article with some method references sprinkled in. I want to make sure I don’t short-change any of the browsers on the list, so please let me know if I’ve missed any APIs.

Happy extension development!

State of the Add-on Developer Union: The Browser Add-on API Coverage Table

Add-ons (sometimes referred to as extensions) are one of the most powerful features of modern web browsers. They allow users to customize browser UI elements, web content, and the user’s data in ways that are not possible with a standard web page. In short, add-ons allow developers to augment the user’s web experience in almost every way imaginable. As a testament to their power to do so, browser manufacturers now routinely use add-ons to prototype new features, some of which end up being built into the browser itself (look under the section entitled “Graduated”).

Add-ons rising!

In the last couple of years the developer landscape for add-ons has been heating up. Mozilla started the Jetpack project (now a full fledged product, the Add-ons SDK), Chrome introduced its extensions APIs, Safari joined the fray, and Opera will soon introduce its own add-ons framework. In comparison with years past, it is an even better time to be an add-ons developer. Assuming you are interested in developing an add-on for any of the major browser vendors today, you would start by asking yourself what they offered in terms of developer support and APIs…

…enter the Browser Add-on API Coverage Table

The following table is a work up of all the various types of add-on APIs offered by each platform. For various APIs, the names may differ from one browser to another, I have done my best to group APIs together that offer comparable functionality. I chose to standardized the titles of the various APIs shown in the table by their Mozilla Add-ons SDK name for uniformity. The list of total possible APIs was derived by taking the all the APIs from each of the browser vendors and reducing them to a unique set based on their comparative functionality. This means the list will grow as browsers release new and different APIs, which will in turn affect the coverage ratings in the table. All APIs link to their source documentation where possible. Have fun learning about all the amazing things you can do to your browser!

Browser Add-on API Coverage Table

If you find anything that is out of date or in need of correction, there is a form in the table’s key that you can fill out and I will be sure to adjust the table. If there is interest in listing other browsers on the table you can leave a comment on the same form and I will be happy to follow up with you about doing so.

Jetbug – Mozilla Add-on SDK debugging library

Dogfooding is an essential part of product development for many reasons and should not be a task set aside for only certain teams. Dogfooding products helps you understand the true user experience a product offers, brainstorm new features, and uncover rough edges in need of correction. Recently while using the Add-ons SDK for a Personas related add-on, I got frustrated with the stringified console logging available by default in the SDK. While attempts were made in the past to provide more robust debugging, none have been able to maintain stability, as they were strongly tied to various moving-target applications.

Necessity Annoyance, Mother of Invention

As I set out on a search for something that would provide a better debugging experience for SDK-base add-ons, I thought I’d first take a crack at utilizing the best debugger on the planet, Firebug. To my delight (and hopefully yours as well) I was able to construct an Add-on SDK library that enabled Firebug-based debugging of add-on code in a way that should remain stable regardless of any future SDK release or Firebug code changes.

Jetbug to the rescue!

Welcome to logging of chrome-level objects and elements. Say hello to introspection of an add-on’s contents. Meet invocation of SDK APIs from the Firebug command line. Yeah, I know, its going to rock your socks. Jetbug is pretty flexible and should go a long way to advance the developer ergonomics story for the Add-ons SDK.

Download the Jetbug SDK library and drop it into an add-on you’re working on. There is a readme file included in the library that contains a brief explanation of how to use Jetbug and what methods are available to you. Let us know how you like it, we’d love to hear your feedback!

Programatically Convert CSS named colors to RGB & HEX

Converting color values between different formats is commonplace on the web. Whether it is a JavaScript-assisted animation, color picker, or modifying a color’s attributes, there are many circumstances where color manipulation is essential to front-end development. One color format particularly hard to work with is CSS named colors. Named colors are widely supported in A-grade browsers, here’s a list of common named colors courtesy of w3schools.

So what’s the problem?

The problem with named colors is the difficult lengths to which a developer must go to manipulate and use them practically. It is relatively easy to use them statically in style-sheets (though I prefer RGB or HEX, in that order), but more interesting uses are usually dynamic ones that result from user input.

As developers, we think in RGB and HEX values because that is the world we are immersed in, users however are more likely to think in black and white as opposed to #000000 and #FFFFFF. What does that mean to you as a developer? Let’s say you have a color picker that transitions a target element to and from colors based on user input, how do you allow a user to type in “purple” and effectively animate your element from #000000 to “purple” without a gigantic, pre-populated, name colors object? Furthermore, what developer would ever want to spend their time assembling and maintaining such a list?

“Computed Styles, I’ve heard so much about you.”

Most developers are aware of computed styles, but just in case you are not, here’s a definition to prime the pump:

Computed Styles methods provide used values for all CSS properties of an element in their most reduced format. Computed Styles is a somewhat costly operation as all the values must be calculated each time the method is called.

One note on the above definition – the used values returned by computed styles methods are always reduced to a common format, this is most evident with the transform property, it is reduced to the common matrix(a, b, c, x, y) representation of the value regardless of which format (rotate, scale, skew, translate, etc.) the style was applied with.

Now that we have a better understanding of computed styles, let’s find out how we can use them to overcome the use of dumb, static named color tables.

As it turns out, all browsers have internal methods for reducing named color values to HEX or RGB formats, some are just harder to access than others. Mozilla, Chrome, and Safari all have a common global method for retrieving computed styles – window.getComputedStyles() – that takes as an argument the element you are requesting the computed styles for.

Opera uses the same mechanism as other non-IE browsers to report computed styles, however named colors are not converted to HEX or RGB values when retrieved with the computed styles method. Instead, Opera strangely chooses to reset the property in question on the style object of the element to the calculated HEX or RGB value of the named color.

IE provides an object, currentStyles, that is accessible directly from the element. Unfortunately IE does not convert named colors to RGB or HEX through any sane means – even in IE9. It is possible to get to the calculated HEX and RGB values of named colors in IE, but as you’ll see below, it isn’t pretty.

Bringing it all together

So let’s get smart about this! With the goods on computed styles I crossmedibrowsertated and came up with the String native methods “colorToHex()” and “colorToRgb()” with a little help from the sextacular MooTools javascript framework:

© 2018 Back Alley Coder

Theme by Anders NorenUp ↑