Most of the level 3 properties deal specifically with text layout (layout-grid, line-grid, line-break, word-wrap), but they’ve also prefixed some non text layout-specific properties including background-position-x & background-position-y and overflow-x & overflow-y.

One thing I was surprised to see was the amount of proprietary properties that they are continuing to support; in case you’re not already familiar with the functionality of these properties, I’d thought I’d come up with a brief intro for each of the most interesting properties (full property list):-

• -ms-interpolation-mode – Introduced in IE7, this property deals with smooth image scaling; this gives the author the ability to de-scale large images using CSS, without losing definition. The two keyword values that can be used are nearest-neighbor (using nearest neighbor interpolation mode) and bicubic (using high-quality bicubic interpolation mode). MSDN page
• -ms-filter – Probably the most used property on the list as it is currently the only way to emulate opacity in versions of IE. NOTE: MS have recognised that the former syntax used to emulate opacity was illegal, so they have no re-written the value.
• -ms-accelerator – As far as I’m aware, this is a brand new extension for IE8 and there is currently no specification from MS on it’s function.
• -ms-behaviour – This property allows a script to be attached to the element to which it is applied; the script that is specified in the property is saved as an HTC file (HTML Component). I’d hazard a guess that the most common purpose of this property is getting semi-transparency in PNGs working in IE5+. MSDN page
• -ms-scrollbar-* – This set of properties has been with us since IE5 and the property name is pretty self-explanitory; they’re used to control the colour of the browser window scrollbars.
• -ms-text-underline-position – Supported since IE6, this property sets the position of the underline that is set through the text-decoration property.
• -ms-zoom – sets the maginfication scale of an element.

I’m currently working on a large-scale Drupal site which includes a large number of modules, each with their own styleshee. As already mentioned, IE6 (and below) ignore any stylesheet declarations (using style or link elements) after 30 instances. Add to this the numberous non-module stylesheets (Drupal core & IE-specific) and you’re well on your to reaching IE6s limit.

So, what are the solutions?

Aggregate & Compress CSS within Drupal

Drupal recognises the issue of an additional HTTP request required for each module stylesheet. Fortunately this feature gets around the IE6 issue by aggregating all module and core stylesheets into one instance for each stylesheet media type defined. You can access this feature by logging in as an Admin and going to Site Configuration > Performance

However this method caches CSS too, which means it’s far from ideal whilst theming development is taking place.

Unsetting stylesheets within template.php and using @import

You can disable any module stylesheets from being included by unsetting them from within template.php. First get the stylesheet array by using $css = drupal_add_css() and then go ahead and unset all stylesheets (which will then all be linked to from within just one). Your snippet will look something like this:-

# get array of stylesheets
$css = drupal_add_css();
unset($css['all']['module']['modules/system/system.css']);
unset($css['all']['module']['modules/system/defaults.css']);
unset($css['print']['theme']['themes/mytheme/print.css']);

Now you would go ahead and use the @import rule to import your stylesheets through one of your theme-level stylesheets. The issue however, still exists that if you have more than 30 being imported within a single document, stylesheets that are <30 will be ignored. To only workaround is to create a new stylesheet in this case, specifically for importing the remaining stylesheets.

It was always a given that Beta 2 was going to be focused on delivering an enhanced and more seemless user experience, rather than concentrating on ‘under the bonnet’ enhancements like Beta 1 tried to deliver. However, on the surface of things, they appear to be very similar; one feature that I immediately noticed had gone (at least from the top toolbar) was the ‘Emulate IE7′ button- to me, this wasn’t much of a suprise as I simply could never see a practical use of that feature for end-users.

To coincide with this latest release, the IE team have also released a whitepaper detailing CSS improvments in Beta 2. For me, arguably the most major enhancement is support of the box-sizing property without the need for the -ms- prefix.

Beta 2 also supports the shorthand syntax for the filter property which can be used to emulate opacity – this must mean that IE8 don’t intend to implement the Level 3 opacity property.

Although I haven’t played around with Beta 2 for long, I have had time to put it through it’s paces on CSS3.Info’s Selector Test Suite; expecting a much better score than Beta 1s measley 14 out of 43, Beta 2 surprisingly only supports 13 selectors out of the 43.

This is only a quick write-up so will write a more concise post when I have some more time. Right, off to bed.

The call for supporting the Opacity property in IE8 stems from the team removing the proprietary ‘Layout’ concept, which renders the filter property useless (as this document explains), although there had previously been some talk of the longhand value working – this means there is currently no way to emulate opacity in IE8 (the first browser for 10 or so years that doesn’t support a way of emulating this)!!!

A few days ago now, the status on the bug ticket changed – it’d remained closed ever since I was given access to Connect, but its status had changed from ‘By Design’ to ‘Postponed’. Until I got my first copy of the IE8 Beta News pdf through, I had been trying to hunt down exact definitions of these statuses, but to no avail; however now, I have them (word for word):-

‘Won’t fix’ –

generally means we know that we will not be addressing the reported issue, ususally becuase it risks breaking the code in other, more serious ways or because the effort to fix the issue is not justified for the improvement.

‘By Design’ –

generally means the feedback you provided is, at this time, expected behaviour for Internet Exlorer

‘Postponed’ –

means unfortunately we will not be fixing this in IE8, but we will considering it for the next release of IE

Our only hope now is that it includes support for the filter property (that we all know and love), by re-engineering the property application itself. UPDATE:- They’ve announced that IE8 will be able to emulate Opacity using the filter property but only by prepending the property with the -ms- prefix.

Essentially IE8s implementation of the :hover pseudo class is buggy and whether it exhibits the expected behaviour is dependant as to what nesting level the element appears at.

Full bug description and test cases

Back to the subject in hand though; why did Facebook feel it was necessary to come up with a complete new iPhone UI? As Peter correctly suggested, the sites entire stylesheet could be incorporated into a Media Query based on max-width so that handheld devices of varying width (within reason) are dealt the same layout. Granted, the site does have a prominent theme replicating the behaviour and colour palette that iPhone uses, so although the URL can of course be accessed through any browser (Opera Mini in my case), there is an obvious mis-match between the theme of the site and the skin that Opera Mini uses (it’s also worth noting that Opera Mini fell flat on it’s face trying to render anything other than the logo, links the either side of it, and the navigation menu below that- I’m guessing this is down to the processing power of my Nokia E65 as opposed to the browser itself).

Also it’s interesting that the site’s in quirks mode, and check out the body > .fullScreen declaration- for some strange reason they’ve chosen to use a combination of min-height and max-height to emulate height!

As you can read if you visit the link, the article starts off by explaining what Acid2 is and the hype at Mix08 surrounding IE8. What I found particularly interesting in the article was a single comment from Eric Meyer; it reads, “CSS support in IE8 looks thus far to be very, very promising…”. He does actually mention that he’s “never had any inside track” from the IE guys, and granted, his comments did come before MS released a document outlining planned CSS support in the IE8 final release (which I talk more about in a recent post), but still…