It does, however, support parts of the Shadow DOM. That means we can style this element, and give our users a visible control.

The image below shows a rather garish green-and-orange version of the range user interface widget. This is after adding some styling, as it appears in the stock Android browser.

And below is the CSS that gives us the above image.

input[type='range']{
    background: #0c0;
    height:10px;
}

input[type='range']::-webkit-slider-thumb{
    background:#f60;
    height:30px;
    width:30px;
    border-radius: 30px;
}

To date, this does not affect Chrome or Safari for the Desktop. ::-webkit-slider-thumb does partially affect iOS Safari. I’ve included an image of what it looks like below (not to scale). Notice that the thumb color changes, but the slider background does not.

This may also affect other browsers that use Webkit such as the Web Browser for S60 Nokia and Samsung’s Dolfin. I haven’t tested it yet, but if you have, please let us know in the comments.

Also keep in mind that this element has a pretty poor user interaction in Android browser. It’s not very responsive, and doesn’t operate all that intuitively. This is true of most mobile browsers, but in my opinion (and based on limited experience), Android is worst of all.

Now I work almost exclusively with JavaScript, HTML5, CSS, and occasionally SVG. I haven’t touched ActionScript in any serious way for close to a year. But working on those projects was “training” of sorts. And it served me well.

It’s an open secret that HTML5* evolved to kill Flash. Many of the features of HTML5 and technologies such as XMLHttpRequest, Level 2 and Cross-origin Resource Sharing have parallels in ActionScript 3.0. The front-end stack, in other words, is gunning for Flash. And it will happen sooner rather than later.

ActionScript developers may cringe at that news, but I don’t think they should. I strongly believe that AS3.0 developers are better positioned than the rest of us to be leaders in front-end stack development. Problems that most JavaScript developers are learning how to think about — reading and manipulating bitmap data, doing object hit testing, making cross-domain requests, — ActionScript developers have been doing for years.

Of course, this is all provided ActionScript developers are willing to make the switch.

To that end, I’m starting an ongoing (but occasional … perhaps very occasional) series of blog posts detailing some of the commonalities and differences between ActionScript 3.0 and the HTML5 Stack. I am calling it HTML5 for ActionScript 3.0 Devs, even though it isn’t just about HTML5.

Sometimes they’ll be deep dives. Other times they’ll be shallow ones. It is quite possible that I will misunderstand aspects of both (that’s what comments are for). My goal here is less to be comprehensive than it is to encourage developers to learn more about these topics.

*Of course, I am using “HTML5” as a short hand for HTML5, CSS3, JavaScript, the Document Object Model, Scalable Vector Graphics, and several other web technologies and specifications.

Not really. Browsers ignore the unit type when the value is 0. That’s why margin: 0 is the same as margin: 0em and margin: 0px. If it’s zero, after all, what does the unit matter? That explains why the second item’s transition worked well.

But when there is a mis-match between the type of unit, most browsers — Firefox is the exception to date — won’t transition between the two values. The result? It jumps. The fix: make sure that you are transitioning between two values of the same unit (or transitioning from a 0 start value).

Since this is better shown than written about, this demo illustrates what I mean.

What makes the magic? Using height: auto, and transitioning the min-height and max-height properties instead.

View the demo, or study / steal the code.

This example makes use of CSS3 transitions, and DOMTokenList / classList. There’s also a fallback that uses className and some regular expression-ism in browsers that don’t yet support classList.

classList makes it much easier to work with elements and class names. With it, you can:

• Add, remove, and toggle classes;
• Retrieve the class name at a specified index; or
• Check whether an element contains a particular class.

classList returns a DOMTokenList — a space-separated list of tokens — containing the class names currently applied to the element.

Its syntax is simple: elementNode.classList.methodname(arg) where methodname is either add(), remove(), toggle(), contains(), or item() and arg is either a numeric index (in the case of item() ), or a class name. classList also has a length property, which tells you how many class names have been applied to the element.

Let’s look at some examples.

LetsPretendWeAreBuildingANewsSite.net

