Author: Steve

Could Expression break the tedium of CSS design?

 

I’ve been dealing with CSS layout quirks and bugs for seven years and, frankly, by now the thrill of designing an elegant style sheet by hand has worn off. The process of choosing the right lengths and font-sizes, and setting all these properties by hand (even with autocomplete) is just unacceptably tedious and just bogs you down. The “CSS panels” various apps have just don’t save enough time; I can almost always edit the rules by hand faster than scrolling through lists of properties and clicking in value boxes. Yes, a 2nd monitor auto-refreshing the page would help, but I’m still guessing at values, saving, repeating endlessly.

I just want to drag and drop elements into place, maybe in a DOM tree view in a side panel, then zoom in and adjust layout properties like margin and padding by dragging handles or using the mousewheel, same with font-sizes in %/ems. Even if it stores these properties in inline style attributes, this would be a huge time-saver. Just also give me a wizard to take all inline styles and merge them into my external files intelligently, maybe let me pick the ids or choose when to use various contextual selectors.

It looks like Microsoft’s Expression designer has some of these features. Dreamweaver has a nice page zoom and yeah, you can stretch tables around like it’s 1996, but it doesn’t cut it. Right now DW8 is my primary editor, but as I do less front-end work I can forsee it losing ground to more capable PHP editors (if they could just match DW’s site management tools).

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…