In this talk at The Future of Web Apps London, Aza Raskin talks about the future of browsers. He discusses …

1. YOU-Centric browsing
2. How browsers will manage your identity
3. Browsers with native natural language processing
4. Built-in payments in browsers

By the way, hope you can join us at …

A Microsoft browser plug-in might seem an odd target for the PHP developer, more used to working with open source platforms such as Linux, Apache and the MySQL database server. However there is much about Microsoft Silverlight that makes it a good match to such technologies. For a start, it is a free download and there are versions that run not only on Microsoft Windows XP and Vista but also on Intel-based Apple Macs running OS X 10. It is designed to work not only with Microsoft Internet Explorer but with all major Web browsers, and Microsoft is taking particular care to ensure compatibility with Firefox and Safari. There is even a version for Linux called Moonlight which is being developed as part of the open source Mono Project.

Silverlight is a powerful tool for creating Internet applications that go considerably beyond the capabilities of standard HTML and CSS. It supports a wide range of visual effects and has more than 30 user interface controls built-in, including not only buttons, list boxes and sliders but also a data grid and a calendar. It can display PNG and JPEG image files, and play back WMV, WMA and MP3 media with support for 720p HDTV display modes. Silverlight 1.0 was released in April 2007. The current version is Silverlight 2.0 (originally referred to as Silverlight 1.1) which is fully compatible with the original while offering many enhancements.

Inside a Silverlight application
You define the application that you want Silverlight to present using XAML (eXtensible Application Markup Language). This is based on the XML specification and was designed by Microsoft for initialising structured values and objects. The following XAML document declares a Canvas object containing a TextBlock, which is a lightweight element for displaying text:

Download complete code example

The visual elements that make up a Silverlight application need to be placed within a container object, and this provides a reference in which they can be positioned. In our example we are using a Canvas object measuring 300 by 100 pixels as the container and we have set its Background property so that it displays in a light blue color. Into this we have placed a single TextBlock object which will display the traditional ‘Hello World!’ text string in a Verdana font 30 pixels in size and 10 pixels below and to the right of the top-left corner of the Canvas object. Note the dot syntax that we have employed to reference properties of the Canvas object.

Actually displaying a Silverlight application within an HTML page need involve little more than a standard Object tag. At its simplest, the following renders our example within a browser:

Download complete code example

Here we have defined a space 300 pixels wide and 100 pixels wide in which to place the Silverlight plug-in, as defined by its MIME type. We have also defined a data attribute for the plug-in. In practice this is usually ignored but it can boost performance with some browsers (and note that the trailing comma is necessary as the attribute takes two parameters, the second having a ‘null’ value in this case). Finally, in the event that the client does not have Silverlight 2.0 installed, the anchor element displays a ‘Get Silverlight’ image from the Microsoft Web site which is linked to the page from which the user can download and install the plug-in.

The Silverlight plug-in takes a number of parameters but in this context the most important is ‘source’ which tells the plug-in where to find the application. In this case we are directing it to the file ‘silverlightapp.xml’. If this was to contain the XAML of our earlier example in simple text form, and both these files were uploaded to a directory on your Web server, then opening the HTML page would result in our ‘Hello World!’ application appearing to the top-left of your browser.

The XAML that defines the Silverlight application need not reside in a separate file. It can instead be defined within the page that instantiates the plug-in using a special script block. For example, we could insert the following immediately before the ‘pluginHost’ div block in our HTML page above, which also shows off some of the special effects supported by Silverlight:

Download complete code example

We reference this XAML block by changing the ‘source’ parameter for the Silverlight1 object as follows:

Download complete code example

The hash character indicates that what follows references a script block on the current page. The other principle difference between this and our earlier XAML example is that we have placed a Rectangle object on the Canvas. This is a Shape element, as is the Line, Ellipse, Polygon and Polyline, and as such supports a wider range of display options. The RadiusX and RadiusY attributes round the corners of the Rectangle, while the Fill property allows us to specify a Brush object. In this case we have used the LinearGradientBrush to shade the Rectangle in a graduated blend of yellow and light blue.