Pretend we’re building the home page of a news web site. This means we have lots of lists of stories, each styled slightly differently based on their section and prominence. We’re also going to allow users to hide some lists of headlines. Which ones can be hidden is determined by a class name.

One of our home page lists, then, has three class names: hardnews (as opposed to say, celebrity gossip), business, and removable. The markup looks like this:

<ul id="bizheadlines" class="hardnews business removable">
	<li>Coca-Cola posts a Q3 profit</li>
	<li>Justin Timberlake invests in MySpace</li>
	<li>Google tries to get social (again) with Google+</li>
	<li>Southwest and AirTran airlines to merge</li>
	<li>Stocks can't decide whether they're up or down</li>
</ul>

Retrieving all classes on an element

If we wanted to retrieve all class names on our list, that’s an easy enough task:

var biz = document.getElementById('bizheadlines'); // could also use document.querySelector('#bizheadlines');
var bizclasses = biz.classList;
console.log(bizclasses)

The code above would write hardnews business removable to the JavaScript console.

Retrieving all class names on an element is only somewhat useful. You would typically use this to test whether the element has a class at all, or whether classList is supported by the browser. If document.body.classList == undefined, for example, you know that it is unsupported in that browser.

Retrieving a class name by index

Instead, let’s try retrieving the third class name in the list. Here we’d use item(n), where n is an integer between 0 and the number of classes minus 1 (element.classList.length - 1).

var biz = document.getElementById('bizheadlines');
var bizclasses = biz.classList;
console.log( bizclasses.item(2) )

Executing the above writes removable to the console. If a class name does not exist at that index, the value of bizclasses.item(2) would be null instead.

Adding a class name

Now, the real fun of classList is the ability to add, remove and toggle the class names of an element. So let’s say one of our users wants to hide our list. They can do that because we’ve specified that it is removable with the removable class. But removable only says that it can be removed. We need to add another class (hide) in order to remove the list from view. Meet the add() method.

var biz = document.getElementById('bizheadlines');
biz.classList.add('hide');

In order for this to work, of course, .hide must be defined in our CSS: .hide{display:none;}.

Note that you can’t add a list of space-separated values to classList. For example, document.body.classList.add('sports sectionfront') won’t work. You must instead add them one at a time, or use className.

Removing a class name

To remove a class name (maybe our user wants to restore that list of headlines) use the remove() method. It, like add(), accepts a class name as a parameter.

var biz = document.getElementById('bizheadlines');
biz.classList.remove('hide');

Here too, you need to remove classes one by one, or use className.

Toggling classes

Of course, since we’re just adding and removing a class name, we could just toggle it. As you’d expect, this is where we’d use the toggle() method.

var biz = document.getElementById('bizheadlines');
biz.classList.toggle('hide');

If the element does not contain the hide class, toggle() will add it. If it does, invoking toggle() will remove it.

Checking whether a particular class exists

What if you wanted to show a message only when the user tries to close a hard news headline list? Then you would want to check whether the element in question has a hardnews class. This is where the contains() method comes in handy.

// Get all removable lists of headlines
var removable = document.querySelectorAll('.removable');

var clickhandler = function(e){
	// if the current target has a 'hardnews' class
	if( e.target.classList.contains('hardnews') ){
		var cont = confirm("Hiding this will make you a less informed citizen. Are you sure?");

		if(cont){
			e.target.classList.add('hide');
		} else{}
	}
}

// apply the click handler
for( var i=0; i < removable.length; i++){
	removable[i].onclick = clickhandler;
}

In the above example, we have applied a click handler to all removable lists. If a user tries to remove a hard news section, we ask for confirmation. If they confirm, we will hide it. Otherwise, we won't.

See classList in action

Though decidedly not a news web site home page, you can get a sense of how these methods can be used together in this classList demo.

Browser support

