Month: July 2006

Why CSS layout is hard

 

The complaints are many and oft-repeated: “CSS has no grid system”, “the cascade is dumb”, “it’s broken”, etc. So why is CSS layout so hard? The obvious answer is that doing anything really well isn’t always easy. Most anyone can make a page in a modern WYSIWG editor (DW8/GoLiveCS2) in five minutes and have an accessible web page that nearly browser can read, and it can even look good–in that area we’ve come a long way–but it won’t necessarily look professional. There’s always a point in any field where your goals outmatch your abilities and I don’t see why CSS should be expected to be any different.

As for specifics, plain old CSS2 (1998!) can accomplish just about any layout you can dream up, but standing in your way more than anything else is the IE Factor. Even the upcoming version 7, which we’ll be supporting for a long time to come, will not support the table-* values for display that make multi-column layout easy as cake. Is it the CSS working group’s fault that a browser fails to implement standards for almost a decade? If existing standards aren’t supported, why should we believe alternatives would be/would’ve been? The sad part in the case of display is that IE also cannot change the display properties of table elements (the color chart is a table as it should be).

I’ve seen the point made that the cascade is great for text-styling, but terrible for layout. This person probably didn’t notice that the values of layout properties like display, position and float don’t actually cascade (aren’t inherited from the parent element). Oops.

Now, to give credit to the critics, there are a couple areas where I see CSS2 partucularly fails to deliver: 1) floated elements must precede elements that “wrap around” them in the markup. This is not usually a big issue since markup is easy to control, but at least one CSS3 draft addresses this. 2) the table-* display values mentioned before cannot duplicate table layouts that use rowspan/colspan. Again, the WG has put work into it, but don’t expect to see this anytime soon. Then again, non-IE browsers continuously forge ahead, supporting various bits of CSS3 like selectors, multiple backgrounds, rounded corners, opacity, speech, multi-columnal layout…

Opera folks: Make it easy to test in your browser

 

Opera wants to know what features web developers would most like to see. I posted this in response (but it never seemed to show up on the page):

“Testing” version: offer devs a download pre-configured for more easily testing site compatibility with Opera. Marketshare will only rise if more sites are tested in Opera, so this has to be dead-easy for devs used to testing in IE/FF.

Strict-mode JS Notices: tell devs when they’ve attempted to use a common interface that IE/FF supports but Opera doesn’t. Link to a knowledgebase article, which leads me to…

Documentation: Be public and upfront about lack of support for popular proprietary features that IE/FF support and that web devs are itching to use, and list practical alternatives and workarounds in knowledgebase articles. In fact, publish usable compatibility scripts if possible, not just secret browser.js fixes.

In the 7.5 days this would’ve been XMLHTTPRequest. Yes, Opera devs were working on it, but web devs were in the cold for knowledge of the current level of support (eg. you couldn’t POST until 7.6 so many sites half worked). If support is in the works, let us know how it’s coming along! Not just in an odd hint drop on the forums.

This also goes for Opera-specific tech; I shouldn’t have to figure out myself that UserJS doesn’t fire in panels (why not?) or search forums for the most basic widget methods. Devs need thorough docs. Take the PHP docs as a model.

JS Panel: I sorely miss not being able to watch JS errors in real-time in a panel, as I did with v8. In fact, it should be a top-notch panel developed by Opera that ships with the browser.

DOM Inspector: devs love them, plenty of bookmarklet versions exist out there. Grab the best, improve the hell out of it and ship it in a panel or publish it as an official Opera bookmarklet. Grab one of your widget developers for two days and you’ll have this.

widgets++

 

My first Opera widget is available. I designed it to take up as little desktop space as possible (a 22x22px icon) until you click it, which opens the interface and queries del.icio.us to show your latest bookmarks. By default, when you click a bookmark, the page opens in Opera and the widget “minimizes” back to the icon. I’ve followed Opera’s guidelines in using their standard “flip” button for preferences, and these persist after you close and reopen the widget.

For people who browse full screen, I’m still not sold on the widget concept, or at least Opera’s implementation, which is only slightly less limiting in functionality as a web page. The only big advantage widgets offer to, say, bookmarklets (since BM can open windows), is the persistent storage, which is thankfully larger than the cookie 4K limit. The testing and build process needs improvement; you have to delete the previous version in Opera, clear the cache, make a zip of the folder, serve it with a special content-type and reinstall in Opera. Easier testing can be done by including Javascript that emulates the widget API if it’s not available, but this still won’t allow cross-domain XHR requests, so for some widgets your workflow has to be tweak-rebuild-retest-repeat.