A few months ago, I embarked on a work project that has ultimately left me with no time to keep on top of incoming mails, let alone bug reports from contributors. If you haven’t received a reply from me regarding your correspondence, then I could easily see how you may think I can’t be bothered to reply – rest assured, this isn’t the case at all.

I’ve had a truly great response from authors ever since I requested they write in about potential bugs they’ve found. For me to not respond to the more recent emails in an adequate time frame is completely unprofessional and I apologise profusely for this. I still have a complete archive of all emails sent to me, and I endeavour to respond appropriately to all of these in the coming month.

Some people may argue that since IE9 is now starting to be exposed publicly, that maintaining an IE8 bug list such as mine is worthless. I disagree strongly with this view. I like to think the list in it’s current form is providing developers with a much needed knowledge base that Microsoft Connect is lacking (filtering, clear UI, etc). My aim is to carry on maintaining the list into the near future, and for it to become a permanent resource to developers.

IE9, and associated bug reporting

Apart from reading the majority of IEBlog articles on IE9’s rendering capabilities, I’ve been completely out of the loop as to what IE9 has in store for developers when it’s finally released. You may be wondering, since I’m an IE MVP, why I wasn’t informed on a product group level; I don’t have an answer for you. There’s been absolutely no PGIs for Internet Explorer and the IE MVP newsgroup has been extremely quiet- so quiet in fact I’ve now removed Unison from opening at startup, and I now don’t pay attention to the newsgroups at all.

I for one was astounded after finding out that IE9 won’t be released for WIndows XP – limiting a browser version to certain platform versions is absurd on so many different levels. I do all my browser testing on my Macbook Pro and I have two VM’s installed (one for IE6/7, and one for IE8). I’ve decided to bit the bullet and purchase Windows 7 tomorrow so that I can test drive IE9 for the first time, albeit on ‘Platform Preview’.

In terms of IE9 bug testing, like with IE8, my aim is to create an initial list and would open up participation to authors that are inclined to do so. I see a far greater need to establish a prominent list of IE9 issues than with IE8, since IE9 attempts to include complete implementations of several CSS3 modules, that they haven’t embarked on before with IE8. For this reason, I can evisage there being far more bugs with IE9 than with IE8.

Coming back to outstanding IE8 bug reports from authors writing in to me, I envisage to respond appropriately to those in the next month or so, and to continue to invite authors to contribute to this ever-growing list.

Thank you for submitting your feedback on Internet Explorer 8. The information in this bug has been reviewed carefully by the team and will help inform future releases of Internet Explorer. We are now closing down the Internet Explorer 8 Feedback Program in preparation for soliciting feedback for our next version and as such, per the Microsoft Connect guidelines, all remaining bugs for IE8 will be resolved as “Postponed” for now. When the feedback program for the next release is ready, we will look at transferring this bug, along with any applicable status update.

I would certainly take this as a sign that the release of IE9 is approaching. To close the bug reporting system relating to a current browser version for any significant period of time, without a new version (reporting system or browser) being released soon after, would be ludicrous. On the other hand, it does make sense to transfer all bug reports for IE8 over to the reporting system for IE9, and by Microsoft doing this, it confirms there’ll be no interim browser versions, anyway. Hopefully Microsoft will open up IE9’s reporting system soon, as I currently don’t have anywhere to create new tickets!

This status message from Microsoft also ties in nicely with the upcoming date of MIX 2010 where it’s been confirmed that Dean Hachamovitch will be discussing the development of IE9. Dare I suggest that Microsoft will give us a definitive release date for IE9, or even better, release it there and then? If it’s not the latter, I’d hazard a guess that we’ll see a beta release within the next five months.

Initially discussed as a possible way to remove suppress whitespace textnodes between inline-blocks, the control itself would take the form of a pseudo element incorporating function notation taking a matching pattern as an argument – something along the lines of ::text(matching-pattern) – which would have the ability to match strings of text within an element.

In contrast to my own confused ramblings (which I subsequently retracted), the consensus now is that the pseudo element should be excluded from crossing element boundaries in order to match a constituent of the argument, which means the full range of CSS layout properties can be exposed to the pseudo element (dependant on DOM-based pattern matching). Otherwise, consider Tab’s example:

p::text("foo b"){ display:block; }
<p>foo <span>bar</span> baz</p>

The above would split the pseudo element in two, since part of it would cross into the <span> in order to match the pattern given as the argument, resulting in:

<p><text match="foo b">foo </text><i><text match="foo b">b</text>ar</i> baz</p>

Not only would this be quite-rightly unintuitive from an author’s perspective, but it would also be harder to implement (compared to excluding element boundary crossing) from a vendor point of view. Having said that, the former issue could be solved by providing a limited range of CSS properties, similar to that of ::first-line, although conversation is veering away from such a resolution.

The sub-topic of discussion at the moment is how to avoid one ::text() boundary from crossing another.

If you can take some time out of your day, it’s certainly an interesting read.

Authors have become reliant on either replicating a clearing markup element using generated content (borne from author findings), or have found that overflow:hidden|scroll|auto; applied to the parent, expands the parent’s margin-box to encapsulate the height of the child(ren). In fact, any property/value pair that can establish a new block formatting context (BFC) has the ability to do this. These pairs include:

• float:left|right
• position:absolute|fixed
• display:inline-block|table-cell|table-caption
• overflow:hidden|scroll|auto

Although there are a couple of areas in the spec that detail behavioral characteristics of BFCs, the crucial containment behavior can be derived from the Float specification

[...] an element in the normal flow that establishes a new block formatting context (such as an element with ‘overflow’ other than ‘visible’) must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space.

9.5 Floats

A host of potential candidates

Whilst the aforementioned properties are all able to clear child floats, there is a major difference with one property/value pair in particular in the way that it computes an element’s width.

Every property/value pair that has the ability to establish a BFC – apart from overflow:hidden|scroll|auto – irrecoverably alters a block box’s computed width by applying the ’shrink-to-fit’ algorithm. In theory, we could try to emulate the expand-to-fit computed width of an in-flow block box with something like:

display:inline-block; /* Establish a new BFC, but that applies shrink-to-fit to computed width */
   width:100%;
   box-sizing:border-box;
}

Whilst this would be a plausible solution in the presence of any horizontal padding values, horizontal margins would remain an issue, which leaves overflow as being the only real solution.

Exploiting a property for it’s side-effect

Since we’re hacking a property purely for the purposes of harnessing a side-effect of it’s BFC-establishing characteristic, we have to contend with it’s primary purpose; controlling the clipping of an element’s content when it overflows that element’s content box.

In the common case where an element (which has a floated sibling) overflows it’s parent and the parent is established as the containing block, one of the overflow mechanisms will be invoked; this is a problem if you require the overflowing content of the containing block to remain visible. The only solution in this case is to ‘revert’ to one of the more traditional workarounds involving placing a clearing pseudo element after the parent’s document tree content. However, this author-invented solution acquires the pseudo element and means it can’t be used for more appropriate presentational purposes.

What’s needed

The crux of the matter is this – we’re being forced to use hacks in order to contain floats. Whilst float is an arguably adequate layout model for controlling content position amongst siblings (images, text, etc), it’s inadequate as a fundamental layout mechanism.

We’ve already identified that one particular characteristic of a BFC is that it contains floats in the manner that we require, each of the properties also have their own primary behavioral characteristics. So what I think’s needed is a new control which has the primary purpose of float containment in the same manner as a BFC currently does:

'float-contain'
Value:       auto | contain
Initial:     auto
Applies to:  non-replaced block-level elements
Inherited:   no

Granted, there are modules in the pipeline that will supersede float as a layout tool, but these are all still Working Drafts and likely to remain as drafts for a while longer (as far as I know). However, establishing a control that can be used as an interim solution whilst we still have to use floats, would be advantageous.

You can follow the discussion on www-style here (NOTE: the thread spans multiple months)

To me, float-displace is another good example of a property (another being box-sizing) introduced in CSS3 that aims to ‘patch’ a logical failing present in previous CSS revisisons. The current behavior can be described as, the indented edge (caused by a margin value) of the in-flow element isn’t preserved between the margin-edge of the float and the content-edge of the in-flow element; this creates the following pit-falls:-