Most of the other parameters supported by the Silverlight plug-in can be ignored at this stage. However ‘minRuntimeVersion’ can be useful if you want to ensure, for example, that version 2.0 is installed rather than version 1.0. This can be accompanied by ‘autoUpgrade’ which means that an attempt should be made to upgrade automatically in the event of too early a version being found. There is also the ‘OnLoad’ parameter which can specify a JavaScript function that should be run once the plug-in is loaded (more on that later).

If you want to know more about the options available when instantiating Silverlight, then the article ‘Instantiating a Silverlight Plug-in’ from Microsoft’s MSDN Library is a good place to start.

Using PHP with Silverlight
For the PHP developer, the important point is that the source for the Silverlight object can be anything that returns XAML, and that includes a PHP script. This opens up many possibilities. For example, the following PHP page uses Silverlight to display data extracted from a MySQL database:

Download complete code example

Assuming this is part of the page ‘customers.php’ on our PHP server, then calling it with the following URL would cause Silverlight to display the name, city and postcode of the 134th customer in the database:

http://myserver.com/customers.php?ID=134

Having extracted the ID value from the query string, the code opens a connection to the database and then runs a query which gets the data for the customer specified and places it in the object $result. The function mysqli_fetch_array() extracts the data from $result into the array $row, from where it can be read and inserted into the XAML using the echo command.
This is far from production code, with little in the way of error checking, but it does serve to demonstrate how PHP can be used to generate a Silverlight application. For the sake of simplicity our example embeds the XAML within the page that instantiates the Silverlight control, but you could equally specify a PHP page as the source for the Silverlight control itself, as in the following snippet:

Download complete code example

All that is required here is that the page clients.php return valid XAML code that can be rendered by Silverlight.

Adding user interaction with JavaScript
The Silverlight plug-in exposes a JavaScript API that allows any XAML element can be manipulated by JavaScript, in much the same way that you would program against the HTML Document Object Model (DOM) exposed by the page. Furthermore, Silverlight boasts a wide range of programmable events which opens up many possibilities for user interaction.

For example, in the following we have added an ‘x:Name’ attribute to the TextBlock element. This allows JavaScript to access and manipulate the element using the findName function. We have also attached an event handler stating that the JavaScript function changeText should be executed if the user depresses the left mouse button while the pointer is over the Canvas element:

Download complete code example

We can now define the changeText function by adding the following to the page that instantiates the Silverlight object:

Download complete code example

This script locates the element we want to manipulate using the findName function, and then sets its Text attribute to change from ‘Hello World!’ to ‘Goodbye!’ when the Canvas is clicked. One important point to note here is that the JavaScript is interpreted by the browser and not by the Silverlight plug-in. The x:Name attribute provides a handle that allows the findName function to reach into Silverlight for objects declared within the XAML code.

You can use these techniques to respond to a wide range of events. The API allows you to respond to simple movements of the mouse, or when the mouse pointer enters or leaves an object. You can respond to the depression of the left mouse button, and when it is released. Most objects respond to key up and key down events as well, and there are facilities for determining the key combination. The TextBox control supports a TextChanged event, while the PasswordBox control supports a PasswordChanged event and the Button control supports a Click event

One of Silverlight’s great strengths is this ability to manipulate anything you declare in your XAML code through a coherent object model. Check out the Silverlight Developer Center in the MSDN Library for a comprehensive reference to the whole API.

Interacting with a PHP Web Service
Most of the techniques discussed so far work with both versions of Silverlight. However Silverlight 2.0 opens up new possibilities for client-side processing as it includes a version of the .NET Framework and the Common Language Runtime (CLR) which allows it to run client-side code written in C#, Visual Basic and many other languages. The code for such programs is compressed into a single ZIP file together with the XAML definition and a manifest (also written in XML). The result is given the file extension XAP and referenced through the plug-in’s source parameter in the same way as we referenced our XAML file in the example above. When the page containing the plug-in is opened by the client, the XAP file is downloaded and unpacked, and then the code is compiled and executed.

This opens up further opportunities for the PHP programmer as such applications can make calls to Web services, and those Web services can be defined in PHP. For such an application to work the service has to be SOAP 1.1 compliant, and you will need to define a clientaccesspolicy.xml file if the service comes from a different domain to the application. This is to prevent cross-site forgery (see the article Making a Service Available Across Domain Boundaries for more on this).

