Year: 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.

Missing a show twice

 

Saturday night. Josh called from Common Grounds to remind me to come to the Holopaw show. It’s a bit after 11, so I still have time to see them. When I get down there it’s some sort of free event and Neko Case is a surprise opener! She starts playing Buddy Holly’s “Baby Won’t You Come Out Tonight?” with the rockabilly “go baby, go baby…” and I’m thinking Kathleen needs to be here. Since she loves Holopaw I don’t know why she didn’t wanna come but I run toward the entrance to head out and go get her. When I get out in the parking lot I realize it’s raining and I’m not wearing shoes. I run back inside and start waiting in line to talk to the doorman, because CG has some weird policy now where you have to check your shoes in at the door. As I start to get frustrated, I wake up.

Not only do I miss the dream show with Neko Case and Holopaw, but I check the clock to see it’s past 5 and we’ve missed the real Holopaw show as well. My brain is mocking me! At least earlier that evening we got to see Neko Case on Austin City Limits (wow). I’m so pissed at myself because I’ve been waiting to see Holopaw for several months and I don’t know why I didn’t just buy an advanced ticket as a reminder.

Opera 9 thoughts

 

Opera 8’s UI really had most everything it needed to be a great browser (I haven’t upgraded at work and can barely tell the difference). 9’s big delivery is in the area of web standards (opacity, SVG, DOM Style) and hot proprietary ones like rich text editing, Flash-Javascript communication and the Canvas element. There are additions to write home about on the UI side as well (site-specific settings, content blocking), but the under-the-hood stuff above is what will truly allow a new Opera user to use the latest web sites they’re already used to without getting a broken/dumbed down interface or being flat out blocked.

The new widgets feature is surely meant as an answer to (or at least a distraction from) Firefox Extensions, but I think this move will only make it more apparent that people really want to customize their browsing experience rather than collect desktop gizmos. Even with all the headaches associated with dealing with managing Extensions (and upgrades)–and I’ve dealt with them from the Mozilla 0.9 days through Pheonix and now Firefox)–the modifications they can perform are staggering and impossible to ignore. Although extensions give you the power to wreck/destabilize your browser and make upgrading a pain, users now expect that power.

A couple things I’d personally like to see in Opera is a richer panel implementation and maybe some advanced Javascript extensions. Mozilla/Netscape7’s “sidebar” could’ve used a better control UI, but it allowed multiple panels to be visible simultaneously. I think if Opera encouraged web developers to develop panels with the same gusto as they promote widgets, they might prove more useful just because they live inside the browser where the user lives most of the time anyway! Maybe I need to create a slick panel as a proof of concept. In the Javascript area I’m thinking some extra interfaces available to bookmarklets (better persistant storage than document.cookie, local storage of JS libraries) could help make up for the lack of extensions. Just some ideas…

PHP for Easy Bookmarklet Testing and Distribution

 

Bookmarklet authors have it tough. On top of the usual challenges of cross-browser Javascript testing, we’ve traditionally also had to workaround IE’s character limit and jump through hoops to embed code inside of javascript: links.

Bookmarklet Server (source) eases testing and deployment by allowing you to keep code where it should be—in .js files. A single SCRIPT element dynamically loads the bookmarklet code and creates the javascript: link for you.

Continue reading