Windows Phone 7

Windows Phone 7, Microsoft’s modern replacement for the ancient Windows Mobile 6, is finally here, and it actually looks quite decent. I haven’t yet used it in person, but judging from various screenshots and videos, it looks like Microsoft really tried to innovate with their new platform, rather than create yet another “3×4 grid of rounded icons” iPhone clone. In particular, the “hubs” concept is a really interesting idea that solves a common problem in a unique way.

But there’s something even more significant about the release of Windows Phone 7 – it is completely incapable of running Windows Mobile 6.x apps. This was absolutely the right decision for Microsoft to make, given Windows Phone 7′s radically different touch-based UI; but it’s a surprising one from Microsoft, which typically opts to preserve backwards compatibility when launching new products.

In fact, has Microsoft ever introduced a major new platform that completely broke compatibility with existing software or file formats? Imagine Microsoft releasing a new version of Windows that couldn’t run any existing Windows apps – it sounds crazy when you think about it from that perspective. Yet that’s basically what they’ve done with Windows Phone 7.

So if only for that reason alone, I hope that Windows Phone 7 succeeds. If the platform does well, Microsoft will have proven to itself that starting over from scratch can pay off. And if that inspires them to make similar revolutionary jumps with their other products, that can only be a good thing.

Mark Pilgrim on HTML5

Mark Pilgrim’s new book on HTML5, titled “HTML5: Up and Running,” is now officially available. Select chapters are also available online, for free, at http://diveintohtml5.org. It’s an interesting and informative read for any web developer.

A Quick Tip for Writing Semantic Code

Web designers and developers are frequently urged to write “semantic” code, and with good reason – semantics add meaning to code so that it can be understood by humans and computers alike.

Too often, the importance of semantic code is forgotten. Web design is constantly evolving, and if the structure and naming conventions used within your site are based specifically on how that site looks and works today, you’re setting yourself up for difficulties in the future.

Here’s an easy example. Let’s say you have this CSS:

.red {color: red;}

You’ve gone through your site and applied this class to a few paragraphs that you want to stand out from the rest of the page. But now you’ve decided to redesign, and you feel that blue would look better than red. What do you do? If you just change the property value, you’ll have a class called “red” that’s setting the text color to blue, which doesn’t make sense. On the other hand, if you change the class name itself to “blue” so that it matches, then you’ll have to go through your entire site and replace all instances of “red” with “blue.” And that still won’t help when a third redesign looks best with green – you’ll have the exact same problem.

But what if you had just done this?

.important {color: red;}

Now you can change the text color as much as you want – text that you’ve decided is important will pick up whatever color you decide on. Your CSS still makes sense, and you don’t need to make a single change to your HTML.

So here’s a quick tip for creating semantic naming conventions – name your IDs and classes by their purpose or meaning, not by their appearance. Assign styles to elements based on what they do rather than what they are. You’ll thank yourself in the future!

Replace Images With Alt Text When Printing

An interesting web design question was posed to me recently: is it possible to automatically replace images on a webpage with their alt text when the page is printed? I searched around online, but couldn’t find any specific solutions.

So, after a bit of trial and error, I invented my own solution using JavaScript and CSS media types, and thought I would share in case anyone else was interested. It’s a rather specific problem, but perhaps this could be used for accessibility reasons.

HTML

Start off with a simple HTML document:

<!DOCTYPE html>
<html lang="en-US">
<head>
	<meta charset="UTF-8" />
	<title>Print Alt Text</title>
	<link rel="stylesheet" href="css/screen.css" media="screen" />
	<link rel="stylesheet" href="css/print.css" media="print" />
	<script type="text/javascript" src="js/displayAlt.js"></script>
</head>
<body>
	<div>
		<img src="images/test1.jpg" alt="This is the alt text of Test Image 1" />
	</div>
	<div>
		<img src="images/test2.jpg" alt="This is the alt text of Test Image 2" />
	</div>
</body>
</html>

There’s nothing particularly special about this – just inline images wrapped in <div> tags (which aren’t necessarily required, but will probably create better results).

JavaScript

In the <head> of the HTML document is a script called displayAlt.js:

window.onload = function displayAlt(){
	var imgs = document.images;
	for (i = 0; i < imgs.length; i++){
		var imgParent = imgs[i].parentNode;
		var altText = imgs[i].alt;
		var altDiv = imgParent.appendChild(document.createElement('div'));
		altDiv.className = "altContent";
		altDiv.innerHTML = altText;
	}
}

Line by line, in plain English:

