Wednesday, January 14th, 2009
Next IE 8 Release Candidate to have updated getter/setter support and DOM prototypes
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):
- Document Object Model Prototypes, Part 1: Introduction
- Document Object Model Prototypes, Part 2: Accessor (getter/setter) Support
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:
-
-
// 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:
-
-
// standard
-
foo={get test(){ return "foo"; }};
-
alert(foo.test);
-
-
// Standard
-
foo={};
-
Object.defineProperty(foo, "test", { getter: function() { return "foo" } });
-
Related Content:
That’s cool but it’s a bummer we can’t use it until 2015 when IE6 and IE7 is a thing of the past.
Wow! I hope there’s a Mac version! Just kidding, I just hope it can display pngs.
“Who cares” – before this hits the shelves IE has thanx to FF’s 40% market share at that time and Chrome’s 55% share at that time *zero adoption*…!
.
They could bend time and matter without me being interested…
.
Beside even if the above statements wasn’t true, I must agree with “Spocke” that because of MSFT not being able/willing to upgrade existing users of IE IE6/7 would still hold back the possibility to use that stuff anyway…
.
MSFT has finally managed to make IE become History … ;)
Or to rephrase, there is nothing MSFT can do to ever “save” IE. It might take some years, but just like Titanic – it’s already struck by ice and there is nothing MSFT can do to save it from sinking…
And still no native Canvas.
Whoa. Tough crowd! :-)
On the bright side, this now means we can fix any of IE8′s object model deficiencies, doesn’t it? That’s something I’ve been wanting to do since IE5!
Btw, I hate IE, too, and wish it would just DIE!!!!!11111 ;-)
Canvas are overrated.
.
But why do they keep the 30 css files include limit?
That is great but do they have the DOM event model yet?
Maybe I missed something, but I thought the getter setter syntax was supposed to be:
.
o = {
a:7,
get b() { return this.a+1; },
set c(x) { this.a = x/2; }
};
reference
.
Where in the new standard is it proposed to be getter and setter?
Coming soon to a javascript library near you:
Object.defineProperty(Object, "get", {
getter : function() {
return /*getter thing*/
}
});
In addition to my last post, the Working Draft defines the syntax under 11.1.5
.
Maybe I’m just blind. I can’t find .getter/.setter
nvm, Kris Zyp’s comment clarified it for me
As I wrote in IEBlog too, in my opinion, as long as we can normalize behaviors, welcome to getter: setter: implementation.
if(!Object.defineProperty)Object.defineProperty = function(Object, propertyName, getterSetter){
if(getterSetter.getter)
Object.__defineGetter__(propertyName, getterSetter.getter);
if(getterSetter.setter)
Object.__defineSetter__(propertyName, getterSetter.setter);
};
Easy? Just in time I implemented Object watch for every browser, so above code could be even more portable ( IE6 and others too, for example )
@Everyone: this was a MSFT comment in the blog linked to above by TNO…
“Note: The IE8 getter/setter documentation was out-of-date. The syntax in the builds is “get” and “set” for consistency with the object literal syntax, and we’re working to update the documentation–sorry about the confusion. (ES3.1 latest drafts have “get” and “set” for property descriptors). ”
So… there you go. Stop fricken griping like a bunch of children, or implement your own damn browser already. Yes IE lags the others, but get over your misguided “MS can do no right” BS… they’re working on it, which is clearly a Good Thing.
>>…implement your own damn browser already
.
Why would we do that? FF, Safari, Opera, and Chrome are all good enough.
@Nos: no current browser is “good enough”, hence continued competition and improvements for all.
They are good enough to dissuade me from writing my own browser.