They bypass all the detritus in ‘economic leveraging’, ‘strategic incubation’, ‘synergistic e-business’ and the rest of the bullshit and produce something simply for the challenge and love of experimentation. Last week flickr exemplified this beautifully, and really renewed my faith in the development and web community at-large having a good sense of humour. Yet at the same time pushing forward at what’s possible with data and technology. I present:

The Rainbow Vomiting Panda of Awesomeness

If the image wasn’t enough to warrant the highest of praise—I foresee pandas as the new meme to beat unicorns— flickr have just launched a couple of very curious and fun API calls that may have limited usefulness but really exalt what today’s Web should be about.

We’re no longer a passive Web of static, inaccessible content. Today’s Web is a huge, living, breathing pool of data and it’s all about seeing what we can do with it!

Long may the renaissance continue!

Due to the size and scale of of the application—it’s quite big and complex in comparison to many Opensocial apps—our message bundle XML files contain a lot of content and, as a consequence, consume quite a lot of a bandwidth over the wire.

Why is this a problem? Well, it shouldn’t be, but many Opensocial containers opt not to cache message bundles, and instead request them on every application invocation. The result is that network dropouts, latency or server-load can mean your message bundles occasionally fail to reach the consumer server and entirely prevent your app from loading. End-users shouldn’t ever have to suffer as a result of server-to-server communication.

So, in lieu of consistent caching across Opensocial containers, this issue can be sidestepped by inlining the message bundle content inside your application gadget specification. This is a new feature introduced in Opensocial 0.8.1, and so you should ensure the container you’re working with is operating on a 0.8.1 codebase.

How to Inline a Message Bundle

It’s actually very simple, but it’s also something that isn’t officially documented anywhere. Opensocial development often involves shooting in the dark… but fortunately it’s well enough spec’ed that a little bit of guesswork goes a long way.

Message bundles are always referenced from the <ModulePrefs /> block in a gadget spec, and look something like this:

By simply removing the messages attribute from each <Locale /> element, and placing the relevant message bundle content (excluding the xml prolog), message bundles are no longer referenced externally and load along with your gadget spec:

We’ve found that it’s much more common for gadget specs to be cached hard. Thus the additional weight of inlining your message bundle content inside your gadget XML is negated, and the application should—container-dependant—get some improvements to stability and performance.

There is one caveat. Inlining content introduces maintenance and development issues, especially if you’re running several gadget specs for different enviroments i.e. development, QA and live. In respect of this, I’d recommend keeping all your message bundles in external files and instead adding something into your deployment process that will perform the inlining as and when it is needed.

One of the first lessons of HCI is the concept of interface metaphors – singular design elements that quickly infer an action or result of the user based on familiarity and association. The Recycle Bin and the Folder being two of the most well-known.

On the web, icon design contributes to this hugely, and the success of a site’s design is largely thanks to a consistent icon set. Unfortunately most of us don’t have the time, patience (or talent!) to create an all-encompassing set of icons for a project, and so we must rely on the excellent work of designers around the World to help us on our way.

Here are 5 free icon sets, available for commercial use, that I believe fit the bill over the plethora of icon sets available:

FamFamFam Silk

How could I not start with the ubiquitous Silk set. It’s a set that is seen absolutely everywhere, for a very good reason. It’s a huge set of 700 beautifully crafted icons that are free of a strong design-style; able to fit into any design and for any purpose.

» Download FamFamFam Silk

FamFamFam Mint

I’m particularly fond of this small set of minty-hued icons (apparently inspired by Shaun Inman’s Mint). While they might not find their place in every design, their minimalism and space-saving dimensions deserves giving them a look.

» Download FamFamFam Mint

Sweetie

Compact, but useful icon set with a glossy and colourful style. Comes with 4 icons sizes, from 8×8 up to 24×24, for a number of the included icons.

» Download Sweetie

n-design Mini Pixel-Icons

A smart and well-featured set of 320 14×14 icons; particularly good for e-commerce sites, as a good number of credit-card, shopping-cart and basket icons are included. Comes bundled with multiple shades to fit into and brighten up a plain app design.

» Download n-design Mini Pixel-Icons

Pinvoke Fugue

A huge, stylish icon set that I’ve not seen as widespread in the wild as Silk. Certainly one of the best large icon sets available on the Web.

» Download Pinvoke Fugue

Closing Note

