Archive for the ‘CSS’ Category

HTML5 elements in Internet Explorer without Javascript

Elco Klingen has written up his exploration into a technique for support of HTML5 elements without the need for Javascript tweaking.

Most browsers will support styling of HTML5 named elements using CSS, even if they don’t properly support or recognise those elements. Internet Explorer is the exception to the rule, and doesn’t apply styling to the new elements — it takes the approach that if it’s not part of the doctype spec, then there’s no point in even trying to parse the CSS.

Elco on the approach:

The solution is actually pretty simple; put the new HTML5 elements in their own namespace. By doing so, Internet Explorer skips checking (and collapsing) the new elements and they display just fine. It’s the same method as styling an XML document with CSS and Internet Explorer displays that just fine, too.

It’s a technique I played around with a few weeks ago, and — although quite clever — isn’t really useful in any practical way. Instead of using an <section> element, you instead need to use a namespaced version, like <html5:section>. The reason I abandoned the use of this technique was because it creates more problems than it solves, and your not using a very convoluted strain of HTML5 — if we’re trying to standardise things with HTML5, then this kind of technique just muddies the waters.

It’s a commendable attempt at solving an irritating problem though: I really wish basic support for HTML5 elements could be enabled without the need for scripting. I’ve tried a few techniques and have yet to find the holy grail. I’ve tried several methods of tweaking the doctype to include the new elements, but to no avail. I even looked at using an HTC file to wrestle things into shape, but since any transformations on the DOM require scripting, that was a dead-end.

The closest I got was to use XSLT to transform the document – effectively swapping out every instance of an HTML5 element with a division which identified the element type with a class name, like <div class="article">. Since Internet Explorer has good support for XSLT this is a very reliable technique, but with one major drawback: for it to work, the document has to be served up as an XML file. Aside from the complications that creates for how you serve up your documents — particularly if they’re scripted — it causes havoc for other browsers.

So, sadly, it looks like Javascript is the only way to do it, for now.

The 1140 Grid

Another contender in the one-grid-to-rule-them-all category: the 1140 grid is designed to be fluid, right down to a mobile version:

The 1140 grid fits perfectly into a 1280 monitor. On smaller monitors it becomes fluid and adapts to the width of the browser.

Beyond a certain point it uses media queries to serve up a mobile version, which essentially stacks all the columns on top of each other so the flow of information still makes sense.

It’s a nice, simple idea explained in a very clear and concise way.

Sencha Animator: The CSS3 Alternative to Flash?

Sencha, the guys behind the ongoing development of ExtJS and some other very clever UI technologies, have announced the release of a new tool for creating CSS3 animations:

Sencha Animator allows you simply place objects (text, shapes, and images) onto a re-sizable stage area, configure their properties and then animate to bring them to life. You can move, scale, skew and rotate objects singly or at various levels of nesting, in 2D or 3D space. With Sencha Animator, you can also take advantage of CSS3 capabilities like gradients, blurs, reflections and shadows.

At first glance, it looks to have a very clean and well-implemented user interface – better than the offering Adobe previewed earlier this week at least.

I can’t say I’m too keen on this continuing trend towards using CSS for “animations” though. My worry is that people will start to abuse these kinds of tools and start to create ugly, breakable user experiences which hark back to a web we were glad to leave behind. Slick and elegant transitions I have no problem with, but give people a Flash-esque tool for CSS, and Flash-esque applications they will create.

The really interesting thing to note here is in the foot of their announcement:

For those of you wondering what Sencha Animator is written in, the answer is… Ext JS of course! Ext JS provided an enormous short-cut in development time and allowed us to deliver the product on multiple platforms without worrying about Objective-C or Windows APIs.

Very clever: a fully-fledged, multi-platform application written in Javascript. And I assume that means it would also run perfectly fine in the browser.

Preview of the Edge prototype tool for HTML5

Interesting. Short video from Adobe showcasing a prototype of their new Edge tool, for creating animations and transitions using “the capabilities of HTML5″.

