New Dojo Site--Most incompetent ever?
David Mark
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’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. ;)
<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.
Gregor Kofler
[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
> 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
[...]
> 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.
Andrew Poulos
David Mark
> 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
> Have you seen the shiny new Dojo Toolkit site? [ ... ]
Umm... David, you do realize c.l.j.s. is about Javascript, right?
:-)
-- Scott
Andrew Poulos
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.
Andrew Poulos
Scott Sauyet
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
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
> 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).
S.T.
> 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
>> <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
S.T.
>> 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.
Gregor Kofler
> 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
S.T.
> 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.
Garrett Smith
> 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/
S.T.
> 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.
Garrett Smith
> 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.
>
This is getting more to the topic of HTML (f'up to ciwah).
If consistent expected results matter, then validating is important.
Browsers do handle invalid markup in nonstandard ways. The HTML 4
authors were aware of that fact, and included the following note:
"Since user agents may vary in how they handle error conditions, authors
and users must not rely on specific error recovery behavior."
http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1
The spec also adds:
"We also recommend that user agents provide support for notifying the
user of such errors."
I believe a c2004 version of iCab would follow that recommendation,
though I am not certain about others.
It is also important to consider that just because a page is valid, does
not mean that it is conforming. See also:
http://validator.w3.org/about.html
One case in particular that can be a problem is back at Appendix B where
the URI handling recommendation for escaping characters is discussed.
Browsers do not all handle invalid characters in URIs consistently. It
is worth mentioning that hte w3c validator will not catch those
problems, e.g. <a href="^*~WTF?!">test</a> - is going to look a-ok to
the validator but watch what the browsers will do -- uh oh!
> 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.
>
Finding missing end tags depends on the doctype and the tag.
In HTML, some tags have optional end tags. LI, for example. To find
those missing LI, one might use an override doctype in the w3c validator.
>>> "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.
>
Right; CSS 2.1 TR is the normative ref for that.
To test its correctness, create an inline element, set its position to
absolute, then try and get the computed style for "display".
Andrew Poulos
> 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
>> situation.
>
> Validating is a debugging tool - that's it. It's not important if a page
> "passes" or not.
For me, not caring about validation is the equivalent of incompetence.
Andrew Poulos
Matt Kruse
> 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
> 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 fuck 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
> On Mar 9, 9:10 pm, Andrew Poulos <ap_p...@hotmail.com> 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.
Andrew Poulos
If you ever need a job send samples of your work with your job
application and, if the stuff doesn't validate, it will be easy for me
to access your application. Oh, and don't worry about spelling or
grammar as I can generally work out what is meant.
Andrew Poulos
SteveYoungGoogle
> 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.
Where then?
Steve.
<snip>
David Mark
> 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
> 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.
As mentioned, no (Google "Dojo Foundation").
But I'm glad you brought up that site. Assuming your estimates are
correct, it's still way too large (no matter what your mechanical Turk
says).
A few excerpts:-
"Some folks have noticed a new landing page for dojotoolkit.org, one
that includes hard numbers about the performance of Dojo vs. jQuery.
Every library makes tradeoffs for speed in order to provide better APIs,
but JavaScript toolkit performance shootouts obscure that reality more
often than not. After all, there would hardly be a need for toolkits if
the built in APIs were livable. Our new site isn�t arguing that Dojo
gives you the fastest possible way to do each of the tasks in the
benchmark, all we argue is that we provide the fastest implementation
that you�ll love using."
So they are proud of the new site and deluded enough to think that their
botched query engine is something I'll love using. :) And the bit
about the "built in APIs" is the typical BS designed to scare you into
using their crap (ostensibly it smells better than the browsers').
And "hard numbers?" That would be based on TaskSpeed of course. :(
"I gathered the numbers and stand behind them, so let me quickly outline
where they come from, why they�re fair, and why they matter to your app."
No thanks. Fuck off.
"Similarly Flex, Laszlo, GWT�s UI Binder, and Silverlight have
discovered the value in markup as a simple declarative way for
developers to understand the hierarchical relationships between
components, but they correspond to completely unambiguous definitions of
components they rely on compiled code � not reliably parsed markup � for
final delivery of the UI."
LOL. Look up "pseudo-intellectual" in the dictionary and you'll find a
picture of this guy.
"So from time to time I�d wondered what all the brilliant DHTML hackers
that Google had hired were up to. Obviously, building products. Sure.
But I knew these guys. They do infrastructure, not just kludges and
one-off�s. You don�t build a product like Gmail and have no significant
UI infrastructure to show for it."
Yes, he works for Google.
"There�s a ton of great code in Closure,"
Enough.
And as you like to compare everything to cinsoft.net. I see on Alexa
that this particular site is going down the proverbial toilet (at a rate
of knots).
http://www.alexa.com/siteinfo/dojotoolkit.com#trafficstats
...so there may be some hope for the Web after all:-
http://www.alexa.com/siteinfo/cinsoft.net?p=tgraph&r=home_home
Not bad for a domain that up until recently had no home page. :)
And, one final note (or nail), I see that Dojo deleted my branch. I'm
not complaining, of course, as I told them to (don't have time to walk
them through it and am tired of watching them stumble around). Didn't
take them 24 hours to jump to it either. That's it for them; they've
thrown their last paddle overboard. :)
And if anyone is crazy enough to actually want to fork Dojo (from a
relatively sane starting point), I'd be glad to send the files and
instructions.
David Mark
Groan. You again?
David Mark
Here you go:-
JavaScript - http://www.dojofoundation.org/
Timeout thread: delay 0 ms
Unhandled exception: [Object DOMException]
name: Error
message: SYNTAX_ERR
stacktrace: n/a; see opera:config#UserPrefs|Exceptions Have Stacktrace
In Opera 10 no less. And check out the "layout" in anything less than a
maximized browser at a very high resolution. You can bet the developers
never did. ;)
SteveYoungGoogle
> David Mark wrote:
> > SteveYoungGoogle wrote:
> >> On Mar 10, 5:42 am, David Mark <dmark.cins...@gmail.com> wrote:
> >>> 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.
> >> Where then?
>
> > Groan. You again?
>
> Here you go:-
>
> Timeout thread: delay 0 ms
> Unhandled exception: [Object DOMException]
> name: Error
> message: SYNTAX_ERR
> stacktrace: n/a; see opera:config#UserPrefs|Exceptions Have Stacktrace
>
> In Opera 10 no less. And check out the "layout" in anything less than a
> maximized browser at a very high resolution. You can bet the developers
> never did. ;)
So your thread and OP is entitled "New Dojo Site--Most incompetent
ever?". The OP opens with the question "Have you seen the shiny new
Dojo Toolkit site?". But your figures for a bad site come from
http://www.dojofoundation.org/
David Mark
Interesting take. As was noted clearly, that aside was about the
_Foundation_ site, which is one of several that link from the single
page Toolkit "site." Everything else in the review applies to that
page. HTH.
David Stone
Garrett Smith <dhtmlk...@gmail.com> wrote:
> 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.
>
> This is getting more to the topic of HTML (f'up to ciwah).
>
> If consistent expected results matter, then validating is important.
>
> Browsers do handle invalid markup in nonstandard ways. The HTML 4
> authors were aware of that fact, and included the following note:
> "Since user agents may vary in how they handle error conditions, authors
> and users must not rely on specific error recovery behavior."
> http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1
>
> The spec also adds:
> "We also recommend that user agents provide support for notifying the
> user of such errors."
>
> I believe a c2004 version of iCab would follow that recommendation,
> though I am not certain about others.
I used that for a while on a Mac. If enabled, you would see either
a green smiley face, a yellow neutral face, or a red frowning face.
There was an option to pull up a list of the cautions and errors
giving rise to these icons.
In Firefox, Tools -> Error Console gives a fair bit of information
in terms of html and css errors and warnings on parsing documents.
I don't see anything in the current Safari along these lines.
Lasse Reichstein Nielsen
> 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.
True. What matters is that the page works as expected.
However, for invalid HTML, the HTML specification doesn't say what
the HTML means or how it will be parsed. I.e., you cannot possibly
know whether it will work as expected. That's why invalidly nested
HTML is bad.
> 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.
Except for accessability, I'd agree. The HTML will still be meaningfull.
> Escaping every ampersand in a URL is wasted time.
Here I disagree. Again you cannot predict what meaning a browser will
give to your characters, so you can't know that it will work as
expected.
> That page says an inline element with position: absolute is computed
> as a block level element, which was my original point.
That's CSS, not HTML.
If you write "<span> foo <H1> bar </H1> baz </span>", it is likely to
be interpreted as "<span> foo </span><H1> bar </h1> baz ". No amount
of inline positioning will make the H1 a child of the span.
>> 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.
But do you *know* what the browser does with invalid markup?
All browsers?
Have you tried dumping the DOM of the page to see what it's really
turned into? (And if it's the right thing, why not just write that
to begin with).
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
John G Harris
Reichstein Nielsen wrote:
>"S.T." <an...@anon.com> writes:
>
>> 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.
>
>True. What matters is that the page works as expected.
>However, for invalid HTML, the HTML specification doesn't say what
>the HTML means or how it will be parsed. I.e., you cannot possibly
>know whether it will work as expected. That's why invalidly nested
>HTML is bad.
In addition, you don't know what future browsers will do. It could
require a major re-work.
John
--
John Harris
Garrett Smith
In Firefox 3.5, I get the following errors:
------------------------------------------------
An invalid or illegal string was specified" code: "12
[Break on this error] (function(){var
_1=null;if((_1||(typeo...meout(dojo._fakeLoadInit,1000);}})();
------------------------------------------------
Use of getBoxObjectFor() is deprecated. Try to use
element.getBoundingClientRect() if possible.
------------------------------------------------
Method getBoxObject for is an XUL method that was accidentally leaked
onto the dom. It became popular some time around 2007 or so. The method
was never intended to be available in HTML (and never intended for web).
Those who initially made the mistake of using it figured out not to do
that over a year ago.
I see they make an XHR to:
http://www.dojofoundation.org/dojango/media/dojango/_base.js
- to which the server responds with:
| dojo.provide("dojango._base");
| dojo.mixin(dojango, {
| test: function(){
| console.log("test");
| }
| });
Which has the result of calling their misnamed namespacing methods
"dojo.getObject" and "dojo._getProp" all to create an adapter for
console.log, thus requiring the use of firebug lite or something that
adds a global `console` method.
I don't care much what they do with the code on their site, and in fact
the code on my site is a little old, too (7 years or so).
What bothers me about Dojo is the code behind the marketing. Through the
website and through presentations, the founders of Dojo instill a sense
of confidence and empowerment to the project managers who consider using
Dojo. That in and of itself is not bad -- it is a great thing to be
able to win an audience over (I need to improve in that area).
The problem is the code itself. The code is large. There is disturbingly
faulty logic in the core of dojo itself (some of it discussed in this NG
archives).
Projects that have used Dojo FWIS, tended to have performance issues and
take too much effort to maintain.
Significantly larger projects (72+ man months) having a poor outcome or
total failure is a more significant failure than a smallish website that
throws a few errors and hangs for two seconds. The dojofoundation isn't
much worse than any other pop website nowadays.
[...]
David Mark
> "S.T." <an...@anon.com> writes:
>
>> 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.
>
> True. What matters is that the page works as expected.
But that's an observation and as you can hardly observe anywhere near
every browser/mode/configuration, past, present and future, it is a good
idea to go with abstractions (e.g. error correction can't be counted on).
> However, for invalid HTML, the HTML specification doesn't say what
> the HTML means or how it will be parsed. I.e., you cannot possibly
> know whether it will work as expected. That's why invalidly nested
> HTML is bad.
Yes. That's what I'm getting at.
>
>> 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.
>
> Except for accessability, I'd agree. The HTML will still be meaningfull.
Accessibility is the rule, not an exception. The ALT attributes are
needed for the HTML to make sense when - for example - images are
disabled or unavailable. Then there are blind people, users of text
browsers, etc.
S.T.
> 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? 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.
>
> As mentioned, no (Google "Dojo Foundation").
Yeah, I see that now. Got confused as the bulk of your post was about
the toolkit site. 450K is steep, especially given 400K of it is images.
~200K is in sponsor logos - they may have had their hands tied there.
> But I'm glad you brought up that site. Assuming your estimates are
> correct, it's still way too large (no matter what your mechanical Turk
> says).
150K and 30 requests seems reasonable this day in age. I'd personally
sprite the six icons on the bottom to save a few K and get rid of 5
requests, but I wouldn't rush to do it if there were other aspects of
the site to focus on.
CNN home page is a full meg (varies slightly by photos). Gets slightly
better for dial-up users after the first visit as 650K is various JS
stuff that gets cached, but they'll still lose a big chunk of dial-up
users. They don't care and it's not from ignorance.
Sites are no longer built to serve the lowest common denominator, Jakob
Nielsen be damned.
> A few excerpts:-
>
[snip]
You hate the popular libraries. There is a real probability jQuery, Dojo
and YUI are the cause of the Darfur genocide. I get it.
>
> And as you like to compare everything to cinsoft.net. I see on Alexa
> that this particular site is going down the proverbial toilet (at a rate
> of knots).
>
> http://www.alexa.com/siteinfo/dojotoolkit.com#trafficstats
>
> ...so there may be some hope for the Web after all:-
jQuery is evolving into an effective standard at the expense of other
libraries. There will remain a significant user-base for the current
libraries, and by no means is it a 'done deal', but the lion's share is
now headed one direction. There are pros and cons to this consolidation.
> http://www.alexa.com/siteinfo/cinsoft.net?p=tgraph&r=home_home
>
> Not bad for a domain that up until recently had no home page. :)
You've got quite a bit of catch-up to go. I'd suggest you port some of
the various jQuery (or whomever) tutorials so people can see how it
works. Far easier to learn by example.
> And, one final note (or nail), I see that Dojo deleted my branch. I'm
> not complaining, of course, as I told them to (don't have time to walk
> them through it and am tired of watching them stumble around). Didn't
> take them 24 hours to jump to it either. That's it for them; they've
> thrown their last paddle overboard. :)
>
> And if anyone is crazy enough to actually want to fork Dojo (from a
> relatively sane starting point), I'd be glad to send the files and
> instructions.
No idea what you did for them, but sounds like a generous offer.
David Mark
Yep, there's a fork that uses it (when available) My Library.
> The method
> was never intended to be available in HTML (and never intended for web).
> Those who initially made the mistake of using it figured out not to do
> that over a year ago.
At least a year ago. I've never bothered to take it out My Library
though as that fork isn't used by anything but older FF versions. There
is one highly unnecessary feature test for margins on the HTML element
that I should remove though (it's been on my list forever).
>
> I see they make an XHR to:
>
> http://www.dojofoundation.org/dojango/media/dojango/_base.js
They are positively wacky with that shit. They seem to feel that
downloading (and evaluating) scripts is forward-thinking and the Web
will eventually "catch up" and require such "advanced" technology. Of
course, if you saw their "global" eval method... :)
It is all part of the idiotic train of thought that every document will
eventually be a huge application, rendering navigation (what browsers
are made to do) an antiquated concept. Of course, if you just avoid the
unload listeners, you can have a huge application spread across multiple
documents and leverage the browsers' intuitive navigation interface.
>
> - to which the server responds with:
>
> | dojo.provide("dojango._base");
> | dojo.mixin(dojango, {
> | test: function(){
> | console.log("test");
> | }
> | });
Whatever. You get the idea that they just slap things together, observe
that they seem to work in whatever browsers they have on hand? Actually
reviewing these messes must be relegated to the "waste of time"
category. Then they end up huge messes that throw exceptions in the
latest browser and not enough time to go back and rewrite them all. I
dare say they never even spoke to Time! :)
>
> Which has the result of calling their misnamed namespacing methods
> "dojo.getObject" and "dojo._getProp" all to create an adapter for
> console.log, thus requiring the use of firebug lite or something that
> adds a global `console` method.
Whatever again. I went over their ill-advised Firebug Lite nonsense
several times.
>
> I don't care much what they do with the code on their site, and in fact
> the code on my site is a little old, too (7 years or so).
But do your sites still function without throwing exceptions?
>
> What bothers me about Dojo is the code behind the marketing.
Yes, it is quite bothersome. Talk to the people behind it and you will
find they are bothersome as well. They refer to themselves as "awesome
hackers" (which always turned my stomach) and staunchly refuse to
discuss any abstract concepts, preferring to go strictly by what they
can see and feel (in the current browsers they "care" about, never mind
what the future or past holds). It's no way to run a rodeo.
> Through the
> website and through presentations, the founders of Dojo instill a sense
> of confidence and empowerment to the project managers who consider using
> Dojo.
Yes, what a crock.
> That in and of itself is not bad -- it is a great thing to be
> able to win an audience over (I need to improve in that area).
It's called lying in my book. At best it is perpetuating myths and
delusions as facts.
>
> The problem is the code itself. The code is large. There is disturbingly
> faulty logic in the core of dojo itself (some of it discussed in this NG
> archives).
It's the tip of the iceberg. Wait until you see my review of Dojo 1.4
(coming soon to cinsoft.net). Of course, it looks very much like Dojo
1.3 as nobody over there touches the core, which is understandable once
you grasp the depth of their misunderstandings (who wants to fiddle with
a foundation that they can't even explain).
>
> Projects that have used Dojo FWIS, tended to have performance issues and
> take too much effort to maintain.
Yes.
>
> Significantly larger projects (72+ man months) having a poor outcome or
> total failure is a more significant failure than a smallish website that
> throws a few errors and hangs for two seconds. The dojofoundation isn't
> much worse than any other pop website nowadays.
>
Er, size your browser window down a few notches... :)
David Mark
> On 3/10/2010 3:07 AM, David Mark wrote:
>> 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? 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.
>>
>> As mentioned, no (Google "Dojo Foundation").
>
> Yeah, I see that now. Got confused as the bulk of your post was about
> the toolkit site.
Which, JFTR is not the site you cited either (it's org, not com).
> 450K is steep, especially given 400K of it is images.
> ~200K is in sponsor logos - they may have had their hands tied there.
450K is obscene and I have no doubt that it could be done with minimal
degradation for a quarter of that.
>
>> But I'm glad you brought up that site. Assuming your estimates are
>> correct, it's still way too large (no matter what your mechanical Turk
>> says).
>
> 150K and 30 requests seems reasonable this day in age.
The day and age are irrelevant. That site doesn't do anything special.
> I'd personally
> sprite the six icons on the bottom to save a few K and get rid of 5
> requests, but I wouldn't rush to do it if there were other aspects of
> the site to focus on.
>
> CNN home page is a full meg (varies slightly by photos).
Then they have incompetent developers. Not news for a news site, that's
for sure.
> Gets slightly
> better for dial-up users after the first visit as 650K is various JS
> stuff that gets cached, but they'll still lose a big chunk of dial-up
> users. They don't care and it's not from ignorance.
It is most assuredly from ignorance. 650K of JS is the punchline to a
bad joke.
>
> Sites are no longer built to serve the lowest common denominator, Jakob
> Nielsen be damned.
We've been over this. The script for my favorite mockup is 15K. My
whole library is 150K. What the hell could they be doing that needs 650K?!
>
>> A few excerpts:-
>>
>
> [snip]
>
> You hate the popular libraries. There is a real probability jQuery, Dojo
> and YUI are the cause of the Darfur genocide. I get it.
That's just stupid (and not the slightest bit relevant to what was
snipped). But they are contributing to businesses pissing away lots of
money on bandwidth, lost customers, unnecessary maintenance, etc.
>
>>
>> And as you like to compare everything to cinsoft.net. I see on Alexa
>> that this particular site is going down the proverbial toilet (at a rate
>> of knots).
>>
>> http://www.alexa.com/siteinfo/dojotoolkit.com#trafficstats
>>
>> ...so there may be some hope for the Web after all:-
>
> jQuery is evolving into an effective standard at the expense of other
> libraries.
No, check jQuery's logo. It is devolving and will never be any sort of
standard. Technology just doesn't work like that.
> There will remain a significant user-base for the current
> libraries, and by no means is it a 'done deal', but the lion's share is
> now headed one direction. There are pros and cons to this consolidation.
It's already hit its peak. It's got nowhere to go but away.
>
>> http://www.alexa.com/siteinfo/cinsoft.net?p=tgraph&r=home_home
>>
>> Not bad for a domain that up until recently had no home page. :)
>
> You've got quite a bit of catch-up to go.
I'm just getting started. :)
> I'd suggest you port some of
> the various jQuery (or whomever) tutorials so people can see how it
> works. Far easier to learn by example.
I agree that I need more examples. I'm working on a big one right now
that I am sure will be popular (very "wowie").
>
>> And, one final note (or nail), I see that Dojo deleted my branch. I'm
>> not complaining, of course, as I told them to (don't have time to walk
>> them through it and am tired of watching them stumble around). Didn't
>> take them 24 hours to jump to it either. That's it for them; they've
>> thrown their last paddle overboard. :)
>>
>> And if anyone is crazy enough to actually want to fork Dojo (from a
>> relatively sane starting point), I'd be glad to send the files and
>> instructions.
>
> No idea what you did for them, but sounds like a generous offer.
>
I got rid of all of the browser sniffing and synchronous XHR. Also
cleaned every miserable file up to the point where they passed JSLint
(finding many typos and other gaffes along the way). Cleaned up some of
the comments too, which varied from confused to nauseating in places.
Those are the broad strokes and it is by no means a completed mission,
but I did get to the point of running (and passing) their unit tests (in
the major browsers at least). Due to circumstances beyond my control,
the effort was cut short.
S.T.
>> page "passes" or not.
>
> True. What matters is that the page works as expected.
> However, for invalid HTML, the HTML specification doesn't say what
> the HTML means or how it will be parsed. I.e., you cannot possibly
> know whether it will work as expected. That's why invalidly nested
> HTML is bad.
I worry about what the marketplace has specified, not a W3C decade-long
adventure in producing a "Recommendation" that sometimes is, sometimes
is not followed.
W3C is like the United Nations for geeks. A lumbering organization that
periodically produces some documents that the world then decides whether
they want to follow them or not. What they say means nothing to my
users. What my users see and interact with is what matters to my users.
I don't care, at all, about any document or specification the W3C
produces. I only care about what the market does (or doesn't do) with
those specifications.
>> Escaping every ampersand in a URL is wasted time.
>
> Here I disagree. Again you cannot predict what meaning a browser will
> give to your characters, so you can't know that it will work as
> expected.
I see where you're coming from. It's not a bad practice by any means --
and perhaps I should put more effort into it -- but I'm not too worried
about it.
Put it this way, if a browser comes out and cannot successfully handle
<a href="page.php?a=1&b=2">link</a> -- it's not going to have any market
share to warrant consideration.
>> That page says an inline element with position: absolute is computed
>> as a block level element, which was my original point.
>
> That's CSS, not HTML.
> If you write "<span> foo<H1> bar</H1> baz</span>", it is likely to
> be interpreted as "<span> foo</span><H1> bar</h1> baz ". No amount
> of inline positioning will make the H1 a child of the span.
Again, I'm not advocating nesting blocks within inline -- not a good
practice. But should it occur it's really not a big deal. For instance
if I have:
<span class="blue">
We sell blue widgets cheap!
</span>
... and decide, for SEO purposes, I want:
<span class="blue">
We sell
<h2 style="display: inline; font-size:1em;">blue widgets<h2>
cheap!
</span>
... I'm not going to panic. Maybe I'll get around to restructuring
outlying tags, but it won't be because I'm worried whether I'll pass W3C
validation.
An unlikely example. I'd agree it's best to avoid Hx tags inside spans,
but objected to a scathing condemnation of Dojo's site because they had
a block inside an inline and had the audacity to allow CSS to ensure the
user sees the intended effect. Suggesting they swap the absolute
positioned span to an absolute positioned div is fine. Mocking them
because they haven't bothered to was absurd.
>
>>> 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.
>
> But do you *know* what the browser does with invalid markup?
> All browsers?
I don't know what all browsers do with valid markup. I know what the
overwhelming percentage of browser visits to my sites do with my markup.
That's the best I can do.
I have no delusions of my pages being future-proof, whether they
validate or not. I think anyone who believes their pages are
future-proof because they validate on W3C is kidding themselves.
> Have you tried dumping the DOM of the page to see what it's really
> turned into? (And if it's the right thing, why not just write that
> to begin with).
Not sure exactly what you're asking. Not sure how to dump the DOM.
If you're talking computed styles, I tested if an absolute positioned
span was rendered 'display: block' on various browsers
Also tested innerText/textContent on <span>a<h1>b</h1></span> to see
current browsers rendered it as <span>a</span><h1>b</h1>. Didn't appear
to be the case - always returned 'ab'.
David Mark
> On 3/10/2010 8:17 AM, Lasse Reichstein Nielsen wrote:
>> "S.T."<an...@anon.com> writes:
>>> Validating is a debugging tool - that's it. It's not important if a
>>> page "passes" or not.
>>
>> True. What matters is that the page works as expected.
>> However, for invalid HTML, the HTML specification doesn't say what
>> the HTML means or how it will be parsed. I.e., you cannot possibly
>> know whether it will work as expected. That's why invalidly nested
>> HTML is bad.
>
> I worry about what the marketplace has specified, not a W3C decade-long
> adventure in producing a "Recommendation" that sometimes is, sometimes
> is not followed.
The marketplace specifies sites that work. The recommendations are
followed by the browser developers more often than they are not; and
regardless, they are all we have to go on as the browser developers
don't share their error correction algorithms.
>
> W3C is like the United Nations for geeks. A lumbering organization that
> periodically produces some documents that the world then decides whether
> they want to follow them or not. What they say means nothing to my
> users. What my users see and interact with is what matters to my users.
But you can't judge your work by empirical evidence as you can't see
every browser/mode/configuration, past, present and future. To ensure
that your sites work (and continue to work) in the maximum number of
environments, validating your markup is an essential first step. After
that you need to consider what scripts you will allow between your
markup and your users. Just because you can't see something fail
doesn't mean it isn't failing (or will fail) for somebody somewhere.
You start out with no scripts, which means there is nothing to foul up
your documents. With each script that you add, particularly if you do
not know _exactly_ what they are doing, you increase the likelihood of
pissed off users.
>
> I don't care, at all, about any document or specification the W3C
> produces. I only care about what the market does (or doesn't do) with
> those specifications.
But you can't quantify that. Just be assured that the browser
developers do care about those documents, so they represent your only
solid clues as to what browsers can be expected to do. Trying to
observe browsers to determine what will fly is folly. You could more
easily make general predictions about the behavior of birds by observing
pigeons at the park.
>
>>> Escaping every ampersand in a URL is wasted time.
>>
>> Here I disagree. Again you cannot predict what meaning a browser will
>> give to your characters, so you can't know that it will work as
>> expected.
>
> I see where you're coming from. It's not a bad practice by any means --
> and perhaps I should put more effort into it -- but I'm not too worried
> about it.
It shouldn't take more than five minutes to clean up the typical invalid
document. The bogus entities are some of the easiest to spot and
correct. You shouldn't even need a validation service to fix those, but
should always use one to check your work (another five seconds or so).
Only then can you stop worrying about the problem as it will no longer
exist.
>
> Put it this way, if a browser comes out and cannot successfully handle
> <a href="page.php?a=1&b=2">link</a> -- it's not going to have any market
> share to warrant consideration.
You have no idea what a browser (or other agent, search engine, etc.)
may do in the future, even those that already enjoy a healthy share of
the market. Look what happens to bad sites every time a new version of
IE comes out. In most cases, it is the sites, not the browser that is
to blame. I validate my markup and CSS, use sound scripts with
appropriate feature testing and I can't remember the last time I had to
change a thing due to a new browser coming out (and contrary to your
previous assertion, I primarily work on very complicated sites and
applications). Coincidence?
>
>>> That page says an inline element with position: absolute is computed
>>> as a block level element, which was my original point.
>>
>> That's CSS, not HTML.
>> If you write "<span> foo<H1> bar</H1> baz</span>", it is likely to
>> be interpreted as "<span> foo</span><H1> bar</h1> baz ". No amount
>> of inline positioning will make the H1 a child of the span.
>
> Again, I'm not advocating nesting blocks within inline -- not a good
> practice. But should it occur it's really not a big deal. For instance
> if I have:
You are very quick to dismiss what you perceive as small issues. Why
not just do things right and avoid the cumulative effect of such an
attitude, which is invariably undesirable behavior (if not today,
tomorrow and if not your browser, one of your users').
>
> <span class="blue">
> We sell blue widgets cheap!
> </span>
>
> ... and decide, for SEO purposes, I want:
>
> <span class="blue">
> We sell
> <h2 style="display: inline; font-size:1em;">blue widgets<h2>
> cheap!
> </span>
Search engines can't stand tag soup. ;)
>
> ... I'm not going to panic.
Of course not, you should simply structure your document appropriately
from the start and the search engines will love them. If you find
yourself trying to fool the search engines, you are doing something wrong.
> Maybe I'll get around to restructuring
> outlying tags, but it won't be because I'm worried whether I'll pass W3C
> validation.
There's no reason to worry about _why_ you are doing it right. If you
simply do things right, everything else (e.g. search engines, disabled
visitors, oddball browsers) will take care of itself.
>
> An unlikely example. I'd agree it's best to avoid Hx tags inside spans,
Yes, of course it is. It's a very silly rookie mistake and I only
pointed it out as the author in question had puffed about being an
"expert" on markup and didn't like hearing that he wasn't. Perhaps
he'll learn something from this dialog. Or perhaps not if I am any
judge of human nature. :(
> but objected to a scathing condemnation of Dojo's site because they had
> a block inside an inline and had the audacity to allow CSS to ensure the
> user sees the intended effect.
That was one of dozens of rookie mistakes detailed.
> Suggesting they swap the absolute
> positioned span to an absolute positioned div is fine. Mocking them
> because they haven't bothered to was absurd.
It wasn't mocking. I'm okay, they suck. Now that's mocking. :)
>
>>
>>>> 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.
>>
>> But do you *know* what the browser does with invalid markup?
>> All browsers?
>
> I don't know what all browsers do with valid markup. I know what the
> overwhelming percentage of browser visits to my sites do with my markup.
> That's the best I can do.
You can't possibly know that and certainly whatever you do know in that
regard has a near future expiration date as new browsers (and browser
versions) come out constantly these days. Add another five minutes of
effort (and a bit more understanding) to your best.
>
> I have no delusions of my pages being future-proof, whether they
> validate or not.
All you can do is your best. :) It's worked for me for a very long
time. That's history, not delusion. In contrast, your position sounds
very much like eschewing smoke detectors because you have no delusions
of your house being fireproof. Doesn't make any sense does it?
> I think anyone who believes their pages are
> future-proof because they validate on W3C is kidding themselves.
It's just one measure. Put the detectors in. Granted, your house may
still burn down.
>
>> Have you tried dumping the DOM of the page to see what it's really
>> turned into? (And if it's the right thing, why not just write that
>> to begin with).
>
> Not sure exactly what you're asking. Not sure how to dump the DOM.
Firebug is one tool that will let you inspect the DOM. Newer browsers
have similar tools built in.
>
> If you're talking computed styles, I tested if an absolute positioned
> span was rendered 'display: block' on various browsers
Well that was a waste of time as you could have just read the specs you
seem so keen on avoiding. ;)
>
> http://jsfiddle.net/9xrYg/
>
> Also tested innerText/textContent on <span>a<h1>b</h1></span> to see
> current browsers rendered it as <span>a</span><h1>b</h1>. Didn't appear
> to be the case - always returned 'ab'.
>
Current browsers?
S.T.
Fascinating tidbit Andrew.
I'm guessing validating is important to programmer types because many
have personalities that gravitate toward 0/1 - true/false structure.
Unfortunately the web offers no such measure. Validating against W3C
gives the illusion of such measure, but the scale is irrelevant.
David Mark
> On 3/9/2010 7:10 PM, Andrew Poulos wrote:
>> On 10/03/2010 11:43 AM, S.T. wrote:
>>> Validating is a debugging tool - that's it. It's not important if a page
>>> "passes" or not.
>>
>> For me, not caring about validation is the equivalent of incompetence.
>
> Fascinating tidbit Andrew.
>
> I'm guessing validating is important to programmer types
If you have been reading the replies, you should have realized by now
that it is important to competent and trustworthy types.
> because many
> have personalities that gravitate toward 0/1 - true/false structure.
That makes no sense at all. Like I said, you should take the five
minutes to install a smoke detector. Yes (obviously), your house may
still burn down.
> Unfortunately the web offers no such measure.
You take measures. The Web just so happens to offer tools to help.
> Validating against W3C
> gives the illusion of such measure, but the scale is irrelevant.
So I say take five minutes and validate and at least skim the results.
You say "the scale is irrelevant?" What does that even mean?
S.T.
> But you can't judge your work by empirical evidence as you can't see
> every browser/mode/configuration, past, present and future. To ensure
> that your sites work (and continue to work) in the maximum number of
> environments, validating your markup is an essential first step. After
> that you need to consider what scripts you will allow between your
> markup and your users. Just because you can't see something fail
> doesn't mean it isn't failing (or will fail) for somebody somewhere.
> You start out with no scripts, which means there is nothing to foul up
> your documents. With each script that you add, particularly if you do
> not know _exactly_ what they are doing, you increase the likelihood of
> pissed off users.
You have a tendency to speak of web pages as static entities that need
to survive the test of time. That's rarely the case.
Only the content need "survive". More often than not, and nearly always
on any large-scale site, content is safely tucked away in a database, or
stored as a number of files in a directory (i.e. images) or other
self-contained manner. Often content has a long life cycle.
The markup to render this content, the server-side scripting to
manipulate and present the content and the client-side scripting to
interact with this content is ever-evolving. It's easily fixed. It's
frequently changed/updated/redone from scratch. It has a shorter life
cycle than the browser market, and infinitely shorter than the W3C.
I can see the points you're making about the dangers of invalid markup
and popular js library's to a current page's future. However there is
(virtually) no need to protect my site's markup and interactive
functionality from the future. It's not intended to make it there.
Perfect the content for use in the future. Work in the 'now' for the
presentation.
Short on time.
David Mark
> On 3/10/2010 11:54 AM, David Mark wrote:
>> But you can't judge your work by empirical evidence as you can't see
>> every browser/mode/configuration, past, present and future. To ensure
>> that your sites work (and continue to work) in the maximum number of
>> environments, validating your markup is an essential first step. After
>> that you need to consider what scripts you will allow between your
>> markup and your users. Just because you can't see something fail
>> doesn't mean it isn't failing (or will fail) for somebody somewhere.
>> You start out with no scripts, which means there is nothing to foul up
>> your documents. With each script that you add, particularly if you do
>> not know _exactly_ what they are doing, you increase the likelihood of
>> pissed off users.
>
> You have a tendency to speak of web pages as static entities that need
> to survive the test of time. That's rarely the case.
No, you have misconstrued my message somehow. Static or not, the same
rules apply.
>
> Only the content need "survive". More often than not, and nearly always
> on any large-scale site, content is safely tucked away in a database, or
> stored as a number of files in a directory (i.e. images) or other
> self-contained manner.
Stored as a number of files in a directory? That pretty much describes
anything and everything. And yes, some of those files may be databases.
> Often content has a long life cycle.
Some content does, some content doesn't. Irrelevant regardless.
>
> The markup to render this content, the server-side scripting to
> manipulate and present the content and the client-side scripting to
> interact with this content is ever-evolving.
You aren't really saying much of substance. It sounds as if you are
building towards an excuse to just do anything and never mind what
happens as a consequence.
> It's easily fixed.
You don't have to fix what is not broken.
> It's
> frequently changed/updated/redone from scratch.
What is? You've pretty much said everything is redone from scratch often.
> It has a shorter life
> cycle than the browser market, and infinitely shorter than the W3C.
You are focusing on the future, but I take it you haven't mastered the
past or present yet.
>
> I can see the points you're making about the dangers of invalid markup
> and popular js library's to a current page's future.
And its present (which is influenced by the past).
> However there is
> (virtually) no need to protect my site's markup and interactive
> functionality from the future.
Ah, so you are talking about _your_ sites. Again, concentrate on the
present for now.
> It's not intended to make it there.
And it surely won't if it is already broken in the present.
>
> Perfect the content for use in the future.
"Perfecting" content is beyond the scope of this discussion. I'm not
even sure what that means in most contexts.
> Work in the 'now' for the
> presentation.
The CSS? Yes, it should work today (and hopefully tomorrow as well or
your future visitors will be upset). And no, it doesn't make the
slightest bit of sense to perpetually rewrite style sheets (or markup
for that matter).
It's a good thing that the W3C is so slow. It makes it easy to reuse
the same templates for years on end. And now that the browsers (at
least the majors) have converged somewhat, it is even less likely that
you would need to jump through hoops for them either. I have the
sneaking suspicion that you are trying to justify doing things in some
extremely hard way that is completely alien to me (and no, it isn't
because I think of all Web pages as static).
>
> Short on time.
>
If you knew Time as well as I do... :)
Garrett Smith
> Garrett Smith wrote:
>> David Mark wrote:
>>> SteveYoungGoogle wrote:
>>>> On Mar 10, 12:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>> David Mark wrote:
>>>>>> SteveYoungGoogle wrote:
>>>>>>> On Mar 10, 5:42 am, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>>> S.T. wrote:
>>>>>>>>> On 3/8/2010 1:04 AM, David Mark wrote:
[...]
>> The problem is the code itself. The code is large. There is disturbingly
>> faulty logic in the core of dojo itself (some of it discussed in this NG
>> archives).
>
> It's the tip of the iceberg. Wait until you see my review of Dojo 1.4
> (coming soon to cinsoft.net). Of course, it looks very much like Dojo
> 1.3 as nobody over there touches the core, which is understandable once
> you grasp the depth of their misunderstandings (who wants to fiddle with
> a foundation that they can't even explain).
>
The core has many dependencies and so trying to adjust that, with so
many things that require it, is a risk. OTOH, the problems won't go away
by ignoring them. Fixing the problems sounds like a good idea, but then
there would have to be somebody capable of doing that, and if it is
going to be done by the original authors, then much learning should take
place prior to doing that (or different mistakes will be made).
Regaring your review, I would like to suggest the following document:
http://www.jibbering.com/faq/notes/review/
I'd also like comments on how it can be improved.
>> Projects that have used Dojo FWIS, tended to have performance issues and
>> take too much effort to maintain.
>
> Yes.
>
>> Significantly larger projects (72+ man months) having a poor outcome or
>> total failure is a more significant failure than a smallish website that
>> throws a few errors and hangs for two seconds. The dojofoundation isn't
>> much worse than any other pop website nowadays.
>>
>
> Er, size your browser window down a few notches... :)
The Dojo site is a fine incompetence exemplar, but so are others.
A bad corporate website is not nearly as bad as a large corporate
software project failing. Half a million dollars is not something that
should be thrown in the trash.
Eric Bednarz
> Put it this way, if a browser comes out and cannot successfully handle
> <a href="page.php?a=1&b=2">link</a> -- it's not going to have any
> market share to warrant consideration.
That is *one* (1) example to support your thesis. Browsers with any
market share commonly support at least 96 counter examples.
Garrett Smith
Good example, it is also important consider characters that need to be
percent-encoded, such as: (, ), %.
And that's just for A href.
If the HTML is valid, the program can be focused more on the
requirements problems and not how browsers handle errors.
Andrew Poulos
For me Opera 10.01 1893 says
Error!
Could not connect to remote server
You tried to access the address http://www.dojofoundation.org/, which is
currently unavailable. Please make sure that the Web address (URL) is
correctly spelled and punctuated, then try reloading the page.
Andrew Poulos
David Mark
> David Mark wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> SteveYoungGoogle wrote:
>>>>> On Mar 10, 12:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>> David Mark wrote:
>>>>>>> SteveYoungGoogle wrote:
>>>>>>>> On Mar 10, 5:42 am, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>>>> S.T. wrote:
>>>>>>>>>> On 3/8/2010 1:04 AM, David Mark wrote:
>
>
> [...]
>
>>> The problem is the code itself. The code is large. There is disturbingly
>>> faulty logic in the core of dojo itself (some of it discussed in this NG
>>> archives).
>>
>> It's the tip of the iceberg. Wait until you see my review of Dojo 1.4
>> (coming soon to cinsoft.net). Of course, it looks very much like Dojo
>> 1.3 as nobody over there touches the core, which is understandable once
>> you grasp the depth of their misunderstandings (who wants to fiddle with
>> a foundation that they can't even explain).
>>
>
> The core has many dependencies and so trying to adjust that, with so
> many things that require it, is a risk.
I assume by dependencies, you mean the modules built on top of the core.
Yes, there are a lot of them (they tend to throw anything and
everything in there, regardless of whether it actually works). But if
you know what you are doing (and ostensibly _somebody_ involved with
that project does), it's not that bad. Lots of interdependencies in the
core itself, but that's more of an inconvenience than a real issue. The
thing is, most of the individual modules are pretty basic. Their
biggest claim to "fame" is that they have a bunch of widgets, supposedly
by IBM, but in reality the work of someone called "bill". They are some
pretty awful widgets and somehow their focus is adding more "themes"
(they have all of two, with a distinct style sheet per widget), rather
than making the widget code competent.
Anyway, I did most of the heavy lifting already (particularly in the
core). But then it became apparent that the other contributors didn't
see the whole as a mess and only wanted to discuss one tiny patch at a
time (which would mean completing the transformation would take
approximately fifty years). :(
> OTOH, the problems won't go away
> by ignoring them.
Ain't that the truth.
> Fixing the problems sounds like a good idea, but then
> there would have to be somebody capable of doing that, and if it is
> going to be done by the original authors, then much learning should take
> place prior to doing that (or different mistakes will be made).
Exactly! But, oddly enough, the original authors don't see it that way.
:) In fact, the very idea that so many changes (in code and
understanding) could be needed caused a complete nullification.
>
> Regaring your review, I would like to suggest the following document:
>
> http://www.jibbering.com/faq/notes/review/
Yes, I've read it. IIRC, I agreed with much of it.
>
> I'd also like comments on how it can be improved.
I'll see if I can make some time for that, but I am swamped at the moment.
>
>>> Projects that have used Dojo FWIS, tended to have performance issues and
>>> take too much effort to maintain.
>>
>> Yes.
>>
>>> Significantly larger projects (72+ man months) having a poor outcome or
>>> total failure is a more significant failure than a smallish website that
>>> throws a few errors and hangs for two seconds. The dojofoundation isn't
>>> much worse than any other pop website nowadays.
>>>
>>
>> Er, size your browser window down a few notches... :)
>
> The Dojo site is a fine incompetence exemplar, but so are others.
I was referring to the Foundation site. I've never seen anything quite
so resolution-challenged. It's like the developer(s) had their browsers
maximized at a relatively high resolution during the entire testing
process (assuming there was a testing process). And the fact that it is
throwing exceptions in brand new browsers (e.g. Opera 10) goes to show
how anything based on Dojo (even basic pages by the authors/supporters
of the library) falls apart in short order (requiring a huge upgrade
ordeal). There's a business opportunity in there somewhere as I know a
lot of companies are currently stuck in such endless cycles behind their
firewalls. I'm working on that as part of my new site. I can offer a
far more future-proof Dojo or fix the one they have.
>
> A bad corporate website is not nearly as bad as a large corporate
> software project failing. Half a million dollars is not something that
> should be thrown in the trash.
That's what I'm talking about. ;)
David Mark
And isn't that the pitch of these things? They want to save everyone
from the rigors of front-end development, yet their developers are
almost exclusively from the "just gettin' stuff done" school where
anything goes, so long as they can see it "work" in their test browsers.
Of course, the marketers and shills put a different spin on it. They
are just being "pragmatic" (and some actually _believe_ that BS). I
guess it's not a lie if you believe it. :)
Garrett Smith
> Garrett Smith wrote:
>> David Mark wrote:
>>> Garrett Smith wrote:
>>>> David Mark wrote:
>>>>> SteveYoungGoogle wrote:
>>>>>> On Mar 10, 12:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>> David Mark wrote:
>>>>>>>> SteveYoungGoogle wrote:
>>>>>>>>> On Mar 10, 5:42 am, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>>>>> S.T. wrote:
>>>>>>>>>>> On 3/8/2010 1:04 AM, David Mark wrote:
>>
[...]
> I was referring to the Foundation site.
Yes I know and I have seen the resizing issue there. There are many
sites that are worse, breaking functionality. Pubmed, for example. I
love the content but what an awful UI.
The web is a mess.
I've never seen anything quite
> so resolution-challenged. It's like the developer(s) had their browsers
> maximized at a relatively high resolution during the entire testing
> process (assuming there was a testing process). And the fact that it is
> throwing exceptions in brand new browsers (e.g. Opera 10)
Firefox 3.5 - "An invalid or illegal string was specified" code: "12"
I get that every time I click on a tab header.
And in Safari 4 - "Error: SYNTAX_ERR: DOM Exception 12"
I don't have the energy to dig through their obfuscated code to find
exactly what it is, but it appears to be dom-related.
The iframe to try to fix the history has some odd markup:
http://www.dojofoundation.org/media/documents/iframe_history.html
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></meta>
David Mark
> David Mark wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> Garrett Smith wrote:
>>>>> David Mark wrote:
>>>>>> SteveYoungGoogle wrote:
>>>>>>> On Mar 10, 12:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>>> David Mark wrote:
>>>>>>>>> SteveYoungGoogle wrote:
>>>>>>>>>> On Mar 10, 5:42 am, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>>>>>> S.T. wrote:
>>>>>>>>>>>> On 3/8/2010 1:04 AM, David Mark wrote:
>>>
> [...]
>
>> I was referring to the Foundation site.
>
> Yes I know and I have seen the resizing issue there. There are many
> sites that are worse, breaking functionality. Pubmed, for example. I
> love the content but what an awful UI.
That one was pretty much the pits in my book. I've seen some bad sites,
but when you've got a single page that reaches for the stars with
Ajax-ified sliding of content bits and fails to even allow reading the
content, you've got a candidate for worst site in history. Even a basic
page with no style, no script, etc. would beat that. Yet, somebody
somewhere signed off on that thing as "cool" and would likely have
sniffed at doing a basic site with normal navigation. I think most Web
developers try to please themselves (and must be extraordinarily easy to
please).
>
> The web is a mess.
That's an understatement. And you should see the train wrecks behind
most of it. :)
>
> I've never seen anything quite
>> so resolution-challenged. It's like the developer(s) had their browsers
>> maximized at a relatively high resolution during the entire testing
>> process (assuming there was a testing process). And the fact that it is
>> throwing exceptions in brand new browsers (e.g. Opera 10)
>
> Firefox 3.5 - "An invalid or illegal string was specified" code: "12"
Yes and that browser was certainly in widespread use (and was one they
asserted to "care" about) at the time that page was created. Makes you
wonder what sort of horror show you would get in a browser they don't
care about. It simultaneously gives Open Source and the Web black eyes.
>
> I get that every time I click on a tab header.
Yes, you wonder if anybody bothered to test the page at all. Wonder how
it will fare in FF4. I haven't even tried it in IE (lately), but I
imagine it can be coaxed into throwing errors there as well.
>
> And in Safari 4 - "Error: SYNTAX_ERR: DOM Exception 12"
Now I know that's one browser they "care" about. In fact, it's the only
Safari they claim to "support". Makes you wonder how anybody gets
sucked into using Dojo to create applications when it is clear the
people promoting it are out of their league creating a simple document.
>
> I don't have the energy to dig through their obfuscated code to find
> exactly what it is, but it appears to be dom-related.
Yeah, they apparently don't have the energy either. You know I reported
these problems a long time ago.
>
> The iframe to try to fix the history has some odd markup:
> http://www.dojofoundation.org/media/documents/iframe_history.html
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"></meta>
LOL. The whole idea of using an IFrame to "fix history" so that
visitors won't be "inconvenienced" by navigation is ludicrous beyond
belief, but such thinking is blasphemy to this bunch. Then I guess when
you have 500K pages with 50 http requests, navigation can be a bit
sluggish. They've designed themselves into a box and can't punch their
way out of it to save their lives (or reputation). IMO, people who
think like that belong in rubber rooms, not cubicles (and they sure as
hell shouldn't be let near company Websites).
Richard Cornford
> On 3/10/2010 8:17 AM, Lasse Reichstein Nielsen wrote:
>>> Validating is a debugging tool - that's it. It's not important
>>> if a page "passes" or not.
>
>> True. What matters is that the page works as expected.
>> However, for invalid HTML, the HTML specification doesn't
>> say what the HTML means or how it will be parsed. I.e., you
>> cannot possibly know whether it will work as expected. That's
>> why invalidly nested HTML is bad.
>
> I worry about what the marketplace has specified, not a W3C
> decade-long adventure in producing a "Recommendation" that
> sometimes is, sometimes is not followed.
> An unlikely example. I'd agree it's best to avoid Hx tags inside
> spans, but objected to a scathing condemnation of Dojo's site
> because they had a block inside an inline and had the audacity
> to allow CSS to ensure the user sees the intended effect.
> Suggesting they swap the absolute positioned span to an absolute
> positioned div is fine. Mocking them because they haven't bothered
> to was absurd.
It is not as absurd as it may seem. It does directly reflect on Dojo
as a scripting project, and on its author's, experience/understanding
in relation to DOM scripting.
It has long been known that when presented with structurally invalid
mark-up the error correction applied by web browsers can result in
(sometimes radically) divergent DOM structures (including structures
where some elements become the decedents/children of multiple elements
(which is not possible in a true tree-like structure such as the DOM
is supposed to be).
This is very significant for anyone who is trying to create non-
trivial DOM scripts (which is presumably something Dojo is attempting
to qualify as), and so should be understood by any individual involved
in such a task. The result of that understanding is usually an
appreciation of the value of using structurally valid mark-up (as
represented by the participants in this group[1]), and so observing
the use of invalid mark-up implies a failure to understand this point
(a shortfall of experience or knowledge).
Here is the URL of post of mine from 2005 that included a number of
test cases (based on real-world examples from questions asked on this
group):-
<URL: http://groups.google.com/group/comp.lang.javascript/msg/2672da2374ec16c2
>
Some of the handling of the test-case code has changed in more modern
browsers (showing that error-correction in any given browser is not
even stable over time), but it is still the case that you get to see 3
different DOM structures in, say, Firefox, IE and Opera.
Richard.
[1] There may be obsessive, anal, etc. individuals who insist on the
use of valid mark-up because following rules (regardless of any need)
makes them feel better, but there are practical, demonstrable and
significant consequences of the use of structurally invalid mark-up in
relation to DOM scripting. So the motivation for insisting on the use
of valid mark-up elsewhere (in other groups, in relation to other
fields) may not be entirely valid, but in the context of DOM
scripting, at least, the arguments for structural validity in mark-up
are substantial. Here, only the ignorant and/or inexperienced (or in
VK's case, barking mad) would be happy to see structurally invalid
mark-up.
S.T.
> That is *one* (1) example to support your thesis. Browsers with any
> market share commonly support at least 96 counter examples.
>
> <http://bednarz.nl/tmp/entref/>
>
Point taken.
Perhaps naively, I thought the format had to be &xxx; (with the trailing
semi-colon) and figured the odds of me naming a GET something like
'divide;' was nil. I guess there is somewhat of a risk of naming
something 'pound' or 'para' though.
David Mark
Which is virtually nil (still). I was just reading some reviews of
their 2007 model. Nothing has changed. If anything, the delusions have
become more dramatic.
[...]
>
> This is very significant for anyone who is trying to create non-
> trivial DOM scripts (which is presumably something Dojo is attempting
> to qualify as), and so should be understood by any individual involved
> in such a task.
Yes, when the Dojo authors can't create a very basic Website (they've
had myriad shots at it over the years) with their own wonder-scripts,
anyone with sense must conclude they are barking up the wrong tree (i.e.
they should find a new hobby).
> The result of that understanding is usually an
> appreciation of the value of using structurally valid mark-up (as
> represented by the participants in this group[1]), and so observing
> the use of invalid mark-up implies a failure to understand this point
> (a shortfall of experience or knowledge).
As evidenced, they fail to understand even the most basic concepts of
sound Web development. Furthermore, they can't seem to grasp
abstractions, preferring to demand empirical "proofs" for what should be
self-evident propositions. How they figure they can keep rewriting the
stupid thing in perpetuity, constantly changing the code to "keep up"
with the latest browsers, piling bad code on top of worse and discarding
older browsers (and visitors) on whims is beyond my comprehension. It
seems like they perversely (almost gleefully) strive to do everything
backwards and are quite unwilling to consider contrary points of view.
Small wonder the project has gone nowhere, but they seem to cling to the
idea that next year could be the one where everyone comes around to see
things their way.
Dr J R Stockton
t>, Tue, 9 Mar 2010 16:43:58, S.T. <an...@anon.com> posted:
>Validating is a debugging tool
Agreed. It finds three types of bugs :
A. Those which you could find by testing & reading the page
B. Those which you would not find by testing & reading the page
C. Those which no-one will ever be affected by.
It is useful for A, very useful for B, and unimportant for C.
> - 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.
After realising that validation is useful for detecting errors, the step
which you should take next is to realise that it is much easier to check
a validator's output for important errors if the output is not cluttered
up by a large number of easily-fixed errors that you are not otherwise
bothered by.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
Eric Bednarz
> […] but in the context of DOM
> scripting, at least, the arguments for structural validity in mark-up
> are substantial.
Now everybody who nevertheless uses a Firefox debugging add-on that not
only modifies the DOM, but does so in a way that breaks this structural
validity, raise your hand.
David Mark
I swore off that piece of crap long ago for that and numerous other
reasons. Never again. That stupid IETester does something similar,
which drove me nuts a little while back because it was causing a query
test to fail.