Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Interview and Book Review: Pro HTML5 and CSS3 Design Patterns

Interview and Book Review: Pro HTML5 and CSS3 Design Patterns

Every application is unique - but its components aren't necessarily. Toolkits and libraries can bundle higher level GUI elements and concepts, but they drag along a dependency on that library. 

The new book "Pro HTML5 and CSS3 Design Patterns" investigates and catalogs a host of commonly used patterns in web applications and presents solutions using HTML5, CSS and, where necessary, Javascript. The book’s publisher, Apress, has provided InfoQ an exclusive excerpt from Chapter 2, “HTML Design Patterns”.

InfoQ caught up with one of the authors of the book, Dionysios Synodinos, to talk about the ideas behind the book and the state of the art in HTML5/CSS3 and Javascript development.

InfoQ: One contribution of the GoF Design Pattern book was a shared terminology that simplified communicating solutions. Does your book do the same, and if yes: where do you get the names for the patterns? Are they problems known from different domains (typesetting, GUI toolkits,..)?

Design patterns have been used with great success in software programming. They improve productivity, creativity, and efficiency in web design and development, and they reduce code bloat and complexity. In the context of CSS(3) and HTML(5), design patterns are sets of common functionality that work across various browsers and screen readers, without sacrificing design values or accessibility or relying on hacks and filters. But until recently they have not been applied systematically to web design and development.

Once a design pattern is revealed, it greatly increases creativity and productivity. It can be used by itself to create quick results, and it can be easily combined with other patterns to create more complex results. Design patterns simplify and amplify the creative process. They make creation as easy as building with blocks or Legos. You simply choose predesigned patterns, vary them, and combine them to create the result you want. Patterns do not limit creativity—they unleash creativity.

The GoF Patterns book you mentioned, explains that a design pattern consists of four elements: a pattern name, a problem, a solution, and tradeoffs. Our book follows exactly this approach.

InfoQ: Does the book deal with cross browser programming/design?

Cross browser development is hell and since this is a practical book, it focuses directly on the concrete patterns designed into CSS and HTML that are actually implemented in all the major browsers. Each pattern has been tested to work in all major browsers and in many cases there is a special mention regarding compatibility with even older browsers.

Lets take for example the “Center Aligned” pattern, which deals with the case where you want to align an element and its content to the horizontal center of its parent or closest positioned ancestor. Now, this should be an easy task to do but unfortunately there are several caveats. As it is mentioned in our book, Internet Explorer 6 cannot center absolute elements; version 7 can center stretched absolute elements, but still cannot center sized absolute elements and versions 8 and forward do center sized absolute elements. The recipe we provide deals with all browsers!

Additionally there are recipes that apply only to HTML5-capable browsers, e.g. “HTML5 Form Validation” etc.

InfoQ: What's your position on using frameworks? Would you suggest sticking to one big framework that covers every aspect, or a kind of pick and choose approach using a micro framework for a specific task?

I’m personally in favor of combining small frameworks and libraries than using huge ones that try to do everything. This goes for both the front-end and server-side programming. Cherry-picking from smaller libraries gives me more freedom to do exactly what I want, in the way I want it. It also helps me choose the best tool for the job and keep my sanity when abstractions leak.

The good thing about the HTML5 platform is that it is favors this mixing of libraries, in a much better way than any other platform I can think of, and this is probably one of it’s strongest points!

There are several JavaScript and CSS libraries out there that make a developers life easier like jQuery, jQueryUI, Underscore.js, Yahoo UI, HTML5 Boilerplate, Modernizr, 960 Grid System, Twitter’s Bootstrap and many more.

InfoQ: What's your top 3 list of most atrocious HTML problems? Ie. what are the HTML concepts that caused you the most head scratching?

There are 3 main types of “problems” I see with the HTML5 platform:
  1. Browser support: Having to build any serious app that has to work in several different environments (browser+OS), is a major challenge. This is why libraries like jQuery have been so successful because they abstract these differences. I also like tools like and Abobe’s BrowserLab for testing on multiple configurations.
  2. Unnecessary verbosity/limited functionality: The HTML syntax is generally considered verbose and that is why people have been looking elsewhere for specific implementations (hint: markdown). Similarly the CSS syntax has several limitations and again people have been inventing stuff to overcome this (hint2: LESS).
  3. HTML5 spec gotchas: There are cases where some HTML5 API features work in the way that are documented, but are counter-intuitive and almost invite mistakes because they are both enticingly easy to invoke and completely unexpected in their outcome. A good example is the Application Cache and how exactly it gets updated.