It is also worth noting that Silverlight 2.0 also includes the Dynamic Language Runtime (DLR) which supports IronPython, IronRuby and Managed JScript. These languages are being developed at Microsoft’s open source project hosting site Codeplex. For further details see Silverlight Dynamic Languages SDK.

Choosing the Right Tools
While not a requirement, Microsoft has released a number of tools that would be useful to the PHP developer looking to work with Silverlight. Microsoft Visual Web Developer 2008 Express Edition is a useful Web page designer with full support for CSS, JavaScript and AJAX. It can also be used with Silverlight Tools for Visual Studio 2008 to automate production of much of the infrastructure behind a Silverlight application. Both can be downloaded from the Microsoft Web site free of charge.

Microsoft Expression Blend 2 is a professional graphic design tool that outputs XAML, allowing designers to create attractive user interfaces and to automatically generate the code required by Silverlight for its display. Alternatively increased support from the community means there are a growing number of third party XAML editors out there as well.

Sitting alongside Blend 2 is Microsoft Expression Web 2. Aimed at the professional Web designer, this latest release introducing many features that have been designed specifically for the PHP developer. There are menu options for inserting common PHP snippets, including pre-defined form, URL and session variables, server side includes and other structures. Furthermore, Expression Web 2 will render the page in Design View as though all the code, including server side includes, were in a single file, allowing you to see your code in action without leaving the editor.

Expression Web 2 understands PHP which means it will colour code language constructs intelligently, and there is full support for auto-completion so that you can see what functions and parameters are available to you as you write the code. Expression Web 2 also includes the PHP 5.2.5 runtime which you can use locally as a development server.

So Silverlight has a great deal to offer the PHP developer – something that Microsoft is clearly recognising with its support for PHP in Expression Web 2. Trial versions of Microsoft’s Expression range are available for download.

[Main image by Pathfinder Linden]

The internet would never have become the phenomenon it is today without the web browser; the simplicity of the browser concept allowed the Web to grow rapidly. Developers just had to write basic text documents using a simple markup language (HTML) and the browser took care of everything. As websites became web applications developers still did not have to deal with the complex task of building client applications in the traditional sense: make it work in a browser and anyone can access it without having to install any new software, no matter what device (or OS) they are using.

While the browser makes life easy in many ways for developers it also throws up certain challenges. Major software companies such as Microsoft, Adobe and Google are now trying to address these challenges, albeit in different ways. This article will focus primarily on the option of building desktop applications, what the key drivers and considerations are, and how this may affect the future of the web browser.

What are the Challenges?

The recent launch of Google’s web browser is the latest shakeup in the browser wars that have raged for over a decade. Of course, competition has been good for the evolution of the Web, by bringing us new technologies such as CSS and Ajax and driving adoption of web standards, but there has been some negatives.

The inconsistencies between browsers have always been a major headache for developers. What works in one browser doesn’t always work in another or, worse yet, works differently. Many of the latest web applications now utilise Ajax for a superior user experience, but unfortunately Ajax libraries are so bloated to handle cross-browser quirks that they can cause performance problems. Even with the latest “standards compliant” browsers a lot of time has to be invested in making web apps work and look the same across IE, Firefox, Safari, Opera, and so on.

Today’s web apps are complex and, perhaps, pushing the browser to its limit. Other technologies are emerging to try and help developers build the next generation of Rich Internet Applications (RIAs): Flash has been around for many years, but now Adobe offers Flex and Microsoft have given us Silverlight. In the context of the web browser these are great options and will certainly challenge the traditional mix of HTML, JavaScript and CSS as the standard way of building web apps.

These new technologies are still running up against one of the age-old challenges: the more browsers do to protect the user from viruses, spyware and the like the more these security barriers limit a web app’s interaction with the user’s PC. Uploading your latest holiday snaps to Flickr is a painful process, primarily because anything running inside a browser is abstracted from the user’s desktop.

In addition, a number of social networks and services have run into the other major challenge with browsers: if the user does not have the browser open with the site loaded and are looking at it they have no idea what’s going on in their network. This creates a level of separation between the app and the user which is problematic if part of the application’s benefit is live data.

What’s the answer?

