The good

JavaScript performance. I’m curious to know how they accomplished this (JIT compiler?) but I’m happy it’s here. More and more, client-side JavaScript is becoming something that can do heavy lifting.

Tabbed browsing. The weird tab/title bar doesn’t appeal to me, but I can see its value. To me, the window needs to feel like it’s a container, and the tabs just screw that up for me. But the space savings is nice.

Better keyboard navigation. Greatly appreciated by those of us who fill out forms on the web. Which is to say everyone. turns out they had this in Safari 3.

Better hints for location bar. Much better! The hints now work kind of like spotlight. Type stuff into the URL bar, and Safari will do its best to find a matching URL from any source it can think of (history, bookmarks, etc). The best guess is shown first (like Spotlight) and the rest are categorized. Problems: The location bar doesn’t seem to handle page titles, which is a shame. Also, if you mistype a URL and get a 404 or other error, it still shows up in history and can end up as the “top hit”. Uh… whoops!

Embedded web fonts. It’s great that Safari is doing this. However, to be realistic (a) more browsers need to support this, and (b) someone needs to sort through all the legal issues having to do with font embedding.

The meh

CSS animations. Back in 97, I was one of the folks working on the first version of Dreamweaver. At that point in time, the Netscape folks were coming up with new tags all the time.

When we told the Netscape folks that we were going to add a timeline to Dreamweaver to take advantage of the <layer> tag, they were surprised and happy. You see, the inspiration for the <layer> tag was this question: “how can we have the browser do the things that the Shockwave plugin does?” Fast forward to 2009 and replace “layer” with “CSS animations” or “canvas” and replace “Shockwave” with “Flash”.

My opinion on all this? Meh. If you want to do everything that Flash does, use Flash. Or invent something radically new that blows HTML out of the water. Don’t bother bolting that stuff onto HTML/CSS.

In fact, if you’re going to bolt stuff onto CSS, focus on getting the basics of static presentation right. CSS layout is still incredibly difficult (way harder than tables were). You have to do hours of Google research just to get a usable two column layout.

Top Sites. The top sites UI feels overly glitzy to me, and for no good reason. The slightly curved appearance implies (to my eye) that I should be able to rotate my view to the left and the right to see more sites. Which you can’t do, as far as I can tell.

Bookmark Sidebar / Cover Flow. I like Cover Flow, but it’s getting to the point where I can’t tell the Apple apps apart. iTunes has a sidebar on the left, a list of stuff on the right, which can include a Cover Flow view and a list below. Same with the Finder. Same with the browser. Same with…

Maybe I’m just thinking about this too abstractly, but it bothers me that so many of the Apple apps are starting to feel the same as each other. Not so long ago, iTunes was different than the Finder, which was different than iPhoto. Now, you have cover flow in the Finder and with Quick Look, you can play the song right from there.

So I don’t know. I’m kind of torn. Consistency is nice, but too much consistency leads to every single thing looking exactly the same. It feels a little bit like MS Windows UI right around when XP came out. Tree views were pretty general, and a lot of applications fit into the pattern of “tree view on left, detail view on right”, so that’s what everyone did.

Maybe it will grow on me. Or maybe they’ll iron out the kinks. (single clicking on a bookmark in the sidebar doesn’t navigate you to the page. It shows you a “category” with a single bookmark in it. Double clicking on the bookmark in the sidebar lets you rename the bookmark. The only way to navigate to that bookmark, as far as I can tell, is to click on the bookmark, and then click on the image of the website in cover flow, or else double click on the bookmark in the bottom pane below cover flow. I mean… cover flow is pretty, but isn’t single clicking a bookmark more important?)

The WTF?

Color profile support. They claim to be the first only one to support this, but doesn’t Firefox already do this? Is the issue that it is turned off by default? Or does Safari handle colors in a significantly better way than Firefox?

It’s been a while since I’ve touched CSS, and in coming up with the design for this blog, I was reminded again how difficult it is to use CSS to get the layout you want. It was incredibly difficult. I couldn’t get it to work and I ended up having to google around to figure out how other people had done their page layouts.

