D
David Mark
Nope. Same old shit.
As all of these libraries/frameworks had the same (bad) idea to use
CSS selectors as their primary interface (without a clue of what that
would take), they are all still struggling with their own overly
ambitious designs. It's not the browsers, it's _them_. They made a
stupid design decision and Web developers been paying for it for
years.
One type of selector involves attributes. This is the type none of
them can get working cross-browser. YUI3 takes the absurd step of
using their own broken attribute interface _internally_.
/**
* Mapping of shorthand tokens to corresponding attribute
selector
* @property shorthand
* @type object
*/
shorthand: {
'\\#(-?[_a-z]+[-\\w]*)': '[id=$1]',
'\\.(-?[_a-z]+[-\\w]*)': '[className~=$1]'
},
Look at that second one. Is "className" an attribute? Perhaps they
are confused from observing IE? Anyway, this is a ridiculous design,
whether they botched the name of the attribute or not. And this is
the _latest_ offering from YUI. You'd think that Yahoo would have at
least _one_ competent developer on this.
ISTM that YUI is open source now as well, so where in the world is
everybody? Piling huge table-based widgets on top of this wobbly mess
I imagine.
/**
* List of operators and corresponding boolean functions.
* These functions are passed the attribute and the current
node's value of the attribute.
* @property operators
* @type object
*/
operators: {
'': function(node, attr) { return Y.DOM.getAttribute(node,
attr) !== ''; }, // Just test for existence of attribute
//'': '.+',
//'=': '^{val}$', // equality
'~=': '(?:^|\\s+){val}(?:\\s+|$)', // space-delimited
'|=': '^{val}-?' // optional hyphen-delimited
},
Look at that first one. That seems like a job for a hasAttribute
wrapper. Unfortunately, this is what they have for that:-
if (!document.documentElement.hasAttribute) { // IE < 8
Y.Node.prototype.hasAttribute = function(attr) {
return Y.DOM.getAttribute(this._node, attr) !== '';
};
}
No help there.
CUSTOM_ATTRIBUTES: (!documentElement.hasAttribute) ? { // IE < 8
'for': 'htmlFor',
'class': 'className'
} : { // w3c
'htmlFor': 'for',
'className': 'class'
},
What a perfectly ridiculous inference. And why would they translate
property names to attribute names? It doesn't make any sense. Maybe
their docs indicate you can pass either "for" or "htmlFor", depending
on your mood? Regardless, this is not going to help much.
/**
* Provides a normalized attribute interface.
* @method getAttibute
* @param {String | HTMLElement} el The target element for the
attribute.
* @param {String} attr The attribute to get.
* @return {String} The current value of the attribute.
*/
getAttribute: function(el, attr, ieAttr) {
ieAttr = (ieAttr !== undefined) ? ieAttr : 2;
That didn't get passed
var ret = '';
if (el && el.getAttribute) {
It's a minor issue. but why check these every time?
attr = Y.DOM.CUSTOM_ATTRIBUTES[attr] || attr;
That just translates for to htmlFor, class to className.
ret = el.getAttribute(attr, ieAttr);
They even pass the IE flags. ISTM that will blow up in some
browsers.
if (ret === null) {
ret = ''; // per DOM spec
LOL. What "spec" would that be?
The ret variable could hold virtually anything at this point. In IE
< 8 and IE8 compatibility mode, it could be a string (possibly empty),
undefined, a number, boolean, function, etc. or even null. If it is
null, they change it to an empty string per some imagined "DOM spec".
What if it was an empty string to begin with?
In IE8 (and other quasi-standard browsers) ret will be a string
(possibly empty) or null. If it is null, they change it to an empty
string. That's not going to be good for anybody.
}
}
return ret;
},
So, yes. YUI is just as full of shit on basic DOM arithmetic as
GoogClosure, Qooxdoo, jQuery, Prototype and _all_ of the rest of these
"time-savers". Be fair, this probably the worst handling of
attributes I've seen yet.
It's plainly obvious that the author(s) were _very_ confused and
watching the results in various browsers but could never quite spot
the patterns. Of course, they should have just read the decade-old
specifications. How long does it take to read the section on
attributes? And there's an ancient MSDN article about the broken
MSHTML implementation, not to mention endless discussions on the Web.
Why don't the "Ninjas" notice this stuff is broken? IE6 came out over
ten years ago and IE7 didn't change much (and then there's that handy
compatibility button in IE8). Hard to say as they all preach thorough
unit testing and ostensibly have the best JS developers working around
the clock to ensure reliability.
For one, you can't test something you don't understand (and none of
these projects has come to grips with basic DOM manipulation). For
two, it's no _fun_ working in the basement. They all want to invent
and create "cool" widgets to show off their "genius". That's why none
of this stuff lives up to its billing. They always get _way_ ahead of
themselves and spend years trying to take in the slack. Meanwhile
site owners are bombarded with updates and their developers get the
idea that this stuff really is completely impossible to get right
without a huge library and the "luminaries" that come with it. It's
self-perpetuating futility.
I've tested all of these query-based "frameworks" thoroughly. I
started with simple attribute and property manipulation, as in this
exercise:-
http://www.cinsoft.net/attributes.html
.....and then took the next logical step (up one floor) to the queries,
which are the most lauded (and ostensibly simplifying features). Some
of these (e.g. jQuery) are little more than query engines.
Looking at each version of each framework in the various "major"
browsers paints a very ugly picture and proves that these projects
have failed miserably. All of the nitwit bloggers and Ajaxian
articles in the world can't change the facts. All of the plug-ins and
(generally inaccurate) documentation in the world can't make these
things useful. The idea that neophytes can "save time" with them is
laughable. All you have to do is cross-reference the related issues
reported in the forums (and wonder why the developers have no
answers).
So, there goes the theory that the massive Web concerns would never do
anything stupid, waste time and money, etc. Look at what Yahoo is
using on their own sites.
Can you spot the gaffes in these two quasi-related methods? It would
be faster to rewrite them.
/**
* Generates an HTML element, this is not appended to a document
* @method _node
* @param type {string} the type of element
* @param attr {string} the attributes
* @param win {Window} optional window to create the element in
* @return {HTMLElement} the generated node
* @private
*/
_node = function(type, attr, win) {
var w = win || Y.config.win, d=w.document, n=d.createElement
(type),
i;
for (i in attr) {
if (attr && attr.hasOwnProperty(i)) {
n.setAttribute(i, attr);
}
}
return n;
},
// IE throws error when setting input.type = 'hidden',
// input.setAttribute('type', 'hidden') and
input.attributes.type.value = 'hidden'
Y.Node.ATTRS.type = {
setter: function(val) {
if (val === 'hidden') {
try {
this._node.type = 'hidden';
} catch(e) {
this.setStyle('display', 'none');
this._inputType = 'hidden';
}
} else {
try { // IE errors when changing the type from "hidden'
this._node.type = val;
} catch (e) {
}
}
return val;
},
getter: function() {
return this._inputType || this._node.type;
},
_bypassProxy: true // don't update DOM when using with Attribute
};
As all of these libraries/frameworks had the same (bad) idea to use
CSS selectors as their primary interface (without a clue of what that
would take), they are all still struggling with their own overly
ambitious designs. It's not the browsers, it's _them_. They made a
stupid design decision and Web developers been paying for it for
years.
One type of selector involves attributes. This is the type none of
them can get working cross-browser. YUI3 takes the absurd step of
using their own broken attribute interface _internally_.
/**
* Mapping of shorthand tokens to corresponding attribute
selector
* @property shorthand
* @type object
*/
shorthand: {
'\\#(-?[_a-z]+[-\\w]*)': '[id=$1]',
'\\.(-?[_a-z]+[-\\w]*)': '[className~=$1]'
},
Look at that second one. Is "className" an attribute? Perhaps they
are confused from observing IE? Anyway, this is a ridiculous design,
whether they botched the name of the attribute or not. And this is
the _latest_ offering from YUI. You'd think that Yahoo would have at
least _one_ competent developer on this.
ISTM that YUI is open source now as well, so where in the world is
everybody? Piling huge table-based widgets on top of this wobbly mess
I imagine.
/**
* List of operators and corresponding boolean functions.
* These functions are passed the attribute and the current
node's value of the attribute.
* @property operators
* @type object
*/
operators: {
'': function(node, attr) { return Y.DOM.getAttribute(node,
attr) !== ''; }, // Just test for existence of attribute
//'': '.+',
//'=': '^{val}$', // equality
'~=': '(?:^|\\s+){val}(?:\\s+|$)', // space-delimited
'|=': '^{val}-?' // optional hyphen-delimited
},
Look at that first one. That seems like a job for a hasAttribute
wrapper. Unfortunately, this is what they have for that:-
if (!document.documentElement.hasAttribute) { // IE < 8
Y.Node.prototype.hasAttribute = function(attr) {
return Y.DOM.getAttribute(this._node, attr) !== '';
};
}
No help there.
CUSTOM_ATTRIBUTES: (!documentElement.hasAttribute) ? { // IE < 8
'for': 'htmlFor',
'class': 'className'
} : { // w3c
'htmlFor': 'for',
'className': 'class'
},
What a perfectly ridiculous inference. And why would they translate
property names to attribute names? It doesn't make any sense. Maybe
their docs indicate you can pass either "for" or "htmlFor", depending
on your mood? Regardless, this is not going to help much.
/**
* Provides a normalized attribute interface.
* @method getAttibute
* @param {String | HTMLElement} el The target element for the
attribute.
* @param {String} attr The attribute to get.
* @return {String} The current value of the attribute.
*/
getAttribute: function(el, attr, ieAttr) {
ieAttr = (ieAttr !== undefined) ? ieAttr : 2;
That didn't get passed
var ret = '';
if (el && el.getAttribute) {
It's a minor issue. but why check these every time?
attr = Y.DOM.CUSTOM_ATTRIBUTES[attr] || attr;
That just translates for to htmlFor, class to className.
ret = el.getAttribute(attr, ieAttr);
They even pass the IE flags. ISTM that will blow up in some
browsers.
if (ret === null) {
ret = ''; // per DOM spec
LOL. What "spec" would that be?
The ret variable could hold virtually anything at this point. In IE
< 8 and IE8 compatibility mode, it could be a string (possibly empty),
undefined, a number, boolean, function, etc. or even null. If it is
null, they change it to an empty string per some imagined "DOM spec".
What if it was an empty string to begin with?
In IE8 (and other quasi-standard browsers) ret will be a string
(possibly empty) or null. If it is null, they change it to an empty
string. That's not going to be good for anybody.
}
}
return ret;
},
So, yes. YUI is just as full of shit on basic DOM arithmetic as
GoogClosure, Qooxdoo, jQuery, Prototype and _all_ of the rest of these
"time-savers". Be fair, this probably the worst handling of
attributes I've seen yet.
It's plainly obvious that the author(s) were _very_ confused and
watching the results in various browsers but could never quite spot
the patterns. Of course, they should have just read the decade-old
specifications. How long does it take to read the section on
attributes? And there's an ancient MSDN article about the broken
MSHTML implementation, not to mention endless discussions on the Web.
Why don't the "Ninjas" notice this stuff is broken? IE6 came out over
ten years ago and IE7 didn't change much (and then there's that handy
compatibility button in IE8). Hard to say as they all preach thorough
unit testing and ostensibly have the best JS developers working around
the clock to ensure reliability.
For one, you can't test something you don't understand (and none of
these projects has come to grips with basic DOM manipulation). For
two, it's no _fun_ working in the basement. They all want to invent
and create "cool" widgets to show off their "genius". That's why none
of this stuff lives up to its billing. They always get _way_ ahead of
themselves and spend years trying to take in the slack. Meanwhile
site owners are bombarded with updates and their developers get the
idea that this stuff really is completely impossible to get right
without a huge library and the "luminaries" that come with it. It's
self-perpetuating futility.
I've tested all of these query-based "frameworks" thoroughly. I
started with simple attribute and property manipulation, as in this
exercise:-
http://www.cinsoft.net/attributes.html
.....and then took the next logical step (up one floor) to the queries,
which are the most lauded (and ostensibly simplifying features). Some
of these (e.g. jQuery) are little more than query engines.
Looking at each version of each framework in the various "major"
browsers paints a very ugly picture and proves that these projects
have failed miserably. All of the nitwit bloggers and Ajaxian
articles in the world can't change the facts. All of the plug-ins and
(generally inaccurate) documentation in the world can't make these
things useful. The idea that neophytes can "save time" with them is
laughable. All you have to do is cross-reference the related issues
reported in the forums (and wonder why the developers have no
answers).
So, there goes the theory that the massive Web concerns would never do
anything stupid, waste time and money, etc. Look at what Yahoo is
using on their own sites.
Can you spot the gaffes in these two quasi-related methods? It would
be faster to rewrite them.
/**
* Generates an HTML element, this is not appended to a document
* @method _node
* @param type {string} the type of element
* @param attr {string} the attributes
* @param win {Window} optional window to create the element in
* @return {HTMLElement} the generated node
* @private
*/
_node = function(type, attr, win) {
var w = win || Y.config.win, d=w.document, n=d.createElement
(type),
i;
for (i in attr) {
if (attr && attr.hasOwnProperty(i)) {
n.setAttribute(i, attr);
}
}
return n;
},
// IE throws error when setting input.type = 'hidden',
// input.setAttribute('type', 'hidden') and
input.attributes.type.value = 'hidden'
Y.Node.ATTRS.type = {
setter: function(val) {
if (val === 'hidden') {
try {
this._node.type = 'hidden';
} catch(e) {
this.setStyle('display', 'none');
this._inputType = 'hidden';
}
} else {
try { // IE errors when changing the type from "hidden'
this._node.type = val;
} catch (e) {
}
}
return val;
},
getter: function() {
return this._inputType || this._node.type;
},
_bypassProxy: true // don't update DOM when using with Attribute
};