Most icon sets come prepared with transparent backgrounds, using PNG alpha-transparency. This type of transparency is unsupported in IE6 and produces undesirable results.

The simplest solution to this problem, is to create alternative versions for IE6 in PNG-8 format (which supports 1-bit transparency). A little bit of pixel-pushing will be needed to make them look perfect, but I’ve never had any problems using this workaround. The Pinvoke and Sweetie sets already come bundled with alternative IE6-friendly versions.

Well, almost… In combining the two content networks, I’ve had to be quite careful about what appears where, to whom and how. As I mentioned in a previous post about MTV Networks, video content comes from the most restricted datafeeds used on the Compendium, particularly regarding geographical location. Dependant on your location, and licensing, some videos may not be available.

When videos are loaded in an artist profile on the Compendium, an AJAX request invokes two simultaneous server-side requests to go off and retrieve videos from Y!Music and MTVN—this is cached. Once these are successfully retrieved, they are combined and then passed off for pre-filtering.

Filtering the video feeds involves three steps:

1. Remove duplicate videos, based on the song title
2. Remove videos that are not specifically by the artist or under the artist’s name, but may have been returned as part of the webservice search query
3. Remove videos that are restricted either by geographical location or are not available for external embedding.

Geographical filtering is done with the help of the Net_GeoIP Pear package. This is OO version of the regular Pear GeoIP package that queries the flat Maxmind GeoIP databases. This returns geolocation information based on IP. It is still in beta, but appears completely stable. It can be installed from the command-line using:

$ pear config-set preferred_state beta
$ pear install Net_GeoIP
$ pear config-set preferred_state stable

Conveniently it uses a Singleton pattern to stop the flat database files being initialised multiple times within a script. However it is still by far the slowest data lookup in the Compendium. I wrapped my own lookup methods into another Singleton, and used $_SESSION values to store country and city lookups. This prevent multiple database lookups happening, unless they change, since geolocation is used not only in Video feeds but also Events data lookups. Further improvements can be made by pushing the flat database files into memory or into a DBMS like MySQL.

With this geolocation data at hand, MTVN videos are filtered based on attributes in the returned dataset. Y!Music works slightly differently, in that each geographical location has it’s own base API address, returning videos only available in that region. So Y!Music is filtered at the source, rather than at the point of retrieval.

Once this filtering takes place, the resulting array is checked to see if it still contains any valid videos. If there are no videos available, an empty response is returned to the page. This return value causes the Compendium javascript to invoke another AJAX call to retrieve fallback content from Youtube. Youtube nearly always returns results from its catalogue of x million videos; but these still need a little bit of filtering and nudging to produce accurate results.

All these lookups are cached, and the AJAX lookups are bypassed when valid caches exist, meaning that videos are injected directly into the page when it renders.

If you’re in the US, UK, much or Europe and a few other places, you should see official music videos appearing for selected artists. If not, you’ll get Youtube results appearing.

Some examples:

• Britney Spears Videos
• Led Zeppelin Videos
• My Brightest Diamond Videos

The last, however, is US only. So to end this post on a high-note, here’s the excellent video by Raf Toro of My Brightest Diamond – Inside a Boy. In hi-def, courtesy of Vimeo (coming soon to the Compendium… perhaps):

Inside A Boy from Rafa Toro on Vimeo.

If you find any bugs with the video feeds, please let me know.

Traditionally, the default action for a <form> is to fire the first submit button found within the current <form> element. Every form has one default action.

Striking the enter key within a text input field should submit the current set of—logically grouped—fields; this is the expected behaviour. For pages with multiple forms and actions, this is easily separated by having multiple <form> elements, each with their own submit buttons and actions. Each form operates independently, has its own default action, and doesn’t interfere with other forms.

In the Single Form Model, the presence of just one <form> element, means that different default actions cannot be easily separated. Every input field on the page is automatically tied to just one default action – the first submit button on the page.

Take a blog site as an example – like this very page! It has a search form at the top, with associated submit button, a comment form further down the page and perhaps another form for signing up to a newsletter. Implemented with the Single Form Model, only the search form will produce the correct behaviour as it introduces the first submit button on the page. All subsequent fields will be tied to this same button as their default action – submitting a comment by pressing enter would cause the search form to submit, as would signing up to a newsletter. Not particularly useful.

Can we cure this problem?