InfoQ: You write about CSS, but recently we've seen growing interest in CSS supersets like LESS, SASS, Closure Stylesheets. What do you think about them? When are they a good idea to use?

Absolutly yes, things like variables, mixins nested rules, etc., make the designers work so much easier!

Anyone that has ever tried to manage colors in CSS files will love the following example:

    // This is less (note the single line comment format)
    @color: #4D926F;

    #header {
       color: @color;
    h2 {
       color: @color;

Now, having said that I must stress out that you cannot expect to use things like LESS, without a solid understanding of CSS. LESS/SASS is there to help you write your CSS, not to replace CSS. I would also like to point out that although there are several things that people find wrong with CSS, the alternative ways of styling GUIs are just appalling. I would take broken CSS syntax over adding style in XML or OO code classes any day!

InfoQ: Oddly enough for a document format, HTML has bad support for rich text editing in the browser. The contentEditable attribute has been added to HTML5, but recently many projects have stopped using it, eg. Google Docs, as well as source editors like CodeMirror 2 and Cloud9's ACE editor never used it at all. If you had to build an editor with rich styling today, what would you use? 

It depends on what you want the editor to do and how long you wish to wait for it. For example, if you want to format documents, you might be interested in something like Kylix, which Google Docs started using, after they also gave up on contentEditable.

For code, the people at Mozilla have been putting a lot of though about the code editor that will ship with Firefox dev tools and the scoop is that they’ll be using [Eclipse's] Orion because it can handle their i18n and a10y needs, and they’ll also be porting a bunch of goodies from Ace and Skywalker. Both approaches require significant effort, even to get basic editing features working and it’s the same deal with Ace and Skywalker.

So, although rich text editing in the browser falls short compared to the desktop experience, I know that many smart people are working on it and I’m sure the gap will be closing soon, especially since the rest of the web platform has so many advantages.

InfoQ: The ACE editor's mode of drawing formatted text is impressive because it recreates HTML for every screen update - but apparently it works because HTML components are incredibly fast today. Do you know any other examples this? 

A nice example is the layout engine for Kylix, the Google Docs editor: When you type the letter ‘a’ the editor notices you pressed the ‘a’ key and respond by drawing a single ‘a’ off-screen. It then measures the width and height of that ‘a’, combines those measurements with the x and y position of your cursor, and places the ‘a’ at the correct spot on the screen. If you’re in the middle of a word, it pushes the characters after your cursor over. If you’re at the end of a line, the editor moves your word to the next line and pushes any overflow to the lines after it.

Similarly the cursor in Google Docs is actually a thin, 2 pixel-wide div element that is “manually” placed on the screen. When you click somewhere, the editor finds the x and y coordinates of your click and draws the cursor at that position.

InfoQ: The book provides a lot of solutions for what's essentially features of a GUI toolkit (alerts, layout, etc). Should applications try to emulate native GUI toolkits and behaviors (eg on mobile platforms) or just commit to a web-ish cross platform style?

For the desktop it has always been accepted that applications must commit to the “web-ish, cross platform style” you mention. This is where our book focuses on.

On the other hand, in the mobile space, people go to great trouble to imitate the native look ‘n’ feel. A good example of this is jQTouch which not only provide an Apple-like theme, but even native-looking animations, etc.

InfoQ: What do you think about using Markdown, HAML or other alternative ways to write HTML?

Markdown is very successful at taking away much of the verbosity of HTML and the actual content easier for humans to edit/read. Therefore it is much better to use for web editing, e.g. in a CMS, than plain HTML. On the other hand many of the time I come across a field that requires Markdown, I often wonder why it’s not a WYSIWYG editor. Similarly HAML tries to remove verbosity, but from the developer’s perspective. This way it helps you write HTML templates faster and have them be easier to maintain.

For example:

         #date= print_date
         #address= current_user.address

is so much better than:

    <div id="profile">
       <div class="left column">
         <div id="date"><%= print_date %></div>
         <div id="address"><%= current_user.address %></div>
       <div class="right column">
         <div id="email"><%= %></div>
         <div id="bio"><%= %></div>

I would personally use HAML in every project I could, assuming that there was some decent platform support for it, where “decent” means direct support in the template engine. Being a husband and a father doesn’t leave me too much free time to spend manually converting HAML files to native templates, every time a change is made :)

About the Book Author

Dionysios Synodinos is the research platform team lead at C4Media and a freelance consultant, focusing on rich Internet applications, web application security, mobile web, and web services. He's also the lead editor for HTML5 and JavaScript for InfoQ, where he also regularly writes about the JVM platform. Going back and forth between server-side programming and UI design for more than a decade, he has been involved in diverse software projects and contributed to different technical publications.



Rate this Article