Prev: JSON.parse error
Next: how to handle this AJAX error?
From: S.T. on 3 Aug 2010 15:58 On 8/3/2010 2:49 AM, David Mark wrote: > And to alleviate any confusion among the uninitiated, there is no > "answer" to the "question" posted on StackOverflow and (as the name > indicates), that site is literally bursting with such exchanges (so I > can hardly correct them all). I have tried a few times in the past > and my real answers were voted down in favor or fantasy answers (the > type that recommend snake oil like jQuery to soothe the suffering of > incompetents, but do nothing but waste time and money for their > clients). Have you ever noticed your postings are consistently shot down in every format that has any sort of moderation? You should ask yourself... "why is that?"
From: David Mark on 4 Aug 2010 03:55 On Aug 3, 3:58 pm, "S.T." <a...(a)anon.com> wrote: > On 8/3/2010 2:49 AM, David Mark wrote: > > > And to alleviate any confusion among the uninitiated, there is no > > "answer" to the "question" posted on StackOverflow and (as the name > > indicates), that site is literally bursting with such exchanges (so I > > can hardly correct them all). I have tried a few times in the past > > and my real answers were voted down in favor or fantasy answers (the > > type that recommend snake oil like jQuery to soothe the suffering of > > incompetents, but do nothing but waste time and money for their > > clients). > > Have you ever noticed your postings are consistently shot down in every > format that has any sort of moderation? That's false. > > You should ask yourself... "why is that?" No I shouldn't as it isn't true. Have you ever noticed that you have nothing useful to say?
From: Richard Cornford on 4 Aug 2010 07:32 On Aug 2, 10:32 am, David Mark wrote: <snip> > "The properties: document.body.clientHeight, > document.body.clientWidth > return different values on IE7, IE8 and Firefox: > ... " > > This is certainly to be expected and not a problem at all, ... <snip> > "Paul A is right about why the discrepancy exists but the > solution offered by Ngm is wrong (in the sense of JQuery). > > The equivalent of clientHeight and clientWidth in jquery > (1.3) is $(window).width(), $(window).height()" <snip> The subject of this thread (Now I've seen everything) seems a little over the top attached to a case of an individual who doesn't know any better failing to ask the right question and getting a series of different 'try this' response form people to whom stopping and finding out what actual problem they are proposing 'solutions' for is unimaginable. That is not unexpected, it is pretty much the norm for web forums. Generally the level of understanding/knowledge in web development is so low that each new exhibit in the parade of jaw-dropping stupidity actually does little more than raise an eyebrow. For example, yesterday, while looking at a post-log-out HTML page on a client's intranet I noticed this at the bottom of the page:- | </DIV> | </BODY> | <!-- bonus HEAD section | as per http://support.microsoft.com/kb/q222064/ --> | <HEAD> | <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> | <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="no-cache"> | <META HTTP-EQUIV="Expires" CONTENT="0"> | </HEAD> | </HTML> A "bonus HEAD section" (and there was another one at the top of the page) is such a ludicrous notion that it is hard (but not impossible, given Microsoft's record on web development) to believe that it would be recommend in a Microsoft knowledge base article, or that anyone sane would take it seriously if it were. For those not interested in reading the article the proposition is that <META HTTP-EQUIV="CACHE-CONTROL" ... > will not be acted upon if found prior to the page filling half of a 64KB 'buffer' because up until that point there is nothing in the cache to act upon. Microsoft propose that this be addressed by placing an additional HEAD section at the bottom of the page and placing the offending META elements within it. (They do not say what implications follow from the total size of the page being less than half of their 64KB 'buffer', and so any inserted HEAD section sill being encountered prior to the cache entry being created). The article does not suggest that there are any issues with real HTTP headers, but also does not suggest them as an alternative approach to their issue with META elements. The page where I encountered this was sent with the headers:- | HTTP/1.1 200 OK | Server: Sun-ONE-Web-Server/6.1 | Date: Tue, 03 Aug 2010 12:41:26 GMT | Content-length: 2142 | Content-type: text/html | Last-modified: Mon, 23 Feb 2009 23:49:07 GMT | Etag: "85e-49a335f3" | Accept-ranges: bytes - so clearly there is someone who is willing to do ridiculous things to discourage IE from caching this page, but not willing or able to set up the headers for the response such that they would discourage caching. This client is a large (but unnameable, for the usual reasons) US bank who have a large internal IT department that employs the 'web developers' who created this and 'Websphere experts' to set up the servers so you would expect better (it is not lack of funds that prevent them from hiring people who understand what they are doing). This is a case of solving the wrong problem in the wrong way, but as such it is no more tha just another case of doing that. I am fairly confident that I never will have "seen everything". Richard.
From: Dave on 4 Aug 2010 08:23 Richard Cornford wrote: > For example, yesterday, while looking at a post-log-out HTML page on > a client's intranet I noticed this at the bottom of the page:- > > | </DIV> > | </BODY> > | <!-- bonus HEAD section > | as per http://support.microsoft.com/kb/q222064/ --> > | <HEAD> > | <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> > | <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="no-cache"> > | <META HTTP-EQUIV="Expires" CONTENT="0"> > | </HEAD> > | </HTML> > > A "bonus HEAD section" (and there was another one at the top of the > page) is such a ludicrous notion that it is hard (but not impossible, > given Microsoft's record on web development) to believe that it would > be recommend in a Microsoft knowledge base article, or that anyone > sane would take it seriously if it were. Perhaps a typo for "bogus"... :p
From: Garrett Smith on 6 Aug 2010 20:24
On 2010-08-04 04:32 AM, Richard Cornford wrote: > On Aug 2, 10:32 am, David Mark wrote: > <snip> >> "The properties: document.body.clientHeight, >> document.body.clientWidth >> return different values on IE7, IE8 and Firefox: >> ... " >> >> This is certainly to be expected and not a problem at all, ... > <snip> >> "Paul A is right about why the discrepancy exists but the >> solution offered by Ngm is wrong (in the sense of JQuery). >> >> The equivalent of clientHeight and clientWidth in jquery >> (1.3) is $(window).width(), $(window).height()" > <snip> > > The subject of this thread (Now I've seen everything) seems a little > over the top attached to a case of an individual who doesn't know any > better failing to ask the right question and getting a series of > different 'try this' response form people to whom stopping and finding > out what actual problem they are proposing 'solutions' for is > unimaginable. That is not unexpected, it is pretty much the norm for > web forums. > Totally. I can't see reason for getting upset about someone who is admittedly confused. [...] > > The page where I encountered this was sent with the headers:- > [...] Uh-oh. That might be cached. Better add an extra head. (Kidding, of course). > > - so clearly there is someone who is willing to do ridiculous things > to discourage IE from caching this page, but not willing or able to > set up the headers for the response such that they would discourage > caching. This client is a large (but unnameable, for the usual > reasons) US bank who have a large internal IT department that employs > the 'web developers' who created this and 'Websphere experts' to set > up the servers so you would expect better (it is not lack of funds > that prevent them from hiring people who understand what they are > doing). > US banks spend a lot of money on projects, mostly wasting it in process and red tape. They usually pay on the low-end of market rate and provide an environment that good developers find stifling. -- Garrett |