IE8 beta 2: First Experiences
- JavaScript: The Browsers
- The Web: The Browsers
My first experiences with IE8 beta 2 have been mixed. On the one hand, I like the fact that compatibility mode no longer requires restarting the browser. However, I've found it virtually impossible to tell when I have compatibility mode turned on or off. I've also found that once turned on, you do have to reload a page in order to turn it off again, because the button disappears.
Sam Ruby wrote about an improved namespace blurb that appeared about IE8 at a Microsoft site, which has since disappeared. In the post, Sam also mentioned that IE8 no longer supports CSS for elements it doesn't recognize, also detailed in a
bug
Anne van Kesteren linked in comments.
I went to check out the bug at Microsoft's LiveConnect with IE8 beta 2, but received an error in the page that I don't have permission to view the page. Puzzled, I also noticed that the page asked if I wanted to sign out of LiveConnect.
I had originally obtained a LiveConnect login in order to report bugs about Expression Media, which I was testing for my Painting the Web book. I figured that somehow my old account was interacting with the page in such a way as to make it inaccessible. I tried to delete cookies, in fact every kind of storage associated with IE8, but I still received the same page: I don't have permission to access the bug, would I like to sign out of LiveConnect.
I looked more closely at the IE8 Delete options, and noticed that there's another option I missed, Preserve favorite website data, with the following explanation:
Keep cookies and temporary files that enable your favorite websites to retain preferences and display faster.
This checkbox overrides the cookie deletion option when login information is stored. *I'm not sure if this option was present with IE8 beta 1, and I'm not sure I like it—one could easily think they've cleared all personal information out of a browser by deleting cookies, only to forget to uncheck the favorite site option, and leave critical logins still active.
Hakon Lie wrote about Microsoft's back stepping on standards mode. Microsoft had originally stated it would support standards mode by default with the first beta of IE8. Now, it supports standards mode by default on the internet, but supports the old IE7 non-standards mode by default for intranet accesses. The setting can be changed via a menu option, but the problem with this approach is that if you develop a web site internally and it works one way, it may break or work oddly once published externally, unless you remember to turn standards mode on when developing the page internally. This adds all new meaning to the term, quirks mode, as this really is quirky behavior.
IE8 does implement the new JSON object, though be forewarned: it treats single quotes as second class citizens. In other words if your application returns strings delimited with single quotes, your application will fail. The JSON with single quotes still works with eval, though, so you could end up with breaking behavior when you switch from one to the other. To be honest, I find this to be a flaw with the JSON "standard"—either JSON is JavaScript Object Notation, or it's not, and single quotes can delimit strings in JavaScript.
One new feature, or at least another feature I don't remember from IE8 beta 1 is that when you encounter a runtime error in JavaScript, IE8 now pops up a window with a note about a runtime error, and asks if you wish to debug it. I imagine this will only appear if you have developer tools enabled. The script debugger included with IE8 in beta 1 is still available in beta 2, and is one really nice feature in IE8.
Less nice, though, is Microsoft's non-support for DOM Level 2 event handling. There's also no need to go into details about how the browser doesn't support XHTML and SVG and MathML—Microsoft will never support XHTML, which should be a disappointing given now. In fact, it's unlikely Microsoft will ever support SVG, even if this gets included in HTML5. Some would say this will kill SVG. I disagree and believe that this will eventually kill IE. Not just the lack of SVG support: Microsoft's refusal to deal effectively with the issue of XHTML support, DOM Level 2 event handling support, and so on. Too many gaping holes in standards support, and too little commitment on Microsoft's part to truly be a standards-based browser.
On the other hand, IE8 does have improved support for CSS. It's now about equivalent to Firefox 2 in CSS support.
Lastly, if you're a Netflix Watch Now fan, be warned: IE8 beta 2 does not work with the Watch Now feature, no matter what mode you set. Do not install IE8 beta 2 if you use this feature.
All in all, beta 2 has the feel of being a rushed delivery. Not surprising when you consider beta 2 was released on the seventh anniversary of the release of IE6—a day some of us designated as IE6 EOL or
Uninstall day.
*The Preserve favorite option is new with beta 2, but is not working as described. It's preserving data for sites that are not on my favorites list. In addition, Microsoft puts its own sites on this list, automatically making data to them "saved" with this option.
Comments
Cute integration of favicons. :-)
JSON is intentionally a subset of ECMAScript. As an example, names (or keys) in ECMAScript don't require quotes at all if they match the production for identifiers, for example this might not produce what you might expect:
foo=1; bar='foo'; x={foo:2, bar:3}; x['foo']
The favicons is based on Simon Willison's exposed Google API, which converts icons to PNGs. I'm trying it out. If I keep the use, I'll wrap the Google API with one of my own, which will cache the generated PNGs. Or just implement my own, though my hosting company has disabled my ImageMagick PHP library. I am, after all, a good and RESTful neighbor.
Yes, I'm aware of JSON differences, but I have a feeling the single/double quote thing will generate more than one gotcha, as people move from eval to JSON2.js and/or IE8's et al implementation of the JSON object.
I know that JSON lacks the context, like you're showing with your example, and therefore it has to be a subset. However, given that, as far as I know, whether one delimits a string with single or double quote isn't context dependent, other than what the string contains, I have a hard time embracing this particular subsetting.
Some of the favicons are bigger than 16×16; forcing them to that size via the stylesheet does not help people reading through a feed reader… It would be nice if you’d include
widthandheightattributes in the feed.Also, it would look much neater if the baseline of the images was aligned with the baseline of the text, or even set a little lower. Which of course also won’t work for the feed, but maybe wrapping the images in
<sub>tags would emulate the effect well enough in that context.(Unfortunately, since feed content is generally heavily stripped before rendering, with CSS often axed wholesale, you need presentational markup. I have long pondered writing some code that will take a stylesheet and a piece of HTML and output a mix of its HTML input with presentational markup that achieves the stylesheet's effects. That way when I want just a little more than the default browser styles, I could still write clean markup for my site and style it with CSS, without having to live with terrible or even misleading display in aggregators.)
I know, the Microsoft ones have really popped out of the page.
If I decide to implement this, my own wrapper/version would make sure the converted images are set to the right size. It's just as easy to resize the buggers as it is to convert and cache them.
Not sure about the baseline, though. What I would need to do is see about adding a Drupal module that will pull out links, derive domains, and then add the images automatically. I could add formatting, too.
If I do a Drupal Module, it would then work only in my posts, not my feeds.
I like the favicon idea, but the last one (for Adaptavist) is odd. It uses the default Confluence favicon rather than the Adaptavist icon that I see on their site. A quick check shows that they don't use the naming convention of favicon.ico for their custom icons and they aren't stored at the domain root, presumably to keep the icons as part of the theme. I do wonder if this is an edge case that's worth solving or not, but I figured I'd point it out.
As for IE8, the fact that they have now added a third value for X-UA-Compatible when we started with only one means that Microsoft really do appear to be feeling their way through this. I'm no longer certain which value I'd want to use. I'll have to do some testing of the Compatibility View feature in conjunction with 'EmulateIE7' as opposed to 'IE8'. This really doesn't bode well for a solid and consistent product.
This last value for X-UA-Compatible seems to be it, knock on wood.
But no, I'm not sure what we'll end up with in the final version of IE8.
I still need to check to see if the company is not supporting opacity in any form with IE8. If not, that's going to force the new "compatibility" mode, as Microsoft terms it, leaving one to wonder: what's the point?
Citing you*: »I'm trying it out. If I keep the use […]«
Please don't. Icons in longer text disrupt the eye and lessens the ability to read since the lines are now not a flow of patterns of word but words interleaved with coloured blobs. Favicons or other icons inside of lines of text really hurt the readability.
(* … since I only get wellformedness errors with
blockquotein preview. Drupal seems to auto-insert an closing paragraph tag without opening it and throws unnecessary divs just for fun. No amount of blank line hex helps. I'd rather write full HTML. ;)Nail on the head. Lack of standards support will kill IE, not vice versa. The dominance of standards is witnessed by Microsoft's increasing support of them.
Microsoft only supports standards that doesn't compete with its own technology. I wouldn't say it's increasing support for standards.
Fair enough, but they didn't used to go that far.
I think you have to look at Google's Chrome anouncement today as a powerful boost for standards.
Your prior analysis is really based on a proprietary software model. MS would not change because selling software was their business.
For Google, software is what gets people to their business. It's the same for every web company. It behooves Google for software to become free and easy to reproduce. That makes it easy to get to them.
Microsoft will have a hard time fighting this. They use to be the prism through which the Internet was filtered. Now, they're just a plugin. See the comic book:
Microsoft reduced to a plugin
Enabling IE7 emulation for intranet sites but not for the web at large seems fine to me. It was also suggested by many people during the IE7 emulation echo chamber brouhaha a while ago. Directly exposing the exact same intranet site to the internet also does not seem like a very common scenario. And I’m not going to hold it against Microsoft that they’re trying to cater to the needs of their corporate customers, as long as that doesn’t mean shortchanging the open web. The chosen policy seems like the best possible compromise for satisfying both requirements.
Other than the fact that we seem to be stuck in a continuing cycle of web pages frozen on intranets, not only making it difficult for the web to move forward, but adding to the difficulty in getting other browsers into enterprises.
We're not going to know what MS will do with its "compatibility mode" until IE8 releases.
I can see the argument. OTOH, as long as the open web is able to move forward, I am pretty sure that it will drag the intranets along by sheer inertia, even if they continue to lag behind. And the rules are different enough for intranets that I think they are always going to trail the open web and are always going to have a browser vendor favouritism tendency. If they aren’t binding themselves to IE, they will bind themselves to Firefox – or if it’s an Apple-heavy shop, Safari. I certainly see this tendency to prescribe a browser in my day job. It’s simply easier for a corporate IT services dep’t to operate that way.
It's worth noting that they also have a feature that allows specific sites to be forced into compatibility mode using Group Policy, which would be a fine way for enterprises to ensure that their legacy Intranet apps go on working without holding back anything else.
Good point.
I can still understand if they are nervous about requiring even this much work of their customers, though. But it can certainly be made into a case that they follow up with IE8.5 relatively soon, where the default policy in all contexts be standards compliance. Anyone who still refuses to get with the program will then need to do the Group Policy dance.
This is quite analogous to the API deprecation cycles that we follow over here in the free software world, incidentally.
Hi Shelley,
FWIW, you can submit your bug reports on Expression Media to xmbugs@microsoft.com. We'd be grateful to hear what you've bumped into.
Kind regards,
Kevin Bier
xMedia team