1. It’s completely counter-intuitive for authors who aren’t already aware of this limitation
2. The only real workaround to this limitation is to apply a margin value (which equals the indentation of the in-flow element) to the floated element, thus emulating this indentation.

From an author’s perspective, it’s perfectly acceptable to assume that the indented egde of the in-flow element will be preserved upon encountering a float.

I have no idea what the reasoning behind removing this property from the current revision was, but am keen to find out.

Believing what Microsoft had promised about layout not being in IE8, I didn’t feel it necessary to carry out a simple test which checks whether an element has layout, back when Beta 1 was first released. The test happened to have been included in a recent thread on WebmasterWorld, in which a contributor suggested that layout was indeed part of IE8. Upon running this test, I was absolutely astonished by the result I was seeing; the test proves that layout is definitely included in IE8 Standards Mode.  Upon checking the scope of the known layout triggers to test the completeness of IE8’s layout implementation, I observed that all (including IE7-specific) known trigger properties invoke layout.

Now that I’d identfied layout was indeed a feature of IE8, I needed to try and ascertain the scope of layout with regards to its effect on document styling.

After discovering this unwelcome addition, the first port of call was to go back over all the bugs I’ve documented to see if by triggering layout, a workaround could be established for each of the bugs, although it subsequently turned out this wasn’t to be the case. With this in mind, I’ve concluded that layout in IE8 is either:-

1. an implementation whose effects on layout style have been purposefully suppressed. This could have resulted from IE7’s codebase being forked to provide a base for development of IE8
2. an accidental implementation whose suppressed effect on document styling can be attributed to inadvertant links with IE8’s seperate browser/document modes

More confirmation

I then came across a thread at SitePoint relating to an issue where a rounded-corner JS library (Nifty Corners Cube) was wrongly invoking the shrink-to-fit computation for block-level elements in normal flow. One contributor pointed out a confirmed fix which is reminiscent of triggering layout; height:1%. This particular issue, which is discussed in more detail, was essentially down to Javascript triggering layout in elements whose layout value was initially set to false. Adding a triggering property before the Javascript was fired, fixed the issue since these properties are recognised in IE8 as being layout triggers.

In conclusion, I haven’t yet some across any direct issues, such as CSS-only layout anomalies, that have resulted from layout in IE8, and I’d be very surprised if any such issues arose because of it. The real issue here however, is that some existing web pages are now broken as an indirect consequence of Microsoft backtracking on what it had previously promised. A perfectly plausible rationale behind the train of thought from the creator of Nifty Cube Corners, could be that since Microsoft had promised not to include layout in IE8, he saw no need to change the display:inline-block layout trigger, as this property doesn’t exhibit the change in width computation in IE6 & 7 (as the change to the shrink-to-fit computation is ignored for elements that aren’t naturally inline-level). However, since IE8 includes a full implementation of display:inline-block and implements layout, the unwanted behavior (in this context) is exhibited. Another example of Microsoft going back on their word, and another example of the negative effect that their fabrications are having on authors…

Aside: the IE8 fix for Nifty Corners Cube

I’ve seen a fair few posts now where IE8 appears to adopt the shrink-to-fit computation for block-level elements in normal flow, which the Javascript from Nifty Corners Cube is applied to. A snippet from the distributed ‘niftycube.js’ file:-

function FixIE(el){
if(el.currentStyle!=null && el.currentStyle.hasLayout!=null && el.currentStyle.hasLayout==false)
    el.style.display="inline-block";
}

display:inline-block (which uses the shrink-to-fit computation) is being used in the context of a layout trigger if hasLayout is detected as being false. Since we’ve already established that IE8 includes an implementation of layout, this trigger will be applied unless layout is set to true before this script is activated.

A more suitable trigger would be a property that doesn’t affect the initial width computation of an element. To fix this issue, instead use a more suitable trigger such as overflow:hidden

IE8 Bugs

I’m discovering (and people are writing in about) bugs in IE8 on a fairly regular basis at the moment, although that regularity has obviously decreased significantly since the RTW version was released. Astonishingly, there’s still a significant (around 40-50%) percentage of bugs that are regressions from IE7, which I guess goes to demonstrate the insufficient regression testing program used in IE8.  More so, the nature of some of the reported bugs [1][2][3][4][5] go to demonstrate how quirky and broken IE8 actually is; these aren’t straightforward spec violations – these are some very serious quirks akin to the severity of bugs found in a beta release.