The answer is yes… partially. The problem we have concerns UI behaviour. Any solution needs to manipulate and override behaviour, and this is the domain of Javascript. We can’t manipulate the markup in our favour as we’re under the control of the Single Form Model (not without a complete switch to .NET MVC anyway). But there’s a conflict here—javascript is not a fully accessible technology. There are many environments where users do not have Javascript available.

However, in this case, using Javascript is an acceptable answer—this is progressive enhancement of sorts. We’re not adding a dependency on Javascript, merely enhancing the usability of the form inputs for those users with it enabled. Javascript-disabled users will still be able to use the form, except they will experience the ‘broken’ behaviour. Form accessibility in .NET is pretty horrendous anyway, so anything we can do to make improvements is better than nothing at all.

Doesn’t .NET provide a solution already?

Yes, it does in version 2.0 and above. This is the defaultbutton attribute, which can be used in <asp:panel /> and <form>. Fine, so why not use this? There’s no real reason not to, if you’re starting from scratch and don’t mind crufty .aspx pages.

But this wasn’t suitable for me. In an existing codebase, this requires a lot of extra change, and the addition of specific panels to group related sets of form fields is completely unnecessary. An HTML element already exists for that: <fieldset>. Yes, the mighty fieldset-who would have thought?! In any sanely coded page, fieldsets group fields, and so we already have part of the solution without needing to make any changes.

The other reason for rolling our own solution is that defaultbutton doesn’t offer the flexibility of applying the default action to any type of button—be it a <input type="submit />, a <button />, an <a href="javascript:..."> anchor and so on. Nor provide any custom event handling when default actions are fired.

A Proposed Solution

1. Connect fieldsets with their default buttons using minimal markup

Although fields are grouped, we still need to provide some relationship between a button and a fieldset. We should provide enough flexibility that our default button could be anywhere on the page, not necessarily within the <fieldset>.

A clean and unobtrusive way to provide the relationship is via a common attribute, the classname. We could use the id attribute, but this should be avoided – you have to accept that when you’re working with .NET, it owns every ID attribute.

Using the classname, we create a unique identifier for the fieldset. If we then add the same identifier to the default button for that fieldset, a useful relationship between the two is created. For this to work best, all identifiers should begin with the same string so that we may write a generic function to pick them out of the markup and identifiers for each button to fieldset relationship must be unique. Here I’ve used “submit-…“:

Now we have connected buttons and fieldsets, we need to handle events on the page fired when the enter key is hit.

2. Handle enter key events with Javascript/jQuery

There are a couple of ways we can do this:

1. Be proactive. Scan the entire DOM on page load, find any fieldsets with a “submit-…” class and bind an onkeypress event to every input inside to connect it with the right button.
2. Be passive. Use event delegation and listen for keypress events on the page and decide whether we need to handle a default action event for it.

Option 1 is quick to implement, but very inefficient. On every page load, we must scan the entire DOM for <fieldset>s, and then do all the work of binding events to the input elements, even to elements that may never be used. This is computationally expensive and will be a real drag on page startup times.

With option 2, we need only find one element in the DOM, bind one event to it and then wait for the enter key to be pressed:

1. Using a fast ID selector, $('#content'), we find one containing element for the whole page. It could be <body>, but in this code I’ve gone for an imaginary <div id="content"></div> element that might always surround our site’s content. This element will handle the keypresses for all fields on the page.
2. To this element we bind an onkeypress event listener function to listen out for any keypress that happen within it— $('#content').bind('keypress', function(e) {});.
3. We start the function by checking for two attributes of the keypress event. These are both contained within the event object that is passed into the function— e:
   1. The key that was pressed
   2. The target HTML element that the keypress has bubbled up from.
4. For valid keypresses— an enter keypress from an input target— we find the input element’s parent fieldset, and extract the classname begining with “submit-”. We use the CSS attribute selector and find any value that begins with (^=) the submit string— ('class^="submit-"').
5. We can now find the button in the page that corresponds to the identifier, and trigger a click event on it. We need to handle different types of buttons, submits and anchors slightly differently.

If no button is found, we leave the function silently. We could re-trigger the default action, but this is what we’re trying to fix. I think it’s better the enter key stops working completely, rather than producing unexpected or potentially dangerous results if the wrong action is triggered.

In this initial phase of the platform rollout, Linkedin sensibly took the decision not to open the floodgates to developers and launch with just eight selected partners who could provide application features that are relevant and provide value for the core Linkedin userbase. Business deals aren’t made by virtual high-fiving the CEO of a multinational, and dream jobs aren’t won by poking your prospective employer—well at least not without the risk of legal action.