A few things which instantly spring to mind:

  1. The transitions featured in this demo aren’t capabilities of HTML5, they’re capabilities of CSS3. CSS is the technology which deals with presentation logic, and to continually refer to the “animation capabilities” of HTML5 is simply misleading and will cause confusion.
  2. Speaking of confusion: it’s interesting that Adobe are seeing fit to use unfamiliar language to describe the elements of their user interface: “Layers” to identify DOM elements; “Actions” to manage groups of transitions; “Symbols” to group objects. The semantics seem all wrong, and are reminiscent of Flash authoring (something they’re probably quite keen on). It just all sounds very unfamiliar and over-complicated, because…
  3. I know this is just a prototype and proof-of-concept, but surely this is just a very basic UI for writing CSS transition rules? Webkit is being used for rendering much of the property panels seem to be borrowed from Firebug and Safari development tools. The only new thing here seems to be a Flash-esque timeline.

Well done to Adobe for stepping into the HTML5 eco-system. But surely it makes sense to jump in with both feet and present something with substance, rather than dipping their toe in with some flimsy animations?

Update: It appears than on closer inspection, this prototype isn’t even using CSS for transitions: it’s Javascript manipulating the HTML DOM. So what exactly has it got to do with HTML5? Absolutely nothing. Bad show Adobe.

The 1Kb CSS Grid

I’m a bit late to the table with this one, but worth noting nonetheless. The 1Kb CSS Grid is a super-lightweight CSS grid system:

Other CSS frameworks try to do everything—grid system, style reset, basic typography, form styles. But complex systems are, well, complex.

Tyler Tate elaborates in the first of a series of posts:

With added complexity comes… well, complexity: a steeper learning curve, increased development time, and — cringe — tougher debugging.

Here is a fresh take on the CSS grid (loosely based on Nathan Smith’s 960 Grid System). Its mission is to be lightweight.

End hover abuse now

Cennydd Bowles speaks out on the trend of using hover states in web interaction:

Designers who pop up information panels or move page elements on hover are using flawed logic, second-guessing what users want to do before they do it. The result, which I’ve seen in countless usability tests, is that users activate these controls accidentally. You know what happens? People actually flinch: “What was that?” They return with hesitation, less confident in their understanding of the site. It’s no accident that the Twitter worm propagated through hover— accidental activation meant users spread the worm unintentionally.

He makes a good point, particularly in a time when hover states are becoming a less reliable feature anyway, as the onset of touch devices makes hovering a non-entity.

Trent Walton has written a really useful and informative article about this subject:

As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.


Keys.css is a really simple and elegant stylesheet from Michael Hüneburg for rendering beautiful keyboard-style elements. Compatible with all modern browsers, and degrades gracefully in older ones.

Top job! And no horrible font-wrangling or images in sight.

The Square Grid

There are a proliferation of new grid-based CSS frameworks popping up. The latest is The Square Grid, built around the idea of a 28px horizontal and vertical rhythm:

simple CSS framework for designers and developers, based on 35 equal-width columns. It aims to cut down on development time and help you create beautiful-structured websites.

Well thought through, and nicely presented.

960 Grid System is Getting Old

Nick La on why it might be time to take a fresh look at the trend of using the 960 grid system:

The problem with 960gs is the gutter space and content width. Minus the margin space, the actual content area is only 940px. It worked well back then because most designs are set at 12px font size. These days most designs are set at 13px font size or higher. Since the font size has increased, don’t you think we should increase the content area as well as the gutter space?

In a follow up post, he elaborates and presents details of a more modern, semantic and simpler grid system, concluding:

Don’t force your design to fit to a grid that hinders your creative genius. Do what makes your designs look good and is comfortable to you. A grid should be your layout guideline, not restriction.


Stylebot makes it stupidly easy to customise your web experience:

Stylebot is a Chrome extension that aims to simplify customizing the web, making it more accessible and adaptable. It puts you in control of the web’s presentation, allowing you to quickly change the appearance of any page.

A real coup for web accessibility and adaptability. Beautiful.