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 13:04 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. 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.
From: S.T. on 10 Mar 2010 13:33 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. 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.
From: David Mark on 10 Mar 2010 13:38 S.T. wrote: > 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.
From: S.T. on 10 Mar 2010 14:29 On 3/10/2010 8:17 AM, Lasse Reichstein Nielsen wrote: > "S.T."<anon(a)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. 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 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'.
From: David Mark on 10 Mar 2010 14:54
S.T. wrote: > On 3/10/2010 8:17 AM, Lasse Reichstein Nielsen wrote: >> "S.T."<anon(a)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? |