Archive for August, 2008

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.

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.

will gradually be updated – it can be seen at the top of the right column on every page on the site

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.

[youtube:http://www.youtube.com/watch?v=lZ-s3DRZJKY& 415 415]

Recently, I accepted an invitation from the IE devs to take part in their ‘closed’ technical Beta program- essentially filing reports on any bugs I come across (and believe me, there are a huge amount of them already in Connect) in IE8.

It all started when I came across a post on the IEBlog, asking for potential QAs to lend their capacity to the IE team in reporting bugs in the very buggy Beta 1, and beyond. The catch? You had to justify to MS as to why you would be a good analyst, as opposed to MS justifying why we should bother investing our time into the project, in the first place. I’m sure you can imagine the wrath that ensued soon after the post was submitted; many people were angry (and quite rightly so) for the reasons I stated above – why should potentially many of the top QAs in the industry have to justify themselves to Microsoft which might be seen to benefit only IE in delivering an enhanced final product?

The only marginally sensible reason why Microsoft would take this step to limit (!!) the number of developers who would help make IE more stable/feature-rich would be that they’re afraid of too many nonsensical bug reports that either a) can’t be replicated, b) would become a duplicate bug report & c) don’t actually make any sense. However, this is exactly what Webkit, Mozilla etc have to put up with and you don’t hear them complaining; and with a diminishing market share, beggars can’t be choosers.

Now I’ve never had the ‘pleasure’ of using the Microsoft Connect interface, nor gauging the type of feedback that the devs give before, but one thing I’m quickly finding out is that major bugs seem to have a habit of being closed even when no resolution has been recorded. For example, there is a bug report that details the omission of Opacity (or the filter property for that matter); the report itself was filed under a month after the launch of Beta 1 and there are many comments as you would expect from developers, requesting that Opacity be inclued in at least the final product (although from this article it doesn’t look like they plan to support it). The problem is that MS shot themselves in the foot a little when it came removing the ‘hasLayout‘ concept from version 8; in order for the ‘filter’ property to work, the element that it is applied to must have ‘layout’, which is impossible when ‘layout’ has been removed! But anyway, back to the point in hand; the ticket itself has been ‘closed – by design’- after many Google searches for meanings to different bug statuses in Connect, I still haven’t managed to ascertain exactly what this status means. I would have felt happier if there was some half decent explanation from the team as to why the ticket was closed but there is only one response from them simply saying:-

Thank-you for this suggestion.
We will consider this in a future version of IE.

If people (including myself) are having to jump through hoops even to get a point where we can start posting reports, some decent communication from the IE team wouldn’t go amiss!