the reason the first one works is because - as it stands - the $ (document.id) selector in mootools returns the actual element. this - in regular browsers - is identical to document.getElementById (), and the element element provides any and all of its attributes / properties for editing.
problems with NOT using .set:
- When mootools 2.0 aka MILK is released, it will not work, because it will be wrapped like jQuery, and the selector will not return the object (mootools becomes AMD, therefore, it will not change its own types - element, array, Number, String, Function (maybe !) - prototypes).
- You cannot tie it. with a set you can:
$('someid').set("html", "loading...").highlight(); , eg. - set is overloaded - it can set either a single property or multiplicity by passing an object. for example,
element.set({html: "hello", href: "#", events: boundObj}); - look at https://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L936-942 - you can pass an array as an argument and it will join it for you, this will simplify the work with multi-line strings and provides performance in IE
edit: the BBT fan has some open, separate topic: if the structure tries to block you / stop you from doing something that breaks the browser?
- if you want, you can add forbidden elements by changing this setter
Element.Properties.html.set = function() { var tag = this.get("tag"); ... check tag }; Element.Properties.html.set = function() { var tag = this.get("tag"); ... check tag }; - aren't mootools really?
mootools - by default - will not try to stop you from doing dumb shit [tm] - which is your responsibility :) try setting the element height to a negative value in IE, for example. should the Fx class stop you from doing this? Not. Should the setter prevent you? Not. A trace of constant checks to make sure that you are not breaking, means that all this will slow down work in critical cases such as animation.