Here's the caveat: classList is not yet supported in iOS Safari, or Internet Explorer 9 (it's unclear whether support will be available in IE10). In those cases, you will still need to use className or getAttribute('class') and manipulate it using JavaScript string methods and regular expressions. ]]> http://tiffanybbrown.com/2011/08/15/class-manipulation-with-classlist/feed/ 0 http://tiffanybbrown.com/2011/08/12/meet-the-selectors-api/ http://tiffanybbrown.com/2011/08/12/meet-the-selectors-api/#comments Fri, 12 Aug 2011 12:00:44 +0000 tiffany http://tiffanybbrown.com/?p=6125 DOM Scripting is sometimes clunky. Consider the retrieval of elements with a particular class name. The code might look like this:

var p = document.getElementsByTagName('p');
var newsitems = [];
var i;
for(i = 0; i < p.length; i++){
  if( p[i].className == 'newsitem' ){
     newsitems.push( p[i] );
  }
}

In the example above, we’ve retrieved all elements in the document using document.getElementsByTagName(). Then we’ve iterated over them, checking for the presence of the desired class name.

It’s ugly, right? That᾿s even more true when you look at the elegant, CSS-style selectors of libraries like jQuery and MooTools.

Code like that above is why the W3C developed a Selectors API. It consists of two methods on the document object: querySelector() and querySelectorAll().

querySelector() and querySelectorAll() both accept any CSS selector that the browser supports. All recent browser releases support both methods, though Internet Explorer 8 is limited to CSS2 selectors.

querySelectorAll(), as its name suggests, returns a node list of elements matching the given selector. querySelector() only returns the first matching element. You can pass any CSS selector as an argument, including ones like the adjacent sibling combinator and nth-child() if the browser supports it.

Let's re-write the above code using querySelectorAll().

var newsitems = document.querySelectorAll('.newsitem');

That’s much more concise. The newsitems variable contains only those elements with the newsitem class. Using the Selectors API greatly simplifies the code we need to use when interacting with the DOM.

Learn more

• Selectors API Level 1 Specification
• Selectors API Level 2 Specification
• CSS Selectors Level 3 Specification
• CSS Cascading Style Sheets Level 2 Revision 1 Specification

What Mazzola’s CSS3 buttons look like in Opera 11.10.

In January, Chad Mazzola posted a Thoughtbot article titled Make CSS3 buttons like a boss (via nico604). It is a great read for designers, but it does have one glaring omission: no Opera support.* (I know right? Who does that?)

So let’s improve Mazzola’s code to add Opera support and use standard, prefix-less properties where we can.

Opera and Linear gradients

As Mazzola points out, the light source for these buttons is coming from overhead, giving highlights at the top edge, but darkness and shadows at the bottom. He starts with linear gradients for Firefox and Safari/Chrome.