But enough about Linkedin’s launch from me; there’s lots in the blogosphere and the tech press out there. I want to focus on the most important and exciting aspect of this launch. That being the existence of online collaboration startup Huddle.net as one of the eight partners to be featured in the launch. They are the only UK-based partner—in fact the only one outside the US—and a company that I hold in very high regard… it is the company that I work for. It’s a very exciting time to see Huddle sitting up there against big heavyweights Google, Wordpress and Amazon. And, from the development team’s viewpoint, a somewhat frightening prospect too… scalability in code and hardware is a whole new ballgame.

So, without further ado, I present to you the result of a fair amount of blood, sweat and tears [not forgetting the coffee, cigarettes, beer and pizza] amongst my colleagues—it’s been an incredibly intense couple of months— the Huddle Workspaces application on Linkedin.

“Huddle Workspaces offers private online workspaces for secure team collaboration, document sharing and discussions within the LinkedIn network. Users receive 1Gb of free storage and can collaborate with unlimited connection.”

I’m unashamedly biased, but I do highly recommend you to go and get it installed and simply have a play. There’s a lot more going on in the app than anything else on Linkedin’s platform at the moment. It’s a shame that it’s the only properly interactive and genuinely collaborative tool available. All the others seem, at first glance, to suffer from that rather ugly social network trait of passive “look at me! look at me!” signposting and ignore the point of networking in the first place – to actively connect, engage and collaborate with likeminded people. So, in case you didn’t catch that… install Huddle Workspaces on Linkedin here.

Ok. I’ll stop with the shameless pimping. I do have sleep to catch up on. In future entries I want to write about the more interesting stuff of actually working with the Opensocial API. It’s currently a technology lacking general blog chatter. There are lots of questions out there, but usually with few answers; it was peculiar to discover Myspace as a technical resource. And the documentation is currently too dry/technical and lacking in ‘human’ explanation to be a sufficient one-stop Opensocial resource. If in fact there is something out there I missed, please let me know in the comments.

Yes, most certainly we can. In this tiny whisper of time, we’ve got a great opportunity to exploit an inactive javascript engine before the serious work starts at DOM Ready. This period of time occurs before CSS styling, layout and rendering (the ‘painting’ of the UI after the previous steps). The typical model for page load in a browser is Parse/Load DOM -> Styling -> Layout -> Rendering, with javascript being allowed to execute at each step.

Of course, executing javascript before the DOM Ready ‘event’ is certainly not a new technique, but a pertinent reminder in these days where DOM manipulation is the hot topic that we don’t need the entire DOM loaded for javascript to be of use, just a little bit before the first code can be introduced in the <head />:

At this point, code in <script> can access and manipulate a few elements, two important ones being the Window Object and the root of the Document Object—whence the DOM descends— otherwise known as documentElement, or everyone’s favourite HTML element, <html />. On this, the very cusp of page load, we can actually do some useful startup initialisation aka bootstrapping.

Bear in mind that browsers these days reach DOM Ready very quickly, and so no matter how fiendishly inventive the code you might write to run here is, it must be compact and efficient to be downloaded and run in a manner of milliseconds. Just native javascript here, nothing fancy from your favourite framework. Expensive calculations and weighty scripts can end up having negative impact on page load times. For a start, <script /> elements block parallel downloads – that is to say that they prevent the browser from starting to download any other page assets—like images and css—until the referenced script has been downloaded, parsed and executed.

So, with this in mind, what are some simple and useful pieces of code to run?

Utilising the Window Object – frame busting!

The traditional javascript “frame buster” technique is designed to prevent sites from being enclosed in an <iframe />. For most, it’s a defensive measure against website hijacking and other similar nastiness. It’s a simple trick that requires only a reference to the parent window object.

By making a strict comparsion—using the !== operator—of window.self (a reference to the window object itself) against window.top (a reference to the topmost window in the window hierarchy) we can ascertain whether the window of the calling page is the one it is supposed to belong to.

In a non-iframed page, top is identical to self. The topmost window in the window hierarchy is the calling page’s window and not a reference to another window outside an iframe.

In iframed pages, the condition evaluates to true, and so the parent window location is set to the calling page’s location causing the entire page to redirect directly to the calling page.