The problem of keeping users up-to-date when the browser is not running (or the app is not loaded in the browser) has seen a raft of third party desktop applications pop-up. For example, just look at the array of desktop applicationss for Twitter (Twhirl, Twitterific, Snitter, Tweetr, Twitteroo), FriendFeed (AlertThingy, Sobees, Feedalizr) or Facebook (FizzBoost, Facebook Desktop Client). These are just a small selection from the vast number out there.

These have been made possible by, firstly, the growth in web apps providing developers access to their functionality via APIs and, secondly, by the increased ease of building desktop applications. While developers have been focused on the Web (browser) as the main app platform the major vendors have been working on ways to make traditional desktop application development faster and more accessible. The latest and most popular of these is Adobe’s AIR technology which allows developers to use the knowledge and skills acquired from building web apps to develop cross-platform desktop applications. Using HTML, JavaScript, and CSS you can now build a fully-functional desktop application with AIR that runs on PC, Mac and Linux.

Desktop applications have a number of advantages over those that run in the web browser. They provide an “always on” method of communicating with the user. AlertThingy, for example, can hide in the system tray, but pops up an alert in the bottom right corner of the screen whenever a new notification comes in. They also have far greater access to the users’ system than anything running within a browser: uploading files suddenly becomes as easy as drag’n’drop; user data can be saved on the user’s machine; and the app can continue to work without an internet connection. These benefits can be put to incredibly powerful use in building feature-rich apps that provide a great user experience.

Providing users with a web-based interface and a desktop version with additional functionality is not a new idea, nor is it the preserve of Web 2.0 start-ups. Microsoft Outlook, with its companion web app version, Outlook Web Access, is a well-known example of this, having been around since 1997. Fortunately, the technology available to developers has come a long way since 1997: a benefit of Adobe Flex is that the exact-same app can be hosted within AIR or the browser; you just have to disable certain features in the browser. That’s both options covered with very little extra work.

The traditional difficulties associated with building desktop applications are done away with with technologies such as AIR. Not only can you use web development skills to build a desktop application, but the runtime also takes care of features like the ability to have the application automatically update to new versions. By building within a runtime, the developer does not have to worry about the awkward plumbing of desktop apps, such as minimizing to the system tray. Plus, Dreamweaver suddenly becomes a desktop development IDE!

Important considerations

There are some important questions to answer when deciding to build a desktop application. The first is whether it is really necessary. Many web apps work perfectly well within a browser and would not add any benefit for the user by having a desktop version. Building a desktop application just because you can is not a valid reason.

Next, however easy it is for a user to install an application there is still the question of whether they will. Some are put off by the idea of installing something on their machine and will choose not to. You are adding one more barrier to entry that does not exist with traditional browser-based web apps. Will the user see the benefits and that they outweigh any reservations they may have?

Finally, it is important that as an industry we do not go crazy building desktop apps. The swelling numbers of Twitter, FriendFeed, Jaiku, etc. desktop clients is already creating problems for users who do not want (or have space on their screen for) so many apps. When we released AlertThingy, we received a lot of feedback from users asking us to add certain features just so they could stop using one of their existing desktop apps and use AlertThingy instead. This takes us back to the issue above: will users want to install the app? The more apps they have the more challenging this becomes.

One area in which this can be addressed is that there are different types of desktop app. If your potential app is providing basic information requiring little user interaction or a small amount of screen space then Mac Dashboard widgets or Vista Sidebar gadgets are a great option. They are easy to develop (again utilising web technologies), lightweight and easy to install.

Is the browser a dead man walking?

I mentioned earlier Google’s latest browser, Chrome, which comes bundled with Gears. It is an attempt by Google to increase the install base of Gears and drive development of Gears-based apps. They are certainly highlighting other features of Chrome but Gears is most likely to be Google’s motivation for investing in their own browser, especially as it will benefit their own applications, such as Google Docs.

This situation is interesting because Gears attempts to overcome the issues discussed above, like Adobe AIR, but using the browser instead. This strategy could mark a new dawn for the web browser, which some believe will lead to it replacing the desktop OS (or at least rendering it redundant) but consider this: the Web is more than the browser, so much more, and with the growth of APIs and web-enabled platforms should we not look beyond the browser as the only client in future?