Does it have to be this way? Shouldn’t a reasonably smart person who has read the spec be able to create a layout without referring to a guru?

~

Tables vs CSS

The general idea of using CSS for layout is absolutely right. CSS lets you separate presentation from content, which is a good thing. The general idea of using tables for layout is wrong for exactly the same reason. It intermixes content with presentation, and besides, tables were originally meant to represent tabular data. There is another, more subtle reason why CSS is better than tables for layout: accessibility. With CSS, you can order your content in the preferred order for screen readers, and then use CSS to dictate where everything should go. With tables, the layout dictates document order.

However, there are some things that are trivial to do with tables that are mind-bendingly difficult with CSS. A lot of it has to do with what I’ll call float abuse.

Float abuse

There are a number of ways that people have found to create two and three column layouts that are popular on the web. Most of them rely on display: float.

Floats were originally intended to be used for floating elements such as sidebars.This is an example of a traditional use of float.They were not specifically designed to handle the overall layout of a page. Using floats to handle the overall layout of a page is not quite as egregious as table abuse, but there are similarities.

One of the problems with using floats to do overall layout is that they have significantly different rules for how margins are handled when compared with inline or block elements. If you were designing a system from scratch to define web layouts, would you purposefully make it so that the left column had different rules for margin handling than the right column? Probably not. Yet that’s what you get with floats.

The reason that margins need to be treated differently for floats is clear when you consider the original use case. Here’s a diagram from the CSS2 spec:

However, when you use floats to do a multi column layout, look at what happens to the margins. Let’s assume that A, B and C each have a top and bottom margin of 10px. Let’s also assume that B is floated left. In this case, the margins of A and C collapse, but the margin of B does not.

Worse yet, some of the wrapping rules of floats can lead to situations like this:

As bad as tables are, you rarely get yourself into situations like this with tables. My belief is that all these problems occur because floats were never designed to serve this purpose in the first place.

How should it work?

Bert Bos once mentioned to me that the CSS group had discussed doing something within CSS to handle overall layout. I don’t know what the syntax was that was being thrown around at the time, but it looks like there has been some progress on that front in the CSS3 spec. The current proposal seems a bit bizarre to me, but I am incredibly happy that they are looking at this issue. FWIW, my personal preference would be to introduce @ rules to do a container based layout hierarchy:

@layout {
    name: "threecol";
    type: vertical;
    width: 100%;
    height: 100%;
    children:
        @layout {
            name: "headerArea";
            width: 100%;
            height: 40px;
        },
        @layout {
            type: horizontal;
            width: 100%;
            height: 100%;
            children:
                @layout {
                    name: "leftArea";
                    width: 150px;
                    height: 100%;
                },
                @layout {
                    name: "mainArea";
                    width: 100%;
                    height: 100%;
                }
        }
}

#header {
    layout: "headerArea";
}

#sidebar {
    layout: "leftArea";
}

#content {
    layout: "mainArea";
}

I’m sure that the above psuedo-CSS has lots of problems, but the general gist is that I want to think about layout in terms of containment, not in terms of slots. But in any event, anything is better than thinking about floats!!

When to be practical, and when not to be

The main thing standing in the way of a new, better syntax for page layout is the real world. Can the W3C create a proposal that a whole consortium of companies agree to? Can we get this implemented in the browsers?

These are good questions, and for the foreseeable future, we may have to live with what CSS2 offers us. However, I want to make sure that pragmatism doesn’t lead to complacency. Is it great that I can now do a web page layout using standards-based CSS? Absolutely. Does CSS seem easy enough for the kinds of things that people want to do with it? Absolutely not! Laying out a web page in CSS is mind-bendingly hard. It shouldn’t be that way. People who create web pages should be jumping up and down asking for something better.
]]> http://kuwamoto.org/2006/04/26/css-is-too-hard/feed/ 13