Simple, quick and handy… though not always useful. In the real world, we sometimes need to use iframes.

Utilising documentElement – enhancing accessibility

Accessibility’s not just about making your page work in a screen reader. It’s about providing a usable site for as many different types of users, in as many different environments as possible. In this code snippet, we can enhance accessibility for two types of users – javascript-enabled users and those with javascript disabled. And we can do this with CSS.

Having access to documentElement, or <html />, means we can manipulate it; notably its attributes. With a few lines of code we can modify the document’s <html /> element to enforce a global CSS class on the document… perhaps something like “canhasjs”:

In this code, we first check whether the class name “canhasjs” already exists using a regular expression match(). If it doesn’t, we attach it. The class name is attached under two conditions using a ternary operator for brevity – if <html /> already has a class name, we append it with a preceding space character, otherwise we just set an entirely new class name.

And voila, the page is loaded javascript aware. With this selector available it is simple to use CSS styling conditionally – enabling certain styling for javascript aware browsers, and different styling for javascript-disabled browsers.

Bringing the Two Together – accessibility and flexibility

In the first code snippet, a simple conditional informs us whether the page is iframed, while the second informs us about the availability of javascript. With a simple change, we can combine the two bits of information to initialise a page that can render in multiple states – be it iframed and javascript disabled, javascript-enabled and not iframed and so on.

Produces:

<iframe /> and Javascript aware CSS selector goodness!

This is a very simple, and somewhat naive, example of bootstrapping. But it provides the basic principle to build upon. A smart idea would be to perform some kind of javascript dependency handling and injection: instead of loading all your JS up front, the bootstrap code could figure out which javascript files need to be included in the page—using class names or similar attributes— and load them on demand. Or detecting window width and loading an appropriate stylesheet that would manipulate layout for smaller or larger window sizes. Lots of potential.

It’s very much an initial dip in the water – it’s unstyled and unformatted, and frankly pretty damn rough and ready. But it’s working, and that’s the exciting thing. At this stage, the Compendium is automagically determining your current location with a pinch of magic powder, and attempts to provide details of any relevant upcoming events for the selected artist. Events data comes courtesy of eventful.com.

This geolocation method does need to be tuned, and will be modified to offer a choice of location in case it doesn’t accurately choose a location for you in the first instance. Along with lots more usability improvements for ‘events’, this is the first of a series of planned updates to the Compendium over the coming month or so.

And now, a few Compendium statistics:

• Total number of Artists known : 55,358
• Total number of Releases known : 62,963
• Volume of cover artwork stored: 1.2GB
• Volume of raw Compendium data stored: 2.5GB
• Total number of web-services consumed: 9
• Average number of web-service calls made per page: 11
• Average level of awesomeness of artist viewed: high
• Typical data retrieval speed: Ninja-speed
• Volume of coffee consumed: Dangerous
• Hours of sleep lost: Not that much, actually…

There are a number of steps involved in providing assets to clients efficiently. This entry covers one of them: combining and compressing. The primary aim is to reduce the number of (HTTP) requests made to the webserver while serving assets and to reduce the bandwidth consumed in delivering them. In the simplest form, we do this by combining all our CSS and all our Javascript into single files, compress the text by removing redundant whitespace and comments and/or running code optimisation routines, and finally send them gzipped. The latter takes place, if supported by the end-user, to further compress the files when they’re sent over the wire from the webserver to the end-user.

We could do all this from the very start of developing a new project, but this introduces great pain into the development process. It’s nigh on impossible to debug combined code compressed to a single line of text, and a massive headache to manage and work with in multi-developer situations under revision control. So, in this case, compression and combining—“combressing” perhaps!—should always take place just before code is put into a production environment, leaving development with fully commented, uncompressed code. Thus ‘combressing’ (I’m going to patent it) should be scripted so that it’s a simple one-click process to push these special live-only assets to live servers.

1. Combine files to a single file
2. Compress files using our method of choice
3. Configure our webserver to send the files gzipped
4. Modify the codebase to make development easier

Combining

The first step, combining, is a simple process. On Linux boxen, we use the cat command and on Windows we can use the copy command. Both are roughly equivalent commands. Note that the process is identical for both CSS and JS, bar the file extension.

Combining on Linux (.sh)

We con_cat_enate all files together at once and push the output to one file ‘tmp.js’.

Combining on Windows (.bat)

