Internet Explorer 8 beta 1
Microsoft has released the first beta of Internet Explorer 8. I won’t give a final assessment of its standards support and whatnot until the final release, but here are some of my impressions on the beta so far:
- It’s really really slow. I feel almost like I’m using Amaya. In particular, the Web Devout site is nearly unusable because the heading backgrounds take forever to render (they are just tiled 2×1 alphatransparent PNGs).
- Switching to IE 7 mode requires a browser restart. That’s a little annoying, especially since it doesn’t gracefully restore your session like Firefox does during addon changes.
- It broke the Web. I took a run through Alexa’s top 20 sites (cue rant about Alexa’s methodology), and about half the sites had big glaring display glitches. Yahoo is busted up, CNN is bleeding content… even Microsoft’s own Live.com looks like it has seen better days. I predict that the Web is about to have a lot more meta tags.
- Web Devout’s headings are standing tall, but not very proud. It looks like IE 8 has a problem with negative margins in generated content. In fact, IE 8 seems to have lots of problems with generated content (which I pretty much expected). Other than that, it’s actually making a good effort at rendering Web Devout properly without any IE-specific rules that apply to IE 8. Still not up to scratch with the other browsers, though.
- IE 8 still fails 9 tests in the brief CSS test suite I made for IE 7 a while ago.
- Did I mention it’s really slow?
Keeping in mind what IE 7 beta 1 was like, I’m hoping IE 8 will improve a ton before the final release. But for now, the browser is too slow and buggy to actually use, and it doesn’t help web developers much because there will probably be a lot of additional changes before anything in the engine is final. I’ll dive into it more once Microsoft announces that it’s layout-complete.
March 6th, 2008 at 23:28 UTC
Hi David – a few comments:
1) this is an early beta. We do have some rough edges, most definitely. Remember, though, that we’ve built an entire new layout engine for standards mode content from scratch. You’ll see a lot of those rough edges smoothed out in future betas.
2) Breaking the web – yep, that’s the price of standards by default. The web getting a whole lost more meta rags- in the short term, possibly, but I think longer term, though, I think the benefits of being in standards mode will be worth it.
3) As for perf – new layout engine perf hasn’t been addressed yet, which is probably why it feels slow to you. Programmability perf has been improved, though.
Posted using Internet Explorer (Windows) 8.0 on Windows.
March 7th, 2008 at 00:07 UTC
Oh, I definitely agree that the standards-by-default decision is the best thing for the Web in the long run. It’s just a bit unsettling to see that *most* modern websites seem to have problems, and I have a feeling that a majority of those sites will simply use the meta element as a quick fix. But that’s life.
I think the alphatransparent PNG performance problem might have actually existed in IE 7. I just notice it more now since the negative margin issue causes the Web Devout headings to be so big.
Posted using Mozilla Firefox 3.0b on Linux.
March 7th, 2008 at 18:21 UTC
I have problems using the bugtracker, hope this will improve as well over time.
I just wanted to mention that a new bug appeared:
/* IEMac section \*//*/body {background:red !important}/**/is incorrectly interpreted (it wasn’t in IE7 and shouldn’t per spec).
Posted using Mozilla Firefox 2.0.0.12 on Windows.
March 9th, 2008 at 09:24 UTC
WebKit rules the universe.
Posted using Internet Explorer (Windows) 7.0 on Windows.
March 10th, 2008 at 09:58 UTC
I’ve tested IE8b1 too, on a design I’m making to replace my website’s current design.
OK, IE8 is slow – but then, that should be addressed soon.
What I found most unsettling though, was that :before and :after are still not well supported (I’m adding some to block-level elements and classes, with content:’ ‘ and style background; it renders well under Opera, with CSS2.0 (not 2.1) compliance under Firefox 2 too).
There are also problems with padding on positioned elements (I’m using a pseudoframe absolutely positioned WRT the body, which is set to take up the whole viewport no more no less), said padding causes shifting of the elements by as much as it has padding (but then padding is re-applied), this could be caused by the negative margins some elements it contains have, and the element’s size remains what it should be (it spills over).
There still seems to be problems with absolute/fixed dynamically modified elements (help bubble following mouse) impacting other page elements (see http://moneyshop.perso.cegetel.net/moneyshop and http://moneyshop.perso.cegetel.net/moneyshop/form.php for most problematic pages)
The pages are in XHTML 1.0 Strict, sending different MIMEtype and slightly different content depending on UA.
Posted using Mozilla Firefox 2.0.0.12 on Linux.
March 20th, 2008 at 03:17 UTC
I have tested IE8 too. And it made my site a real mess.
Some margins / paddings are discarded when placed dynamically. And a lot of other bugs.
It still has got a lot to fix. I would downgrade to IE7 or even IE6.
P.S. Safari 3.1 is also out. I think it added some spell/grammar-checker.
Posted using Safari 525.13 on Windows.
March 27th, 2008 at 09:27 UTC
Addendum to my previous coment: :before and :after are actually well supported in IE 8 beta 1, but just can’t handle images (I tried .GIF and .PNG), be it as background or as generated content. Positions (with solid colour backgrounds and/or borders) do work well.
About margins: it appears that IE 8’s layout engine is FAR from being ‘all new’ – element dimensions are computed once first in Quirks mode, then they are positioned, then they are resized again to be compliant with CSS box model. However, if there is an element positioned negatively WRT its parent, parent’s positioning goes boom. I get something similar in IE 6/7 on some edge cases or in page refresh flashes.
So, when Chris wilson says “Remember, though, that we’ve built an entire new layout engine for standards mode content from scratch.”, it’s bull: IE8 still has IE4’s engine with yet another load of bug fixes (good) and shims (bad!) piled on.
Posted using Mozilla Firefox 2.0.0.12 on Linux.
May 22nd, 2008 at 21:05 UTC
First a question to Mitch 74: How can you tell that IE8b1 calculates its dimensions in Quirks Mode first?
But yeah, there’s a testcase that shows an interesting IE behaviour: http://tjkdesign.com/test/ie8/links.asp
Anyway, an unrelated question to Mr. Webdevout: I wondered if there are any plans to incorporate Firefox 3’s Standards state into your tables (it’s an RC1 now) in the future?
Posted using Mozilla Firefox 3.0 on Windows.
May 22nd, 2008 at 21:15 UTC
Daniel: Soon. My work on Web Devout will be limited to weekends, but I intend to get on it as soon as I can.
Posted using Mozilla Firefox 3.0b5 on Linux.
June 20th, 2008 at 08:38 UTC
@Daniel: Simple, the elements are shifted on a distance equivalent to their padding.
Remember, in Quirk Mode a box’s size is considered to be its content’s size (a 100px box with 10px padding will actually be 120px wide) so that the box’s content actually has 100px to use, while Strict will define the box content to be 80px, + 20px (10px * 2) for padding = 100px.
What’s interesting in the CSS box model is that if you give a box’s position as top=10, left=10, its size can be computed right from this positioning. This helps if this box’s children are positioned, because in such cases padding isn’t taken into account – so you don’t have to compute around it.
Now, what happens in IE8b1 if you use Strict mode, and absolutely positioned elements with padding >0 ? If they contain children which are absolutely positioned, or using negative margins, whatever, then said element is shifted down and to the right by exactly the same amount of pixels you’ve defined for its padding – like it’s been shrunk!
Workaround: all your paddings should be set at 0, and you must get creative with your children’s margins… Yes, like we did to get the same rendering under IE 5 and 6 without resorting to CSS expressions!
So, what actually seems to happen is that, the element is sized and positioned according to IE4/5’s box model, then its content is redrawn according to the CSS box model – but the content box’s coordinates aren’t updated. Note that it somewhat ignores ‘bottom’ and ‘right’ properties again if ‘top’ and ‘left’ are specified (they are used once to compute the box’s content dimensions, but since said box is resized, they are disregarded later on).
Considering the same case could provoke a 100% CPU use in IE 7 if some fixed dimensions elements weren’t explicitly sized (constantly updating properties?), I’d say my reasoning holds.
Mitch
Posted using Mozilla Firefox 2.0.0.14 on Linux.
June 28th, 2008 at 16:42 UTC
@Mitch 74
I think in the first paragraph you mixed Quirks’ and Standards Mode’s box definitions.
I can’t really reproduce what you say though.
In IE7, if I position a box with padding inside an absPos element using top and bottom values, the box is two times the padding shorter in height. I think, that’s what you mean?
However, I wasn’t able to reproduce this in IE8b1. Do you have some code that reproduces this bug in IE8b1?
Oh, by the way, IE4 calculated the box model according to CSS, it just wasn’t able to do more comlex things like centering with margin: 0 auto;
The box model was changed to Netscape’s model in IE5.
Posted using Mozilla Firefox 3.0 on Windows.
July 10th, 2008 at 14:00 UTC
@Daniel: indeed, I did swap the two definitions, and IE4 did (try to) implement the correct CSS box model. My bad (I got mistaken due to the special way I worked around IE5/6’s inability to deal with top, bottom, left, right coordinates for the same element).
Revert all I’m talking about it the previous post (and now, the CSS3 inclusion of a box model switcher gets oh so inviting…).
Have a look at http://moneyshop.perso.cegetel.fr/moneyshop, you’ll get an idea of what I’m talking about (this early design managed to hit at least 3 bugs in IE8; you can also notice how the main scrollbar gets jumpy on some pages in IE 7; it’s a byproduct of my workaround for the 100% CPU use under this browser).
Mitch
Posted using Mozilla Firefox 3.0 on Linux.
July 11th, 2008 at 20:07 UTC
Doesn’t seem to be online.
Anyway, I’m actually looking forward to Beta 2, I’m sure it’ll be a ton better than the current one.
Posted using Mozilla Firefox 3.0 on Windows.
July 15th, 2008 at 16:22 UTC
Whoops, my bad:
http://moneyshop.perso.cegetel.net/moneyshop/
Posted using Mozilla Firefox 3.0 on Linux.
July 19th, 2008 at 08:36 UTC
Interesting, indeed.
I personally havent tested anything but simple testcases in IE8b1 yet. the engine was overhauled but is still full of bugs. I really cross my fingers for the final result.
Posted using Mozilla Firefox 3.0.1 on Windows.
July 21st, 2008 at 09:12 UTC
I guess the fact that I use a quite unusual layout (the main browsing ‘window’ is in fact a pseudoframe) that still works across most current browsers (IE5-6 included, through 2 well documented workarounds) qualifies as a ‘not-simple’ test case.
It’s also true that older versions of other browsers have trouble with it:
– Firefox 1.0 has problems with pop-up menus (there used a workaround, but I removed it); works fine with Firefox 1.5+
– Opera 7 displays it strangely (but it’s still usable); works and displays fine with Opera 8+
– Mozilla 1.0b2 can’t make Javascript work (due to ‘real XHTML’ use); see Firefox for Mozilla 1.7+
– Konqueror 3.x can’t scroll the pseudoframe with the keyboard, the mouse wheel or inner links (missing feature in its CSS layers management) only by clicking on the scrollbar; fixed in 4 and Safari.
Still, although I made a bad mistake in my descriptions of the box systems, do you agree that when I call bull on IE8’s engine being all new, but in fact still based on IE(4 or 5)’s Trident engine with another load of fixes (good) and shims (bad), I’m not completely off my rocker?
Posted using Mozilla Firefox 3.0.1 on Linux.
July 25th, 2008 at 15:04 UTC
I can’t really believe either that IE8’s standards mode is completely new. But who can tell in which ways the JavaScript/CSS/Parser and what not all systems are connected in IE? The hasLayout example I mentioned above makes me wonder wether it’s new or not. but it could be a dynamic style bug that’s connected with Scripting (remember hasLayout was meant as data structure). I think we’ll never know..
I guess beta 2 will show us what we can expect. It’s my main hope at the moment. though I’m getting critical when I hear they want to release IE8 this year..
Posted using Mozilla Firefox 3.0.1 on Windows.
July 28th, 2008 at 13:02 UTC
At what time is a piece of software considered new? When it’s been so extensively rewritten that the only remains of the old code are a few one-liners here and there, and routines so simple there isn’t any benefit in rewriting them?
It is also true that, due to the way IE interacts with the rest of the system, a bug we may feel comes from IE in fact comes from the scripting engine, or COM, or the XML parser…
But that would also mean that updating IE means rewriting a bunch of systems, and yet we didn’t see a Jscript upgrade (a Jscript-to-COM update maybe, but not ‘pure’ Js) in quite a while.
No, I’d say they got rid of the hasLayout problem, but not the underlying mechanism; hasLayout was switched to private in Uberstrict mode, and the added shims that redraw all parent boxes when a child box changes size, instead of doing the complicated but much cleaner rewrite of IE’s layout engine. Or maybe, that’s the target for IE8b2 – that or they’ll add yet another layer of shims to prevent the ’scroll back to top’ or ‘add padding to element’s margin’ bugs. If they do so, I’m pretty sure that someone out there will hit a brand new bug in the layout engine.
Posted using Mozilla Firefox 3.0.1 on Linux.
August 1st, 2008 at 14:40 UTC
Well, it was not the complete software but the rendering engine for standards mode. That’d mean the sole CSS engine.
They are also aware that old software is expecting something different. That’s why Windows should be able to run with IE 5.5 while websites are still IE8 viewed.
At least they got some DOM bugs fixed.
About hasLayout and the above statement. One can’t tell, which is right. Wilson states it’s a new render (CSS) engine from scratch, Mielke goes into your direction and says that hasLayout should’ve never been exposed and that’s why they removed it now. Removing hasLayout could mean a new engine as well as hiding it. Who will ever be able to tell.
Well again, in one or two weeks well see what beta 2 will look like.
Posted using Mozilla Firefox 3.0.1 on Windows.
August 14th, 2008 at 14:34 UTC
Mitch, you’re probably not further reading this. Anyway, I found something new (well old) in IE8b1.
I wrote a design with a link with a double border. On hover, the border-style changes to be solid.
In IE8b1, as well as IE 5.5 not only the style gets changed, but also the thickness of the border went from 3px to 4px..
Also, remeber the video when MS announced IE8 will pass Acid2? The video started from IE7 and incrementally improved on it’s way to IE8.
I don’t say that’s evidence, but it’s when the rendering engine is said to be written from scratch.
Posted using Mozilla Firefox 3.0.1 on Windows.
August 20th, 2008 at 13:22 UTC
Ah, I’ve found that video again and it actually starts at August 2007, so I can’t tell wether the starting point has anything to do with IE7’s engine or not..
Posted using Mozilla Firefox 3.0.1 on Windows.