- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
From JSP to Ruby on Rails: First thoughts on front-end coding conventions
Now that I've got a few Ruby on Rails projects under my belt, I finally feel qualified to comment on Rails front-end coding conventions. As a UI specialist coming to Rails from the JSP world, I find a lot of room for improvement in the RoR approach to view-layer code. I love working on the non-view aspects of RoR projects, but I find I've got to do tons of cleanup at the ERB layer. Expect to see some open-source components from Pathfinder to help ease this pain. In the meantime, let me articulate my pain points:
Code organization
If I'm filling a front-end role on a Rails project, most of the files I need are in /app/views and /public. I dig that. Likewise, I appreciate the underscore naming conventions for partials. However, I wish /layouts weren't just another subdirectory of /app/views. Layouts are inherently different from standard view templates. A better hierarchy within /app/views would help drive this home. Likewise, I wish partials and full templates each had their own directory within a specific controller's view folder. That would help keep directories manageable on big projects. The /public directory, on the other hand, offers just the right amount of organization.
What does your CSS Swiss Army knife look like?
CSS 2.1 is more like a Swiss Army knife than a fully stocked toolbox. We can accomplish a lot, but we have to get creative with the standard attachments. Floats, relative positioning, the box model - each tool must performs double or triple duty because they're the only ones we've got.
When we do discover a clever way to accomplish a common task using these limited tools, we're likely to employ that technique over and over. I'm not talking about CSS frameworks here; those help out more at the macro level. I'm talking about repeatable techniques that can be applied at the micro level. When done right, these simple techniques can feel like entirely new Swiss Army attachments rather than intelligent application of existing blades.
Whenever I start out on a new client project, I start off with the following plug-and-play components:
Topics: CSS, Javascript, Progressive Enhancement, Web Standards
Working effectively as a team of one: Five tips for front-end developers on Agile teams
Most UI engineers - a.k.a. front-end folks - have worked in environments where they're a shared resource of one person. I often did so early in my career, when I played "webmaster" to a team of writers, editors and visual designers at various online publications.
Now that I'm the Ajax lead at a small, Agile software development firm, I'm no longer the only technical person in the room. But I'm still just as specialized. It's not that my JavaScript, CSS and JSP skills are any more important than somebody else's SQL, Java or Swing skills. It's just that I'm a team of one, so utilizing me effectively takes a little more planning. Everybody at Pathfinder wears multiple hats, but I was hired specifically to wear the same hat all the time.
Many projects at Pathfinder seek my input, but my attention can only be parceled up into so many chunks. I can't serve as an actual development resource on every project. Over time, I've realized that the following strategies help me deliver the value I need for my company:
Topics: Ajax, CSS, front end, Javascript
Formatting quoted code in blog posts: CSS2.1 white-space: pre-wrap
When migrating our blog posts from TypePad to WordPress, chunks of code presented the biggest problem. There was a lot of variation in how individual authors had marked up their code samples. Then there was the junk markup TypePad had inserted, of its own accord, inside <pre> and <blockquote> elements. In the end, I had get my hands dirty inside individual posts in WordPress. For future posts, however, we'll be standardizing our markup patterns and using CSS to style code quotes consistently. We're still working the kinks out of our stylesheets, so please bear with us when reading older posts.
In the meantime, I stumbled upon an informative post by Lim Chee Aun that offers a one-size-fits-all solution for implementing the CSS 2.1 "white-space: pre-wrap" declaration in today's user-agents. If you're not familiar with "white-sace: pre-wrap," it's a way to honor whitespace and line breaks within preformatted text, yet still allow individual lines to wrap when they reach the edge of their enclosing container. In short, it provides the browser equivalent of the "soft wrap text" option in your favorite IDE or text editor - which in many cases looks better than using "overflow: auto" to create an internal scrollbar on the container.
Developer’s Notebook: Find computed styles in IE, Firefox, Opera or Safari
At my recent Web 2.0 Expo talk, I exhorted developers to get comfortable outside the Firebug/Firefox safety zone. By rotating between Opera, Safari and even IE as our primary development environments, we can really get to know those browsers - and perhaps learn to utilize their non-standard features. Switching things up, however, can inhibit productivity until you learn your way around each browser's tools.
To that end, I offer these step-by-step instructions for finding computed styles in all four A-grade browsers. I chose the display of computed styles as my "debuggers are cool" use case because it's an obscure but useful feature for CSS debugging. Most of the time I can debug styles by looking at my debugger's snapshot of the current cascade for a given element. But sometimes that's not enough. If I've assigned a value of "inherit" to the font-family of an element, then the cascade snapshot won't tell me what font is actually applied to that element. (Not being a designer, I often can't tell the difference between various sans-serif faces, especially at small sizes.) Luckily, computed styles can give me the information I need.
As these examples demonstrate, debugging tools have come a long way in the last couple of years. Let's make the most of them for all of our UI-layer needs.
Internet Explorer 8 and DebugBar
500
IE's JavaScript debugging tools have finally matured, but its CSS ones lag behind. Even IE8, with its built-in debuggers (under Tools > Developer Tools), won't show you computed styles. Luckily, Jean-Fabrice Rabaute has crafted DebugBar, an plugin for Internet Explorer 5+ that adds all sorts of useful tools. Install DebugBar, fire up your version of IE and choose View > Toolbars > DebugBar to make the plugin visible. Then click the "DebugBar" icon in the resulting toolbar to open the DebugBar sidebar. You'll see two tabbed panes, one below the other. Choose the "DOM" tab on top and the "Comp. Style" tab on the bottom. In the upper pane, you should see a target icon with the caption "Drag target on document to find element." Drag the icon anywhere on an open web page and you'll see computed styles for the corresponding element in the bottom pane of the sidebar.
Alternate approaches to IE6 and transparent PNGs
Who knew IE6 and transparent PNGs could inspire so much discussion?
When you're churning out tips and tricks on a regular basis, you quickly learn to state things like this:
"I had Problem X, and my solution was Y given constraints Z."
... instead of this:
"The only way to solve Problem X is Y."
I was reminded of this lesson last week, after I posted a series of beginner-level tutorials about overcoming some of IE6's shortcomings with jQuery. My two-part piece on transparent PNG support got picked up by the kind folks at Ajaxian, and boy did the comments come. Between the two sites, we've heard from 20 people so far. A few were from the usual cranky haters. (Thanks to whoever felt the need to write, "Is this year 2001? IE6 png transparency? News on Ajaxian? Good heavens..." instead of just moving on to the next post.) But the rest provided lively debate and some valuable alternative approaches to the problem.
For review, here are the posts (with comments):
And here are some of the various approaches suggested:
Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 2 of 2)
For the recent redesign of the Pathfinder web site, we made extensive use of transparent PNGs to layer rounded corners and other curvy shapes on top of a non-contiguous background that mixes a black-and-gray gradient with a wallpaper-style repeating logo. Transparent PNGs are the only way to achieve this visual effect using semantic, standards-based markup and CSS - but IE6 doesn't support PNG alpha-channel transparency.
Yesterday, in Part 1 of this piece, we showed you how to install Angus Turnbull's IE PNG Fix on your server to correct this IE6 shortcoming. Today, we'll show how to overcome one use case not covered by Turnbull's script using a couple lines of CSS and JavaScript.
As we explained yesterday:
There is, however, one drawback to Turnbull's script: It can't account for PNG background images with a background-position other than top left. It will restore the alpha-channel transparency to such images, but it will reposition them to top left, potentially making your designs look even worse than they would have with an ugly gray halo where the transparency should be.
Topics: CSS, IE, IE6, Javascript, jQuery, Web Standards
Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 1 of 2)
Yesterday's post showed how to hack the :first-child pseudo-class into IE6 with jQuery and CSS. Continuing with that theme, today and tomorrow we'll show how to enable transparent PNG support in IE6 (so your rounded corners don't look like the ones in this picture).
Today, we'll look at an awesome open-source script that will cover 90% of your needs. Tomorrow, we'll cook up some custom jQuery-flavored JavaScript to cover the corner cases.
As with many of my recent posts, my use case is the new Pathfinder web site, which launched last month. We took a pragmatic approach to implementing our new visual design using web standards. We practiced progressive enhancement globally, resorting to hacks and trickery only in browsers that aren't fully standards-compliant. (To be honest, that includes most modern browsers, though IE6 is the biggest problem child by far).
Our game plan went like this:
- If possible, implement the desired look and feel across all browsers using only CSS and semantic markup.
- When necessary, serve browser-specific styles using CSS filters.
- Don't deploy non-semantic markup just to achieve a specific visual objective in non-standards-compliant browsers.
- Instead, if only junk markup will achieve the desired visual effect in non-compliant browsers, inject that junk markup via JavaScript.
- The result is a site whose visual fidelity suffers only in non-standards-compliant browsers with JavaScript disabled.
Topics: CSS, IE, IE6, Web Standards
Hacking the :first-child pseudo-class into IE6 with jQuery and CSS
IE6 continues to define the lowest common denominator for our JavaScript and CSS strategies. IE7 may finally have edged past its younger sibling in terms of market share, but as of late 2007, IE6 still commanded commanded close to a third of the market.
For the relaunch of Pathfinder's website, we wanted our code to be standards-compliant and forward-looking, but we didn't want things to fall to pieces in IE6. We therefore used a variety of strategies to achieve a high degree of visual fidelity between IE6 and newer, better browsers. When CSS hacks and filters wouldn't provide us what we needed for IE6, we resorted to one of two strategies:
- Use JavaScript to create the desired visual effect so that only JavaScript-disabled IE6 users would see a less than perfect rendering.
- Just accept a degraded visual experience in a seven-year-old browser with declining market share.
Luckily, strategy No. 1 worked in most cases. Often, a single line of jQuery and a couple of CSS tweaks would create the desired look and feel. This was the case with one of IE6's most annoying shortcomings: its lack of support for CSS's :first-child pseudo-class.
GWT: DOM and Opacity
One thing missing from the DOM class in GWT is the ability to set element opacity in a browser independent way. You do have DOM.setStyleAttribute, but in IE you set the opacity by squeezing a alpha(opacity=val) into the filter, where in most other browsers you set the opacity style attribute directly.
If you take a peek into the prototype library, you'll see all sorts of cruft around setting opacity, such as supporting Konquerer, etc., but in the world of GWT, we just have to support a few browsers (IE6+, Mozilla, Safari, Opera). I had a need for a kinder, gentler opacity when I started developing GWTaculous, my pure GWT port of the Scriptaculous effects library. I implemented my own DOMX class to support those extended DOM operations I needed.
Topics: Ajax Frameworks, CSS, GWT
Developer’s Notebook: Forward-thinking CSS float-clearing
The art of float-clearing - getting containers to honor the height of floated elements inside of them - has slowly evolved over the past several years as Safari has taken over many Mac desktops, IE5/Mac has atrophied, IE7 has slowly caught on, and our use of CSS filters has improved. I'd like to share a slight variation on the state of the art that I believe makes for much cleaner markup. But first, a little background.
How we got here
Several years ago, Tony Aslett of csscreator.com convinced us to stop using clearing our floats using this sort of junk markup:
<div id="container">
<div id="rail" style="float: left;"></div>
<div id="content" style="float: left;"></div>
<br style="clear: both; height: 0; visibility: hidden;">
</div>
His solution, popularized on Position is Everything, convinced us to use pure CSS to solve the problem:
.clearfix:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}.clearfix {display: inline-block;}
/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */<div id="container" class="clearfix">
<div id="rail" style="float: left;"></div>
<div id="content" style="float: left;"></div>
</div>
The advantage, of course, was that you didn't have to litter your markup with extra <br /> tags that would eventually become totally useless once the state of the art changed.
Where we are now
For sites that have dropped support of IE5/Mac and adopted support of IE7, the recent concensus on float-clearing has been something like this (using the same markup as above):
/* float clearing for IE6 */
* html .clearfix{
height: 1%;
overflow: visible;
}/* float clearing for IE7 */
*+html .clearfix{
min-height: 1%;
}/* float clearing for everyone else */
.clearfix:after{
clear: both;
content: ".";
display: block;
height: 0;
visibility: hidden;
}
And now, a slight refinement
Which leads me to a technique used at Orbitz, my previous employer, to apply the same methodology with even less impact on the markup itself. Instead of declaring a single clearfix class and then applying it to countless containers inside their XHTML, the Orbitz UI team uses a grocery list of CSS selectors, like this:
/* float clearing for IE6 */
* html #container,
* html .classThatNeedsToBeCleared,
* html div.anotherClassThatNeedsToBeCleared,
* html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
height: 1%;
overflow: visible;
}/* float clearing for IE7 */
*+html #container,
*+html .classThatNeedsToBeCleared,
*+html div.anotherClassThatNeedsToBeCleared,
*+html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
min-height: 1%;
}/* float clearing for everyone else */
#container:after,
.classThatNeedsToBeCleared:after,
div.anotherClassThatNeedsToBeCleared:after,
#someDiv .someClass .yetAnotherClassThatNeedsToBeCleared:after{
clear: both;
content: ".";
display: block;
height: 0;
visibility: hidden;
}<div id="container">
<div id="rail" style="float: left;"></div>
<div id="content" style="float: left;"></div>
</div>
The idea here, of course, is that each time you have another container that needs to be cleared, you add browser-specific selectors for it to each of the three blocks above. Suddenly, there's no need to apply a utility class to a zillion different nodes in your HTML. Instead, you apply the same CSS rules to a bunch of atomic CSS selectors. Voila: float-clearing with absolutely no impact on markup. Presto: a solution completely centralized in a single block of CSS code, so that it can be changed in one place as the browser landscape evolves.
(Props to Gena Wilson, Orbitz's CSS headmistress extraordinaire, for constantly synthesizing elegant solutions like this one.)
Final side note: As long as folks are going to keep griping about missing items from their CSS wish list, could we please just eliminate the need to clear floats altogether? I know that the need to clear floats isn't actually a bug, according to the WC3, but it should be. I can't think of a single time I've ever _not_ needed to clear my floats. Can you? Tell me in the comments.
Topics: Browsers, CSS, Developer's Notebook
CSS 3: Multi-column Layout vs. Advanced Layout
My colleague Sholom Sandalow's post about multi-column layout in CSS 3 drew a lot of comments and remains one of our most popular articles two months after publication. Folks are obviously hungry for discussion about the future of CSS. Yet there's still a lot of fuzzy logic out there about where we're headed.
Viewport dimensions still matter
Lots of pixels have been burned in the discussion of changing viewport specs. But most of the people talking about the advent of very large viewports are probably designers with Mac Cinema displays - NOT average users. As market penetration for super-wide resolutions grows, so will market penetration for portable devices with resolutions at or below the old-school 640x480. (And I'm sorry, iPhone designers, but reading a full-width web page on a tiny screen isn't actually all that easy on my eyes. I'd much rather see media-appropriate layouts than tons of pan-and-zoom.) My point being: Assumptions about your audience's screen resolution have always been at odds with the idea of the Open Web. They still will as user-agents proliferate and diversify. As CSS evolves, it must continue to offer us tools to make content attractive and readable on a variety of resolutions and devices.
Multi-column text isn't a panacea
I also just don't get the excitement over multi-column text in the browser. Again, this goes back to assumptions about the viewport. One commenter uses this page as an example of good multi-column type that mimics the eventual CSS 3 spec. Yet on Firefox/Mac and IE6/PC, it's ugly, unreadable or both when you resize your browser to less than 500px tall or 1250px wide. How is this good design?
The main disadvantage of single-column text - that it's hard to read when the columns are too wide - can easily be solved by strong design skills and smart use of existing CSS capabilities. And the main advantage of multi-column text - that it makes more efficient use of space - ignores the fact that a browser is not a piece of newsprint. Ultimately, print-style columns work in some situations and don't work in others. They are neither a universal solution nor an antidote to bad web design. They are simply an additional tool in our CSS arsenal - one useful mostly in print stylesheets. It's nice that this basic layout feature is finally coming to CSS, but it's hardly the most exciting part of the CSS 3 roadmap.
Advanced layout: Finally, something to get excited about
No, my favorite CSS 3 spec is the Advanced Layout Module. (Thanks to my buddy Zack for alerting me to its existence.) This "concept album" exploring advanced layout strategies recently received its first refresh since 2005 (discussion here). For anybody who's ever struggled with CSS layout, there's a lot to love in this proposed templating system. Basically, the spec calls for a new type of display that combines the best aspects of table-based and float-based layout but provides far more flexibility than either. Of course, implementation is a far-off dream, and many aspects of the proposal haven't yet matured. But the Advanced Layout Module proves that the standards bodies are attempting to tackle the big picture of CSS layout rather than the little details.
In the meantime, several frameworks and techniques have emerged to tackle the problem of cross-browser, grid-based layout. Notable examples include the following:
- YUI Grids
- YAML (Yest Another Multicolumn Layout)
- Blueprint CSS
- Switchy McLayout: An Adaptive Layout Technique
I'd be interested to know who's using these tools, how userful they are, and whether they provide the same advantages as JavaScript/Ajax frameworks - that is, less time spent reinventing the wheel and more time creating great websites and webapps. As always, weigh in on the comments.
Topics: CSS, Frameworks
Cognitive Load, Portability and the Superiority of Client-Side Frameworks
The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?
I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.
Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.
GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.
The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.
An Event Apart Chicago: Day 2
Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.
Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the
Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.
Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.
After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.
The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.
CSS considered harmful by Ajaxian commentators?
There's a super-entertaining comment thread/flamewar going down at Ajaxian in response to Dion Almaer's recent editorial on The Future of CSS and the end of 3.0. Almaer has lots of interesting and perceptive things to say about the maddeningly erratic way in which new standards make their way into general use. But the vast majority of commentators jumped at the chance to sound off on some of his minor points:
CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!
Of those four assertations, there's not a single one I can fully endorse. IMHO, current implementations of CSS are _pretty good_ for simple web style, but they're not great. (See the comments for many examples: rounded corners, varied fonts, etc.) They're not great for layout, either, but if you take the time to learn the tricks - and account for spotty browser implementations - then you can develop attractive, robust and usable UIs using CSS. As for whether rich Ajax apps need layout, well, yes. But what kind of layout is open to considerable interpretation. Just because the first few generations of web designers kept trying to apply the same old print paradigms to the browser doesn't mean it was right. The same goes for the current wave Ajax frameworks and the desktop-app layout paradigms some of them attempt to implement.
The assertation that bothers me the most, though, is the one about the time it takes to get CSS working properly. As with any code executed in the browser, CSS is subject to the quirks and peccidillos of browser vendors, operating systems and ever-mutating standards. Still, once you account for the major differences in execution environment, it's not that hard to come up with a single global stylesheet that can zero out built-in styles and browser quirks to offers a more or less blank canvas for cross-browser CSS development. CSS authors may not release their design frameworks under open-source licences the way JavaScript authors do. But that doesn't mean they don't exist. Just peek under the hood at a big, forward-thinking consumer webapp or pick up a Jeffrey Zeldman book.
Regardless of what _I_ think, the thread at Ajaxian provides an interesting vox populi. As can be expected, comments range from wholehearted endorsements of Almaer's position to finger-wagging about the importance of web standards to chest-puffing from people who've mastered the tricky art of CSS layout and don't have much sympathy for those who haven't. I'm fascinated by the way participants in these conversations let their personal investment in a certain skill set lead them to make sweeping generalizations about entire swaths of the software-engineering world. Just because you know how to make a site look a certain way using tables, or floats, or XSLT, doesn't mean that that's the only way, or that the Internet won't eventually cough up a much better way than any of the above.
The fact is, any programming language or development framework can be improved, and there's lots to both love and hate about the CSS specs and the various imperfect implementations of them. It's _so_ far from the all-or-nothing proposition that many of the commentators would have you believe.
Dealing with client-side technology is frustrating for anybody who's used to having complete control over their execution environment, or a stable platform at all. The reason the pace of change is so glacial on the client side is that standards take time to develop; vendors take time to implement them; and a variety of market forces contribute to how well and how quickly they're implemented. Nobody said the Open Web was easy, but it's vastly preferable a host of closed-off, proprietary formats controlled by individual vendors and immune to grassroots innovation.
Any developer who's lived through successive generations of client-side technology knows that things have only gotten better with time. It's hard to imagine that standards won't continue to improve, no matter how painfully slow the process.
Topics: Browsers, CSS, Standards, Web Standards
About Pathfinder
Recent
- Bandwidth profiling Flex projects and more with Charles
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
- From JSP to Ruby on Rails: First thoughts on front-end coding conventions
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
acts_as_ferret
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
apple
Application Architecture
Application Development
architecture
AS3
ASP.NET
Asynchronous Processing
awards
Azure
Back Button
bandwidth
bandwidth profiling
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
caching
Canvas
Case Studies
Charles
chess
Chesspresso
Chicago
Cloud Computing
CMS
COBOL
code
code art
Code Generation
Color
COMET
Conference
Confluence
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
design thinking
Desktop
Desktop RIA
Developer's Notebook
DHTML
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
fixtures
Flash
flash awards
flash player
flash player 10
Flex
flex css
flex skins
flexunit
Flickr
Flock
Flow
Frameworks
FriendFeed
front end
front end development
fulltext search
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gadgets
Google Gears
g phone
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
hardware
Healthcare
Hibernate
HTML
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
iGoogle
illustrator cs3
ILOG JRules
importing graphics to flex
Information Architecture
Innovation
Instructional Design
Interaction Design
interaction patterns design
Interview
iPhone
iPod
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSP
JSR-94
JsUnit
laptop
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
minimalism
Mobile
Mootools
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
notebook
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
OpenSocial
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PGN
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
project management
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
resesign
Restlet
RETE
Review
ria
Rich Interactions
ruby
rubyamf
Ruby on Rails
Ruby on R