Monday, June 29th, 2009
Category: Browsers
, IE, Performance
Developers tend to tease MySpace for its look, but the insiders are incredibly impressed by some of the engineering behind the scenes (e.g. their internal monitoring tools are said to be second to none).
They have surprised us again with their new tool MSFast which is “a browser plugin that help developers to improve their code performance by capturing and measuring possible bottlenecks on their web pages.”
The IE 8 tools are getting better, but in general no one has been able to touch Firebug (and the new WebKit Inspector improvements) but this tool is actually plugin for IE! It captures a lot:
- Measure the CPU hit and memory footprint of your pages as they render on the client’s browser
- Review screen shots of the page while it renders
- Review the rendered HTML on each point of the page’s lifecycle
- Measure and show estimates of the time it takes to render each section of the page in different connection speeds
- Validate the content of your page against a set of proven “best practice” rules of web development
Review downloaded files and show download time estimation on different bandwidths
That is some impressive data, and great to be able to test on IE where it has been SO hard to do so in the past.
Thursday, June 18th, 2009
Category: Browsers, IE, Microsoft
There are some good engineers working to make IE a better browser. I don’t want to belittle their work, but I couldn’t let go the recent work of various marketing groups this week.
First up, we had the the chaps from down under try to buy downloads with 10 grand, ripping into other browsers along the way…. as they use all images and no type in their lovely page. I have found Aussies to be a hilarious bunch, but not so much this time? I can see how the idea would seem good in a meeting room…..
Michael Yoshitaka Erlewine quickly realised that tengrandisburiedthere.com wasn’t taken so built his fun retort for the Mozilla community.
Then we had the new “get the facts” campaign that showed an angry “we don’t suck like you think” angle:
Lately, there’s been a lot of talk about Internet Explorer’s speed, security, and adaptability. But many of the claims are comparing older versions of Internet Explorer to competitors’ newest releases.
These pages somehow manage to claim that IE is more secure, is the only browser with privacy features, is the easiest browser to use, has great Web standards support, fantastic developer tools, is more reliable, and customizable, and on and on. They even use their monopoly baggage to claim that all of those annoying “built for IE” pages of the past make IE more “compatible”. Oh, and obviously the performance of IE 8 is vastly superior to other browsers. Sure the “benchmarks” don’t tell that story, but that isn’t what matters. Of course, anyone who has USED THE DARN BROWSERS can get a decent feeling on performance.
IE 8 is a decent browser, much better than IE 7 and before it. However, it drives me nuts to see the marketing spin and bare-faced lies that come across here. It denigrates the work that the engineers are doing.
To finish up, I feel like I have to end with the third piece on IE this week:
Thursday, April 16th, 2009
Category: IE
James Edwards has a fun little list that dares to dream about life after IE 6. He gives us a list of 10 things that we can look forward to in that sunny time:
Use child selectors
No more having to define endless descendent rules to cancel out other descendent rules. With CSS2 child selectors we can specify CSS rules that only apply to direct children, not to descendants in general.
Make full use of 24-bit PNGs
No more blending images against different coloured backgrounds so that the edges have decent anti-aliasing. With PNG alpha-channel support we can use images with shadows, glows and other opacity effects, safe in the knowledge that all graphical browser users can see them.
Use attribute selectors
No more having to define type classes for inputs — things like <input class="text" ... /> — when we can address them with CSS2 attribute selectors like input[type="text"]. We can even use CSS3 substring-matching attribute selectors (supported in all modern browsers including IE7), which can be very useful for defining selectors that apply to a range of different attribute values, thereby reducing significantly the amount of code it takes to address groups of elements with similar class names (for example).
Use a wider range of display properties
Being able to use things like display:inline-block instead of float:left means no more endless float within float within float, or the slightly-dubious use of overflow:hidden, just to get blocks to clear properly. (Though I should point out, we had to wait until Firefox 3 for this one too!)
Use min-width and max-width
Although IE6’s implementation of width is very similar to the correct implementation of min-width, it’s not the same, and it doesn’t serve every purpose; and it doesn’t do anything about max-width. With the end of IE6 can come a new renaissance in block-layout design, with the greater flexibility that designers have been crying out for for years.
Throw away 90% of CSS hacks (and 90% of the reasons for needing them!)
No more worrying about bizarrely repeating characters, mysteriously invisible blocks, or frustrating double margins; with the end of IE6 comes the end of needing to be able to diagnose and cure such a large array of rendering bugs.
Add abbreviations that everyone can see
Although personally, I only use the <abbr> element and never use <acronym>, still it does occasionally irk me to remember that IE6 users won’t see the expansion, and bugs me even more on the odd occasion that I need to script for them (and can’t).
Trust z-index again
No more scratching our heads as we ponder why layer X is on top of layer Y when it should be beneath, wondering what we might have done wrong, only to remember that — d’oh — we haven’t done anything wrong, it’s a stacking context bug in IE6.
Save time and money
Significantly less time spent hacking means shorter development time and lower development costs.
Enjoy ourselves again!
Writing CSS will become the pleasure that it used to be. That is, until our expectations rise again, and IE7 becomes our nemesis …
But we still have to wait for CSS Counters, box-sizing, and decent JavaScript (and much much more…. like Canvas / SVG support!).
Hopefully the automatic update plan for IE 8 will kick this into gear.
Wednesday, April 15th, 2009
Category: IE, JavaScript
Tim Cameron Ryan has released a full, feature complete version of W3C DOM Ranges shim that adds support to IE, ierange. It goes further than other versions:
Ranges:
- document.createRange()
- startContainer, startOffset, endContainer, endOffset, commonAncestorContainer, collapsed
- setStart(), setEnd(), setStartBefore(), setStartAfter(), setEndBefore(), setEndAfter(), selectNode(), selectNodeContents(), collapse()
- insertNode(), surroundContents()
- extractContents(), cloneContents(), deleteContents()
- compareBoundaryPoints(), cloneRange(), createContextualFragment(), toString()
Selection:
Not yet implemented:
You can test this out on IE.
Thursday, April 9th, 2009
Category: CSS, IE, Performance
Web performance guru Steve Souders noted some time ago in his book that @import is harmful to web page rendering times, but today he elaborated on this claim in a longish blog post:
There are two ways to include a stylesheet in your web page. You can use the LINK tag:
<link rel=’stylesheet’ href=’a.css’>
Or you can use the @import rule:
<style>
@import url(’a.css’);
</style>
I prefer using LINK for simplicity—you have to remember to put @import at the top of the style block or else it won’t work. It turns out that avoiding @import is better for performance, too.
He shows that while always using @import by itself is actually okay, there are a number of scenarios where @import can jack you up:
- link mixed with @import breaks parallel downloads in IE
- using @import from within a LINKed stylesheet breaks parallel downloads in all browsers
- LINK blocks @import embedded in other stylesheets in IE
- @import causes resources to be downloaded out-of-order in IE
His conclusion:
It’s especially bad that resources can end up getting downloaded in a different order. All browsers should implement a small lookahead when downloading stylesheets to extract any @import rules and start those downloads immediately. Until browsers make these changes, I recommend avoiding @import and instead using LINK for inserting stylesheets.
See the full blog post for fancy charts and more detail.
Tuesday, March 31st, 2009
Category: IE, Microsoft
We mentioned that a new excanvas was released to keep up support with IE 8. Well, Louis-Rémi Babe has detailed his travails finding out what what changed in IE 8 VML land:
Although the VML specification hasn’t undergone any improvements or modifications since its publication back in 1998, Microsft development team felt like considerably changing the way their own standard should be handled:
- The namespace declaration has to take a second argument to be functional:
document.namespaces.add('v', 'urn:schemas-microsoft-com:vml', "#default#VML");
instead of simply:
document.namespaces.add('v', 'urn:schemas-microsoft-com:vml');
- The selector for the behaviour rules needs to be slightly modified (more information follows).
- For a standard compliance purpose, when setting dimensions or position of an element, the unit no longer defaults to ‘px’. It has to be explicitly specified
- It is no longer possible to create a VML element outside of the DOM:
var myFragment = document.createDocumentFragment();
myFragment.insertAdjacentHTML(’beforeEnd’,
‘<v:rect id=”myRect” fillcolor=”blue” style=”top:10px;left:15px;width:50px;height:30px;position:absolute;”></biv:rect>’
);
document.body.appendChild(myFragment);
This rect element will not be displayed! And don’t try to modify its CSS properties with the developer tool, you are likely to crash the tab or even the browser, if you’re lucky. Fortunately, there is an easy fix for this bug: you just have to copy the outerHTML of the element into itself:
var myRect = document.getElementById('myRect');
myRect.outerHTML = myRect.outerHTML;
- It’s no more possible to use % unit! This one is my favourite. The advantage of vector graphics is that they can be scaled without quality loss. Now tell me how you scale a graphic from which all components dimensions and position are set in pixels! You have to resort to using the onpropertychange event to recalculate one after the other those values each time you want to resize your graphic. But there is a lot of case where you simply can’t fix this bug. For example, if you had an rectangle in a div: the div has no dimensions and scales with its content, and you want the height of your rectangle to scale with the div. There was a time when it was possible to simply set the height of the rectangle to 100% (providing the position of the div is relative, of course). But it was probably too easy after all.
Remarkably, none of this change has been announced by the IE dev team, as far as I know. The only announcement made about VML can be found on a blog post
Thursday, March 19th, 2009
Category: Browsers, IE
You may have noticed that day 2 at MIX was IE8 day (compared to the Silverlight 3 day one) in that the puppy launched!
This is good news in that IE 8 is better than IE 7, which is better than IE 6. Maybe, with 6 being two versions back, we have more weight to get rid of the chap. However, even though Microsoft has recently claimed that IE 8 is the fastest browser, its legacy weight still shows for now, and the other browsers are sprinting ahead.
I have a sneaky suspicion that IE 9 is going to be different and a lot better (new team? got the old greats back? or are they on Azure?), but that is wild speculation on my part.
We had a lot of comments on the news today, and one person who will rename anonymous purely because I don’t know if he would like to be attached or not said this:
When you do your IE8 post, don’t forget to toss out a line indicating the writing-mode bug was not fixed. Their only CSS3 feature and they’ve now effectively prevented the entire web for using it for the next x years. Hilariously, they also tried to cover up the bug by marking it fixed and forcing me to open a new one with the same description.
I also count two regressions in IE7 compatibility mode that make it different from IE7. Kind of a headache for those counting on sending that header.
So, thanks for the better browser guys, and we can’t wait to see what happens next. Shortly we will have IE 8, Firefox 3.5, Safari 4, Chrome 2, Opera 10, and others….. and the Web will have nicer cars to drive around on it. Let’s build applications that take these cars on a decent joy ride instead of boring them in the slow lane.
Wednesday, March 18th, 2009
Category: IE, Utility
MIX ‘09 has kicked in and “The Gu” just had someone show SuperPreview something that does what we saw with Meer Meer.
SuperPreview let’s you do the same onion peel overlays to see differences across browsers, and you can have everything run in the server (same as Meer Meer). This means that you don’t need to run VMs with various browsers to get your testing in. On Windows and want to see what your app looks like in Safari Mac? No problem.
The demo also showed the nice visualization of seeing where DOM nodes actually are, allowing you to see how the CSS is different. Promising!
Monday, March 16th, 2009
Category: Canvas, Flash, IE
There is an interesting blog post* and demo code on Azarask explaining Flash Canvas as a solution for IE’s lack of support for Canvas:
How does FlashCanvas work?
FlashCanvas is modeled after ExplorerCanvas which means it is a turn-key solution for adding Canvas support to IE. You can code away, happily using open standards and then use FlashCanvas to forcefully and silently upgrade IE to also being standards compliant.
There are two main components in FlashCanvas: the base FlashCanvas.swf flash file (a mere 688 bytes), and the FlashCanvas.js wrapper. I’ve used the excellent swfobject.js to embed the Flash into the page.
The FlashCanvas.js file implements a fake-canvas object and converts all existing canvas element into a flash object. The javascript intercepts canvas commands and forwards them to the FlashCanvas.swf movie file using the ExternalInterface provided by the flash player. The flash movie clip then interprets the command and draws accordingly.
Aza originally thought that this would also solve the performance problems other fallbacks to VML have but found out that sadly enough this is not the case because of the lag between ActionScript and JavaScript via ExternalInterface.
Each call via the ExternalInterface is taking approximately 0.5 ms. Since we know the time it takes to call an actionscript method from javascript, we can deduce the amount of time it takes for Flash to render. For the example1.htm page it takes ~24 ms to render 20 anti-aliased lines. In Safari a call into actionscript takes roughly 0.4 ms — this is only the call time, it doesn’t include the time to render anything. For example1.htm a single “particle” calls actionscript 3 times with the commands: [lineStyle,moveTo,lineTo]; each particle takes 1.2 ms in JS-to-AS calls; to take 1 second to render the frame ~833 particles need to be rendered.
There are few more ideas in the comments to the article and this might be an interesting concept to take further. Somehow it seems ironic to go back to Flash to make IE render standards, but then again VML is proprietary, too.
* Hat tip to Scott Schiller for pointing out this older, but somehow forgotten post.
Friday, March 6th, 2009
Category: IE
Just when you started having fun with innerHTML, you discovered that on IE, various table-related elements can’t be modified with it. Ever wonder why? Eric Vasilik is the developer responsible for that “feature” of IE, and he came clean about it several years ago:
We never had enough time to implement such a feature. And, in order to deal with attempts to modify tables in such a manner, I prohibited the modification of tables with innerHTML and other methods.
An alternative to all this would have been to “hack” something up. For example, I could have checked to see if the innerHTML of a TBODY was being set to something which began with a “
“. Under these circumstances I could have prepended a “
” to the string, and then plucked the TR’s out of the resulting tree and replaced the contents of the TBODY with them.
Sounds simple enough until you have to consider all the variations. Like, what if the string to be parsed looks like “
…”. Pretty soon you start doing all the work the real parser has to do.
So instead of hacking up something very incomplete and possibly erroneous in many cases, I left the modifications of tables with innerHTML out of the product.
The full blog entry goes into a bit more detail and is fairly interesting. Also, be sure to check out the post on easter eggs in early versions of IE.
Thursday, February 19th, 2009
Category: IE
A new resistance in our fight against teh evil has begun in Norway:
Yesterday, one of Norway’s biggest commercial sites, finn.no started issuing a warning to all IE6 users telling them to upgrade their browsers. Today, a host of big norwegian sites are doing the same. The campaign to end IE6 usage is on!
Here’s their translated message:
Heads up: You’re using an older version of Internet Explorer.
In order to get the most out of our website, you can get a free update of Internet Explorer. If you’re using a work computer, you should contact your IT administrator.
And, here’s one of the warnings in context (from another site that added links to other browsers):
Ironically, the screenshot doesn’t exactly manifest cutting-edge design, but hey, we’ll take what we can get.
Will the campaign spread? Will it accelerate IE6’s decline?
Friday, January 30th, 2009
Category: IE
Some people are very excited to see the improvements that the IE team have made with IE 8 (and the hope that it will get some IE 6 users up up and away). However, others are not so happy. With IE 8 getting close to launch after the RC release, is it ready for prime time yet?
Michael Dayah (of the excellent ptable.com) doesn't think so, and he gives the plea to not rush ahead:
IE8 is lined up to be a disaster. I've submitted about a dozen bugs to the
IE8 connect, but Microsoft is marking some as won't fix and others are brand
new regressions with RC1. I know this really isn't your primary interest,
but I was hoping you could assist in a grassroots effort to get IE
development pushed back a few more months in order to avoid another decade
of disaster on the web.
Here are a few screenshots of the mess IE8 RC1 is making of ptable.com:
Writing-mode: tb-rl now stretches to ridiculous heights (bug).
Radio buttons can no longer be packed in with height or margin (bug).
IE7 compatibility mode introduces white lines between border-collapse cells (bug).
Then we have kangax talking about misbehaving IE 8 and how you can still kill it with:
JAVASCRIPT:
-
-
Element.prototype.cloneNode.call(); // or other Element.prototype methods
-
What do you think? Do you have more examples like this? How are you feeling about the rendering of your sites in IE 8?
Monday, January 26th, 2009
Category: Browsers, IE
Michael Calore of Wired has a writeup of the IE team "Ask The Experts" web chat from this week.
Here is the meat:
- The target for CSS support in IE8 is full and complete support for CSS2.1.
- The only CSS3 module in IE8 is writing-mode (for vertical text support). IE has supported this since version 5.x, so it will continue to do so.
- IE8 will not support CSS' border-radius, which is often used to make rounded corners without images. Microsoft's Chris Wilson confirms that border-radius support is "high on the wish list," though, and should make its way into the next release after IE8.
- There is no official roadmap for IE9, but native SVG support is likely.
- A new JavaScript engine is likely down the road, too. A user asked: "Almost all others browsers are now considering JavaScript compilation. Safari introduced SquirrelFish and last week SquirrelFish extreme in reaction to V8. Mozilla has also started working on ScreamingMonkey. Will IE9 have a new JavaScript engine?" The response: "We're certainly focusing heavily on improving Javascript, in IE8 and beyond. I'd expect to see great things here in the future."
SVG support would be great, and please give us canvas. Please, Chris. What can I write on Ajaxian to help the case? ;)
Thursday, January 15th, 2009
Category: IE
Adrian Bateman of the IE 8 team created a screencast showing the Access Control work that has been done:
I’m happy to announce that we have recently completed our support for the Access Control Check using the Access-Control-Allow-Origin header defined by the updated spec. This means that, in addition to the wildcard check (looking for *) that we supported in Beta 2, we also now support the origin URL check. This support will be part of the next public release of IE that Dean announced a few weeks ago.
I have recorded a short video that demonstrates how to use XDR and what this announcement means. It also shows how the Access Control framework is supported by other browsers allowing interoperable services to be called from your pages.
Wednesday, January 14th, 2009
Category: IE
I’m now pleased to announce that with the upcoming Release Candidate of Internet Explorer 8, we not only have a high-quality DOM prototypes implementation, but we’ve been able to change the getter/setter implementation to follow the draft ECMAScript 3.1 standard. While our JavaScript engine and DOM won’t have support for all of the ECMAScript 3.1 enhancements in this release, it does mean that web developer code written to add getters and setters to the DOM in Internet Explorer 8 will continue to work now and into the future, since that code will be based on web-standards.
I’m very excited about this new capability in IE8! To help you get started, I’ve written a few articles that provide an introduction to DOM prototypes and getter/setters (and the new syntax that will be publicly available in the upcoming release candidate build):
Responding to Change: Updated Getter/Setter Syntax in IE8 RC 1 Travis Leithead, IE PM.
To see the new API at work, you can check out an example:
JAVASCRIPT:
-
-
// Create a property descriptor object
-
var posPropDesc = new Object();
-
// Define the getter
-
posPropDesc.getter = function ()
-
{
-
var coords = new Object();
-
coords.x = parseInt(this.currentStyle.left);
-
coords.y = parseInt(this.currentStyle.top);
-
coords.w = parseInt(this.currentStyle.width);
-
coords.h = parseInt(this.currentStyle.height);
-
return JSON.stringify(coords);
-
}
-
// Define the setter
-
posPropDesc.setter = function (JSONString)
-
{
-
var coords = JSON.parse(JSONString);
-
if (coords.x) this.style.left = coords.x + "px";
-
if (coords.y) this.style.top = coords.y + "px";
-
if (coords.w) this.style.width = coords.w + "px";
-
if (coords.h) this.style.height = coords.h + "px";
-
}
-
// Define the new accessor property "JSONposition" on a new image
-
var img = Object.defineProperty(new Image(), "JSONposition", posPropDesc);
-
img.src = "...";
-
// Call the new property
-
img.JSONposition = '{"w":400,"h":100}';
-
// Read the image's current position
-
console.log(img.JSONposition);
-
-
Object.defineProperty( document.body, "secondChild",
-
{
-
getter: function ()
-
{
-
return this.firstChild.nextSibling;
-
},
-
setter: function ( element )
-
{
-
throw new Error("Sorry! This property can't be " +
-
"set. Better luck next time.");
-
}
-
} );
-
// Changed my mind: don't be so strict about throwing
-
// an error when setting this property...
-
Object.defineProperty( document.body, "secondChild",
-
{ setter: undefined } );
-
Anne van K blasts back wondering why IE didn't just use the defacto standard after all:
So Internet Explorer adding support for getters and setters sounds great initially, until you figure out they support them in a completely different and unique way, apparently as agreed upon with the other three browser vendors.
Huh? And this is somehow better for interoperability? I would love to know why TC39 made this strange design decision and why Microsoft decided to follow it in name of interoperability as it clearly leads to duplicate code short term and other browsers most likely cannot remove their “ancient” getters and setters support long term, which leads to bloat.
He then compares the implementations:
JAVASCRIPT:
-
-
// standard
-
foo={get test(){ return "foo"; }};
-
alert(foo.test);
-
-
// Standard
-
foo={};
-
Object.defineProperty(foo, "test", { getter: function() { return "foo" } });
-
Friday, January 2nd, 2009
Category: Browsers, IE
At a New Years Eve party, a friend help up a drink and toasted to his company deciding to discontinue direct support of IE 6 in 2009, and letting users know that the site may work better with IE 7 or another latest browser.
Then, Asa Dotzer puts up a chart of the IE 6 numbers:
Still far too high a percentage and enough to make you grown. Also, the last few pounds are the hardest to lose. The good news for me is that on most Web applications that I personally work, and definitely those that I work on in early 2009 will have much different numbers.
Maybe IE 8, Windows 7, and the great new browser war will help, or maybe some percentage is for lost computer souls.
Next Page »
