New Dojo Site--Most incompetent ever?

David Mark · Mar 8, 2010

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.



Typical cargo cult comment.

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

Haven't we met before?

</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’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">©</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.

</body>
</html>

Start over.

Gregor Kofler · Mar 8, 2010

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

David Mark · Mar 8, 2010

Gregor said:
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

On Mar 8 said:
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

Andrew said:
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!

Scott Sauyet · Mar 8, 2010

David said:
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

Andrew said:
Scott said:

David said:

Have you seen the shiny new Dojo Toolkit site? [ ... ]

Click to expand...

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

Click to expand...

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

David Mark · Mar 9, 2010

Scott said:
David said:

Have you seen the shiny new Dojo Toolkit site? [ ... ]

Click to expand...

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

Scott said:
Andrew said:

Scott said:

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?

Click to expand...

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.

Click to expand...

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

S.T. · Mar 9, 2010

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.

Gregor Kofler · Mar 9, 2010

S.T. meinte:

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

S.T. · Mar 9, 2010

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.

Gregor Kofler · Mar 9, 2010

S.T. meinte:

Yes. It is.

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

S.T. · Mar 9, 2010

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

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

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.

Garrett Smith · Mar 9, 2010

S.T. said:
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.

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.

S.T. · Mar 10, 2010

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.

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.

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.

Matt Kruse · Mar 10, 2010

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

David Mark · Mar 10, 2010

S.T. said:
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.

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?

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}

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

Lots of extra characters to download? Silly?

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.

How so?

Has no semantic meaning at all (another pattern).

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

Matt said:
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

S.T. said:
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).

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.

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

Working on mobile css menu with plenty of frustration!	2	Dec 29, 2022
Positioning CSS components	1	Nov 16, 2023
Only one table shows up with the information	2	Mar 29, 2023
Buttons lining up	1	Feb 6, 2022
Align img inside nav tabs section	5	Dec 29, 2023
Survey details won't go through using php, ajax, Mysql	0	Oct 26, 2023
Not sure why drop-down is not working.	2	Mar 24, 2024
HTML Site Problems	11	Nov 25, 2019

New Dojo Site--Most incompetent ever?

David Mark

Gregor Kofler

David Mark

David Mark

David Mark

Scott Sauyet

Scott Sauyet

David Mark

David Mark

S.T.

Gregor Kofler

S.T.

Gregor Kofler

S.T.

Garrett Smith

S.T.

Matt Kruse

David Mark

David Mark

David Mark

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads