New Dojo Site--Most incompetent ever?

Discussion in 'Javascript' started by David Mark, Mar 8, 2010.

  1. David Mark

    David Mark Guest

    Have you seen the shiny new Dojo Toolkit site? Well, it's really more
    of a page that leads to other sites. There's the aforementioned (and
    jQuery-fied) Nabble forum and documentation and then there is the
    execrable foundation site. That last one is the worst of the bunch. If
    you don't get your resolution just "right" (i.e. matching whatever the
    developers envisioned as "normal"), you are screwed. Gives new meaning
    to the word incompetence.

    So the page has some pretty graphics and a headline that blares
    "Unbeatable JavaScript (sic) Tools". The pitch reads:-

    "Dojo saves you time, delivers powerful performance, and scales with
    your development process. It's the toolkit experienced developers turn
    to for building great web (sic) experiences."

    What experienced developers? What Web? Where? And scales?! I've yet
    to see a site out of this bunch (even a basic page) that doesn't
    download ten times what it should. A quick glance shows that the front
    (well only) page of the aforementioned Foundation site weighs in at:-

    Total HTTP Requests: 45
    Total Size: 454259 bytes

    So that's nearly half a MB to create one of the worst "sites" I've ever
    seen. In its defense, it does have some pretty graphics, but IIRC those
    account for only a fraction of the waste.

    Now, I've talked to these people. Every one of them really, truly
    believes themselves to be experts in their field (whatever that is).
    Specifically, they are supposed experts at HTML and CSS. And when I
    chastised one of them for using XHTML-style markup for every site, I was
    informed that he was not only an expert with markup as he had been doing
    it for x number of years (!) but was also a good enough JS "hacker" to
    write scripts for _Google_ (I didn't argue that point). :)

    So, this is one of their latest efforts. You be the judge.

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">

    Okay, mea culpa. This is my legacy. I'm afraid I have influenced this
    particular cargo cult in ways I could never have imagined when I was
    trying to teach them the basics of Web development. I beat them over
    the head with the faux XHTML so often that they finally did something
    about it. Of course, changing the doctype is irrelevant to _browsers_.
    It will make validation a bit difficult, but this bunch considers
    validation to be a "waste of time". In their mind, they are now using
    HTML strict (just like me!) Of course, they didn't bother to change the
    markup, which will still have to be error corrected by the browsers. :(

    <head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

    Well, at least that sort of matches now.

    <title>The Dojo Toolkit - Unbeatable JavaScript Tools</title>

    Bullshit. Give me any random person off the street and a few hours and
    I can produce a better JS programmer than anybody working on these
    "tools." The delusions at work here are truly unimaginable in both
    scope and intensity. Somewhere, somebody actually signed off on this
    shit and believed that reasonable people would buy it. The reality is
    that even the lowliest Web developers are going to howl at this whopper.

    <style type="text/css">
    @import
    "/dojango/dojo-media/release/1.4.0-20100212/dojo/resources/dojo.css";
    @import
    "/dojango/dojo-media/release/1.4.0-20100212/dijit/themes/tundra/tundra.css";
    </style>

    Right, well we'll skip those. Needless to say the themes are garbage.
    And they seem to be singularly focused on churning more of them out to
    compete with "juggernauts" like Cappuccino (another massive folly that
    has no shot of ever gaining acceptance on the Web).

    <script type="text/javascript">
    var djConfig = {
    'isDebug':false,
    'parseOnLoad':true,
    'baseUrl':"/dojango/dojo-media/release/1.4.0-20100212/dojo/"
    };

    Why would they need to explicitly specify that debugging is off?

    </script><script type="text/javascript"
    src="/dojango/dojo-media/release/1.4.0-20100212/dojo/dojo.js"></script>

    The kiss of death.

    <!-- Meta Tags -->

    Typical cargo cult comment.

    <meta http-equiv="content-type" content="text/html; charset=utf-8" />

    Haven't we met before? :)

    <meta name="keywords" content="The Dojo Toolkit, dojo, JavaScript
    Framework" />

    Useless and they apparently can't spell the language they are using (or
    their own name).

    <meta name="description" content="The Dojo Toolkit" />

    Very descriptive.

    <meta name="author" content="Dojo Foundation" />

    Having seen their site, I can buy that. But in reality, this is the
    work of one massively deluded individual.

    <meta name="copyright" content="Copyright 2006-2009 by the Dojo
    Foundation" />

    No worries. Nobody in their right mind would copy any of this.

    <meta name="company" content="Dojo Foundation" />

    The foundation is clearly cracked.

    <link rel="shortcut icon"
    href="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/favicon.ico"
    type="image/x-icon" />

    Just put the freaking icon in the root.

    <!-- CSS -->

    :)

    <link rel="stylesheet"
    href="/dojango/dojo-media/release/1.4.0-20100212/dtk/css/site.css"
    type="text/css" media="all" /><link rel="stylesheet"
    href="/dojango/dojo-media/release/1.4.0-20100212/dtk/css/print.css"
    type="text/css" media="print" /><link rel="stylesheet"
    href="/dojango/dojo-media/release/1.4.0-20100212/dtk/css/handheld.css"
    type="text/css" media="handheld" /><link rel="stylesheet"
    href="/dojango/dojo-media/release/1.4.0-20100212/dtk/css/aural.css"
    type="text/css" media="aural" />

    I won't go into those. They definitely copied me on the handheld and
    aural stuff. But like any cargo cult, they didn't know what they were
    copying.

    <!-- Init JavaScript -->

    :)

    <!-- Favicon -->

    :)

    <link rel="shortcut icon" href="" type="image/ico" />

    Another one. Different MIME type, empty href. WTF?! The only possible
    explanation is this was all just copied and pasted together until it
    appeared to "work." If these people did this to one of my enterprises,
    I wouldn't just sack them, I'd physically throw them out the nearest
    window. Barring a convenient window, I think I'd try to create one with
    the first one I could snatch up. :)

    </head>
    <body class="tundra">

    Redundant (as seen in the corresponding CSS).

    <div class="accessibility">
    <a href="#intro">Skip to Content</a>
    |
    <a href="#nav">Skip to Navigation</a>
    </div>

    Copying again.

    <hr class="hide" />

    Same.

    <div id="page" class="homePage">

    The camel-case class name must have seemed like a cool idea (of course,
    it isn't). And what sort of ID is "page?"

    <div id="header">
    <div class="container">

    Semantically bankrupt div-itis (of course). And what sort of class name
    is "container?"

    <span id="logo"><a href="/" title="Homepage">

    Homepage? What sort of word is that?

    <img
    src="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/logo.png"
    alt="Dojo Toolkit" /></a></span>

    The outrageously long paths for every asset are ridiculous.

    <ul id="navigation">

    <li class="download"><a
    href="/download/">Download</a></li>
    <li class="docs"><a
    href="/documentation/">Documentation</a></li>
    <li class="community"><a
    href="/community/">Community</a></li>
    <li class="blog"><a href="/blog/">Blog</a></li>

    </ul>

    Glad they learned something useful about semantics, but why are those
    classes and not ID's? Will there really be more than one of each per page?

    <form method="GET" action="http://www.google.com/search" id="search">
    <span>
    <input type="text" name="q" id="query" value="Search" />

    Ugh. Name/ID mismatch.

    </span>

    And what's with the funny span?

    <input type="hidden" name="sitesearch" value="dojotoolkit.org" />
    <button type="submit">Search</button>

    Yes, they like BUTTON's.

    <div id="resultbox" style="display:none">

    That's ridiculous on a number of levels. Why inline? How do they know
    that they will be able to reverse the effect of the display:none style?
    I guess I am asking too much of them on that last point, but these are
    professed "experts."

    <div class="googleheader"></div>
    <div id="googlesearch"></div>
    <div id="searchClose"><a>Close</a></div>

    Interesting use of the A element.

    </div>

    </form>
    </div>
    </div>
    <hr class="hide" />
    <div id="intro">
    <div class="innerBox">

    Another interesting class name.

    <div class="line">

    Again.

    <div class="unit size1of1 firstUnit homeIntro">

    Four more. And will other pages have a "homeIntro" class?

    <span class="version"><h1>1.4</h1> <span>Instantly Better Web
    Apps</span></span>

    Am I seeing things? An H1 inside of a SPAN? And what sort of top-level
    headline is "1.4?" No, these are not experts. These are not even
    competent beginners.

    <h1 class="introText">
    Unbeatable JavaScript Tools<br />
    </h1>

    Ah, another H1. And the BR seems randomly tossed in.

    <h2 class="introSubText">
    Dojo saves you time, delivers powerful performance, and scales with your
    development process. It&rsquo;s the toolkit experienced developers turn
    to for building great web experiences.

    As mentioned, not in this lifetime. :)

    <a href="/download"><img
    src="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/buttons/getDojoButton.png"
    alt="Get Dojo" /></a>
    <img
    src="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/browsers.png"
    class="browsers" />

    That's the shiny browser icons. No ALT text, which begs the question of
    why they are worried about such accessibility esoterica as aural style
    sheets (assuming they even knew what they were copying there).

    </h2>

    [...]

    <span class="redundant">&copy;</span> <a
    href="http://www.dojofoundation.org">The Dojo Foundation</a>, All Rights
    Reserved.

    [...]

    There's the proverbial smoking gun. The "redundant" class is defined in
    the aural style sheet to stop screen readers and the like from repeating
    the word "copyright". They definitely copied _that_. So how do you
    copy my stuff and come up with such a complete boondoggle? By not
    knowing the first thing about what you are doing.

    They actually didn't need my explicit permission to copy this stuff, but
    I do wish they hadn't fucked it up so badly. Would have behooved them
    to seek my input on its usage, that's for sure. ;)

    <script type="text/javascript">
    dojo.require("dtk.dtk");
    </script>

    That's a synchronous Ajax request, which blocks the browser UI until it
    completes. Judging by the performance of their servers so far, that
    could be anywhere from a second to forever.

    <script type="text/javascript">

    </script>

    That's the most sensible script on the page. :)

    </body>
    </html>

    Start over.
    David Mark, Mar 8, 2010
    #1
    1. Advertising

  2. David Mark meinte:

    [snip]

    Hey, they state

    "To select HTML elements in JavaScript, you can use the browser’s native
    DOM API, but they’re verbose and hard to work with...not to mention slow."

    And

    "dojo.query gives us a more compact way to do it, and it's often faster,
    particularly as we ask for more sophisticated kinds of relationships."

    Faster tahn native methods? Sounds like sheer magic.

    BTW: What happened to your involvement in tis project?

    Gregor



    --
    http://www.gregorkofler.com
    Gregor Kofler, Mar 8, 2010
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    Gregor Kofler wrote:
    > David Mark meinte:
    >
    > [snip]
    >
    > Hey, they state
    >
    > "To select HTML elements in JavaScript, you can use the browser’s native
    > DOM API, but they’re verbose and hard to work with...not to mention slow."


    LOL. How did I miss that?!

    >
    > And
    >
    > "dojo.query gives us a more compact way to do it, and it's often faster,
    > particularly as we ask for more sophisticated kinds of relationships."


    Oh sure, dojo.query gets faster as the queries get more complex. That
    sounds like their typical nonsense. As demonstrated, not only is their
    query thing slow, but it is also terribly inaccurate:-

    http://www.cinsoft.net/slickspeed.html

    Furthermore, it is programming by observation, using UA sniffing:-

    var n = navigator;
    var dua = n.userAgent;
    var dav = n.appVersion;
    var tv = parseFloat(dav);
    acme.isOpera = (dua.indexOf("Opera") >= 0) ? tv: undefined;
    acme.isKhtml = (dav.indexOf("Konqueror") >= 0) ? tv : undefined;
    acme.isWebKit = parseFloat(dua.split("WebKit/")[1]) || undefined;
    acme.isChrome = parseFloat(dua.split("Chrome/")[1]) || undefined;

    [...]
    root = root||getDoc();
    var od = root.ownerDocument||root.documentElement;

    // throw the big case sensitivity switch

    // NOTE:
    // Opera in XHTML mode doesn't detect case-sensitivity correctly
    // and it's not clear that there's any way to test for it
    caseSensitive = (root.contentType &&
    root.contentType=="application/xml") ||
    (d.isOpera && (root.doctype || od.toString() == "[object
    XMLDocument]")) ||
    (!!od) &&
    (d.isIE ? od.xml : (root.xmlVersion||od.xmlVersion));

    So, after all of that UA sniffing, they still couldn't make their
    "design" work (even fleetingly, which is the best you can do with UA
    sniffing) at all in one of the five browsers they "care" about. Well,
    they "care" about version 10. Anything less, screw 'em. Having run the
    SlickSpeed tests in a few versions of Opera 9.x, I can confirm that Dojo
    completely falls apart. The scary thing about that is that next year
    they'll stop "caring" about Opera 10. And this is what they recommend
    using in lieu of gEBI, gEBTN, etc., which work in virtually every
    browser released this century (and several from the last?) They are
    more delusional than I thought.

    >
    > Faster tahn native methods? Sounds like sheer magic.


    And they actually believe their own bullshit. Trust me.

    >
    > BTW: What happened to your involvement in tis project?
    >


    Well basically, the whole problem is that, to a man, they don't seem to
    grasp abstractions. Yes, I know. Any time you try to explain why
    something in the code needs to change, their response is invariably
    "show me where it fails." It's sort of like teaching children basic
    math with beans or apples or whatever. They can't grasp addition or
    subtraction without observing differences in piles of tangible objects.
    Same thing with these browser sniffers. Of course, their observations
    are necessarily dated, so that's why they consciously stop "caring"
    about last year's browsers and adjust their "designs" based on their
    observations of this year's browsers. It's an endless cycle of futility.

    As for me, I rewrote most of it last summer, but I didn't have time to
    explain... everything to them. They've never seen a grin without a cat?
    I say good luck with that!

    What I am doing is starting a premium support service for those stuck in
    Dojo (or jQuery or whatever BS library) hell. The launch will be part
    of the new cinsoft.net site. There are actually some Dojo users out
    there. They are typically found behind corporate firewalls (and are
    usually desperate for someone to explain where they went wrong). I'm
    just the guy to do that. ;)
    David Mark, Mar 8, 2010
    #3
  4. David Mark

    David Mark Guest

    On Mar 8, 5:23 am, David Mark <> wrote:
    [...]
    > root = root||getDoc();
    > var od = root.ownerDocument||root.documentElement;



    I think this particularly execrable bit of "programming" bears
    dissection. Just so happens I was recently working on my own XML
    query fork, so I am aware of the potential solutions (best one is to
    use a flag to indicate XML), as well as the various non-solutions
    floating around out there. This is one of the worst I've seen.

    >
    > // throw the big case sensitivity switch


    And WTF is "big" about it?

    >
    > // NOTE:
    > //              Opera in XHTML mode doesn't detect case-sensitivity correctly
    > //              and it's not clear that there's any way to test for it


    Stealth punt. Opera is right out. :) You can bet this ain't in the
    sales pitch (or even the documentation).

    >                 caseSensitive = (root.contentType &&
    > root.contentType=="application/xml") ||


    Does it get any more clueless than that? This check will identify
    _one_ type of XML document, as long as it is downloaded from a server
    (not parsed or loaded locally) in a browser supports this non-standard
    property (e.g. FF). Can't you just see the abstraction-challenged
    "coder" peering at Firebug and taking notes? :)

    >                 (d.isOpera && (root.doctype || od.toString() == "[object XMLDocument]")) ||


    So, per observations, they have correlated the UA string containing
    the word "Opera" + the presence of a truthy "doctype" or a toString
    result of "[object XMLDocument]" indicates case sensitivity. That's
    definite horse shit (and perhaps the source of the "punt" above). In
    Opera 10 (the only one Dojo "cares" about), it appears that any random
    page will produce a truthy doctype property:-

    window.alert(document.doctype); // [object DocumentType]

    >                 (!!od) &&


    So, uh, that expands to:-

    !!(root.ownerDocument||root.documentElement)

    ....which means that at least one of those objects would have to be
    present to get a truthy result. Hard to imagine how that correlates
    with case-sensitivity. As there are no comments, we can only assume
    the author is mad.

    >                 (d.isIE ? od.xml : (root.xmlVersion||od.xmlVersion));


    Back to counting beans. I suppose they don't care about users who
    change their UA string in Opera either. Or older Opera versions that
    impersonate IE. As mentioned recently, the UA string is primarily a
    device for deception (mostly used to deceive incompetently written
    scripts). Little girls eat eggs quite as much as serpents do, you
    know. :)

    And it's all ridiculous anyway. This problem is easily solved without
    resorting to UA sniffing (as is virtually always the case). And, as
    noted, they didn't even solve it. What makes these Dodo's want to run
    around circles forever? For God's sake, don't follow them.
    David Mark, Mar 8, 2010
    #4
  5. David Mark

    David Mark Guest

    Andrew Poulos wrote:
    > Also I notice that the http://www.dojotoolkit.org/ page give 46 CSS
    > warnings in FF.
    >


    Ah, that's the least of their problems. :) But yeah, I've talked to
    them about their incessant CSS parse hack BS (among other CSS failings).
    But they are experts being pragmatic (or some such shit).

    In Opera 10, the jQuery-powered forum flashes the stop/reload button
    endlessly. Never seen anything like it. And their "permalink" links
    use the javascript pseudo-protocol. (!)

    And if you drill down to their "foundation" site, you'll see the
    ultimately in single-page-Ajaxified-navigation futility. Just size your
    browser to something less than 1024x768 (approx). D'oh!
    David Mark, Mar 8, 2010
    #5
  6. David Mark

    Scott Sauyet Guest

    David Mark wrote:
    > Have you seen the shiny new Dojo Toolkit site? [ ... ]


    Umm... David, you do realize c.l.j.s. is about Javascript, right?

    :)

    -- Scott
    Scott Sauyet, Mar 8, 2010
    #6
  7. David Mark

    Scott Sauyet Guest

    Andrew Poulos wrote:
    > Scott Sauyet wrote:
    >> David Mark wrote:
    >>> Have you seen the shiny new Dojo Toolkit site? [ ... ]

    >>
    >> Umm... David, you do realize c.l.j.s. is about Javascript, right?

    >
    > I can see why he posted it to this group. Dojo considers itself a
    > leading javascript library and it would be reasonable to consider their
    > web site an example of how the library should/could be used. Instead it
    > appears to be a counter example.


    This was of course partially tongue-in-cheek. I know that David knows
    the purpose of this group. But he couldn't have really been
    criticizing the use of the Dojo Toolkit on the home page of the Dojo
    Toolkit, because as far as I can tell, it's not used at all -- really!

    But a 1700+-word post that contained maybe 100 words on Javascript,
    discussing instead such things as the location of the shortcut icon,
    the use of section comments in the markup, and the number of
    characters in their URLs, seems out of place here. The only
    substantive comments on the JS were that it was odd to need to
    explicitly specify that debugging is off and that synchronous AJAX
    requests are a bad idea.

    -- Scott
    Scott Sauyet, Mar 8, 2010
    #7
  8. David Mark

    David Mark Guest

    Scott Sauyet wrote:
    > David Mark wrote:
    >> Have you seen the shiny new Dojo Toolkit site? [ ... ]

    >
    > Umm... David, you do realize c.l.j.s. is about Javascript, right?
    >


    It's c.l.j. and that site is all wild claims about JS. Get it? A
    review of the "toolkit" itself will follow.
    David Mark, Mar 9, 2010
    #8
  9. David Mark

    David Mark Guest

    Scott Sauyet wrote:
    > Andrew Poulos wrote:
    >> Scott Sauyet wrote:
    >>> David Mark wrote:
    >>>> Have you seen the shiny new Dojo Toolkit site? [ ... ]
    >>> Umm... David, you do realize c.l.j.s. is about Javascript, right?

    >> I can see why he posted it to this group. Dojo considers itself a
    >> leading javascript library and it would be reasonable to consider their
    >> web site an example of how the library should/could be used. Instead it
    >> appears to be a counter example.

    >
    > This was of course partially tongue-in-cheek. I know that David knows
    > the purpose of this group. But he couldn't have really been
    > criticizing the use of the Dojo Toolkit on the home page of the Dojo
    > Toolkit, because as far as I can tell, it's not used at all -- really!


    Couldn't I have? Didn't you see it in there? That's exactly the
    mentality I am criticizing. They just dump that mess into every page,
    regardless of how much it is (or isn't) used. As for the rest of the
    pages on the site, most used jQuery. So this should give you pause when
    considering if you really want to buy into the BS on the front page.

    >
    > But a 1700+-word post that contained maybe 100 words on Javascript,


    You counted the words?!

    > discussing instead such things as the location of the shortcut icon,
    > the use of section comments in the markup, and the number of
    > characters in their URLs, seems out of place here.


    I'll decide what's in place here. :) And it all goes to prove that the
    developers are less than proficient at Web development. I mean. this is
    the best that the Dojo developers could do? There was quite the
    build-up for this long-overdue site. Does that make you want to believe
    their pitch? It demonstrates incompetence on so many levels.

    > The only
    > substantive comments on the JS were that it was odd to need to
    > explicitly specify that debugging is off and that synchronous AJAX
    > requests are a bad idea.
    >


    Yes, the synchronous Ajax requests have been integral to their BS from
    the start. It took me months to convince them that they were wrong to
    use those. Still, they remain as nobody wanted to bother merging in the
    changes required to put those out of the picture (too much like work
    with no "wowie" effect I guess).
    David Mark, Mar 9, 2010
    #9
  10. David Mark

    S.T. Guest

    On 3/8/2010 1:04 AM, David Mark wrote:
    > What experienced developers? What Web? Where? And scales?! I've yet
    > to see a site out of this bunch (even a basic page) that doesn't
    > download ten times what it should. A quick glance shows that the front
    > (well only) page of the aforementioned Foundation site weighs in at:-
    >
    > Total HTTP Requests: 45
    > Total Size: 454259 bytes


    On dojotoolkit.com? I show two-thirds less size and a third-less
    requests than you're showing. The YSlow firebug add-on quite likes what
    they've done, in fact.

    > ... like Cappuccino (another massive folly that
    > has no shot of ever gaining acceptance on the Web).


    Out of curiosity if Cappuccino has no shot at gaining acceptance, do you
    believe "My Library" does?


    > <div id="page" class="homePage">
    >
    > The camel-case class name must have seemed like a cool idea (of course,
    > it isn't). And what sort of ID is "page?"


    What's possibly wrong with camel-case in CSS? I frequently use it -
    increases readability dramatically when quickly scanning, especially if
    you prefer single-line rules like I do, i.e.

    #leftLink {font-size: 1.1em; color: blue}
    ..rightLinks {padding-left: 5px; text-decoration: none;}
    #leftColumn a {color: red}

    >
    > <img
    > src="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/logo.png"
    > alt="Dojo Toolkit" /></a></span>
    >
    > The outrageously long paths for every asset are ridiculous.


    Why would a long path possibly matter? Safe bet these links these aren't
    being hand-coded.

    > <form method="GET" action="http://www.google.com/search" id="search">
    > <span>
    > <input type="text" name="q" id="query" value="Search" />
    >
    > Ugh. Name/ID mismatch.


    What's wrong with different name/ID? Nothing.

    Google want's the GET variable to post as 'q'. 'q' isn't very
    descriptive in a style sheet.

    ID's need to be unique on a page, names do not. Plenty of instances
    where form element's id/names should be different. If I'm unsure of the
    finished design or the form will be re-used and am using a common name
    (i.e. "email") I'll always use differing ids/names.

    > <div class="innerBox">
    >
    > Another interesting class name.


    How so?

    > <span class="version"><h1>1.4</h1> <span>Instantly Better Web
    > Apps</span></span>
    >
    > Am I seeing things? An H1 inside of a SPAN?


    span.version is position:absolute. It's no longer inline. H1 is fine
    inside it.

    That was a largely ridiculous, ticky-tack critique of underlying HTML
    that makes it pretty clear you don't design anything more complicated
    than what's on cinsoft.net. If you did you'd realize how ridiculous it
    is to expect the designer(s) to go back and waste time changing
    single-used classes to ids, swap spans that already compute to
    block-level to divs to make the code 'pretty', parse code to strip an
    unused span that has zero impact in any event, and so on.

    I'll grant you a library that supports Opera probably shouldn't use a
    non-Opera supporting jQuery-based forum. Maybe you have a legitimate
    beef with how they instituted 'your' aural/handheld styles - don't know,
    don't care.

    If you spent half as much time documenting "My Library" as you do
    criticizing everything else -- perhaps someone would actually use it. Of
    course actual usage was never the motive of "My Library", was it?

    On the plus side, I've never really looked at Dojo Toolkit before. I
    quite like their widgets in contrast to the (IMHO) still too
    rough-around-the-edges jQueryUI. Might give it a shot in an upcoming
    project.
    S.T., Mar 9, 2010
    #10
  11. S.T. meinte:

    >> <span class="version"><h1>1.4</h1> <span>Instantly Better Web
    >> Apps</span></span>
    >>
    >> Am I seeing things? An H1 inside of a SPAN?

    >
    > span.version is position:absolute. It's no longer inline. H1 is fine
    > inside it.


    No. It's not. Inline elements must not contain block level elements. And
    the markup gives shit about what the CSS says.

    > That was a largely ridiculous, ticky-tack critique of underlying HTML
    > that makes it pretty clear you don't design anything more complicated
    > than what's on cinsoft.net. If you did you'd realize how ridiculous it
    > is to expect the designer(s) to go back and waste time changing
    > single-used classes to ids, swap spans that already compute to
    > block-level to divs to make the code 'pretty', parse code to strip an
    > unused span that has zero impact in any event, and so on.


    It would be nice for web authors, if they could produce documents which
    don't fail validation (in this case 19 errors). True - The dojo webpage
    authors are not the only ones out there, who fail miserably when it
    comes to markup.

    Gregor


    --
    http://www.gregorkofler.com
    Gregor Kofler, Mar 9, 2010
    #11
  12. David Mark

    S.T. Guest

    On 3/9/2010 11:32 AM, Gregor Kofler wrote:
    >> span.version is position:absolute. It's no longer inline. H1 is fine
    >> inside it.

    >
    > No. It's not.


    Yes. It is.

    > Inline elements must not contain block level elements. And
    > the markup gives shit about what the CSS says.


    It's not an inline element.

    http://webkit.org/blog/117/webcore-rendering-iv-absolutefixed-and-relative-positioning/

    "When an object is absolute/fixed positioned, it becomes block-level.
    Even if the CSS display type is set to inline (or inline-block/table),
    the effective display type becomes block-level once an object is
    positioned. "

    Check computed display styles of absolute positioned spans in various
    browsers. They aren't inline.
    S.T., Mar 9, 2010
    #12
  13. S.T. meinte:
    > On 3/9/2010 11:32 AM, Gregor Kofler wrote:
    >>> span.version is position:absolute. It's no longer inline. H1 is fine
    >>> inside it.

    >>
    >> No. It's not.

    >
    > Yes. It is.
    >
    > > Inline elements must not contain block level elements. And
    > > the markup gives shit about what the CSS says.

    >
    > It's not an inline element.


    It is. span is and will always be an inline element.

    > http://webkit.org/blog/117/webcore-rendering-iv-absolutefixed-and-relative-positioning/


    > "When an object is absolute/fixed positioned, it becomes block-level.
    > Even if the CSS display type is set to inline (or inline-block/table),
    > the effective display type becomes block-level once an object is
    > positioned. "


    So? This doesn't state that by setting some CSS properties and invalid
    markup will become valid.

    > Check computed display styles of absolute positioned spans in various
    > browsers. They aren't inline.


    I never said that. The markup is invalid. That's all.

    Gregor


    --
    http://www.gregorkofler.com
    Gregor Kofler, Mar 9, 2010
    #13
  14. David Mark

    S.T. Guest

    On 3/9/2010 12:33 PM, Gregor Kofler wrote:
    > It is. span is and will always be an inline element.
    >
    >> http://webkit.org/blog/117/webcore-rendering-iv-absolutefixed-and-relative-positioning/

    >
    >
    >> "When an object is absolute/fixed positioned, it becomes block-level.
    >> Even if the CSS display type is set to inline (or inline-block/table),
    >> the effective display type becomes block-level once an object is
    >> positioned. "

    >
    > So? This doesn't state that by setting some CSS properties and invalid
    > markup will become valid.
    >
    >> Check computed display styles of absolute positioned spans in various
    >> browsers. They aren't inline.

    >
    > I never said that. The markup is invalid. That's all.
    >


    Alright, I see where you're coming from here.

    Yes, I'll concede if validating HTML to its DTD it'll come out invalid.
    S.T., Mar 9, 2010
    #14
  15. S.T. wrote:
    > On 3/9/2010 11:32 AM, Gregor Kofler wrote:
    >>> span.version is position:absolute. It's no longer inline. H1 is fine
    >>> inside it.

    >>
    >> No. It's not.

    >
    > Yes. It is.
    >


    It is important to validate the HTML. When the browser's HTML parser
    encounters H1 while it is in an inline element (SPAN, here), it has to
    error correct and make a nonstandard decision on how to handle the
    situation.

    > > Inline elements must not contain block level elements. And
    > > the markup gives shit about what the CSS says.

    >
    > It's not an inline element.
    >
    > http://webkit.org/blog/117/webcore-rendering-iv-absolutefixed-and-relative-positioning/
    >
    >
    > "When an object is absolute/fixed positioned, it becomes block-level.
    > Even if the CSS display type is set to inline (or inline-block/table),
    > the effective display type becomes block-level once an object is
    > positioned. "
    >


    It is better to instead refer to the CSS 2.1 specification.
    http://www.w3.org/TR/CSS2/visuren.html#dis-pos-flo

    > Check computed display styles of absolute positioned spans in various
    > browsers. They aren't inline.


    Do not confuse HTML flow types with CSS display values.

    HTML 4 flow types include inline and block. CSS display property can
    have many more values.

    Although an element's CSS display value of the same name as it's HTML
    flow type ("inline" or "block"), it is not necessarily so, and not
    always so. For an example, a table cell is marked up using TD in HTML
    and rendered with display: table-cell, by default, in compliant
    implementations.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Mar 9, 2010
    #15
  16. David Mark

    S.T. Guest

    On 3/9/2010 3:15 PM, Garrett Smith wrote:
    > It is important to validate the HTML. When the browser's HTML parser
    > encounters H1 while it is in an inline element (SPAN, here), it has to
    > error correct and make a nonstandard decision on how to handle the
    > situation.


    Validating is a debugging tool - that's it. It's not important if a page
    "passes" or not.

    No doubt there are lengthy arguments about how critical validating is to
    the future of humanity, but the real world uses validation for it's
    useful purposes and stops there. ALT'ing every single IMG whether useful
    or not is a fool's errand. Escaping every ampersand in a URL is wasted
    time.

    Nice way to find tags that weren't closed and duplicate IDs though.

    >> "When an object is absolute/fixed positioned, it becomes block-level.
    >> Even if the CSS display type is set to inline (or inline-block/table),
    >> the effective display type becomes block-level once an object is
    >> positioned. "
    >>

    > It is better to instead refer to the CSS 2.1 specification.
    > http://www.w3.org/TR/CSS2/visuren.html#dis-pos-flo


    That page says an inline element with position: absolute is computed as
    a block level element, which was my original point.

    >
    >> Check computed display styles of absolute positioned spans in various
    >> browsers. They aren't inline.

    >
    > Do not confuse HTML flow types with CSS display values.


    Yes, I already conceded that point. It wasn't so much confusing the two,
    rather realizing his context was with HTML validation whereas I was
    looking from the browser's perspective, as I care about what the browser
    does with the markup -- not what the W3C thinks of it.
    S.T., Mar 10, 2010
    #16
  17. David Mark

    Matt Kruse Guest

    On Mar 9, 9:10 pm, Andrew Poulos <> wrote:
    > For me, not caring about validation is the equivalent of incompetence.


    For me, that seems more than a bit harsh.

    (Though it's quite typical for computer programmers to be anal
    retentive to the point of insanity about things that don't really
    matter all that much, so it's understandable)

    Matt Kruse
    Matt Kruse, Mar 10, 2010
    #17
  18. David Mark

    David Mark Guest

    S.T. wrote:
    > On 3/8/2010 1:04 AM, David Mark wrote:
    >> What experienced developers? What Web? Where? And scales?! I've yet
    >> to see a site out of this bunch (even a basic page) that doesn't
    >> download ten times what it should. A quick glance shows that the front
    >> (well only) page of the aforementioned Foundation site weighs in at:-
    >>
    >> Total HTTP Requests: 45
    >> Total Size: 454259 bytes

    >
    > On dojotoolkit.com?


    No.

    > I show two-thirds less size and a third-less
    > requests than you're showing. The YSlow firebug add-on quite likes what
    > they've done, in fact.


    That's as maybe and that add-on is often confused.

    >
    >> ... like Cappuccino (another massive folly that
    >> has no shot of ever gaining acceptance on the Web).

    >
    > Out of curiosity if Cappuccino has no shot at gaining acceptance, do you
    > believe "My Library" does?


    Of course it does. Do you have any sound reason to use an incompetent
    script when a competent one is available?

    >
    >
    >> <div id="page" class="homePage">
    >>
    >> The camel-case class name must have seemed like a cool idea (of course,
    >> it isn't). And what sort of ID is "page?"

    >
    > What's possibly wrong with camel-case in CSS? I frequently use it -
    > increases readability dramatically when quickly scanning, especially if
    > you prefer single-line rules like I do, i.e.


    Why would you ask for trouble? You do realize that some browsers (in
    some modes) will treat them case insensitively.

    >
    > #leftLink {font-size: 1.1em; color: blue}
    > .rightLinks {padding-left: 5px; text-decoration: none;}
    > #leftColumn a {color: red}
    >
    >>
    >> <img
    >> src="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/logo.png"
    >> alt="Dojo Toolkit" /></a></span>
    >>
    >> The outrageously long paths for every asset are ridiculous.

    >
    > Why would a long path possibly matter? Safe bet these links these aren't
    > being hand-coded.


    Lots of extra characters to download? Silly?

    >
    >> <form method="GET" action="http://www.google.com/search" id="search">
    >> <span>
    >> <input type="text" name="q" id="query" value="Search" />
    >>
    >> Ugh. Name/ID mismatch.

    >
    > What's wrong with different name/ID? Nothing.


    On the contrary, there are lots of things wrong with it. Not the least
    of which is the gEBI bug in IE (and possibly others), which coupled with
    the query-happy designs that I typically see out of this bunch (e.g.
    using queries instead of referencing the elements collection) and the
    fact that the query engines often use gEBI behind-the-scenes means they
    are unknowingly creating all sorts of potential problems (which is a
    pattern here).

    >
    > Google want's the GET variable to post as 'q'. 'q' isn't very
    > descriptive in a style sheet.


    Not an argument to use different ID's and names.

    >
    > ID's need to be unique on a page, names do not.


    No kidding. :)

    > Plenty of instances
    > where form element's id/names should be different.


    Yes, but that has no bearing here.

    > If I'm unsure of the
    > finished design or the form will be re-used and am using a common name
    > (i.e. "email") I'll always use differing ids/names.


    Then you don't know what you are doing.

    >
    >> <div class="innerBox">
    >>
    >> Another interesting class name.

    >
    > How so?


    Has no semantic meaning at all (another pattern).

    >
    >> <span class="version"><h1>1.4</h1> <span>Instantly Better Web
    >> Apps</span></span>
    >>
    >> Am I seeing things? An H1 inside of a SPAN?

    >
    > span.version is position:absolute. It's no longer inline. H1 is fine
    > inside it.


    No, it isn't.

    >
    > That was a largely ridiculous, ticky-tack critique of underlying HTML
    > that makes it pretty clear you don't design anything more complicated
    > than what's on cinsoft.net.


    No it wasn't and no it doesn't. And isn't that always the way with the
    "I'm okay, you're okay" crowd? You can't address the technical points,
    so you veer off into lame attempts at personal attacks. And it's quite
    clear that they tried to design something on the order of some of the
    documents on cinsoft.net, but fouled it up.

    > If you did you'd realize how ridiculous it
    > is to expect the designer(s) to go back and waste time changing
    > single-used classes to ids, swap spans that already compute to
    > block-level to divs to make the code 'pretty', parse code to strip an
    > unused span that has zero impact in any event, and so on.


    The "designer" seems oblivious to rule #1 (use valid markup). They are
    clearly asking for trouble at every turn (particularly as they seem to
    favor very dubious scripts).

    >
    > I'll grant you a library that supports Opera probably shouldn't use a
    > non-Opera supporting jQuery-based forum.


    But it doesn't support Opera at all. You clearly haven't been following
    along. They use UA sniffing to attempt to support the one version of
    Opera they profess to "care" about (the latest one) and ignore
    everything that came before. They do the same with Safari (only
    "caring" about version 4) and recently tried to lop off IE < 8 as well
    (despite the fact that IE8 can be made to act just like IE7 with the
    push of a button by the end-user). You can't just decide to let
    everything break in random ways because you don't understand
    cross-browser scripting, but want to claim that your "unbeatable
    JavaScript" (sic) is cross-browser.

    > Maybe you have a legitimate
    > beef with how they instituted 'your' aural/handheld styles - don't know,
    > don't care.


    Then why are you talking about it? And it's not a beef, just another in
    a long series of observations concerning their clueless "monkey see,
    monkey do, monkey **** up" behavior.

    >
    > If you spent half as much time documenting "My Library" as you do
    > criticizing everything else -- perhaps someone would actually use it.


    You are hardly privy to my time management. Mind your own business.

    > Of
    > course actual usage was never the motive of "My Library", was it?


    No, it wasn't.

    >
    > On the plus side, I've never really looked at Dojo Toolkit before. I
    > quite like their widgets in contrast to the (IMHO) still too
    > rough-around-the-edges jQueryUI. Might give it a shot in an upcoming
    > project.


    Then you are truly beyond help. The widgets are full of browser
    sniffing and built on top of a cracked foundation that can't even claim
    to "support" anything but the very latest of a handful of browsers in
    their default configurations. In the minds of the developers, today's
    "cared about" browsers are tomorrow's discards, for no reason other than
    to justify their own incompetence.
    David Mark, Mar 10, 2010
    #18
  19. David Mark

    David Mark Guest

    Matt Kruse wrote:
    > On Mar 9, 9:10 pm, Andrew Poulos <> wrote:
    >> For me, not caring about validation is the equivalent of incompetence.

    >
    > For me, that seems more than a bit harsh.


    I'm okay, you're okay. :)

    >
    > (Though it's quite typical for computer programmers to be anal
    > retentive to the point of insanity about things that don't really
    > matter all that much, so it's understandable)


    It's quite typical for you to make ridiculous statements. FYI, if you
    are going to script a DOM, it is in your own best interest to do all you
    can to ensure that browsers will build a consistent DOM from your
    markup. Valid markup is required for that as otherwise you are relying
    on error correction, which varies from one agent to the next.
    David Mark, Mar 10, 2010
    #19
  20. David Mark

    David Mark Guest

    S.T. wrote:
    > On 3/9/2010 3:15 PM, Garrett Smith wrote:
    >> It is important to validate the HTML. When the browser's HTML parser
    >> encounters H1 while it is in an inline element (SPAN, here), it has to
    >> error correct and make a nonstandard decision on how to handle the
    >> situation.

    >
    > Validating is a debugging tool - that's it. It's not important if a page
    > "passes" or not.


    You clearly do not have the knowledge or experience to filter validation
    reports. Best to just abide by them (at least for now).

    >
    > No doubt there are lengthy arguments about how critical validating is to
    > the future of humanity, but the real world uses validation for it's
    > useful purposes and stops there. ALT'ing every single IMG whether useful
    > or not is a fool's errand.


    But do you understand when it is useful and when it is not? Clearly the
    Dojo developers do not (ask any blind person who has the misfortune to
    come across their new site). I'm still wondering why they bothered with
    aural style sheets. Perhaps they were just copying without thinking. :)

    > Escaping every ampersand in a URL is wasted
    > time.


    I don't think so (and you definitely shouldn't think so).

    >
    > Nice way to find tags that weren't closed and duplicate IDs though.


    Unless the errors happen to be lost in a sea of missing attributes (or
    invalid values).

    >
    >>> "When an object is absolute/fixed positioned, it becomes block-level.
    >>> Even if the CSS display type is set to inline (or inline-block/table),
    >>> the effective display type becomes block-level once an object is
    >>> positioned. "
    >>>

    >> It is better to instead refer to the CSS 2.1 specification.
    >> http://www.w3.org/TR/CSS2/visuren.html#dis-pos-flo

    >
    > That page says an inline element with position: absolute is computed as
    > a block level element, which was my original point.


    Which demonstrates that you have no idea what you are talking about.

    >
    >>
    >>> Check computed display styles of absolute positioned spans in various
    >>> browsers. They aren't inline.

    >>
    >> Do not confuse HTML flow types with CSS display values.

    >
    > Yes, I already conceded that point. It wasn't so much confusing the two,
    > rather realizing his context was with HTML validation whereas I was
    > looking from the browser's perspective, as I care about what the browser
    > does with the markup -- not what the W3C thinks of it.
    >


    No point there. Invalid markup definitely affects browsers. The
    validation tools on the W3C site (and elsewhere) simply alert you to
    mistakes (many of which will manifest themselves in your "real world").
    David Mark, Mar 10, 2010
    #20
    1. Advertising

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. most bizarre problem ever

    , Oct 21, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    432
  2. dorayme
    Replies:
    46
    Views:
    1,118
    Neredbojias
    Aug 13, 2007
  3. Replies:
    5
    Views:
    253
  4. Jason
    Replies:
    0
    Views:
    173
    Jason
    Jul 6, 2004
  5. pete
    Replies:
    28
    Views:
    312
    Kyle T. Jones
    Mar 17, 2010
Loading...

Share This Page