Nice to see a re-design finally.

Send your feedback

http://www.neowin.net/news/main/09/02/23/internet-explorer-8-has-reached-rtm

There’s been absolutely no public or internal (within Connect) message from MS regarding the release date, so I for one am going to be extremeley annoyed with them if this is the case, since myself and others are continuing to file bug reports. Lets hope our work and time hasn’t been wasted.

After several months without a public build, we’ve finally got to the RC1.

They’ve fixed around 8 of the 16 of the bugs (that I logged) that were present in the pre-RC1. A list of the bugs that were fixed between the pre-RC1 and this latest build are below:-

As you can see they’ve fixed quite a few bugs in this latest build, but the list of bugs in the IE8 Final Build is getting larger and larger by the day; this means its certain that IE8 will not be fully Level 2.1 compliant, as I’ve said before.

I personally don’t have an issue with Microsofts property prefix being left off the filter property; either way, they don’t validate so I don’t see it as an issue. If anything I would prefer it if they left the prefix off as this would mean we would could retain some level of backwards compatibility.

What’s funny though is that this property currently works without this prefix – check my test case.

I’ve been fairly busy over the past couple of days adding bugs/spec violations in IE8 pre-RC1 ‘Partner build’ to my IE8 Bugs page. I’ve found an additional six; four or so, I would deem fairly serious.

Seriously Google, what is going on?

It’s been around four months since they released the browser for Windows, but still no word (that I’ve heard, anyway) on release dates. Around the time of the Windows version release, I eagerly signed up to their mailing list so I can keep up to date with Mac version development – but still nothing

I’d like to think I’ve gained a fair bit of experience and knowledge of the way the guys at Microsoft like to deal with bugs and the like.

The Software

