New Dojo Site--Most incompetent ever?
in [JavaScript]
|
Prev: Javascript Toolbox - Table Sort utility - Column Width cannot be set.
Next: FireFoc support forums (Re: FF3.6 Stack output from Too MuchRecursion)
From: David Mark on 10 Mar 2010 07:51 SteveYoungGoogle wrote: > On Mar 10, 12:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> David Mark wrote: >>> SteveYoungGoogle wrote: >>>> On Mar 10, 5:42 am, David Mark <dmark.cins...(a)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:- >> >> 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. ;) > > 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/ 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.
From: David Stone on 10 Mar 2010 09:22 In article <hn6u59$p6v$1(a)news.eternal-september.org>, Garrett Smith <dhtmlkitchen(a)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.
From: Lasse Reichstein Nielsen on 10 Mar 2010 11:17 "S.T." <anon(a)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. > 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'
From: John G Harris on 10 Mar 2010 11:42 On Wed, 10 Mar 2010 at 17:17:02, in comp.lang.javascript, Lasse Reichstein Nielsen wrote: >"S.T." <anon(a)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. <snip> In addition, you don't know what future browsers will do. It could require a major re-work. John -- John Harris
From: Garrett Smith on 10 Mar 2010 12:29
David Mark wrote: > SteveYoungGoogle wrote: >> On Mar 10, 12:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>> David Mark wrote: >>>> SteveYoungGoogle wrote: >>>>> On Mar 10, 5:42 am, David Mark <dmark.cins...(a)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:- >>> >>> 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. 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. [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |