As a community, as a whole, web designers and developers need to stop supporting Internet Explorer 6. Now. Completely.
I’ve been thinking a lot about browser compatibility as I’ve been working on Today’s Meet. My CSS is valid, but it doesn’t work quite right in IE6. The interface is completely JavaScript-based, and will only become moreso in the future. How much time should I put into making it all work with IE6?
None. Continue reading
If you somehow haven’t heard of it, Google’s Chrome is a neat, quick, Acid2-compliant “browser” designed to work with web applications, not web pages.
Chrome certainly looks like a modern browser, with tabs along the top and an address bar and a “Most visited” home screen, it will seem familiar to anyone who’s moved past Internet Explorer 6.
And yet, my Twittersphere has been full of comments like “Nice, but not nice enough to make me drop Firefox/Safari.”
While there are some visual improvements, such as an extremely small “chrome” (the parts of the browser around the page area) footprint, the big changes are “under the hood.” Chrome is built for tabs—each tab is an isolated process; no one tab can take down the whole browser—and is built for JavaScript-heavy “web 2.0″ apps—Chrome’s new V8 JavaScript engine executes a full order of magnitude faster than the current browsers, in my experience.
And all of those “under the hood” changes are open source.
Chrome is not a browser.
Chrome is Google’s way of making a point: modern web browsers have not kept up with the web itself.
More and more, the web is becoming an interactive application, and most browsers are not built for it. They display pages, and running applications is an afterthought. While we’ve seen huge improvements in JavaScript execution in the past few years, speed is still a limitation for developers. Applications are also much more likely to crash than static pages (go ahead, just try to crash a browser with just malformed HTML) and isolating tabs will give necessary boosts to speed, stability, and security.
Kris Abel of CTV.ca said it best: “Google’s entire business takes place throughout the internet itself and so they see their interests served regardless of which company takes web browsing to the next level, in fact they see their interests served if all companies do exactly that.”
I’m not switching to Chrome. I doubt very many people will find it useful as a primary browser. I don’t expect many user-interface improvements, like Firefox’s vast add-on library or the accessibility features of Firefox 3, Opera or IE8.
I do expect any future version to have more “under the hood” improvements, and I hope that the makers of Firefox, Opera, Internet Explorer, and any new browsers that spring from this, will re-evaluate their own products and move in this direction.
Because when the browsers get better, the web gets better.
Looking at WordPress themes usually makes me cringe. It’s as if there was a memo on semantic markup and the community of WP developers didn’t get it.
Some themes waste kilobytes of HTML source on something that could be achieved with 75% less markup. Some use blatantly non-compliant code. Almost none use semantic names.
But what really irks me—I’ll cop to using meaningless code to make it look good—is the style of CSS that seems to be spreading: breaking up definitions into a half-dozen chunks, no line breaks, lack of organization. I think their heart is in the right place (a section for colors, so don’t have to worry about layout; a section for typography, so the precious padding is protected) but the result is a horrid mess.
I blame Michael Heilemann, the designer behind the bland and semantic-free default WordPress theme. I imagine theme developers, many just starting with HTML and CSS, started by looking at his code, and thought that was the way to do it. Then it spread like a virus.
Here’s an example from “Autumn Concept 1.0″:
#topbar {background-color: #4b7c44;}
#footer {background-color: #4b7c44;}
#mainpicinner {height: 250px; background: «
url(images/mainpic01.jpg) top left «
no-repeat #fff; border: 1px solid #fff;}
/* typography */
#logo a {color: #3a4032;}
.textbkg {border-left: 4px solid #ebf0cf;}
(« is an inserted linebreak.)
Wow. Line breaks? Readability? Was this passed through a bad version of JSMin?
This is from the “Color Scheme” section, but the first directive for #mainpicinner is height. It also has a border, not just border-color but the whole thing. What’s the point of having sections if you proceed to ignore them immediately?
The rest is filled with classes like cols01 and box01 (while there are other cols##, there is no box02).
But that isn’t my real problem. My real problem is about 20 lines further down:
body {position: relative; background: #1f1f1f; «
font: 70% Verdana, Arial, Helvetica, «
sans-serif; text-align: center; letter-spacing: 0;}
#container {float: left; display: block; width: 100%;}
#topbar {float: left; display: block; width: «
100%; background-image: url(images/topbar.png); «
background-position: top; background-repeat: «
repeat-x; text-align: left; padding: 13px 0 6px 0;}
#topbar div {padding-bottom: 0;}
#container is back. (As are backgrounds. Pick a spot, already!)
This kind of CSS is hard to read, hard to maintain, and hard to customize. Even if the initial version is perfect—which doesn’t exist—things will start to break as soon as someone opens the file. Even in this published style sheet, the author couldn’t decide if background images and borders belonged in “Color Scheme” or “General Styles.” What chance does a maintainer have?
I am, admittedly, obsessively strict with my style sheets. I like to make very sure that every style affects only what I intend it to affect. But I never let the styles for one element single get broken into two places. Instead, what I try to do is keep similar styles in a similar order inside those blocks:
blockquote.dropquote {
float: right; font-family: Arial, «
Helvetica, sans-serif;
font-size: 130%;
color: #662020;
background-color: #ddd;
}
div.login {
position: absolute;
top: 0;
left: 0;
font-size: 80%;
color: #fff;
}
Get the idea? Within each selector, I try to keep things in the same order. I almost always keep positioning styles first and then do either typography or color. To me, this is much more readable and maintainable. If my header div is 3 pixels too wide, I don’t have to comb through all the #header sections. I go to one place and fix it.
I like to extract the CSS order from the document order. This doesn’t necessarily stay complete or strict, especially when you have classes that can be used anywhere or you’re controlling tags directly. The header styles do come before the content styles, though, which come before the footer styles. That just makes sense.
Am I the only one who can’t stand this “style” of CSS? Do you use it? Why?
The premise of Design Patterns is that similar problems have similar solutions. In the same vein, I propose this Work Pattern a set of common steps I use when I create a web site, and maybe you can use, too.
My first step is usually to create an un-styled outline of a “typical” page. I fire up my editor, fill in the basic XHTML, and then go to work inside the <body> tag.
Most sites have this fairly common structure: header, content, footer. And just for fun, let’s throw in navigation between the header and the content. It’s pretty easy to represent this in XHTML:
<div id="header"> </div> <div id="navigation"> </div> <div id="content"> </div> <div id="footer"> </div>
This is my first skeleton for >90% of the sites I design. It’s a very standard document. Sometimes navigation will be inside the header, but most often it goes like this.
Now you have to start thinking about what elements will be on the page. On this site, a blog, I used “articles” instead of “content” for the main div. I also added two side bars, and I knew that inside the articles div I’d want, well, articles.
<div id="header">
<h1>Page Title</h1>
</div>
<div id="navigation">
<ul>
<li>Link 1</li>
<li>Link 2</li>
</ul>
</div>
<div id="articles">
<h2>Recent Articles</h2>
<div class="article">
<h3>Article Title</h3>
</div>
</div>
<div id="theblog">
<h2>Sidebar heading</h2>
<p>Sidebar paragraph</p>
</div>
<div id="theworld">
<h2>Sidebar heading</h2>
<ul>
<li>Sidebar</li>
<li>list</li>
</ul>
</div>
<div id="footer">
</div>
I won’t bore you with more code examples; I think you get the idea. I make an outline. I know at this point that my source is nice and valid, and that it will make sense when I turn off the stylesheet. I use semantic names for everything.
It’s not very pretty, but I now have a workable XHTML document, with a properly-nested outline, and most of the important elements. Good for me, because now I can start to style them.
Now, I know what visual elements will need to go on the page. I know what page elements I need to style. Now I’ll start creating a style sheet.
My first style sheet will contain a few basic HTML tags and the elements of my document. I could probably write an XML-to-CSS generator with how strict I am with this step.
Ok, one more code example:
body {}
h1,
h2,
h3,
h4,
h5,
h6 {}
a:link {}
a:visited {}
a:hover {}
#header {}
#header h1 {}
#navigation {}
#navigation ul {}
#navigation ul li {}
#articles {}
#articles h2 {}
#articles div.article {}
#articles div.article h2 {}
#theblog {}
#theblog h2 {}
#theworld {}
#theworld h2 {}
#theworld ul {}
#theworld ul li {}
#footer {}
One of my favorite things about this is it’s almost impossible for a mistake in one section to mess up anything else.
But obviously there’s a lot in there I can combine, can shorten. Almost anything that’s true for #theblog will also be true for #theworld in this case, so DRY, and keep things together as much as you can. But, when you’re just starting the style sheet, this is a good place to start.
As I’m going, I add a lot to the style sheet. I also add a lot to the XHTML template. Pixels get tweaked left and right and I swear at IE6, of course.
Once I have a complete, or near-complete, mock up, it’s time to start building templates for your CMS of choice. This is mostly copy-and-paste work at this point. Your #header and #navigation go into the header template. #footer goes into footer. #content goes in the content template.
See how easy that is?
Then you get to go through and actually add the template mark up. Whether it’s Smarty or PHP or ASP doesn’t really matter, you just replace your dummy text with the right tags.
I love this process, but there is one thing you really need for it to go smoothly:
You need to know what kind of content you’ll have. When you’re redesigning your blog, or building an in-house site, it’s pretty easy to know. When you’re working for a client, you may need to twist some arms to get this information. (I love this A List Apart article for advice on communicating with clients.)
One final thought: use comments. Any time I create a div, I wrap it in comments like this:
<!--begin #articles --> <div id="articles"> </div> <!-- end #articles -->
I usually use the CSS selector because it’s specific, so #articles, .article, and so on. These comments—which I left out here to save space—have saved me so much time and effort compared to relying on indentation that I can’t imagine working without them.
I didn’t set out this process as a way to streamline my work, but rather, as I started noticing patterns that worked well, I started thinking about the process. Much like Rails, which was already running Basecamp before it was a framework, I’ve been using more-and-more-polished versions of this work flow for months.
Maybe you’ll find it helpful, maybe not. Maybe you already have a “system” in place. If you do, what is it?
“If you wish to be a success in the world, promise everything, deliver nothing.”
If you want to remain the standard-setting body for the web, promise new recommendations, never deliver. Continue reading
I made myself sit down today and finish work on the blog design. I am very happy with how it came out. Continue reading
We all complained, and Microsoft listened to the community: IE8 will now render in IE8-mode by default, and “developers who want their pages shown using IE8’s “IE7 Standards mode” will need to request that explicitly.”
Obviously, this is good news for all forward-looking, standards-aware, progressively-enhancing developers out there.
But even more important is the action from Microsoft: the community voiced an opinion and Microsoft listened and responded. To see any major corporation rethink their position because of community pressure is rare enough, but to see a complete reversal is truly an occasion to celebrate.
Hopefully this is indicative of a new attitude at Microsoft, one that supports or even embraces standards and the goals of progressive enhancement.
Now that we’ve seen what community outrage can do, we should turn our attention to the closed platforms of the iPhone and PSP. It’s a long shot but we can try!
Two months after the whole of the internet has had their say, I thought I’d throw some new kindling on the fire of Internet Explorer 8’s version-targeting mechanism. It’s crap.
The key issue is the default behavior: if I never change my server configuration or every page on my site, they will “forever” be locked in IE7 mode. This is a blow to the heart of the idea of progressive enhancement, or even graceful degradation, and will certainly not encourage developers to make their sites IE8—and thus Acid2—compatible.
Why worry about learning the rules when you have a broken version “forever?”
And what of this “forever?” How long can Microsoft reasonably include every previous version of IE in their new releases? Five years? Say to IE 9? 10 years to IE 10 or 11? At that point there will be 5 separate rendering engines, IE 6 and up, embedded in that increasingly large, increasingly slow program.
Of course, there is also the issue of implementation: Microsoft has said unto us that this shall be. If they really want to get on the standards bandwagon, shouldn’t this have been brought to the W3C, at least for advice?
I have a much more radical suggestion they may not like. Microsoft should abandon “Internet Explorer.” Not the product, but the name, and specifically the abbreviation “MSIE” in the browser string.
They’ll also need to dump the window.ActiveXObject class, perhaps replacing it with a window.ActiveXControl or window.AXObject class. These are the most common ways of identifying IE. If IE shows up like any other standards-compliant browser, there should be no problems for older pages.
I tried to find something good to say about this, but I can’t. It’s a bad idea from the bottom up. Unfortunately, we’re stuck with it.
So I will take Microsoft’s built-in cheat—a not-so-tacit admission that this idea is not viable in the long-term—and adjust my server to send IE=edge with every page. That way I get to keep the progressive enhancement that has served me so well.
Images, flash, frames. These are the “traditional” methods for making a web site “more interesting” or “better looking.” But these hold-overs from the AOL era are the bane of bandwidth, text-only browsers, and non-visual users.
HTML, of course, was originally written to define the structure of a web page, never it’s design. In essence, HTML was intended to be much like XML today. But, when HTML was created, there were no style-sheets, so HTML was forced to include some design information, like <font> tags and the bgcolor attribute. Developers quickly turned to images, JavaScript, frames, and Flash to make their lives easier, but in the process made everyone else’s life harder.
Images and Flash will both suck bandwidth, so why would you use them to display text or a navigation bar? Save images and Flash for what they’re supposed to be: pictures and animations. Frames reek havoc on text-only browsers and screen-readers (hence the rarely-used <noframes> tag) and have been considered blase web-design for years.
So how can you save bandwidth, insure accessibility, and still get all the effects you want? CSS. Let’s go over a few of the quick-and-easy ways to use CSS to replace the bandwidth-heavy, inaccessible design you’re using now:
1) Frames: Fixed Sidebars
Perhaps the most common use of frames was the sidebar, a window on the left (or right) that contained anything from helpful information to your site’s navigation, appeared on every page, and didn’t scroll with the rest of the site.
If you want to do the same thing, use the CSS “position: fixed” definition. For instance:
#sidebar {
position: fixed;
top: 0;
left: 0;
width: 160px;
height: 100%;
background: #00f;
}
This will make a non-scrolling, 160-pixel wide sidebar on the left of the screen. (You could always use “right” and “bottom,” too.) Now, in your HTML file, create a <div> with the id="sidebar" attribute:
<div id="sidebar"> ...all your links go here... </div>
You can put this anywhere in the HTML source, and it will appear in the correct place. In a good screen-reader, if you put this toward the bottom of the HTML source (for instance, after all the content of the page) then the user would hear the content before having to hear the list of links again.
2) Images: Positioning Text
This is really just poor web-design. Unless it’s desperately important that you use a particular, rare font, you should never use images to display text. If it’s important that the text appear a certain way or in a certain position, make use of the box-model and nested <div>s. For example, let’s say you wanted a 480-pixel wide layout, regardless of the users’ screen resolution, with a right gutter and a title and slogan in the top-left. You might do something like:
#main {
width: 480px;
height: 100%;
margin: 0 auto;
padding: 0;
position: relative;
top:0;
left:0;
}
#gutter {
width: 120px;
height: 100%;
margin: 0;
padding: 0;
border-left: 1px solid #000;
position: absolute;
top: 0;
right: 0;
background: #2c2;
color: #fff;
}
#header {
width: 360px;
margin: 0;
padding: 6px;
position: relative;
top: 0;
left: 0;
font-family: Tahoma, Arial, san-serif;
font-size: 140%;
text-align: center;
}
With the corresponding HTML:
<div id="main"> <div id="gutter"> ...gutter code here... </div> <div id="header"> <p>Page Title</p> <p>Page Slogan</p> </div> </div>
Which gives something like (borders added to show box model):
Now, of course, with just a little editing of the CSS file (and none of the HTML) you can move the gutter, change the background, change the page width, change the font, and it’s all in text-format, that will display correctly to text-only or visually-impaired browsers, and save huge percentages of bandwidth.
3) Flash: Cool Navigation Bars
This gets a little more complicated. In general, it’s hard to define the box around <a> tags, so you’ll probably want to do something like this:
#nav
{ margin: 4px auto 0 auto;
position: relative;
top: 0;
left: 0;
}
#nav ul
{ display: inline;
list-style-type: none;
}
#nav li
{ display: inline;
border: 1px solid #000;
padding: 2px 4px 0 4px;
margin: auto 4px 0 4px;
}
#nav li.here
{ border-bottom: 1px solid #FFF;
}
#nav li:HOVER
{ border-bottom: 1px solid #FFF;
font-weight: bold;
}
Now in each <li> tag you’ll make a link to the page you want. This particular set of code gives you a horizontal list. I use a version of this on my projects page, so you can see it in action. If you remove the display: inline parts, you’ll get the vertical list you need for a column. Of course, the margin, padding, and all the colors can be customized however you want, to make it look right. (I got this from the AListApart article “Taming Lists“, which you should read for more information.)
So there you go…
It’s not all the info you’ll ever need, but it solves three of the most heinous wastes of bandwidth I’ve seen on the web, as well as all the problems people have with accessibility. These methods can both look great, and be completely usable by everyone, something Flash, frames, and images can’t.