Microsoft Connect is a clunky, archaic piece of bespoke software that can be a pain to use. First off, its seriously slow for bug tracking software which can leave you frustrated and wishing the IE team just looked at some specific external bug log pages instead of making you jump through hoops to get a bug logged. Secondly, I have a gripe with the Feedback landing page- I despise the bug ticket ‘tooltip’ which displays most of the meta data associated with the bug. Yes, it’s useful to have access to that information without having to wait 5 minutes while the bug page loads, but the performance of those tooltips is absolutely dreadful. Intuitively you have to hover over a link to display the relevant tooltip, but it depends in what area of the link you hover over as to how long it takes to appear; the worst situation (which I have experienced many a time is when the hover behaviour gets into an apparent never-ending ‘cycle’ where the cursor type changes from pointer to cursor and back again every half a second or so. And please Microsoft, get rid of that annoying tooltip fade-in effect – I don’t care for pretty Javascript effects when I’m logging bugs.

It’s all about the small things…

When you come to file a new bug, you’re presented with a number of irrelvant questions (relating to a CSS/HTML bug, for example); “What language of your browsers frame?” (what does that even mean?), “What is your language preference order?”, “How often does this happen?”, etc etc. I’d suggest to Microsoft that they tailor that form page based on the criteria given in some of the initial questions. It’s not a case of it being confusing; it’s just a pain to answer these mandatory questions.

Another one of my pet hates is to do with the individual bug page once you’ve filed the bug (including speciying a test case URL). Although you’re encouraged to visit this URL, for some silly reason it’s outputted as plain text, meaning you have to copy and paste the URL string into your browser – please, please Microsoft transform it into a link!

Once you’ve filed your bug, you’re unable to edit your description.

Communication between developers and the IE team (or lack of)

One of the surprises I came across when I first signed up was to do with the Opacity property ticket. I was never really expecting IE8 to support this property (and indeed they’re not going to be), however I was alarmed at the fact that they so quickly closed the ticket as ‘Closed by Design’, and then later ‘Postponed’. At the time of this status change, there was little to no word from the IE team as to what they were planning on doing in relation to Opacity (or emulating it, at least), hence why there were so many frustrated developers leaving comments on the ticket. Although the original author of the ticket wasn’t completely clear as to the meaning of the ticket, myself, and I’m sure most others were clear it related to the Opacity effect in general, not the actual property itself. This was apparently something that the IE team didn’t understand as can be read in a subsequent comment left on that ticket.

Back to my original gripe

Something I’ve stated in the past, is the fact that the IE team chose to stage a closed Beta program as opposed to an open one. I have no idea on how many testers Microsoft let in to the program, but one thing is for sure – it’s had a detrimental impact on the time it takes to find bugs, hence why we have layout bugs being shipped in a last-minute, closed RC1. Thankfully many people who weren’t able to join this program (for whatever reason) still posted links to either their own sites or sites they had spotted whilst surfing which include obvious layout bugs; this sort of participation is still a real help to us testers, since I’m more than happy to examine the bug and create a reduced testcase to send to Microsoft.

Recently, I’ve been noticing quite a few company TV adverts that don’t include their domain name; instead displaying ‘Search [keyword]‘ at the end of the ad to get their target audience to look on their site. To me, this strategy seems fairly risky; the majority of these adverts are time-limited and unless the SEOers involved have built up some good quality backlinks to the site (using relevant keywords in anchor text, and such), it’s going to be difficult for that site to get to the top spot – I would suggest that even second spot in the SEs for their most competitive keyword would count as a fail.

To be honest I wasn’t really expecting them to release this, considering they only recently posted detailing their release schedule from now until launch (which this Partner build wasn’t included in).

However, like a few others I was concerned that they weren’t going to release another Beta, so I’m pleased they’ve released this version which bridgees the gap between Beta 2 and the Release Candidate which should be with us by the first quarter of next year.

They’ve literally only just notified me of this private build, so I’ve only had time to run through the test cases for the bugs that I spotted and logged on my own IE8 Bugs page; after some initial testing, it appears they’ve fixed five out of the twelve bugs that I spotted in Beta 2.

It seems all I talk about on this blog these days is IE8; if you don’t have any interest in IE8, I apologise.

Upon checking my visit logs tonight, I discovered I was quoted on the ieblog referring to some things I mentioned in my initial post. Subsequently, Scott McIver from the IE team responded with some interesting comments.

In reponse to the ‘assumption’ I made where I described what telementary data the list will be made up from, Scott suggested that I had misenterpreted what will actually happen when in fact what will happen is, … a list of super-important sites is compiled (based on 3rd party survey data). We then look to see if users are having compatibility failures on those sites and, if they are, contact those sites and add them to the list. What I don’t understand is why they’re planning to break down into this ’super-important’ tier. Even with 3rd party survey data, it’s still a very subjective criteria; it’s an obvious fact that different usergroups will deem different types of sites to be most important – it’s a personal thing, at the end of the day. To me, it seems a no-brainer for them to base their list on sites (top 1000 or so) that the highest frequency of users perform a compatibility-switch on- this criteria seems far more relevant in this context.

Show me the list, show me the list

Perhaps a more effective means of finding out whether your site appears on this list, is to make it public (Update: if you want to find out the contents of the active list, you can navigate to res://iecompat.dll/iecompatdata.xml in your address bar), rather than waiting for Microsoft to email you about it? On top of this, Microsoft need to provide developers which a clear means of contacting them regarding removal of their site from the Compatibility View list – currently, I see no way of doing this.

Lack of CSS 2.1 support and it’s probable effect on Compatibility View

I’ve been pretty busy this weekend filing IE8 Beta 2 bugs (I’ve found 11 new (that aren’t logged on other prominent bug list pages) bugs in just one day). Just recently I’ve become acutely aware that the final release of IE8 won’t fully hit CSS 2.1 support, whether it’s because a spec implementation is buggy, or they’re not going to bother implementing a spec full stop. This lack of support got me thinking about the impact this will have on the users interaction with Compatibility View; even though many of the bugs I’m coming across are fringe cases or features that aren’t currently being used on a large scale (can be blamed on browser support, I’m sure), there is lack of support for (or bugs relating to) features that are commony used. These issues will of course result in a substandard page layout, and my concern is that end-users will be tempted to perform a compatibility-switch in the hope that it fixes the layout, when all it’ll do is either look the same or worse – OK, compatibility-switching won’t fix the lack of support for the print media descriptor when used with the @import rule, but you catch my drift.

Incorrect use of Compatibility View

I saw this post, in which we get a better insight into what the IE team were talking about when they said high-volume sites weren’t working for end-users with IE’s new standards compliant default. Scott describes how styles that should be specific only to IE7 (to work around it’s layout bugs) are also getting applied to IE8, on the popular MySpace.com site. For example, they have chosen to use the gte IE7 (greater that or equal to IE7) operator which of course means that IE8 applies these styles too. The underlying issue here then, lies with authors making irresponsible decisions relating to which operator a conditional comment uses not that these sites aren’t coded to be standards compliant. So, perhaps in hinds sight, Microsoft shouldn’t have implemented the greater than operator in the first place.

I can in fact, see this being a problem across all future IE versions; for example, when we get around to IE9 (which will hopefully not include Compatibility View), sites like MySpace will continue to break in the same way they’re doing now if those site authors don’t update the Conditonal Comment operators they’re using.

On a side note, I had a little chuckle when reading this post from one angry developer; based on his use of uppercase text, asterisks for emphasis, and generaly formatting, I’d hate to meet him in person on a bad day!

Aside

This random video made me laugh. I didn’t particularly want to create a whole new post just to showcase this, so I’ve stuffed it in this one