Discussion in 'Javascript' started by David Mark, Dec 25, 2009.

  1. David Mark

    David Mark Guest

    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

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


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

    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
    David Mark, Dec 25, 2009
    1. Advertisements

  2. David Mark

    David Mark Guest

    On Dec 25, 3:53 pm, David Mark <> wrote:
    > Nope.  Same old shit.

    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. :)
    David Mark, Dec 26, 2009
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ken Asbury

    Competent VHDL Simulators?

    Ken Asbury, May 12, 2006, in forum: VHDL
    Ken Asbury
    May 15, 2006
  2. Sumit
    Dhaivat Pandya
    Feb 22, 2011
  3. YUI Custom Events Problem

    , Jul 13, 2006, in forum: Javascript
    Richard Cornford
    Jul 14, 2006
  4. Replies:
    Richard Cornford
    Aug 11, 2006
  5. merwin
    Thomas 'PointedEars' Lahn
    Sep 26, 2008

Share This Page