The first generation iPhone used the Safari browser as its application platform for third-party developers. This had limits and developers were desperate to be able to build native iPhone apps. Apple has now given developers that ability through the iPhone SDK. Many of these iPhone applications will be web apps (communicating with server-based applications) but not browser-based apps. We have seen a much more rapid growth in these types of applications compared to the previous Safari-based ones. And it’s not just the iPhone, surely a Java app on a Nokia phone is more powerful than anything running with the phone’s web browser?

As our TVs, cars and even fridge-freezers become internet-enabled the reach of the web app grows, but many of these devices will never have a browser. I have always found it strange that people think of what they see in the browser as the internet but not their email. As we move forward developers will be focusing on building internet applications, rather than browser-based apps, which can be accessed by a multitude of more powerful native clients on different platforms.

With Chrome joining IE, Firefox, Safari and others the browser war is set to rage on but the glory days of the web browser itself may be past.

Before we get into the issues that plagued the sites in our study, let’s quickly take a look at one that didn’t. “Why bother?” you might say. Well, if your site’s breaking in IE7, then this is the first problem you should attempt to rule out.

Put simply, if you’re using JavaScript or server-side logic to serve different styles to different browsers, you need to make sure that you’re not inadvertently excluding IE7.

How might you be excluding IE7? Well, perhaps you’ve written a script that applies one set of styles when your pages are viewed in IE6 and another set of styles when they’re viewed in all preceding versions of IE. This would have worked nicely in the past, but now that IE7 has arrived it will cause you problems. Why? Because while you’ve specified what would happen in IE6 and earlier, you’ve forgotten to specify what would happen in later versions of IE – later versions like IE7.

If you find that this is the cause of your IE7 problems, the short-term solution is simply to extend your script to target IE7 with a new set of styles. In the long term however, you might want to take a look at an alternative solution.

Browser detection is notoriously problematic: using JavaScript to sniff the browser will only work when JavaScript is enabled in users’ browsers, while parsing the User-Agent String (via JavaScript or server-side code) can prove to be even more unreliable due to “User agent spoofing“. In short, browser detection is not a very robust solution.

The only reliable method of detecting IE going forwards involves the use of conditional comments. This is the only method that Microsoft guarantees that it will support over the long-term. Conditional comments have been available since IE5 and, despite being proprietary, are valid forms of HTML/XHTML markup – other browsers simply ignore them since the syntax of these statements is based on regular HTML comments.

The disadvantage of using conditional comments is that they clutter up your HTML files and require you to keep multiple stylesheets (rather than a single centralised resource). Wouldn’t it have been better to have made conditional comments part of CSS and not HTML, Microsoft?

Examples

MSDN has more information about conditional comments here.

I have nothing to declare except my XML-ness

Having sorted out any IE-detection-related issues, the next thing to check is the first line of markup on your problem pages. The first line on both the Alliance and Leicester and Lastminute.com homepage – two of the most badly broken homepages found during our study – read as follows:

For the uninitiated, this statement is an XML declaration (not to be confused with an “XML prolog” which is the combined total of an XML declaration and a DOCTYPE declaration); its purpose being to tell the browser which version of XML your XHTML pages complies with and (optionally) to specify the type of character encoding you’re using.

The W3C says the following about XML declarations:

“An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents…”

So you don’t have to use them, but they’d like you to. And as a result of this “strong encouragement”, many well-meaning would-be standardistas have added them to their pages with the commendable aim of achieving the highest possible levels of compliance.

Unfortunately, several older browsers can’t handle XML declarations. In fact, they have a nasty effect on them. As Jeffrey Zeldman puts it in Designing With Web Standards, “after imbibing the XML element, they stagger and stumble and soil themselves, bringing shame to their families and eventually losing their place in society”. Some crash as a result, others display nothing. IE6 does something a little more subtle: it ignores your DOCTYPE.

As you know, browsers use the DOCTYPE to toggle between rigorous standards-compliance mode (called strict mode in IE) and fault-tolerant, backwards-compatible quirks mode (so called because it mimics the quirks of various old incompliant browsers that most old websites were designed for). In most modern browsers, a valid XHTML DOCTYPE (complete with full URI) results in pages being rendered in standards-compliant mode, treating your XHTML and CSS content in accordance with the relevant W3C specifications. And IE6 is no exception. Unless you stick an XML declaration in front of it.

