Posts Tagged ‘IE8’

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

#	Name	Description
1	Dynamic changes to counter-increment??		Test Case
2	Children’s counter does not take into account the scope of the parent’s counter, resulting in incorrect incrementation.	This issue goes against the self-nesting nature of counters, as defined in 12.5.1		Bug Ticket
3	Vertical scrollbar when using overflow:auto, and certain combinations of EM units for line-height and font-size for descendant elements			Bug Ticket
4	Mispositioned borders and outlines on elements when parent element has a negative text-indent			Bug Ticket
5	TABLE-displayed element (in normal flow) is rendered below preceeding floated element			Bug Ticket
6	Expanded :hover (and clickable, if A element) area (caused by Padding) of inline element not honoured
7	Bullets or counters within a list (OL or UL, with rtl direction) are affected by the highlighting text within their immediate succeeding element			Bug Ticket
8	Value of malformed width property is parsed

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.

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 . 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 (I’ve found 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 made me laugh. I didn’t particularly want to create a whole new post just to showcase , so I’ve stuffed it in this one

It’s been a while since I’ve posted about the Emulate IE7 Compatibility View feature.

My first gripe…

Granted, the position of the ‘Emulate IE7′ button in Beta 1 was ugly as hell, I can only assume that this button re-posiiton (and re-size) goes to show the apparent lack of thought that has gone into how users will identify with what this button actually does. Instead of a fairly prominent ‘Emulate IE7′ button positioned near the top right of Beta 1, the IE team have placed the new UI button for Compatibility View in an inconspicuous area to the right of the address bar. Chris Wilson has said, however , that they may move the button position based on user feedback. The underlying issue though is that the target audience of IE8 won’t have the first clue what all this fuss is about.

Compatibility View based on user feedback?!

The main reason for me writing this post is down to an article the IE team released yesterday relating to a new extension of Compatibility View, that will make the experience of defaulting to standards mode better for the end user. Essentially they collect the data, relating to what high-volume sites other users clicked the Compatibility View button on (i.e which TLDs most commonly prompt a user to manually switch to Compatibility Mode). A list of the TLDs that prompt the highest number of switches is compiled, and then users who download the next update of IE8 (or install the Beta of Windows 7) have a choice as to whether they want to opt-in to the aforementioned list of sites that should be displayed in Compatibility View (check out the ).

What prompted the IE team to implement this ‘community-powered’ solution?

Apparently, according to the article, high-volume sites such as facebook.com, myspace.com, bbc.co.uk, and cnn.com have been specifically flagged (presumably as a result of this collated user data) as not working correctly in the standards compliant default mode. As this user data has come from Beta 2 (and perhaps more worrying Beta 1?), which still has an alarming amount of rendering bugs still active, it’s highy likely that what end-users are actually seeing are Beta 2 (or Beta 1’s) rendering bugs, not as a result of a badly-coded website which relies on IE7’s quirky layout rendering.

Arguably, the most worrying situation for authors of these sites would be if MS decided not to refresh the data that the TLD list is based on, once the release candidate is distributed. Not refreshing this data (i.e wiping the data collected from the two Betas), would mean that authors of sites that appear in the ‘blacklist’ would presumably have to use the version targeting <META>/HTTP Header together with the newly introduced IE=EmulateIE8 value to remove their site from this blacklist – I presume this since there was a similar mechanism proposed back in August. So we are back to a similar scenario to the one where it was proposed Compatibility Mode be enabled by default, where even though a site is standards-compliant, the <META>/HTTP Header reset will need to be added by default to prevent these standards-compliant sites being viewed in Compatibility Mode.

I am still intrigued as to why sites such as Facebook, BBC etc were flagged, so I did a quick browse in Beta 2 and couldn’t find one rendering issuze on any the sites mentioned- I’d suggest that the apparent issues that end-users have experienced are down to performance (Javascript/AJAX) issues as opposed to layout bugs.

How does this new feature tie-in with the user-specific blacklist

The latest post doesn’t actually mention whether this ‘community-powered’ blacklist will work alongside the user-specific blacklist mention in the initial article on Compatibility View. I imagine that if they were to run in paralell, then the user-specific blacklist would overwrite the community-driven one.

Overall, an interesting concept I’m sure you’ll agree. And this after Chris Wilson thinks Gerard was overplaying how many people will push that [Compatibility View] button

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.

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.

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.

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!

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…