Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > YUI--Competent?

Thread Tools


David Mark
Posts: n/a
Nope. Same old ****.

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

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
* @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
* @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

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 **** 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 IE. 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

.....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

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 ||, d=w.document, n=d.createElement

for (i in attr) {
if (attr[i] && attr.hasOwnProperty(i)) {
n.setAttribute(i, attr[i]);

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
Reply With Quote
David Mark
Posts: n/a
On Dec 25, 3:53*pm, David Mark <(E-Mail Removed)> wrote:
> Nope. *Same old ****.

Is it ever. It's like these half-dozen "major" libraries are all
waiting for their users to fill in the blanks for them (one at a
time). It's an endless Alpha test for software that is so poorly
conceived and executed that testing is futile. Furthermore, the
people monitoring the reports don't know anything (except how to patch
code until it seems to work).

This one is related to tabindex:-

The date is correct. It's not from 1999, but from this month.

It's hard to believe Crockford is involved with this mess. I imagine
all of their modules score well with JSLint (and the other "majors"
aren't even close in this regard). But the extra polish is a waste of
time on this clunker. Looking at the event module (among others), the
project is a major embarrassment for Yahoo. It looks like they hire
the homeless to write their JS.

I saw a comment recently that derided the development of Yet Another
JS Abstraction Layer, as if there are so many useful abstractions that
new ones are superfluous. Now what sort of abstraction for DOM
scripting that can't even _read_ documents would be considered
useful? None of the "majors" are even close on these basic operations
as 2009 comes to close. And the really amazing thing is that most
still rely on browser sniffing to "achieve" such abysmal results
(guaranteeing that rewrites will continue forever).

Read the blogs of the massively over-confident developers/marketers
and it is clear they believe they are doing cutting edge work. I
suppose if it were ten years ago... this project would still be a
waste of time.
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off