In IE6 the DOCTYPE must be the first line in your XHTML file. If it isn’t, your request for standards/strict mode will be ignored and quirks mode will be used instead (Opera 7 does the same). This means that you get IE’s original (read: erroneous) interpretation of the box model and a number of other “features” that don’t align with the W3C specs.

In IE7 however, this bug has been fixed. IE7 therefore doesn’t care whether your DOCTYPE declaration is preceded by an XML declaration or not – either way, it gives you strict mode… and therein lies a problem. If your page starts with an XML declaration you’ll get quirks mode in IE6 and strict mode in IE7. You can verify this yourself by typing the following line of JavaScript into the URL bar of both browsers after your web page has loaded.

javascript:alert(document.compatMode);
	

In IE6, you’ll see a dialog box displaying the word “BackCompat”, meaning that it is in quirks mode. While, in IE7, you’ll see “CSS1Compat”, meaning that it’s in standards-compliant strict mode. This discrepancy explains the inconsistencies you’re seeing in the two browsers’ displaying of your pages.

How do you fix these inconsistencies? I’d recommend removing your XML declarations, so that your pages render in strict mode in both IE7 and IE6 – and then reworking your styles, so that your pages look identical in both browsers.

“Remove my XML declarations? Is that legit?” Yes. Firstly, they’re optional – see the quote from the W3C above – so omitting them isn’t a crime. Secondly, unless you’re part of a very small minority of developers, you probably aren’t serving your pages as XML anyway. Check the head of your document – do you see markup like this?

If you do, guess what, you’re serving HTML, not XHTML (actually, you’re serving HTML compatible XHTML1.0, but let’s not get picky), regardless of what your DOCTYPE says.

You’re only serving true XHTML if you see application/xhtml xml in place of text/html in your version of the above. And this isn’t recommended for most purposes (at least, it isn’t recommended for now) as application/xhtml xml isn’t supported by the majority of browsers. (IE, for example, will ask you if you want to save these types of documents, rather than displaying them as web pages).

Furthermore, newer browsers may opt to validate your markup if you include an XML declaration and specify a Content-Type of application/xhtml xml. This could be disastrous if parts of your pages are inserted dynamically from a content management system. As you won’t have control over the content in the CMS, you won’t know whether it’s 100 per cent XML-valid or not. And if it’s not 100 per cent XML-valid, the newer browsers will likely choose not to display it. (Let’s face it, in the real world you can bet your life it won’t be XML-valid – the combination of CMS and business user doesn’t often produce solid markup!).

If you’re serving your XHTML as text/html however, you can at least rely on browsers displaying your content as you intend (although if you’re going to stick with dishing up text/html, you may be better off slashing the X off XHTML and switching back to plain ol’ HTML – but that’s a discussion for another day).

“But wait!” I hear you say, “I can’t get rid of my XML declarations because I need to specify a character encoding!” Don’t panic. You can still get rid of the XML declarations, just update the Content-Type element in the head of your documents instead. For example, if you want to specify an UTF-8 encoding to keep your international user-base happy, simply insert:

Thinking outside of the (old) box model

If you’ve addressed the previous issues, and you’re sure that your pages are being displayed in strict mode in both IE6 and IE7, your problems might stem from IE7’s updated handling of the CSS box model.

The update is best explained by example. Imagine that you’ve created a box with a width and height of 100px. Now imagine that the content you’ve placed within it is wider and taller than 100px. What should happen? Well, in IE6, the box will automatically stretch to fit around the content (or at least it will as long as the box keeps its default overflow value of visible). This sounds like a good idea, because it looks messy when content bleeds across a box’s borders. However, this isn’t the behaviour prescribed by the W3C’s CSS2.1 specification (and with good reason).

The CSS2.1 spec says that the width and height that you specified for the box should be honoured at all costs if the box’s overflow property is set to visible (its default setting). If the content within the box is wider and/or taller – causing “overspill” – well shucks, you should have created a bigger box then, shouldn’t you?

Why does the spec recommend such behaviour? Well, automatically expanding boxes have a knock-on effect on the other elements placed around them. So if your 100px-wide box suddenly becomes bigger it will displace the elements around it. The result: a fractured page layout.