1. When the document is loaded…
2. Find all images in the document
3. For each of these images…
4. Find the image’s parent (in this case, the wrapping <div>)
5. Get the image’s alt text
6. Create a new <div> and insert it as a child of the wrapping <div>
7. Give the new <div> a class name called “altContent”
8. Take the alt text and insert it into the new <div>

At this point, the alt text of each image on the page will display directly underneath it.

CSS

Now, we want to hide the alt text when the page is viewed in the browser, but hide the images and instead display just their alt text when the page is printed.

Also in the <head> are two stylesheets:

<link rel="stylesheet" href="css/screen.css" media="screen" />
<link rel="stylesheet" href="css/print.css" media="print" />

In screen.css, hide the <div>s that display the alt text:

.altContent {
	display: none;
}

And in print.css, hide the images themselves:

img {
	display: none;
}

Now, when the page is viewed in the browser, it will look just like normal – but when printed, all of the images will automatically be replaced with their alt text.

Use CSS3 visual effects in IE with CSS3 PIE

CSS3 PIE is a brand-new HTC script that makes it possible to use advanced CSS3 visual effects, such as border-radius and box-shadow, in all versions of Internet Explorer.

PIE stands for “Progressive Internet Explorer,” and using it is as easy as…pie (pardon the pun). The way it works is very clever – simply use CSS3 properties like normal in your stylesheet, and then add a “behavior” property that links to PIE.htc for any element that uses those properties. PIE will automatically convert those CSS3 properties into a format that IE can simulate with its own proprietary methods.

The results are extremely impressive, with near pixel-perfect parity between IE and other standards-compliant browsers. In effect, you can just use CSS3 properties as if they’re supported natively in IE – no more clumsy workarounds or hacks.

This may seriously be one of the biggest advancements in web development in years.

Use HTML5 placeholder text in all browsers

A common technique for enhancing web form usability is to place form field labels inside the fields themselves, often in light grey text. When a form field is clicked, the “hint” disappears, allowing the user to enter text. While the idea has been around for years, HTML 4 never provided an official method to add this functionality, so web developers have always had to rely on custom JavaScript solutions.

In recognition of the popularity of this feature, HTML5 now provides a “placeholder” attribute that can be set on input fields. Now, developers can simply specify “placeholder=’whatever’” in their source code, and the browser will add the hint text automatically – no scripting involved whatsoever.

Of course, Safari and Chrome are the only browsers that currently recognize this new attribute (Firefox 4 will add support, as well). So, if you only use the HTML5 method, older browsers won’t get the placeholder text. And that’s where Seth Aldridge’s Replaceholder jQuery plugin comes in – it looks for uses of the placeholder attribute in your code, and provides the functionality itself for browsers that don’t recognize it.

This means you can start using the HTML5 method today, and – without any changes to your HTML whatsoever – simply drop in the Replaceholder plugin to add the same functionality to older browsers. And once browser support increases to a level you’re comfortable with, just remove it. Simple, easy, brilliant.

Apple on HTML5

Apple has added a new section to their website promoting web standards like HTML5 and CSS3.

Now, most people have no idea what HTML5 and CSS3 are, and they could care less – the ongoing “HTML5 vs. Flash” debate between web developers is irrelevant to the millions of people who are actually buying iPhones, iPods, and iPads. So what’s interesting to me is the way that Apple’s taking “web standards support” and turning it into a consumer issue rather than a technical issue.

Reverse Conditional Comments

In one of my previous articles, Target Every Version of IE from a Single Stylesheet, commenter Greg McAusland pointed out a cool technique of using a negative conditional comment to hide code from IE while still sending it to other browsers. I’ve researched the technique a bit further, and for lack of an official term, I’m proposing the term reverse conditional comment.

With a normal conditional comment, the code sent to IE is hidden from other browsers:

<!DOCTYPE html>
<html lang="en-US">
<head>
	<meta charset="UTF-8" />
	<title>IE Test</title>
</head>
<body>
	<!--[if IE]>This text will only appear in IE.<![endif]-->
</body>
</html>

Since non-IE browsers don’t recognize the conditional comment syntax, they interpret a conditional comment as a regular HTML comment and ignore all of the inner text content. IE, on the other hand, parses the conditional comment and displays the text content inside of it.

A reverse conditional comment does the opposite – it sends code to browsers that don’t match the condition specified, while hiding it from the ones that do:

<!DOCTYPE html>
<html lang="en-US">
<head>
	<meta charset="UTF-8" />
	<title>IE Test</title>
</head>
<body>
	<!--[if !IE]><!-->This is not IE.<!--<![endif]-->
</body>
</html>

By adding the extra inner comment tags, the opening and closing tags of the conditional comment itself are commented out. This makes the inner text content visible again, so non-IE browsers will display:

This is not IE.

