Home More on the CSS sucking

More on the CSS sucking

More on the CSS sucking

A couple weeks ago I managed to get a bunch of people upset by saying that CSS sucks. The comments were A) I don't know CSS B) The web and CSS isn't about design. C) Don't blame the CSS blame the browser and D) Back-up your claim by proposing something better.

In short I'll point out that A is not an argument, B used to be true perhaps in 1994 but is no-longer true. People who suggested that I should blame the browser and not CSS should take a close look at the actual CSS spec. I'm not at all surprised that browsers interpret the standard differently and have mistakes in how they render HTML & CSS. Specifications and standards can be overly and unnecessarily complex. CSS has a lot of good concepts but the fact that no two browsers are able to nail the spec it is a huge problem.
Ok. Enough complaining. To propose solutions.

The flash format is actually a fairly large step toward a better overall web-design tool.
It's much more consistent across browsers and platforms. It handles graphics, design and animation with precision. Flash isn't ideal for flowing large amounts of content and it doesn't integrate with the navigation of a page. The largest obstacle to flash is that you can't link between pages of content. Multiple pages of Flash content is treated as a single page within the browser. Adding a navigation element to Flash could allow sites to substitute HTML pages with Flash based pages. This would also allow Google and other search engines to parse and link to specific content.

Ok, idea #2... Beyond the flash story how could you address the CSS issues within HTML?
I'll break that problem into two parts. Part A is the things that have to be done within the browser. There's no easy hack around these things and it' not something that can be fixed in a blog post. These are intrinsic things that should be available in the core HTML rendering platform:

  1. JavaScript drawing primitives (boxes, lines, gradients, canvas objects, etc)
  2. Font control and font embedding (Mozilla & Apple don't have this and perhaps a better implementation for IE is in order)
  3. Anti-aliasing control on fonts/text/images
  4. Rendering effects via JavaScript (Rotation, reflection, scale, animate)

I put these in this order because #1 will allow you to do almost anything you want in terms of layout and design as I will discuss later. #2,#3 will help accessibility by pulling fonts out of images. #4 is optional and would help performance for real-time rendering and effects.

Part B is the styling attributes, look and feel and layout. There are two possible solutions. The first possible solution is to start from scratch. While this is desirable it's perhaps too far reaching. Instead I'll propose a solution to style pages that that:
- Doesn't involve CSS in the traditional sense
- Is accessible - for screen readers or alternative devices
- Allows for semantic markup
- Is optimized for tools
- Is cross browser

Before I get into my proposal a bit of history. Back in 1998 as part of my college senior project I designed a cross-browser HTML editing and animation tool. At the time Microsoft had just introduced DHTML and Netscape had recently made layers possible. Although the two technologies were different they made it possible to position elements on the screen in somewhat predictable ways. The program created layers and absolutely positioned elements and allowed the user to both position and animate objects across the screen.

The editor tool created a library array of objects and then set the position of those objects on the screen using a JavaScript timer. The key thing about this method was that the browser didn't manage the layout of the screen. It was up-to the designer at design-time to decide where objects would go. At run-time the position of the objects was simply a result of the JavaScript execution.

Back in 1998 the problems with layout sounded similar. Thee were incompatibilities in using tables and transparent pixels to create web-pages. There were all sorts of browser hacks to try to get things to line up right.

The solution I used back then and the solution I propose now is to use JavaScript to render the layout instead of having the browser position screen elements. You still use CSS classes to style fonts & colors but you don't allow the position to be specified in CSS. Instead you position and size elements in the design tool and allow these properties to be set at runtime via JavaScript (or even AJAX if you're so bold).

There are many nice things that happen when you use CSS just for fonts and JavaScript to control the layout.

  • The page loads fast. Since all elements are absolutely positioned and you're not cascading the browser doesn't have to wait long to render.
  • The styles are deterministic and predictable.
  • The placement, margins and positions are easily editable (assuming you're using a tool)
  • You can have consistent sizes that are re-used across the layout.
  • Your layout can be parameterizes so elements line up and stick together as designed even when the browser resizes and content flows.
  • You can specify alternate element positions for smaller sizes making it possible to use the same content for mobile applications. Since the position is set in JavaScript it happens at runtime and adjusts to the device it's running on.
  • You fight less with the browser because you only use a few primitives. In addition any browser hacks or tricks are done by the JavaScript compiler and not by the page designer. The page just works.
  • You can re-order the content tags anyway you like so that accessible browsers read the tags in the order you specify. This level of control is often impossible with CSS.
  • The approach is future friendly. As new browser features are exposed the script can progressively and safely expose these features.
  • You can mix traditional HTML/CSS with this new approach
  • You can think outside the box-model.

In many ways you design the page and then compile it down to the appropriate JavaScript that would render the content. This is similar to how PDF/PostScript documents are created. The postscript file is actually a programing language and your document is represented as a series of function calls, loops and procedures.

The concept address many of my own complaints but there are some drawbacks to this approach.

  • Hand coding page layout in JavaScript is slower then writing CSS. To do this properly you need a tool. My college project wouldn't cut it although a similar approach could be used to create a rich-tool. In theory if you had the items #1,2,3 &4 you could even write a printer driver that would convert any document into a web-page.
  • View source won't tell the whole story. This is because in some sense the page is pre-compiled from the editor tool into the JavaScript representation. The compiler may optimize the layout or code and may even discard certain editor specific meta-data that doesn't need to pushed into the web-page. For people who insist on hand coding this may be a drawback.
  • Different tools could produce pages that don't necessarily transition well from one tool to another. This is because the pre-compilation step and the resulting JavaScript file would vary between tools.

These are two possible approaches to the problem. I'm sure there are many others. It's easy to poke holes in these ideas but I'd rather hear your concepts.

This post is licensed under CC BY 4.0 by the author.