Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.
In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.
You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.
This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?
It’s a disappointing day when you find a single serving site that generates the comprehensive syntax for the border-radius property, aptly named border-radius.com. Because not all browsers (and browser versions) support the latest and greatest things CSS3 can do, one has to resort to browser targeting yet again. Only this time, one browser’s syntax is different from another browser’s, and becomes a chore to write CSS for each.
There’s a pretty obvious explanation for the existence of browser-specific properties from SitePoint:
Vendors—browser makers—are free to implement extensions to the CSS specifications that, in most cases, are proprietary to their browser. They may do this for a number of reasons, such as adding new features for users, or for experiments and debugging. Most often, though, the extensions are used to release and test browser features that have been developed in the preparation of W3C drafts that have not yet reached Candidate Recommendation status—the extensions allow these new properties to be widely tested before they become available as standard CSS properties.
So for starters, the browser-specific CSS has prefixes like:
-moz: Gecko-based browsers like Firefox-webkit: WebKit-based browsers like Safari and Chrome-ms: Internet Explorer-o: Opera-khtml: Konqueror
(The complete table is listed at the W3C.) That’s fine, but what I don’t get is why the syntax following the prefix isn’t always the same as the standard CSS syntax. The border-radius property is just one example, which is peanuts compared to the gradients syntax. Compare:
-webkit-gradient(
linear,
left bottom,
left top,
color-stop(0, rgb(0,10,148)),
color-stop(1, rgb(45,58,246))
)
-moz-linear-gradient(
center bottom,
rgb(0,10,148) 0%,
rgb(45,58,246) 100%
)
Sure, we can turn to generators like WestCiv’s and Damien Galarza’s—and we’ll probably be increasingly dependent on them in the future as CSS capabilities and their corresponding syntaxes grow more complex. But why must browser vendors insist on that when it only multiplies the code and maintenance necessary? Does it have to do with the way their engines parse the code, or something less significant?
Whether experienced first-hand or heard of in cautionary tales, everybody is familiar with the horror of not being compensated for one’s work and not being able to do anything about it. Enter a possible solution: a remote kill switch, which gives web designers a back door into a client website via PHP, AJAX or CSS to disable it in case something goes wrong, i.e., one doesn’t get paid.
Avoiding the technical details and instead focusing on the general idea of a remote kill switch, let me say this:
It’s a sad, sad reality that people have to resort to these methods, but it’s just a symptom of a bigger problem. I also see it as designers and developers defending themselves with tools they are familiar with, rather than legalese that could only throw them for a loop and might not even work. Which isn’t to say they should abandon the usual way of going into a project altogether; the kill switch can just be an additional safety net.
Is it unethical? There is no reason to use a kill switch underhandedly, or consider it as a sign of distrust or respect. It’s not about having the upper hand or treating clients unfairly, it’s about protecting one’s business. But to earn your keep you need to stay professional, not paranoid. Integrating a kill switch into a contract, where the client is fully aware of the consequences should it be breached, sounds fair and should achieve those two things. One must remember, however, that once both parties complete their respective deliverables, the kill switch must also be killed.
I wonder what percentage and type of web professionals incorporate this into their business process. This is a controversial issue for sure, but I think people can avoid the unnecessary drama if their intentions are sincere. What do you think? Apart from a contract and this kill switch, are there any other ways to protect web professionals from clients running off with their work?
Or as a like to call it: podcasts that have caught my eye in the past week or so. And they differ in several ways, so there’s sure to be something for everybody. Take your pick:
Confession: It took me a while to realize that this podcast is actually the previously-named You Suck at Web Design, relaunched as a new brand with a new site design. This show isn’t so much a bag of tricks on web design as it is a quirky, personal storybook told by Matthew D. Jordan, but still a must-listen.
This is not just one but seven shows tackling different topics, from photography to Ruby programming, founded just last year by Dan Benjamin. I love the idea of a whole network of shows about the internet, on the internet, and here we have a whole suite for people who make websites. I can think of few things better than that. More networks and more topics, perhaps?
In light of the “circuses” happening in both the Hollywood late night talk show circuit and the web working groups, standardista slash comic strip creator Kyle Weems aka CSSquirrel announced this:
I am in the process of devising a “late night” talk show that the Squirrel will host, featuring interviews with cartoon representations of various web designers/developers/standardistas. It’ll draw from the mighty traditions of the Tonight Show, The Daily Show and Space Ghost: Coast to Coast, and in theory will be a plug-in free experience brought to you in part by HTML5, JavaScript and vector tree-climbing rodents.
Check out the podcast over at SitePoint, titled HTML5 is a beautiful mess:
The podcast touches on that matter, and spins out to the state of the actual implementation of HTML5 itself, whether there’s a challenge in getting designers and developers to start using it, the issues of accessibility in <canvas>, and how delightful it’d be to move past plugins.
Truthfully, I’m trying to avoid getting caught in the sticky details of how HTML5 is developing at the moment because it only adds to the anxiety (isn’t stressing over Internet Explorer enough?) and diminishes hope (we’re supposed to be moving forward with these technologies already). But it also helps to stay realistic not just idealistic, and drawing back the curtain on how the working groups are actually working on the HTML5 standard is a good way to do that.
I started with this article about the decade that was in web design. (Note: an earlier version of this was done here.) It was not much more than a before and after look at the most popular websites out there. Of course, ten years is a long time in web design so the showcase is a satisfactory way to see how far we’ve come, but not quite enough. There was no discussion on the notable features from the different websites. We don’t redesign sites just because we want a different look, do we? We want them to improve. Answering how those sites improved over the years would be a worthy reference for all the web designers out there. This other one almost nails it, though it focuses on the business of these companies, not web design itself.
I hope the likes of Smashing Magazine or some fabulous curator of web design history would come up with an in-depth study illustrating how web design has evolved over the last ten years. Timelines like this and this could help with that, but still needs mention of developments like:
- the downfall of
<table> layouts in favor of semantic markup
- CSS sprites
- the growth of web typography, from sIFR to
@font-face
- Art Direction in web design
- mobile web design
- the HTML 5 Superfriends
- which website or company popularized which design pattern, from the glossy, candy-colored “Web 2.0 look” to the sleeker, more dramatic “Apple look” (though something tells me Apple is responsible for both)
Here’s another approach to the timeline, and is more of a Q&A over the years, and anybody can ask and answer. It also hasn’t been updated since ‘04, as it was part of the 2005 conference, A Decade of Web Design. Jakob Nielsen also did a backtrack that same year.
I’d also like to look forward. This prediction post is quite adequate (with pictures it would be perfect). I think this passage sums up what’s happened in the past decade and what will happen in the next:
While most these technological improvements tend to make the web a more and more homogenous place, at the same time, there is a tendency to create highly curated design setups that use different designs for each article.
There will always be a dichotomy between standardization and specialization on the Web but it’s only lately that we’ve been able to do so with less crap, more elegance. And I can’t wait to see how doing those two things evolve into even more exciting things in 2010 and beyond.
Need more crystal balls and time capsules? See also:
And by jQuery-esque I mean easy! The premise of Jetpack, Mozilla Labs’s latest creation, is that anybody who knows HTML, CSS and JavaScript can create Firefox add-ons.
It takes 80 lines of code to block ads on websites as shown in the demo above, and 14 lines to edit images from within Firefox. Granted, it just sends the data to Pixlr which does all the hard work, but lowering the obstacles to develop some fairly nifty scripts is a commendable effort, just as what jQuery did with JavaScript, Sass with CSS, and HAML with HTML. It’s made even more compelling with Bespin, Mozilla’s HTML5-powered web-based code editor.
Perhaps I’m still in a “standardize everything” mood, or envy this new doodad since I’m now using Chrome as my default browser, but don’t you sometimes wish all browsers could do this? Do the same set of things? We’re getting to a point where the level of HTML and CSS support is the same across every browser, so it makes me wonder what’s the next step for the idea of cross-browser compatibility.
It will probably depend on what the web browser means to its various makers. Google has unveiled the Chrome OS, which will run on a specialized version of Chrome. Opera is focused on its “web servers for everyone” feature in Opera Unite. (And Internet Explorer is playing catch-up, mostly.) Browsers are basically the gateways to the whole Internet, but they’ve become more ambitious than that and their vendors will attend to those ventures first before convening to create new cross-platform goodness.
A gallery that only cares about what your site looks like when it’s printed? Ironic, but that’s what printFancy is all about. Remember those niche design inspiration galleries? This site is obviously another example of that. But that’s not all.
Unfortunately, the fact remains that people still print webpages so they can read them in a more comfortable manner; it’s not very environment-friendly, and frankly, weird behavior to people who are in front of the computer 24/7. (Weirder than using IE6.) But it’s a web designer’s responsibility to accommodate that need. No excuses. Even if sometimes, it does feel like creating a whole other website (except if you’re a minimalist, I guess).
And when you manage to create an effective print version of a site, then printFancy is another opportunity to show it off, another incentive to excel in design. Which is not just about creating something looks pretty, but something that fills a need. In this case, the need to print sites out.
(Then maybe the gallery can have a section like this, and one wouldn’t have to hold a laptop the way Jason Santa Maria did.)
Harry Roberts a.k.a. CSS Wizardry tweeted a certain tutorial by CSS Aid (page is dead now), which was enclosed with four little words (“Good lord, wrong much?”) that echoed such alarming levels of horror and shock (considering he tweets about poor examples of HTML/CSS code everyday), that I had to check it out.
First, the tutorial was entitled “Tables Without Tables”. If that doesn’t trigger warning bells in your head, then consider the opening paragraph:
It’s the year 2009, CSS rendering has vastly improved from when it was released, so there is no reason for any website to use tables as layouts. Although you can ditch the table tag when it comes to layouts, you may someday need to use it for what it was made for…or do you? I am going to show you an easy way to make a table with a simple unordered list.
No. Just no. Yes, <table>-based layouts are considered wrong because HTML is supposed to properly represent data. Lists should be lists. Tables should be tables. Layouts that look like tables (grids) can be done in CSS. That’s semantics, the core principle of web standards.
But avoiding the use of <table>s at all costs is no better. Perhaps it’s even worse, since it demonstrates not only ignorance but false expertise, feigning arrogance over an HTML element that has been shuddered at because of its misuse and abuse.
The page has gone down in between the time that I read the tweet and wrote this post. Fortunately the forum thread that seems to be the source of the link is still up, and shows us the author’s reasoning for writing the tutorial. Take post #7:
Because I hate the <table> tag
Is this the extreme dark side of web standards, where we’ve been conditioned to hate <table>s so much that we can’t even think to use them for what they were meant for anymore? A sad, sad turn for us all.
By post #15 he’s already backed down and promises not to use the experiment for real-life cases, but this summarizes things nicely:
It’s a pointless experiment though. It’d be like experimenting making a house out of tampons. Doable but just plain wrong.
It’s bad enough that we have to deal with preaching proper web standards, dropping crusty old browsers from, and adding newfangled technologies to our web design arsenal. Let’s not get sidetracked by punishing HTML elements by twising them into things they weren’t meant to be.
In the left corner: Tyler Tate’s 1KB CSS Grid, a lean framework sporting 14 classes and the familiar conventions for enforcing a visual grid via CSS.
In the right corner: Vladimir Carrer’s 1-line CSS Grid, an experimental framework sporting a single class to cut nested column widths in half. The solution is mindblowingly brilliant, but does it work? Design tends to work in thirds, not halves. You decide.
Whether or not it’s a coincidence I chanced upon these two extremely simple CSS grid frameworks just days apart, news of these two solutions makes the CSS framework “scene” a lot more interesting. And accessible. I can imagine many front-end developers shying away from heavyweight frameworks because there are too many features, most of which won’t be utilized, and there are too many conventions, most of which aren’t easy to remember.
I’m not even going to get into how using these frameworks leads to unsemantic, presentational class names and lots of <div> soup reminiscent of <table>-based layouts. Let’s just be glad people are streamlining the application of design principles for the Web, namely grid layouts. When a better way comes out—maybe it’ll be display:table, maybe it won’t—we’ll adjust then.
In the meantime, we need to let our arsenal evolve. Balance out the spectrum with lightweight frameworks like these. Then add diversity as well. Look at the Javascript libraries—the tiny moo.fx, the venerable Prototype and Scriptaculous, and the designer darling jQuery—each one caters to a specific need. What other kind of grid frameworks do we need? Fluid? Do-it-yourself? Highly reputable? Unobtrusive? Oh, what will they think of next?
Andy Clarke of For A Beautiful Web has presented a stylesheet for the web browser we haven’t been able to push off the provebial cliff: Internet Explorer 6.
When I asked myself why people visit my sites, and the ones that I make for other people, the answer was always “for the content”. Content that is almost always written words and that means type.
That is why I’m now advocating to my clients (and to you), that where feasible, not to waste hours in time and a client’s money on lengthy workarounds in an unnecessary attempt at cross-browser perfection. Instead, you and I should provide simple but effectively designed HTML elements. This means just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.
But this idea is not new; this Universal IE6 CSS file contains just enough rules for a practically unstyled but easy to navigate website. You’re basically giving websites loaded in a low-fi browser a low-fi experience. Examples here, here, and here.
Despite its waning popularity, we seem to have amassed a whole buffet of solutions to the shortcomings of IE6, ranging from the hostile upgrade messages and campaigns to the subtle conditional stylesheets and scripts.
I can just imagine someone creating one of those personality quizzes out of this whole debacle: which IE6 compatibility fix are you? There’s an idea.
But really, dealing with IE6 and somesuch boils down to principle and circumstance. Can your clients and your conscience accept barely recognizable version of their sites in twentysomething percent of their audience? Is your sanity more precious than squishing mysterious bugs? Or do you feel like throwing some humor in?
Let me know if someone’s actually made a personality quiz about this; I’d love to take it.