button {
  background: #3b88d8;
  background: -moz-linear-gradient(0% 100% 90deg, #377ad0, #52a8e8);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#52a8e8), to(#377ad0));
}

We will add a linear gradient style for Opera.

button {
  background: #3b88d8;
  background: -moz-linear-gradient(0% 100% 90deg, #377ad0, #52a8e8);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#52a8e8), to(#377ad0));
  background: -o-linear-gradient(90deg, #377ad0 0%, #52a8e8 100%);
}

Note that Opera’s syntax is different from that of WebKit’s or Firefox‘s implementation. It’s closer to the current version of the specification. Since this is a simple gradient, we could also use a simpler syntax for Opera: -o-linear-gradient(#377ad0, #52a8e8). Read more about linear gradients in Opera.

The syntax for borders is the same in Opera as it is in Firefox, Internet Explorer, Safari and Chrome. We can skip that section. But we can adjust Mazzola’s box-shadow styles to reflect current browser support.

Browsers have pretty much standardized their implementations of box-shadow. The appearance varies slightly, but the syntax is the same. That means this code:

button {
  -moz-box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
  -webkit-box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
}

can become:

button {
  box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
}

The above works in the latest versions of all major browsers, including Internet Explorer 9. If you’d like, you can retain the -moz- and -webkit- prefixes for older versions of those browsers.

Now let’s look at the styles for the :hover state. Here, Mazzola has applied a linear gradient and a box shadow. Again we will add a gradient for Opera and change the prefixed box-shadow properties to use the unprefixed ones. For future-compatibility, let’s also add an unprefixed, spec-compliant linear-gradient (which we can also do above).

button:hover {
  background: #2a81d7;
  background: -moz-linear-gradient(0% 100% 90deg, #206bcb, #3e9ee5);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#3e9ee5), to(#206bcb));
  background: -o-linear-gradient(#206bcb, #3e9ee5); /* using the simpler syntax */
  background: linear-gradient(#206bcb, #3e9ee5);
  border-top: 1px solid #2a73a6;
  border-right: 1px solid #165899;
  border-bottom: 1px solid #07428f;
  border-left: 1px solid #165899;
  box-shadow: inset 0 1px 0 0 #62b1e9;
  cursor: pointer;
  text-shadow: 0 -1px 1px #1d62ab;
}

Repeat these replacements for the button[disabled] state.

Though Internet Explorer 9 doesn’t support CSS gradients, you could use an SVG gradient as a background image. You can also use a bitmap image file for older versions of all browsers.

And that’s how to make CSS3 buttons like a boss.

*To be fair: Opera didn’t support linear gradients at the time. Support was added in Opera 11.10, released in March 2011. But Opera did support for prefix-less versions of box-shadow and background-clip. You do not, however, need to use background-clip to make these buttons work in Opera.

• don’t require the additional HTTP request of an image file.
• are easier to modify than image files.
• “weigh less” than most image files.

That’s the ideal, at least. In their current state, gradients are actually a hot mess. The reality?

• The specification is still in flux.
• Full gradient support is not available in all modern browsers. (For now, Opera 11 only supports linear gradients.)
• Many older, though relatively recent versions of browsers (Internet Explorer 8 & 9, Opera 10 Desktop, Opera Mobile, and Opera Mini, for example) don’t suport CSS gradients at all.

So, how can developers take advantage of gradients and still support older browsers? Let’s look at some approaches.

Set a background color

Take a look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

This is a fairly common scenario. The developer (*cough*me*cough*) covered most of her bases, but forgot one: browsers that don’t support gradients at all. You can see what this looks like in Internet Explorer 9 (see Figure 1).

Figure 1. Internet Explorer 9 doesn’t yet support CSS gradients. This is what it looks like if you don’t supply a background color.

Now look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-color: #333;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

Here we’ve set a background image, but we’ve also set a background color. Browsers that don’t support CSS gradients will ignore the last three lines. (Note: each browser also ignores the other browsers’ vendor-specific prefixes.)

Setting a background color is the easiest fall back for older / less modern browsers.

Set a background image using an external file

Consider the following CSS.

#linear{
    width:400px;
    height:300px;
    background-image: url(migas.jpg);
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

In this example, we’re taking advantage of how browsers apply the cascade. As it turns out, Opera 11, Chrome whatever-the-heck-version-it’s-up-to, and Firefox 4 will not make the HTTP request for the external file. Safari, however, does (see Figure 2). Internet Explorer 9 (and less-modern browsers) will only load the external file. Depending on your audience, this may be an acceptable alternative.

Figure 2. Safari downloads all images. Click to embiggen.

Note: I have just barely tested this in mobile browsers. (Opera Mobile 11 doesn’t support gradients. Users will see the external image).

Use SVG gradients to create a background image

Internet Explorer 9 and Opera 10 (including Mobile) do not support CSS gradients. They do, however, both support the use of SVG images as background images. Another alternative to using external images, then, is to use an SVG file.

#linear{
    width:400px;
    height:300px;
    background-image: url(gradient.gif);
    background-image: url(gradient.svg);
}

This example works in all current desktop browsers, and most mobile browsers. Safari 5, again, will download both images. Most others will download the latter SVG image. The advantages here are clarity and (arguably) ease of maintenance. Want a different gradient? Change the images.

You should be aware, though, that some recent(-ish) versions of mobile WebKit — such as the T-Mobile myTouch 4G browser — don’t support SVG backgrounds. You’ll still need to add a linear gradient for those browsers, or set a background color.

Or keep doing what we’ve been doing

Of course, the growth of SVG and CSS gradients support doesn’t preclude using GIF, PNG or JPG gradients. The biggest point in favor of using bitmap images is that they still work in older browsers and current ones.

As with any aspect of web development, the right approach should balance concerns of maintainability, file size, and the browser distribution of your audience.

You left out linear-gradient!

I left it out of the examples above for two reasons: (1) simplicity; and (2) the syntax could change (though if I had to predict, it won’t change by much). Be forward-thinking! There are very few reasons not to include the proposed linear-gradient syntax in your code.

That means the specification is stable. Browser vendors can implement these features without a vendor prefix if they haven’t already.

border-radius support

Preceding to this move from Working Draft to Candidate Recommendation: support for border-radius (and border-top-right-radius, etc.) in Opera 10.5+ (current version is 11.01), Safari 5+ and Chrome 5+ (current version — as of February 12, 2011 — is 9.0.597.102 beta).

That means this*:

div{
	-moz-border-radius: 10px;
	-webkit-border-radius: 10px;
}

Can safely become:

div{
	-moz-border-radius: 10px;
	border-radius: 10px;
}

Yep. You can drop -webkit- from your border-radius properties long as you don’t mind your sexy rounded corners not appearing in older versions of WebKit-based browsers (and you’ve been able to do so since June 7, 2010).

Versions of Opera prior to 10.5 didn’t support border-radius, even with a vendor prefix. Ditto Internet Explorer 7 and 8.

Internet Explorer 9 and Firefox 4 will both support border-radius. IE9 pushed its Release Candidate February 11, 2011. Firefox 4 released its 11th beta February 8, 2011.

* But the cool, forward-thinking kids were already including border-radius, even before Opera 10.5 supported it.

1. Not all fonts are licensed for embedding and linking on the web.
2. Major browser developers have differing philosophies about where the responsibility for license compliance should fall.

Microsoft, for example, has not implemented @font-face, in part, because it believes in protecting type foundries from the potential intellectual property violations of embedded fonts.^* Opera, Safari / WebKit, and Mozilla leave compliance to the developer and support @font-face property.

In late May, a Typekit private beta launch brought the issue of embedded fonts and licensing back to the forefront. Typekit is a hosted font service that allows developers to select from a library of type chosen and hosted by Typekit and licensed for the web.

Ars Technica speculated about the future of web typography in its July article, The hazy future of Web typography.

Late last month (October, 2009), type foundry House Industries announced its support for WOFF, stating that the format satisfies the needs and concerns of browser makers, web designers, and type foundries, [and] offers compression to speed page load times, freedom from thorny legacy issues, and inclusiveness (font outlines can be Postscript or TrueType).

That same day, Mozilla announced that WOFF support would be available in Firefox 3.6.

Today (November 2, 2009) Ars Technica features an article with more background on last month’s announcements.

More about embedded web fonts

• Firefox 3.6 Beta 1 is now available for download
• House Party (Zeldman’s round up)
• after Firefox 3.6 – new font control features for designers
• Mozilla Supports Web Open Font Format
• Typographic diversity for the web
• Seven Web Fonts showcases
• CSS @ Ten: The Next Big Thing
• An introduction to W3C Web Fonts

* Chris Wilson and Jeremy Keith had a rather heated debate about this subject at 2009′s South by Southwest “Browser Wars” panel. Chris Wilson, who was a part of the Internet Explorer development team at the time, made essentially this argument. Microsoft does, however, have its own format for embedding fonts on the web

When it comes to Mac and Linux versions, this means that our goal is not to just “port” a Windows application to these other platforms–rather, our goal is to deliver Chromium’s innovative, Google-style user interface without rough edges on any of them. Chromium’s overall design has been multi-platform from the start, but we are also committed to getting the details right for users on each platform. For an application that most of us “live in” most of the day, rough edges in the user experience or operating system integration are like having a stone in your shoe no matter how well the rest of the product works.

Update: I updated this post with more about Chrome’s features and some related links.

I may craft this into a better post later, but for now, I wanted to share some initial thoughts and observations about Google’s Chrome browser, which was released earlier today.

Keep in mind that I’m rolling in true nerd style here: blogging at LAX on my T-Mobile HotSpot collection connection waiting to board my flight to Atlanta. Expect typos, incomplete thoughts and possible profanity because I’m in that kind of mood.

I have only spent a few short hours with the browser, but I can safely say that it may be a game changer. Chrome, which is based on WebKit, has super speedy load times and man-handles JavaScript. I don’t think Google Chrome is using SquirrelFish just yet. But I fully expect that a final release (or at least a later beta) will.

What I’m digging

• Slim, trim interface. Google got the interface right. It’s streamlined and simplified with only what you need to see at any given time. Other options (like your bookmarks bar) can be turned on and off as desired.
• Speed. I’m running this on a Windows XP Parallels virtual machine. Still fast. As f*ck.
• Dead-simple plug-in installs. Chrome realized that I needed to install Flash. One click and a few minutes later, the player was downloaded, installed, and ready to use.
• Most visited sites: Similar to Opera‘s Speed Dial feature, but automated. Chrome automatically saves and organizes the sites you visit most and loads them as your home page when you start the browser (above photo).
• Combined search address bar. Consider it a lesson learned from Firefox, which despite having separate boxes for the URL and web search, will actually search the web if you type a keyword in the address bar. Google Chrome dispenses with the separate boxes. You want to search the web? Type in the address / search bar and hit enter.
• Incognito surfing. It’s similar to Safari’s private browsing feature. Incognito lets you fire up a separate browsing window that gets rid of cookies and your surfing history when you close it.
• Application shortcuts Think of it as a site-specific browser, along the lines of Fluid or Mozilla’s Prism extension. Application shortcuts load separately from the Chrome browser window, and and offers a focused environment for web applications such as GMail or Zoho Writer.
• The nerdiest of nerdy sh*t. Yeah, Chrome lets you tweak your security settings and such. And yes, it has developer tools that don’t require extensions, or special configuration commands. But it’s killer nerd feature is Task Manager. Yes, Google Chrome lets you see which of your tabs and/or plug-ins is sucking up your CPU usage.
• Crash protection. Flash might crash, but it won’t take your browser down with it.

What I’m not digging

• Combined search address bar. Firefox’ keyword search is basically a Google “I’m feeling lucky” search. I like that Firefox removes the Google page middle man. Chrome, conversely, takes you to a Google search results page.
• No really. That’s the only thing I don’t like so far.

Now when looked at individually, there’s not much about Chrome that hasn’t been done before. Unified search bar? Firefox (sort of). Single-site browsing (or site-specific browsing)? Firefox + Prism. Frequently visited pages? Opera Speed Dial.

The innovation, however, comes in the aggregate. No browser available today has an interface that is more thoughtfully-designed than Chrome. Period. Google rounded-up the best browser trends and innovations of the last few years, sprinkled them with G-Dust, and released them as one hell of a browser.

I am surprised, however, that Google’s Chrome is only available for Windows, considering it’s based on the WebKit project — the same software that powers Apple’s Safari browser. I’m also curious why they chose a WebKit core over a Mozilla core, considering the history of collaboration and sharing between Google and the Mozilla Corporation.

For what it’s worth, Google says, that Mac OS X and Linux versions are coming soon. And I hope by “coming soon” they mean “next week.” In the meantime, Windows users can download Chrome and put it through its paces.

Related

• The Pencil Project, Prism and the browser as platform
• JavaScript in Firefox 3.1 will be wicked fast
• Essential Firefox Extensions
• My new favorite Firefox extensions
• Google chrome’s FAQ for web developers

Acid1 and Acid2 tested for compliance with CSS 1 and CSS 2 specifications. Acid3 also tests for support of DOM Scripting / ECMAScript, SVG and webfonts.

Safari 3 and Opera 9 pass the Acid2 test, as does the beta version of Firefox 3. Version 8 of Internet Explorer will also pass the Acid2 test.

Here’s how today’s leading browsers handle Acid3 (check out the reference image). Each image links to a larger screenshot.

Firefox 2

Opera 9.26

Internet Explorer 6

Internet Explorer 7

Safari 3

Firefox 3 Beta

About 6 years ago, I remember taking part in a conversation about preferred browsers on the Jane magazine message boards. IE 5.x was still king of the PC world. IE 6 was coming on strong. Netscape 4 was still widely used by universities. Netscape 6 was on its way.

Most of the respondents said they preferred Internet Explorer. Why? Because sites just “look right” and “work better” in Internet Explorer. My response at the time was simple: if a site doesn’t work in Netscape, it’s because the web developer didn’t know what (s)he was doing.

Of course, they didn’t care. They were far more into Sephora than HTML code quality. As far as they were concerned, Netscape was the problem. They didn’t blame crap code, or Microsoft for developing a browser that stomped harder than a Catalonian flamenco dancer all over the W3C specs and allowed ugly code to thrive. They blamed Netscape.

I was reminded of that conversation when I first read Microsoft’s recent announcement about Internet Explorer 8. After my initial D*MNF*CKINGBLOODYHELL!JUSTBREAKTHF*CKINGWEBALREADYMICROSOFT!WHATTHEF*CK? IAMTIREDOFYOURAGGEDYBASTARDSMAKINGMYDAYJOB1000TIMESHARDERTHANITNEEDSTOBEBECAUSEYOUCAN’T DEVELOPABROWSERTHATFOLLOWSAF*CKING10YEAROLDSPEC!!! reaction passed, I came to the following conclusion: this is the best approach to a bad situation.

Microsoft does not want to be where Netscape was. It’s a sad but true fact is that if a site breaks, the average web user — and, dare I say, average web developer — will blame the browser. Microsoft is too entrenched in corporate intranets and applications to let that happen. Doing so would cause a sh*tstorm of massive proportions for the company. From a business perspective, I understand.

And while I am also not happy about the default implementation (as Jeremy Keith explained Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.), opting-in to web standards eliminates the need to revise existing code.

Yes, it’s potentially a nail in the coffin for progressive enhancement techniques. Yes, we’ll still have to do something special to cater to Microsoft browsers. Yes, this could freeze web development at the IE7 level for years to come. But I believe — and it pains me to say it given the hate-hate more relationship I have with Microsoft browsers — that Microsoft, given its position, had no other choice.

But putting pragmatic approaches and practical considerations aside, I think Ben Buchanan said it best:

If they’ve included a DOCTYPE, they’ve declared they want to render to standards. If they did that in ignorance, it’s time they started earning their money instead of letting Dreamweaver do their jobs.

Related: Internet Explorer 8 Round Up

It’s a technique I’ve employed on smaller, static sites. But it would work at least as well on complex sites with differing content layouts, or with content management and templating systems that generate category identifiers.

I start by defining global styles common to all pages on the site. For example:

body{
     background: #fff;
     color: #606;
     font: 75% / 1.5 arial, helvetica, sans-serif;
}
h1{
     color: #c09;
     font-family: Georgia;
}

Then I use what I’ll call compound selectors to set page- or section-level styles. For example:

body#aboutUs h1{
     font-family: 'Lucida Grande';
}

I find that by using this technique my CSS becomes far more organized, and my HTML requires far fewer class and id names. I can group page and section specific styles together making them easier to find and read at a glance.

An added benefit is that you have another ‘hook’ in your document for CSS or DOM scripting.

Related:

• Understanding CSS and Methods for Hack Management
• Blog customization: DIY or Hire and What to Expect

Speakers include Molly Holzschlag, Garrett Dimon, Stephanie Sullivan, and Jared Spool. It’s really a top-notch list.