In ensuring that heights and widths are honoured where specified, developers are given complete control over their page layouts. If you want a box that’s 100px wide, state that in your stylesheet and you’ve got it. If you want one that expands and contracts in accordance with the size of its contents, leave its width set to auto and overflow set to visible and it’s yours. For even more flexibility, you can use min and max settings.

The release of IE7 sees IE’s box model updated to adhere to the CSS2.1 specification – thereby creating inconsistency between IE6 and IE7 in strict mode. So, if you’re finding that your content is bursting out from its containing box, this could be the problem. (It certainly played a part in breaking BHP Billiton and Teletext Holidays‘ homepages in IE7).

Filtering out the filters

A number of the hacks and filters used to target IE no longer work in IE7. These workarounds took advantage of various bugs and unimplemented parts of the CSS2.1 specification to either hide styles from IE while having other browsers apply them; or to apply styles in IE while hiding them from other browsers. Here are the ones that are affected:

The star html filter (aka The Tan hack)

The star html filter is used to apply CSS rules in IE, while hiding them from other browsers. It is most commonly used to address the aforementioned box model problems in IE5, IE5.5 and IE6 (Mac and Windows versions).

During our study, we found that sites like Woolworths, UpMyStreet.com and Lastminute.com were using this filter (as part of the Holly hack) to address the Peekaboo bug in IE6. British Energyand O2 also used it to address layout inconsistencies.

The filter works by exploiting a bug in the way that the older versions of IE interpret the “star” – or “universal selector” as it’s officially known. The CSS2.1 spec says that the universal selector should match all descendant elements in the document tree (think of it as a wildcard). Combining the star with html to make * html is the equivalent of saying p html, body html or div html (or indeed [any other html element] html). This is clearly illegal as html is always the root element in a document and as such can never be the child of any other element.

Most browsers recognise * html as illegal syntax and ignore it (along with its accompanying declaration block to boot). IE5, IE5.5 and IE6 however, ignore the star but parse all that follows, therefore considering * html the equivalent of html.

This bug has now been fixed, meaning that IE7 will ignore star html filtering in accordance with the CSS2.1 specification.

Examples

The following declarations are parsed in older versions of IE, but ignored in IE7.

* html {
	...
}

* html body {
	...
}

* * body {
/*This is also ignored in IE7 because the body element can never be a grandchild of the root element*/

...
}

An example from British Energy

* html #main {
	height: 98%
	}

The underscore filter

Like the star html filter, the underscore filter is also used to apply rules in IE while hiding them from other browsers. Unlike the star html filter, however, it only works in Windows versions of IE (not Mac) making it a little less flexible.

During our study, we found that Lastminute.com made use of this filter to address layout issues, as did Opodo.

The filter works by exploiting a bug in the way that older versions of IE interpret the underscore character. The CSS2.1 specification reserves underscores (and dashes) for vendor-specific extensions (aka “custom properties”). Thus, rules like _myprop: foo should be ignored by browsers, unless they implement their own proprietary _myprop property.

Most modern browsers follow this guideline. Older versions of IE, however, ignore the underscore but read the text that follows. Thus, they treat statements like _myprop: foo as the equivalent of myprop: foo (no underscore) and try to apply it as a style. As a result, developers could prefix any standard CSS rule – for example, width: 300px – with an underscore to make older versions of IE apply it, while keeping it hidden from all other browsers.

This bug has now been fixed, meaning that IE7 treats properties prefixed with an underscore as vendor-specific extensions per the CSS2.1 standard. As a result, the browser no longer attempts to apply statements like _width: 300px as CSS rules. (However, they still appear in the object model and can be queried via scripts.)

Examples

_height will override the preceding height rule in older versions of IE, but will be ignored in IE7

#promo {
min-height: 300px;
height: auto;
_height: 300px;
...
}

An example from lastminute.com

#homepage_search_category ul li.first {
_top: -2px !important; /*underscore hack fix for IE/Win :( */
}

The comment after property filter

Unlike the star html and underscore filters, this filter is used to hide rules from IE while having other browsers apply them. It only works in strict mode however (not quirks mode).

During our study, we found that Lastminute.com made extensive use of this filter to correct font size and layout issues. Opodo also used this filter to display form elements correctly in IE6.