Why Microsoft still haven’t removed statements claiming full CSS 2.1 support from their PR material, is beyond me. It’s astonishing to think that Microsoft thought that they could get away with publishing these blantant lies; even if IE8 didn’t have any CSS bugs/spec violations (which is essentially near impossible in itself), we still don’t have an approved testsuite which is one of the criterion required to demonstrate interoperability.

CSS 2.1 testsuite

I recently became a contributor to the CSS 2.1 testsuite, and have been busy submitting many of the test cases used to demonstrate bugs in IE8. It’s of the upmost importance that every conceivable area of the specification is covered, so that we end up with a concise test suite – feel free to contribute, if you’d be willing.

New domain

Since idreamincode.co.uk was only ever meant to be temporary, I decided to purchase the domain name, jhop.me. I’ve always been a fan of acquiring an ‘exotic’ country-code TLD, so I decided to go for a .me. I’ve been careful to preserve legacy links, but if you spot a link that is broken, please get in touch.

Something very strange occured when I started viewing this site in the IE8 Candidate Release; for some reason, when I was moving from page to page, I sometimes managed to invoke Compatibility View. Thinking that this was just an issue with the CR, I didn’t bother investigating it. However this issue has crept up in at least one of the issues I’ve looked into, and less than two weeks ago, hidden in a post entitled, Compatibility View and “Smart Defaults”, we got clarificiation as to exactly what this behaviour is, and when we can expect it to affect us;

For the most part, we’ve removed assertions from our retail code. That said, there are particular code paths within the new layout engine where, should an error occur, the layout process can’t gracefully recover and we’ve kept assertions around these paths. In the IE8 Beta builds, encountering one of these layout “hard asserts” caused IE to display a blank page – the thought process being that it was better to show the user nothing at all than allow interaction with a corrupt or otherwise obviously incorrectly displayed page. We refined this experience further in the released version of IE8 by recovering layout “hard asserts” using Compatibility View. In other words, we believe that showing a page the way IE7 would have offers a better user experience than showing no content at all.

Compatibility View and “Smart Defaults” article on IEBlog

In short, when IE8 detects an error which, as we’ve seen, can be invoked by certain CSS property combinations, the browser will fall-back to rendering that document (and entire domain) in Compatibility View. Note however, that this process only applies when you don’t force Standards Mode using either the META declaration or HTTP Header. If however, you do force Standards Mode in this instance, IE8 will display a blank page.

Firstly, it’s quite astonishing to think that it’s possible to invoke complete page blankness simply by using a combination of CSS properties. What’s more, the latter option of forcing Standards Mode is now being used as a pre-emptive measure by authors who, one way or another, have misunderstood the information published by Microsoft and are afraid of their sites being rendered by users in Compatibility View. Ultimately, the combination of forcing Standards Mode and utilising certain CSS property combinations is likely to have some disastrous effects. Secondly, by not forcing Standards Mode, an author is inadvertently introducing the possibility of their entire domain being rendered in Compatibility View, for the remainder of that browser session. This is simply another of the many irrational decisions made by Microsoft throughout the development of IE8.

Aside

Bug Testing

First off, let me expell some myths – a) IE8 is not fully CSS 2.1 compliant, b) passing Acid 2 does not mean a browser is fully CSS 2.1 compliant and, c) creating and passing 7000 or so of your own tests also does not mean you’re fully CSS 2.1 compliant.

If you’ve been keeping track of my IE8 bugs page, you’ll see there’s been a steady stream of additions to the list – it currently stands at 51 CSS bugs. This is, to some part, thanks to folks who wrote in about issues they’ve come across, which has meant many more bugs have been identified and logged on Connect. If you’re someone who has taken the time to write in and I haven’t been in contact yet, please bear with me; I’ve had a lot on my plate over the past few months, but I assure you I’ll get round to replying to you, and filing the issue if neccessary.

I am however, surprised that Ian Jacobs or whoever owns the page would, first of all, allow so blatantly obvious generic keywords and, use a such a mix of capitalization and lowercase link text. Just an observation.