Meanwhile, IE will parse the conditional comment, but the condition – “if not IE” – will always evaluate to false. Therefore, IE will not display the inner text content.

Note: even though it doesn’t seem necessary, the second <! is included right before the first closing comment tag (-->) in order to exclude it from the inner text content. If you don’t include this, and you’re testing for a specific version of IE…

<body>
	<!--[if !IE 8]>-->This is not IE8.<!--<![endif]-->
</body>

…then when the conditional comment evaluates to false (in IE7, 6, etc.), those browsers will interpret the first closing comment tag as part of the inner text content, and will display this:

-->This is not IE8.

For more information on this, see this page on MSDN.

By combining this with a positive conditional comment, you can run one piece of code if the browser is IE (or a certain version of IE), and a different piece of code if the browser is not IE. Essentially, this lets you do browser detection without JavaScript. For example:

<!DOCTYPE html>
<html lang="en-US">
<head>
	<meta charset="UTF-8" />
	<title>IE Test</title>
</head>
<body>
	<!--[if !IE]><!-->This is not IE.<!--<![endif]-->
	<!--[if IE 6]>This is IE6.<![endif]-->
	<!--[if IE 7]>This is IE7.<![endif]-->
	<!--[if IE 8]>This is IE8.<![endif]-->
</body>
</html>

Thanks to Greg McAusland for making me aware of this technique!

What Should We Do About IE6?

Peter Bright at Ars Technica has an article up calling for Microsoft to “stop trash-talking IE6 and just trash it.” In a nutshell, his argument is that Microsoft’s efforts to move people off of IE6 – namely by advertising the improved security of IE8 – are only skin-deep, because the company still officially supports the outdated browser. Instead, he says, Microsoft should end official support, which would essentially force users to upgrade.

The flip side of this, of course, is that many (most?) of the IE6 installations still in use are at corporations, which likely have internal applications that only work with IE6. Business users are one of Microsoft’s core markets, so forcing out an upgrade that breaks tons of proprietary business apps makes little sense – it would do nothing other than frustrate some of Microsoft’s most important customers.

I’d like to propose a solution. Many web developers use a tool called IETester for testing their site designs. It’s a free app that lets you run separate instances of IE5.5, 6, 7, 8, and even 9 beta side-by-side in a single tabbed window.

Now, why can’t Microsoft provide something like this with IE9? Ship the browser with the latest rendering engine enabled by default, but let users toggle the rendering engine to IE8, 7, or 6 as they see fit (in fact, IE8′s “Compatibility View” basically does this already, though it can only switch to an IE7 mode). Then, Microsoft can safely make this a mandatory update – if a proprietary business app breaks, that business can just switch the default engine for their IE installations to whatever they need instead. Meanwhile, the rest of the world will get the benefits of much-improved standards support and security.

What do you say, Microsoft?

Target Every Version of IE from a Single Stylesheet

Conditional comments are a great way to get around annoying IE bugs and limitations, but there’s one common frustration associated with their use – you have to maintain separate stylesheets for each version of IE that you want to target. That is, developers will usually set up something like this in the <head> of their document:

<!--[if IE 6]><link rel="stylesheet" type="text/css" href="ie6.css" /><![endif]-->
<!--[if IE 7]><link rel="stylesheet" type="text/css" href="ie7.css" /><![endif]-->
<!--[if IE 8]><link rel="stylesheet" type="text/css" href="ie8.css" /><![endif]-->

For complex sites, though, this setup gets cumbersome, because if you later spot an error in IE, you have to figure out if the source of the problem is coming from your main stylesheet or an IE-specific one. It also makes maintenance difficult, because code that needs to be applied to every version of IE has to be copied across three different stylesheets and kept in sync as updates are made.

But there’s a great technique to get around this, using just one stylesheet but still targeting any version of IE that you want. I take no credit for this method – I actually have no idea who came up with it first – but it comes in very handy.

Basically, instead of using conditional comments to load unique stylesheets, use them to add a special <div> around the entirety of your document:

<!--[if IE 6]>
	<div id="ie6">
<![endif]-->
		<div id="content">
			<div id="main"></div>
			<div id="sidebar"></div>
		</div>
		<div id="footer"></div>
<!--[if IE 6]>
	</div>
<![endif]-->

Then, you can target IE6, for example, simply by prepending a selector in your stylesheet with #ie6:

#main {background: white;}
#ie6 #main {background: black;}

The #ie6 styles will always take precedence over the regular styles, because they’re “weighted” more (two elements with an ID in the selector versus one, in the above example). And as an added benefit, you can now see your IE-specific styles right next to your regular styles, making debugging and maintenance a lot easier.