The filter works by exploiting a bug in the way that older versions of IE interpret CSS comments. When these browsers encounter a comment – i.e. /**/ – placed after a rule’s property name, they choke and skip the value that appears thereafter, proceeding directly to the next line of code.

This bug has now been fixed, so in IE7 these rules are parsed in full and applied.

Examples

The following height rule is ignored by older versions of IE, but applied in IE7

.myclass {
height/**/: 300px;
...
}

An example from lastminute.com

td, th {
font-size:80% !important;
	font-size/**/:100% !important;
	font-size/**/:80%
	}

td, th {
	font-size:80% !important;
	font-size/**/:100% !important;
	...
	}

The child selector filter

The child selector filter is used to hide rules from IE while having other browsers apply them. During our study, we found that O2 and BP made extensive use of this filter to deal with box model inconsistencies.

Child selectors – e.g. html > body – are used to apply styles to elements that are direct children of other elements. However, despite being part of the CSS2.1 specification, they aren’t supported in older versions of IE and are therefore ignored.

Support for child selectors has been added in IE7, so these rules are now parsed and applied per the standard.

Examples

The following height rule is ignored by older versions of IE, but applied in IE7

html > body {
height: 300px;
...
}

An example from BP

html > body .effLoginContainer{
	padding: 5px 10px 7px 10px;
	background-color: #E7F7E7;
}

The adjacent selector filter

Like the child selector filter, the adjacent selector filter is used to hide rules from IE while having other browsers apply them. During our study, we found that Lastminute.com made use of this filter to align table data.

Adjacent selectors are similar to child selectors. However, while child selectors are used to match the children of an element, adjacent selectors are used to match siblings. Thus, the adjacent selector tr tr matches any table row that follows another table row and results in styles being applied to every row in a table other than the first. However, despite being part of the CSS2.1 specification, they aren’t supported in older versions of IE and are therefore ignored.

Support for adjacent selectors has been added in IE7, so these rules are now parsed and applied per the standard.

Examples

The following height rule is ignored by older versions of IE, but applied in IE7

head   body {
      height: 300px;
   ...
   }
 

An example from lastminute.com – used to align text to the right in all table cells in a row except for the first.

table.priceDestination tbody td   td {
	text-align: right
	}

The first child and adjacent selector filter (aka The Owen hack)

This hack takes the aforementioned adjacent selector filter and gives it a twist, by adding in the :first-child pseudo-class. Like the adjacent selector filter it is used to hide rules from IE while having other browsers apply them.

It usually appears in the form of head:first-child body, which means “select the body element if the body and head elements are siblings AND the head element is the first child of its parent element.”

Since the body and head elements are always siblings, the first part of this statement is true. And since the head element is always the first child of html (its parent element) the second part of the statement is also true.

Despite being part of the CSS2.1 specification, older versions of IE don’t support the first-child pseudo-class or adjacent selectors and ignore them wherever they are found.

Support for both the first-child pseudo-class and adjacent selectors has been added in IE7 however, so these rules are now parsed and applied per the standard.

Examples

The following rule used to hide the height property from Internet Explorer. In IE7 this declaration will be applied.

head:first-child   body {
height: 300px;
...
}

Note: we found no examples of the first child and adjacent selector filter during our study.

The solution?

Purists will recommend that you remove the need to use these types of filters by restricting your designs to only the CSS features that work consistently across all browsers.

This is fine in theory. However, in practice, clients’ demands often mean that we need to use CSS features that don’t work consistently across all browsers and then fudge them to make them appear as though they do. So when filters like the above stop working, we need to find something to replace them with.

The only reliable replacement for filters that target versions of IE are – yes, you’ve guessed it – Microsoft’s proprietary conditional comments. We’ve discussed them before so I won’t blather on about them again; save to say that here’s how they can be used to supply IE7 with one set of styles, while supplying older versions of IE with another – thereby performing the same function as outdated hacks that don’t work any more.

Final thoughts

The results of our study suggest that around 12.7 million websites are in need of a little TLC because of IE7. Maybe even more. However, this article has hopefully shown that the most common problems are easy to diagnose and not too difficult to fix. As always, we welcome your thoughts on the subject.

Like this article? Digg it!

Notes

Ian Hickson has more on the dangers of serving XHTML documents as text/html. Fadtastic has more on HTML vs. XHTML.

]]>