What Am I Looking At?

This mini-site is a copy of the initial Proof-of-Concept which I developed as a promotional tool to 'sell' the new Global Design Initiative to our business stakeholders at LexisNexis International. It was intended to showcase a new, clean, Responsive design with high accessibility, minimal page weight and graceful degradation back to IE8 support. It's built with HTML5 and CSS3, as described below.

It's vital to note that any Javascript within this mini-site is *not* indicative of our actual implementation. It's purely here for a demonstration of basic functionality and was entirely throw-away.

The below is the (somewhat technical) notes that I made available to my colleagues across our international Web Development team, explaining our targets and my choices as to how to approach them.

I'm pleased to note that the new design and platform went live in the US in September 2014 and has been widely regarded as a great success; LNI are currently in the process of rolling it out to a global audience.


These are faked here via SSI; obv. need to be via Handlebars templating in the real thing. The division of content into SS includes may well serve as a useful pointer towards how the content could be broken up into modules.


We support IE8+ and Safari 5+ as our oldest desktop browsers. By the time we launch, we should be looking at IE11, Firefox 34+ and Chrome 40+, all of which have solid HTML5 and CSS3 support. Mobile browser support TBC.

We've been pretty strict with using Graceful Degradation methods; there is very little in the way of extra code for old browsers. Definitely no use of proprietary IE Filter expressions; they run synchronously and cause major slowdown.

We have used a basic reset.css, which normalises a lot of the browser-specific look-and-feel. There are Conditional Comments loading specific CSS for IE9 and IE8; there's no CSS specific to IE10 (which ignores CC's anyway).


We have gone with a 'Mobile-first' methodology; all clients get the 'base.css' styling. We then use a Media Query to determine if the client has at least a 760px resolution; if true, they also get the 'desktop.css' styling, which overrides and adds to base. Between mobile and desktop resolutions the layout is liquid, resizing smoothly.

IE8 is the only supported browser that does not understand Media Queries. Here we use a Conditional Comment to always apply the desktop CSS; IE8 has no non-Desktop userbase, so this should be fine. No support for Flexbox (see below) means that we needed to go with a fixed width of 960px on Desktop, so a user with less than that resolution will see a scrollbar.

IE9 does have a small userbase on mobile phones, but none on tablet devices. We apply the mobile styling, but have gone with a fixed width of 960px when the Desktop CSS applies, because of a lack of Flexbox support. Users with between 760 and 960px resolution will see a scrollbar. We should not have users on intermediate resolutions, so the layout may well break at tablet sizes, but we ought not to care.


The intermediate liquid layout has necessitated the use of Flexbox CSS. We have solid support for Flexbox across Firefox, Chrome, Safari and mobile devices, as well as IE10+. Neither IE8 or IE9 support Flexbox, so they don't get a liquid layout; see above comments.

We're using display:none to remove stuff that is only visible in either Mobile or Desktop mode, as appropriate for the resolution; this might be better accomplished by switching the content on and off in the Handlebars templates.


'Modal' links default to open as a new page. On Desktop, we use some jQuery AJAX to pull the content into a lightweight modal dialog. This almost certainly needs to be done via Handlebars templating instead.


We have a lot of hide-and-show behaviour. For accessibility reasons, such hidden content should be part of the page structure asap after load. We give hidden content class="supplemental", which applies zero height, width and opacity. The opacity allows us to use CSS transitions to fade the content in and out when it's shown and hidden.

Each hidden element has an associated trigger; a clickable button or the like with class="trigger collapsed".

At present, we have minimal JS involvement in hiding and showing; all we do is switch the trigger element's class from 'collapsed' to 'expanded'. We then use the CSS sibling selector to reveal the hidden content: .expanded + .supplemental {CSS when shown}. This therefore requires that a trigger be the immediate previous sibling of the hidden content it's associated with, which may be fragile.

Where that isn't possible, we use a pair of attributes that associate trigger and hidden element, then address them with JS and manually add a 'shown' class or similar to the hidden content. One example of this is in the Global Nav header; the h1 containing the product name button.

It would be nice to avoid that where we can.


We have no JS-powered animations. CSS transitions and animations are much easier to code and run faster, especially if a graphics card is available. IE9 doesn't support transitions, so it and other browsers just get a non-animated experience.


We have disabled in-browser HTML5 form validation, because the validation messages are ugly and can't be re-formatted consistently. We will need to implement our own client-side validation (via jQuery?). We are using the appropriate HTML5 attributes (e.g. 'required="required"'), and should leverage those as part of our JS solution.

See Form-Validation for example output. On a validation failure, we need to create an overall digest of the errors as first child of the form itself which links to each invalid form field. Just preceding each form field, we also add in a list of specific problem(s) with that field, and we must apply class="invalid" to the field itself.

Similarly, form fields that have been completed correctly should get class="valid" to pick up the right styling.


We are using the iconfont technique to show (almost all) icons. This requires loading a custom font with icons imbedded as characters, and allows us to resize, reposition, and apply arbitrary text CSS styling to our icons. We're adding them via CSS generated content in :after and :before pseudo-elements, which is fine but doesn't work on form elements. We use a (possibly nasty) bodge to counter this, where we insert a character from the iconfont as the value of our Submit buttons, to display a 'magnifying glass' icon. A different solution might be preferred...

We have minimal images loaded. We're using CSS gradients; any browser that doesn't support them gets a flat colour instead - no use of IE Filters, as explained above. Almost all icons are part of the custom iconfont; we've used images only where an icon needs more than one colour, and for the LN logo in the footer, which rendered poorly as an icon.

Except for one instance in the (Desktop-only) IE8 CSS, we are not using Data-URIs. There is a major (6x) overhead when decoding Base64 on Mobile devices. See


Craig Woollard identified a set of page types that we're using as classes on the body. These can be thought of as our highest-level templates. The actual position of the various panels may vary by product or localisation:

We have used an OO-type method of applying CSS, e.g. class="icon dropdown trigger collapsed product-names":

This ought to give us maximum flexibility and re-use from class names while maintaining semantics. We have not used non-semantic classes like 'red' or 'leftfloat', because that's the opposite of useful and I hate them. If you do use them, I'll come round your house with a pineapple. There's no bloody 'clearfix' class. We use appropriate float or overflow properties instead.

Wherever possible, we've tried to avoid using elements as CSS selectors; we're sticking with classes 99% of the time. This should allow for re-use and refactoring. We do have a couple of instances of ids being used, but these really are for unique content (the masthead and the page footer).

We're using <button> elements wherever we need something to be clickable, but it's not a link that navigates. This means that they'll still appear in the tab order, and we can give them 'disabled' attributes, and so on. We must specify that they have a type="button"; otherwise dumb IE assumes they submit any form they live in.


By necessity, GDSI cannot cover all possible functionality across LNI/US. Some markup is unfinished, and serves just to place a button or similar, with no results from clicking the thing:

jQuery is a heavy library

It does a lot, but it's pretty big as a result. Can we find a more streamlined library to use, at least on the basic single-column mobile view? Here are some possible options, all focused at responsive or mobile first development.

Anything new and third-party that we add will have to be agreed to by the Architectural Committee, of course...