We copy each file on to the previous and push the result to one file ‘tmp.js’. Note that each line must copy the previous tmp.js to the next file, and then save to tmp.js again. As ever, Windows makes life overtly verbose for the developer.

Compressing

I choose to use the Y!UI compressor as it tends to produce the best overall compression results in combination with gzipping, while being a lot less brutal in actual code optimisation routines (for javascript) and being able to compress CSS too. Other options for javascript exist, such as /packer/ and JSMin. Your mileage may vary!

The following commands are from a Linux script, but are identical for Windows except directory slashes should be \.

Compressing JS:

Compressing CSS requires just a change to the type flag:

At this point there should be two files, a combined.css and a combined.js, You should note a marked difference in file size between the uncompressed files and the finished version.

Reducing Bandwidth Consumption with gzip

This part isn’t essential, but it helps a great deal and gzip-encoding is supported by most modern web clients. Even after combining and compressing, you can see anything from 40%-60% reduction in bandwidth consumption per file! For example, employed on beardscratchers.com, 22KB of javascript drops down to a tiny 6KB!

Naturally this comes with a little bit of processing overhead as it’s performed on-the-fly, so beware of using it on everything. It’s somewhat of a topic all of its own, so I’d like to point you towards my del.icio.us gzip+compression page, which will be updated with the most useful resources I find on the subject. Currently the best reading is at:

• Gzip Your Minified JavaScript Files
• The Definitive Post on Gzipping your CSS

Easing the Pain of Development

How can we make this easier to deal with? Is there one fire-and-forget method for this? The answer is no. In my experience, the best practice is twofold:

• Script the combining and compressing, and make it part of your deployment process. On personal projects I use a simple bash script and run it while my FTP client fires up. While professionally it’s employed into the build processes, and checked for errors (yui compressor returns parser errors).
• Modify your web site/app code so that it conditionally loads the CSS based on the hostname or some other flag indicated by the environment/configs.

By example, I’ve modified my Textpattern templates here to conditionally load CSS based on the hostname aided by the aam_if_host plugin.

My master.css contains a list of @import statements, importing all the separated CSS files during development.

This is only a brief overview; it can get quite complex when you’re dealing with conditional comments for CSS, loading CSS for individual browsers (these shouldn’t be combined), or wish to implement lazy/on-demand loading of Javascript. But hopefully it’s a good starting-point for improving the efficiency of serving CSS and Javascript on the web.

I’m an advocate of encapsulating Javascript functionality in an object-oriented manner using native Object Literals, following a rule of one object per application feature; one for navigation, another to enhance forms or provide an image gallery and so on. Aside from the benefits of encapsulation, it’s just a lot less problematic to scale and manage your javascript codebase across files and developers by organising code in this fashion.

Design patterns for writing javascript objects are in fair abundance in the wider Web. Some are much more strict about exhibiting true object-oriented features than others. One such is the ‘module pattern’ by Douglas Crockford. Personally, I tend to be a bit more lax about it, and simply use literals to reduce the number of objects and variables in the global namespace, while maintaining a quasi-OO structure. If you’re a PHP developer, you can think of it like the difference between OOP in PHP4 and OOP in PHP5. If you’re not, don’t worry.

A simple javascript object

With this code, we’ve contained our methods and properties in a single namespace, avoiding potential collisions with other Javascript code running concurrently.

Making the object useful

If one object is used for each feature we write, then each object should only ever have one context. It is a single static property which we will continually access. In the following example, a new object is created in which our desired context is an element with the incredibly imaginative ID of “element”:

It has a single property, _context. This contains the DOM reference returned from a regular jQuery selector call – $(’#element’). We can use this property throughout our feature’s code, passing it in as selector context or working with it directly.

However, since we will be using the object context a great deal, it makes sense to try and look for any quick-wins. By using a simple getter function, getContext() [line 10], we ensure the actual $(’#element’) function call happens only once, and every subsequent request for context simply returns the reference we’ve already stored in _context. This is a nice and simple optimisation; context shouldn’t ever change, we don’t have to rememeber to initialise the property at the start, and potentially save many unecessary getElementById() calls in our code!

In practice, we use the getter with a call to this.getContext(), as shown in the dummy highlightItems() function [line 18]. The first time it’s called, we retrieve the DOM reference. Do bear in mind that this only references the current scope. You’ll need to watch out for cases where you’re in a different scope, stopping you from accessing the property in this way – a subject for another day, perhaps!