Posts Tagged ‘CSS’

The IE8 proprietary property (and vendor extension) lowdown

Whilst there was me thinking the IE team were going to be sticking rigidly to 2.1 compliance and nothing else, it was announced on the IE Blog that a number of proprietary and level 3 properties are going to be implemented yet again on an experimental basis (using the -ms- prefix).

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.

Removing all those pesky style element declarations in Drupal (to accommodate IE6)

Some of you may already be aware that IE6 has a limitation of reading only up to 30 external stylesheet declarations (when using either the style element, link element or @import rule). This figure may seem ridiculously high, and you might be thinking that an author with that many individual declarations doesn’t have a clue about organization, but this is what out-of-the-box Drupal serves you (Drupal.org related post).If you’re working on a fairly large Drupal site which employs a number of different modules, then you may well experience this problem. The issue is that many Drupal modules that have any kind of theming side of them include their own (sometimes very hacky) stylesheets; so when one of these modules is installed, Drupal adds a link to this stylesheet by means of a style element declaration – yes thats right, one for every module.

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.

IE8 Beta 2 delivers minimal CSS support enhancements (and loses support for at least one selector)

OK, maybe a bit of a haphazard title for a post (but it is very late in the day, and I really should be getting to bed) . Anyway, the anticipated release of Beta 2 was sometime this month (August) and it was finally released yesterday.

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 - 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.

Confirmed – IE8 will NOT support the Opacity property

I’ve been watching the status on the Connect ticket almost daily as this is probably one of the most popular tickets in the whole system, I imagine (along with this one, this one, and this one.

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.

Another bug bites the dust…

Found another a couple of days ago which was first highlighted to me in this ticket

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.

Facebooks iPhone-specific UI – unconventional but is it unnecessary?

If you follow CSS3.Info then you’ll notice my post last week regarding the UI that Facebook have come up with specifically for iPhone. You’ll also notice that some managed to misinterpreted the information I was trying to put across (your apology was welcomed, but in case any of you are still unclear as to the meaning behind my post, please read my subsequent comment).

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 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!

A possibly overzealous comment by Eric?

I was browsing the Guardian newspaper a couple of months ago (I meant to publish this post a couple of days after reading the article) and came across an article entitled, “Internet Explorer aims to embrace the web again“, so decided to take a closer look. Admittedly it was the first time I had read the Technology section of the Guardian, and considering the mainstream format that a lot of broadsheets have, was pleasantly surprised to find the article went into somewhat more depth than I had expect it would do.

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 ), but still…