Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #8202 > unrolled thread

David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions

Back to article view | Back to comp.lang.javascript

Contents

  David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 06:09 -0800
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-10 16:57 -0200
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 11:54 -0800
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Ant" <not@home.today> - 2011-11-10 19:47 +0000
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 13:07 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Matt McDonald <matt@fortybelow.ca> - 2011-11-10 14:12 -0700
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-11 07:26 -0800
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 -   How to Measure Element Dimensions Frobernik <nospam@nospam.com> - 2011-11-17 22:43 +0000
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 16:08 -0800
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How   to Measure Element Dimensions Frobernik <nospam@nospam.com> - 2011-12-06 21:18 +0000
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-06 14:13 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-10 13:17 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-11-10 22:43 +0000
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-11 00:36 +0000
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-10 19:14 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-11 09:59 +0000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-11 11:04 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-11 14:39 +0100
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-12 10:38 +0100
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-12 19:19 +0000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-12 21:07 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 00:42 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-13 14:33 +0000
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 23:14 +0100
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-17 23:55 +0000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-13 20:22 +0100
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-13 08:29 +1000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-13 20:25 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-13 23:05 -0800
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Tim Down <timdown@gmail.com> - 2011-11-14 03:41 -0800
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-16 16:18 -0800
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 16:03 -0800
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-15 16:52 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:54 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-13 10:38 +0200
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Dr J R Stockton <reply1145@merlyn.demon.co.uk> - 2011-11-11 21:33 +0000
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:00 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 18:38 -0800
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-12-03 19:50 -0200
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 15:50 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 16:38 -0800
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 17:14 -0800
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-12-04 11:07 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 02:45 -0800
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 13:37 -0800
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 16:01 -0800
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 16:28 -0800
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 18:56 -0800
                    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions John G Harris <john@nospam.demon.co.uk> - 2011-12-05 14:39 +0000
                      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-05 11:00 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 19:17 -0800
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 00:06 -0200
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 04:31 +0100
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 13:44 -0200
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 18:35 +0100
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 22:00 -0200
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 12:40 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 11:52 -0200
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 15:40 +0100
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 11:16 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-17 21:06 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 22:13 +0100
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:19 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:10 -0800
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 18:04 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#8202 — David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions

How to Measure Element Dimensions

Typically these functions fall into three categories: call them
getOuterDimensions, getInnerDimensions, and getCssDimensions. The
first two refer to the size outside and inside the border respectively
and the last the CSS dimensions (per the box model).

The first two have just one rendition each. With simplified feature
detection*:-

if (document.documentElement && typeof
document.documentElement.offsetWidth == 'number') {
  var getOuterDimensions = function(el) {
    return [el.offsetHeight, el.offsetWidth];
  };
}


if (document.documentElement && typeof
document.documentElement.clientWidth == 'number') {
  var getInnerDimensions = function(el) {
    return [el.clientHeight, el.clientWidth];
  };
}

Those never change. They work even in IE 4. Due to the host feature
detection and conditional creation of these functions, applications
that do proper API feature detection will degrade gracefully in IE 3.
Of course, if the application's script has a try-catch, the
degradation path for IE 4 and under is a parse error.

As for getCssDimensions, a GP solution may (and often does) use
getComputedStyle, but unfortunately that method has been notoriously
buggy over the years and the older versions of IE (under 9) don't
support it at all.  You could try to string together a bunch of hacks
to emulate getComputedStyle with IE's various proprietary objects, but
it's a fool's errand.

Here is a relatively slow solution that works for all box models in
"all browsers":-

http://www.cinsoft.net/size.html

As with virtually everything in cross-browser scripting, defining a
specific context is the key to creating a reliable function.

What if the design decision was made to measure only elements with the
border-box box model?  Then you could do this:-

var getCssDimensions = getOuterDimensions;

Unfortunately, that is an inappropriate solution for most contexts as
many browsers do not support that box model. For example, IE 5-8 will
do it only in quirks mode (which is always best avoided).

What if the design decision was made to measure only elements with the
content-box box model *and* without padding?  Then you could do this:-

var getCssDimensions = getInnerDimensions;

This is an excellent (and relatively fast) solution as the default for
virtually every element in virtually every modern browser is content-
box. When designing an application's widgets, simply take care to only
measure elements without padding.  It's not hard to do and the payoff
is a fast, concise and cross-browser solution. Just make sure to
document the context as the documentation is as much a part of the
rendition as the code.

How *Not* to Measure Element Dimensions

And what of the jQuery height/width functions?  They don't work at all
for border-box.  They also rely on getComputedStyle (or a long-winded,
over-complicated simulation).  It's the worst of both worlds; also
confusing, relatively slow, poorly documented, failure-prone and
subject to change at any time on a whim.  That's what *defines* jQuery
(and the like).  In its favor... uh, lots of Web developers use it to
churn out horrible Websites.

To borrow a term from the jQuery fanboy resistance/marketing
department: does this sound like FUD to you?  I think you should
certainly be afraid of such doubtful material as jQuery, at least
until you understand the employed techniques well enough to avoid it
for rational reasons.  Fear of the unknown can be healthy and most
jQuery users have no idea what it does.

http://en.wikipedia.org/wiki/Cargo_cult_programming

* Use isHostObjectProperty (or the like) to detect
document.documentElement

http://www.cinsoft.net/
http://www.twitter.com/cinsoft
http://jsperf.com/browse/david-mark

[toc] | [next] | [standalone]

#8212

On 10/11/2011 12:09, David Mark wrote:
> How to Measure Element Dimensions
>
> Typically these functions fall into three categories: call them
> getOuterDimensions, getInnerDimensions, and getCssDimensions. The
> first two refer to the size outside and inside the border respectively
> and the last the CSS dimensions (per the box model).
>
> The first two have just one rendition each. With simplified feature
> detection*:-
>
> if (document.documentElement&&  typeof
> document.documentElement.offsetWidth == 'number') {
>    var getOuterDimensions = function(el) {
>      return [el.offsetHeight, el.offsetWidth];
>    };
> }
>
>
> if (document.documentElement&&  typeof
> document.documentElement.clientWidth == 'number') {
>    var getInnerDimensions = function(el) {
>      return [el.clientHeight, el.clientWidth];
>    };
> }
>

I've learned that you've posted a simplified version of the code 
available on "My Library". So I think it's necessary to remark that in 
IE the HTML element (document.documentElement) is used for the
viewport in "standards mode" (also known as "strict mode") and the body
(document.body) is used in "quirks mode" (HTML is not rendered -
document is displayed as it was displayed in previous versions of IE).

Therefore document.documentElement.clientHeight (in strict mode) may
output a slightly different value from document.body.clientHeight (in
quirks mode).

I've also noticed that you have taken care of those differences at 
<http://www.cinsoft.net/viewport.asp>.

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#8215

On Nov 10, 1:57 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 10/11/2011 12:09, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > How to Measure Element Dimensions
>
> > Typically these functions fall into three categories: call them
> > getOuterDimensions, getInnerDimensions, and getCssDimensions. The
> > first two refer to the size outside and inside the border respectively
> > and the last the CSS dimensions (per the box model).
>
> > The first two have just one rendition each. With simplified feature
> > detection*:-
>
> > if (document.documentElement&&  typeof
> > document.documentElement.offsetWidth == 'number') {
> >    var getOuterDimensions = function(el) {
> >      return [el.offsetHeight, el.offsetWidth];
> >    };
> > }
>
> > if (document.documentElement&&  typeof
> > document.documentElement.clientWidth == 'number') {
> >    var getInnerDimensions = function(el) {
> >      return [el.clientHeight, el.clientWidth];
> >    };
> > }
>
> I've learned that you've posted a simplified version of the code
> available on "My Library". So I think it's necessary to remark that in
> IE the HTML element (document.documentElement) is used for the
> viewport in "standards mode" (also known as "strict mode") and the body
> (document.body) is used in "quirks mode" (HTML is not rendered -
> document is displayed as it was displayed in previous versions of IE).

Which code?  The Viewport primer?

>
> Therefore document.documentElement.clientHeight (in strict mode) may
> output a slightly different value from document.body.clientHeight (in
> quirks mode).

Yes, they may.  For example, if the body has a margin.

>
> I've also noticed that you have taken care of those differences at
> <http://www.cinsoft.net/viewport.asp>.

Right.

Just checked MSDN and the offending "community content" entry that I
had noted a while back is gone.  Basically it warned against using the
clientHeight property because it was "broken" (i.e. returned different
values in different rendering modes). :)

[toc] | [prev] | [next] | [standalone]

#8214

"David Mark" wrote:

> http://en.wikipedia.org/wiki/Cargo_cult_programming

"Cargo cult programming is a style of computer programming that is
 characterized by the ritual inclusion of code or program structures
 that serve no real purpose".

Why would anyone do that? In my 30+ years of programming I've never
heard of such a thing. Maybe it's a modern phenomenon like jQuery or
"social networking" that the young 'uns like to engage in. Probably I
should get out more (now that I've retired I can).

[toc] | [prev] | [next] | [standalone]

#8216

On Nov 10, 2:47 pm, "Ant" <n...@home.today> wrote:
> "David Mark" wrote:
> >http://en.wikipedia.org/wiki/Cargo_cult_programming
>
> "Cargo cult programming is a style of computer programming that is
>  characterized by the ritual inclusion of code or program structures
>  that serve no real purpose".
>
> Why would anyone do that?

Only possible reason is that they don't know they are doing it. ;)

> In my 30+ years of programming I've never
> heard of such a thing.

Well, as a theory it goes way back.  In reality, it's a recent (and
troubling) phenomenon.

> Maybe it's a modern phenomenon like jQuery or
> "social networking" that the young 'uns like to engage in.

Yes, exactly like jQuery and on more than one level.  The jQuery
project itself is certainly a cargo cult effort.  It's locked in a
design from 2005 that was just as inappropriate for browser scripting
then as now.  And yes, many of their "innovations" over the years have
been the result of copying patterns without really understanding what
they were doing.

jQuery 1.3 was their attempt to replicate my shiny feature testing
patterns with JS equivalent of bamboo and vines.  More recently there
was the attr/prop overhaul.  After years of telling them two things:-

1. Your attr method makes no sense and is causing a lot of confusion
2. Here's some realistic prop and attr examples, but it's not the
exact solution for your needs

...they went ahead and split their most low-level DOM API to attr/
removeAttr and prop/removeProp (almost but not entirely like my
examples and almost entirely unlike previous jQuery versions).  So
eventually #1 got through, but #2 only partially.

http://www.cinsoft.net/attributes.html

They also kinda-sorta rolled back those changes in a later version.
The details are unclear at this time and will likely remain so. :(

But for those who cry out that I am not helping them (which is ironic
as I'm one of the few people who ever tried to help them with this
mess).  For the umpteenth time, the solution to their "attr" problem
is simple.  First you have to define what "attr" is supposed to do.
To this date, the documentation has never been close to right about
any of its half-dozen incarnations.  In an HTML* DOM, the "attr"
method gets/sets property values by attribute name.  In an XML DOM, it
gets/sets attribute values by attribute name.  That "overloading" is
unfortunate, but jQuery is stuck with it at this point.

1. Fix the attr method so that it is at least consistent in the "core
browsers"
2. Deprecate removeAttr (it's just confusing as it doesn't go with
attr).
3. As companion to form control value getter/setter, add a "checker"
for checkbox/radio buttons

The jQuery users don't need a pure attribute getter/setter; and, as
predicted, they don't want one.  Same for removing attributes (or God
forbid properties).  The underlying query engine is another story.  To
support legacy IE versions (and compatibility modes), it must have
such a function, but never has (and apparently never will).  Probably
doesn't matter as I expect them to stop "caring" about legacy IE any
day now.

I think I've posted more than my share of attribute/property-related
examples over the years, so step 1 should not be a problem for anyone
inclined to fix the silly thing.  The other two take almost no thought
or effort at all.

Finally, jQuery users include it in documents as a rule, regardless of
context or other considerations and often doing more harm than good.
That's also cargo cult behavior.

* Would hold true in an XHTML DOM as well if jQuery worked in an XHTML
DOM

[toc] | [prev] | [next] | [standalone]

#8217

On 11-11-10 12:47 PM, Ant wrote:
> Why would anyone do that? In my 30+ years of programming I've never
> heard of such a thing. Maybe it's a modern phenomenon like jQuery or
> "social networking" that the young 'uns like to engage in. Probably I
> should get out more (now that I've retired I can).

As a "young 'un", I can tell you that it's a phenomenon
propped up by the "best practices" methodology.

"best practices" (sounds terrible when you read it aloud)
is an arguably dogmatic set of beliefs and observations
pertaining to a particular programming topic. The crux of
"best practices" is that it's how "popular" programmers
(in that particular field) operate. For example,
"HTML 5 Boilerplate" is a massive set of server
configurations, CSS file(s) ("normalizing", they call it),
JavaScript files (including jQuery & modernizr, neither of which
have any particular use to me), and other assorted bits.

The belief is that when one is to build an "HTML 5" website
(fallacy alert: appeal to popularity) that one must utilize
"HTML 5 Boilerplate". Why? Simply because the "popular" developers
are using it. Supposedly, it also has countless hours of research
behind it. Anyone who has read this group for an extended period
of time knows that "research" isn't always indicative of code
quality (hat tip to jQuery, YUI, Dojo, et al).

Since HTML 5 *still* doesn't have sufficient support (hopes
are with IE 10) to be considered "implemented", one has to
wonder just how a massive amalgam of resources can make websites
"just work". At least in this case, users have a decision to trash
what they consider unnecessary (unlike jQuery).

For the majority of users, this is simply overkill.
Ritualistically including code hinders the learning process
involved with programming. There's little potential to improve
one's knowledge of a topic by slapping on a copy-pasted
solution, especially if it's poorly written (which is common).

The biggest blow is marketing. Take a gander at
"HTML 5 Boilerplate"'s website (won't link). It's chock full of 
over-the-top marketing speak. The first time I read it, I was
heavily offended by the textual content. I seriously pondered
if it was written by a prepubescent.

Web development is in vogue. People want to create "cool"
projects, but are dismayed by the amount of effort and research
required to create something meaningful. The solution? Abdicate
responsibility to those who have already "done the research".
That's why "frameworks" and "libraries" have sprung up like
weeds in the past half-decade or so.

It is by this type of behavior that "cargo cult programming"
is characterized. My opinion is that it's one of the prime evils
currently in web development (along with overconfidence).

[toc] | [prev] | [next] | [standalone]

#8233

On Nov 10, 4:12 pm, Matt McDonald <m...@fortybelow.ca> wrote:
> On 11-11-10 12:47 PM, Ant wrote:
>
> > Why would anyone do that? In my 30+ years of programming I've never
> > heard of such a thing. Maybe it's a modern phenomenon like jQuery or
> > "social networking" that the young 'uns like to engage in. Probably I
> > should get out more (now that I've retired I can).
>
> As a "young 'un", I can tell you that it's a phenomenon
> propped up by the "best practices" methodology.
>
> "best practices" (sounds terrible when you read it aloud)
> is an arguably dogmatic set of beliefs and observations
> pertaining to a particular programming topic. The crux of
> "best practices" is that it's how "popular" programmers
> (in that particular field) operate. For example,
> "HTML 5 Boilerplate" is a massive set of server
> configurations, CSS file(s) ("normalizing", they call it),
> JavaScript files (including jQuery & modernizr, neither of which
> have any particular use to me), and other assorted bits.
>
> The belief is that when one is to build an "HTML 5" website
> (fallacy alert: appeal to popularity) that one must utilize
> "HTML 5 Boilerplate". Why? Simply because the "popular" developers
> are using it. Supposedly, it also has countless hours of research
> behind it. Anyone who has read this group for an extended period
> of time knows that "research" isn't always indicative of code
> quality (hat tip to jQuery, YUI, Dojo, et al).
>
> Since HTML 5 *still* doesn't have sufficient support (hopes
> are with IE 10) to be considered "implemented", one has to
> wonder just how a massive amalgam of resources can make websites
> "just work". At least in this case, users have a decision to trash
> what they consider unnecessary (unlike jQuery).
>
> For the majority of users, this is simply overkill.
> Ritualistically including code hinders the learning process
> involved with programming. There's little potential to improve
> one's knowledge of a topic by slapping on a copy-pasted
> solution, especially if it's poorly written (which is common).
>
> The biggest blow is marketing. Take a gander at
> "HTML 5 Boilerplate"'s website (won't link). It's chock full of
> over-the-top marketing speak. The first time I read it, I was
> heavily offended by the textual content. I seriously pondered
> if it was written by a prepubescent.

Yes, these things are all about marketing, which is ironic considering
that they are the first ones to cry (and I do mean cry) carpetbagger
at the first sign of criticism.  How many times have I heard "you are
just jealous of our library" or "you are just trashing our library to
promote yours" out of the mouths of (seemingly) petulant tweens?  Of
course, many of them turn out to be adults whose brains have been
destroyed by too many television commercials.  They'll take warm,
glossy ad copy over cold, dull facts any day.  Anybody trying to
"sell" them with reasoned arguments is just trying to make them look
stupid.  They'd apparently much rather be made fools of daily by
disingenuous marketers. ;)

The face of Javascript libraries is a pinched, frustrated visage,
spewing hatred and PKB insinuations at all who dare to question
"established" best practices.  From the history of these things, it's
clear they are very frustrated; but when their users join in blaming
the "self-promoting" messenger, you know you are dealing with a cult.

>
> Web development is in vogue. People want to create "cool"
> projects, but are dismayed by the amount of effort and research
> required to create something meaningful. The solution? Abdicate
> responsibility to those who have already "done the research".
> That's why "frameworks" and "libraries" have sprung up like
> weeds in the past half-decade or so.

Yes, and when it comes to JS, they all look alike to me (probably
because they are constantly copying each other).  Bad is bad, no
matter how "cool" these things may seem to overwhelmed beginners.
Unfortunately, it is relatively easy to write scripts that seem to
work in the developers' array of browsers/configurations.  This leads
to the next stage, which is overconfidence.

>
> It is by this type of behavior that "cargo cult programming"
> is characterized. My opinion is that it's one of the prime evils
> currently in web development (along with overconfidence).

My thoughts exactly.

[toc] | [prev] | [next] | [standalone]

#8396 — Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions

On 10/11/2011 21:12, Matt McDonald wrote:
> On 11-11-10 12:47 PM, Ant wrote:
> "HTML 5 Boilerplate" is a massive set of server
> configurations, CSS file(s) ("normalizing", they call it),
> JavaScript files (including jQuery & modernizr, neither of which
> have any particular use to me), and other assorted bits.

"normalizing" is just a set of resets in the real world made for so 
called "web apps" - because nothing says futuristic like a splash screen 
or a spinning dial

> The biggest blow is marketing. Take a gander at
> "HTML 5 Boilerplate"'s website (won't link). It's chock full of
> over-the-top marketing speak. The first time I read it, I was
> heavily offended by the textual content. I seriously pondered
> if it was written by a prepubescent.

Well there are people (apart from the punters on here) fighting 
modernizer, jQuery and other junk (will link)

http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-modernizr-inadequacy/

Frobernik

[toc] | [prev] | [next] | [standalone]

#8791

On Nov 17, 5:43 pm, Frobernik <nos...@nospam.com> wrote:
> On 10/11/2011 21:12, Matt McDonald wrote:
>
> > On 11-11-10 12:47 PM, Ant wrote:
> > "HTML 5 Boilerplate" is a massive set of server
> > configurations, CSS file(s) ("normalizing", they call it),
> >JavaScriptfiles (includingjQuery& modernizr, neither of which
> > have any particular use to me), and other assorted bits.
>
> "normalizing" is just a set of resets in the real world made for so
> called "web apps" - because nothing says futuristic like a splash screen
> or a spinning dial
>
> > The biggest blow is marketing. Take a gander at
> > "HTML 5 Boilerplate"'s website (won't link). It's chock full of
> > over-the-top marketing speak. The first time I read it, I was
> > heavily offended by the textual content. I seriously pondered
> > if it was written by a prepubescent.
>
> Well there are people (apart from the punters on here) fighting
> modernizer,jQueryand other junk (will link)

I see you have almost *one million* posts on here.  Punter.  :)

And who is fighting what?  Just throw them away.

>
> http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-mo...

I've seen it.  Somebody doesn't like Modrnizer (sp?).  I don't like it
either.  Imagine, a monolithic feature detection script that
pigeonholes browsers according to some predetermined series of
"standard" tests.  Adds a ton of classes too.  No thanks!

[toc] | [prev] | [next] | [standalone]

#8950 — Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions

On 03/12/2011 00:08, David Mark wrote:
> On Nov 17, 5:43 pm, Frobernik<nos...@nospam.com>  wrote:
>> On 10/11/2011 21:12, Matt McDonald wrote:
>>> On 11-11-10 12:47 PM, Ant wrote:
>>> The biggest blow is marketing. Take a gander at
>>> "HTML 5 Boilerplate"'s website (won't link). It's chock full of
>>> over-the-top marketing speak. The first time I read it, I was
>>> heavily offended by the textual content. I seriously pondered
>>> if it was written by a prepubescent.
>>
>> Well there are people (apart from the punters on here) fighting
>> modernizer,jQueryand other junk (will link)
>
> I see you have almost *one million* posts on here.  Punter.  :)
>
> And who is fighting what?  Just throw them away.

This should get Platinum Czar Punter post of 2011 I think!

If only it were that simple - most designers and a lot of developers 
would rather copy and paste or be hypnotised by Googled bulls**t than 
actually get familiar with the browser or even do some work :(

>> http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-mo...
> I've seen it.  Somebody doesn't like Modrnizer (sp?).  I don't like it
> either.  Imagine, a monolithic feature detection script that
> pigeonholes browsers according to some predetermined series of
> "standard" tests.  Adds a ton of classes too.  No thanks!

Moronizers own website is ridiculous. The custom font typefacing has had 
to be hidden until the page finishes loading (thats assuming the JS 
finishes loading!) *face palm*

Frobernik

[toc] | [prev] | [next] | [standalone]

#8951

On Dec 6, 4:18 pm, Frobernik <nos...@nospam.com> wrote:
> On 03/12/2011 00:08, David Mark wrote:
>
> > On Nov 17, 5:43 pm, Frobernik<nos...@nospam.com>  wrote:
> >> On 10/11/2011 21:12, Matt McDonald wrote:
> >>> On 11-11-10 12:47 PM, Ant wrote:
> >>> The biggest blow is marketing. Take a gander at
> >>> "HTML 5 Boilerplate"'s website (won't link). It's chock full of
> >>> over-the-top marketing speak. The first time I read it, I was
> >>> heavily offended by the textual content. I seriously pondered
> >>> if it was written by a prepubescent.
>
> >> Well there are people (apart from the punters on here) fighting
> >> modernizer,jQueryand other junk (will link)
>
> > I see you have almost *one million* posts on here.  Punter.  :)
>
> > And who is fighting what?  Just throw them away.
>
> This should get Platinum Czar Punter post of 2011 I think!

That's very colorful, but don't understand a word of it.  :)

>
> If only it were that simple - most designers and a lot of developers
> would rather copy and paste or be hypnotised by Googled bulls**t than
> actually get familiar with the browser or even do some work :(

Correct.  But designers can get away with it as they only need their
proof of concept to work in one browser (the one they use to demo).
Trouble is that inexperienced and overconfident developers think they
can just test the mock-up in a few more browsers and throw it on the
client's server.  This poor behavior is positively reinforced by
clients who just don't know any better.

>
> >>http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-mo...
> > I've seen it.  Somebody doesn't like Modrnizer (sp?).  I don't like it
> > either.  Imagine, a monolithic feature detection script that
> > pigeonholes browsers according to some predetermined series of
> > "standard" tests.  Adds a ton of classes too.  No thanks!
>
> Moronizers own website is ridiculous. The custom font typefacing has had
> to be hidden until the page finishes loading (thats assuming the JS
> finishes loading!) *face palm*

Yes, that sounds pretty backwards to me.  I see lots of sites that
combine that thing with jQuery and jQuery plug-ins.  An "HTML5
modernizer" combined with a bunch of old IE6/7 hacks?  It's the Sybil
pattern.  :)

As you mentioned, many developers just window shop for these silly
scripts like they were designers.  They pile on all everything that
looks cool in their installed browsers and wait for the inevitable
call back when it all falls apart.  Their ready excuse is that "nobody
is perfect"; but there is a large gulf between absolute perfection and
gross incompetence.  ;)

Just had one of those clods dial in on Twitter.  They said that
something was wrong with some of the old My Library examples on the
new Amazon "Silk" browser (Kindle Fire).  Their juxtaposition was that
"jQuery UI works".  :)

Of course, jQuery UI is completely inappropriate for mobile devices
(or anything else, really).  I wouldn't find it surprising that
whatever jQuery demo they were peering at seemed to "work" in a
browser that the jQuery developers were peering at when they wrote the
thing.  The question is whether it should be expected to work in
browsers unknown to the developers (e.g. future versions, new
browsers, new devices, etc.).  History and good sense say no as such
projects are always about overreaching to "keep up" with current,
popular browsers, usually at the expense of others (the browsers the
developers claim not to "care" about).

And if jQuery UI works so well on mobile, why is there a jQuery
Mobile?  Even more curious, how can anyone even say "jQuery Mobile"
with a straight face?  I just saw a blog that mentioned they
"finalized" the thing recently, and it went on to list five or six
browsers (with specific version numbers, of course) that it
"supports".  What do you guess it does in every other browser released
this century?  Finalized?!  For how many weeks?  Seems these guys
never learn.

Developers should wake up and realize that relying on bored hobbyists
to ferret out and "fix" bugs, one browser version at a time, is
futile.  They should be learning to *avoid* bugs, not trying to find
them.  They sure as hell shouldn't be sending out teams of neophytes
to find (and often misinterpret) issues.

Many developers think browsers are far buggier than they are, simply
because they have spent years watching projects like jQuery stumble,
bumble, fumble, etc.  This reinforces their perceived need for
jQuery.  After all, if the "best minds in the industry" are having
such a time of it...  It's a self-perpetuating cycle.  jQuery makes it
look really difficult and designers/developers assume such frustration
is par for the course.

[toc] | [prev] | [next] | [standalone]

#8218

On Thu, 10 Nov 2011 19:47:35 -0000, "Ant" <not@home.today> wrote:

>"David Mark" wrote:
>
>> http://en.wikipedia.org/wiki/Cargo_cult_programming
>
>"Cargo cult programming is a style of computer programming that is
> characterized by the ritual inclusion of code or program structures
> that serve no real purpose".
>
>Why would anyone do that? In my 30+ years of programming I've never
>heard of such a thing. Maybe it's a modern phenomenon like jQuery or
>"social networking" that the young 'uns like to engage in. Probably I
>should get out more (now that I've retired I can).

     It is not new, but it is much more likely when people do not
understand the details.  Sometimes, it is something that works, but it
is not known why.  Such a thing then tends to be dragged along into
other areas where it may not be relevant.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8219

Ant wrote on 10 nov 2011 in comp.lang.javascript:

> "David Mark" wrote:
> 
>> http://en.wikipedia.org/wiki/Cargo_cult_programming
> 
> "Cargo cult programming is a style of computer programming that is
>  characterized by the ritual inclusion of code or program structures
>  that serve no real purpose".

If it is ".. seems to serve .." it is a perfect definition of DNA.

> Why would anyone do that? In my 30+ years of programming I've never
> heard of such a thing. Maybe it's a modern phenomenon like jQuery or
> "social networking" that the young 'uns like to engage in. Probably I
> should get out more (now that I've retired I can).
 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#8221

Ant wrote:
> "David Mark" wrote:
>
>> http://en.wikipedia.org/wiki/Cargo_cult_programming
>
> "Cargo cult programming is a style of computer programming that is
> characterized by the ritual inclusion of code or program structures
> that serve no real purpose".
>
> Why would anyone do that?

There are lots of reasons why someone would do that. A better question 
is would someone who understood what they were doing ever do that?

> In my 30+ years of programming I've never
> heard of such a thing.

Welcome to the low entry cost world of browser scripting.

So, an illustration, but which one? Try this, go to
<URL: http://www.google.com/codesearch >
and in the search box at the top of the page enter the following line:-

typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript

- and do the search. It gets 4,000+ results (including from a 
cross-section of 'popular' libraries) along the lines of:-

if ( typeof a != "array" )

- so what does that do? Well in javascript (as clearly stated in the 
language specification (ECMA 262)) the - typeof - operator applied to 
any primitive value, native or built-in object (which includes all of 
javascript's arrays) may not ever result in the string value "array" 
(the entire list of possibilities does not include the sting "array"). 
Host object (the objects provided by the browser) may result in any 
string value, but to date the only value that has ever been observed to 
result from applying the - typeof - operator to a host object that is 
not in the list of possible values that applies to normal javascript 
objects is the string 'unknown'. That is - typeof a - will _always_ not 
equal "array", and the example code above is the equivalent of - if 
(true) -, which is pointless, but there it sits regardless.

Why is it there? Because someone wrote it and it didn't make anything 
any worse. Why was it repeated in numerous other scripts? Because other 
people mistook it for an example of code written by someone who knew 
what they were doing, and so for a valid/meaningful/useful test.

> Maybe it's a modern phenomenon like jQuery or
> "social networking" that the young 'uns like to engage in.
> Probably I should get out more (now that I've retired I can).


With javascript this phenomenon is about as old as the language, though 
the form seems to change a little over time.

Richard. 

[toc] | [prev] | [next] | [standalone]

#8224

On Fri, 11 Nov 2011 00:36:57 -0000, "Richard Cornford"
<Richard@litotes.demon.co.uk> wrote:

[snip]

>So, an illustration, but which one? Try this, go to
><URL: http://www.google.com/codesearch >
>and in the search box at the top of the page enter the following line:-
>
>typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>
>- and do the search. It gets 4,000+ results (including from a 

     I got 5500.

>cross-section of 'popular' libraries) along the lines of:-
>
>if ( typeof a != "array" )
>
>- so what does that do? Well in javascript (as clearly stated in the 
[snip]
>objects is the string 'unknown'. That is - typeof a - will _always_ not 
>equal "array", and the example code above is the equivalent of - if 
>(true) -, which is pointless, but there it sits regardless.
>
>Why is it there? Because someone wrote it and it didn't make anything 
>any worse. Why was it repeated in numerous other scripts? Because other 

     Also, later programmers might not know and think, "I do not know
what it does, but removing it might break the code."  Another
possibility is that it might be thought to work that way with old
versions of the language.

     At the point I am in JavaScript, I would not catch the error.  I
might eventually since any code that I do not understand tends to
stick my attention.  But I might not have time to get to it.

>people mistook it for an example of code written by someone who knew 
>what they were doing, and so for a valid/meaningful/useful test.

     A beautiful example of ugliness.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8229

Gene Wirchenko wrote:
> Cornford wrote:
> [snip]
>> So, an illustration, but which one? Try this, go to
>> <URL: http://www.google.com/codesearch >
>> and in the search box at the top of the page enter the following
>> line:-
>>
>>typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') 
>>lang:javascript
>>
>> - and do the search. It gets 4,000+ results (including from a
>
>     I got 5500.

Yes, it varies (it's Google). But there are a few examples that the 
regular expression picks up that not necessarily examples of this 
mistake. e.g. The results of calls to functions that have "tyepof" at 
the end of their name being compared with the string 'array', where you 
don't know whether the function called uses the - typeof - operator at 
all.

>> cross-section of 'popular' libraries) along the lines of:-
>>
>> if ( typeof a != "array" )
>>
>> - so what does that do? Well in javascript (as clearly stated
>> in the
> [snip]
>> objects is the string 'unknown'. That is - typeof a - will
>>  _always_ not equal "array", and the example code above is the
>> equivalent of - if (true) -, which is pointless, but there it
>> sits regardless.
>>
>> Why is it there? Because someone wrote it and it didn't make
>> anything any worse. Why was it repeated in numerous other
>> scripts? Because other
>
>     Also, later programmers might not know and think, "I do not
> know what it does, but removing it might break the code."

That is a reason for not removing that structure from code where it 
appears. It could not explain how the structure moves from project to 
project, and without that it could not qualify as cargo cult 
programming. (It is not a mystical incantation if it is not re-chanted 
in the face of the next unknown)

> Another possibility is that it might be thought to work that
> way with old versions of the language.

Possibly, but it would be possible to check the older specs and observe 
that it should never have 'worked'. Older versions of browsers would be 
a better excuse, but not when it is found in code that is only designed 
to be supported by a known sub-set of 'current' browsers, as is the case 
with the 'popular' libraries that have featured this code.

>     At the point I am in JavaScript, I would not catch the
> error.  I might eventually since any code that I do not
> understand tends to stick my attention.

But at this point would you be publishing your code for use by the 
general (web-programming) public, claiming its inherent superiority to 
alternatives, pronouncing it as a demonstration of your abilities, and 
writing/selling javascript programming books off the back of it?

> But I might not have time to get to it.

Yes, mistakes are often time consuming and inconvenient to reverse. 
That suggests limiting the scope of your early work, and learning from 
the mistakes before propagating the code to the rest of the world.

>> people mistook it for an example of code written by someone who knew
>> what they were doing, and so for a valid/meaningful/useful test.
>
>     A beautiful example of ugliness.

I don't know about "ugliness". Code-wise it is very similar to much that 
is justified, correct and sensible, which is probably one factor in 
preventing it from standing out as something that should have been 
questioned.

Richard. 

[toc] | [prev] | [next] | [standalone]

#8238

On Fri, 11 Nov 2011 09:59:56 -0000, "Richard Cornford"
<Richard@litotes.demon.co.uk> wrote:

>Gene Wirchenko wrote:

[snip]

>> Another possibility is that it might be thought to work that
>> way with old versions of the language.
>
>Possibly, but it would be possible to check the older specs and observe 
>that it should never have 'worked'. Older versions of browsers would be 
>a better excuse, but not when it is found in code that is only designed 
>to be supported by a known sub-set of 'current' browsers, as is the case 
>with the 'popular' libraries that have featured this code.

     Is it worth the time?  It can be rather time-consuming to track
such things down.  Cost-benefit analysis may lead to "Meh.  Why
bother?"

>>     At the point I am in JavaScript, I would not catch the
>> error.  I might eventually since any code that I do not
>> understand tends to stick my attention.
>
>But at this point would you be publishing your code for use by the 
>general (web-programming) public, claiming its inherent superiority to 
>alternatives, pronouncing it as a demonstration of your abilities, and 
>writing/selling javascript programming books off the back of it?

     No.  Even if I had very polished code, I might not even do it
even then.

>> But I might not have time to get to it.
>
>Yes, mistakes are often time consuming and inconvenient to reverse. 
>That suggests limiting the scope of your early work, and learning from 
>the mistakes before propagating the code to the rest of the world.

     Oh, sure.  Bring logic into it!

>>> people mistook it for an example of code written by someone who knew
>>> what they were doing, and so for a valid/meaningful/useful test.
>>
>>     A beautiful example of ugliness.
>
>I don't know about "ugliness". Code-wise it is very similar to much that 
>is justified, correct and sensible, which is probably one factor in 
>preventing it from standing out as something that should have been 
>questioned.

     Extra verbiage that does nothing useful is ugly by my sense of
aesthetics.

     Yes to your second sentence.  A favourite quote of mine: "There
are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult." -- C.A.R. Hoare

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8230

On Thu, 10 Nov 2011 19:14:21 -0800, Gene Wirchenko wrote:

>On Fri, 11 Nov 2011 00:36:57 -0000, "Richard Cornford"
><Richard@litotes.demon.co.uk> wrote:

>[snip]

>>So, an illustration, but which one? Try this, go to
>><URL: http://www.google.com/codesearch >
>>and in the search box at the top of the page enter the following line:-
>>
>>typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>>
>>- and do the search. It gets 4,000+ results (including from a 

>     I got 5500.

It's growing! It's growing!

(:-)

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#8251

On Fri, 11 Nov 2011 00:36:57 -0000, Richard Cornford wrote:

>Welcome to the low entry cost world of browser scripting.
>
>So, an illustration, but which one? Try this, go to
><URL: http://www.google.com/codesearch >
>and in the search box at the top of the page enter the following line:-
>
>typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>
>- and do the search. It gets 4,000+ results (including from a 
>cross-section of 'popular' libraries) along the lines of:-

Nice! I just got 19,000+ hits. Strange that it varies so much.

Anyway, do you have more examples? These would be good demos of
the general ignorance towards correct JavaScript programming.
Good for demos.

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#8268

Hans-Georg Michna wrote:
> On Fri, 11 Nov 2011 00:36:57 -0000, Richard Cornford wrote:
>
>>Welcome to the low entry cost world of browser scripting.
>>
>>So, an illustration, but which one? Try this, go to
>><URL: http://www.google.com/codesearch >
>>and in the search box at the top of the page enter the following
>>line:-
>>
>>typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') 
>>lang:javascript
>>
>>- and do the search. It gets 4,000+ results (including from
>> a cross-section of 'popular' libraries) along the lines of:-
>
> Nice! I just got 19,000+ hits. Strange that it varies so much.

Google don't have the best of records when it comes to programming 
adding up, so varying result counts shouldn't be too unexpected. On the 
other hand, back in 2009 when I last posted about using Google's code 
search to look for this code (using the same regular expression) the 
number of hits were coming up at around 2,000. So it does appear that 
this particular cargo cult  programming example is still propagating 
(even if the worst offenders have since learnt enough to drop it).

> Anyway, do you have more examples? These would be good demos of
> the general ignorance towards correct JavaScript programming.
> Good for demos.

The other example that is common enough, and sufficiently distinct, that 
Google's code search will turn up examples would be found with the 
search expression:-

<scr("|')\+("|')ipt lang:javascript

- of which a representative example (from an old dojo version, and 
re-wrapped for posting) is:-

document.write(
  "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
);

The cargo-cult programming structure is the first (left-most) string 
concatenation operation. The final (right-most) string concatenation 
operation has some justification in some contexts. Its use in those 
contexts demonstrates a shallow understanding of the reasons for its use 
(as there are more efficient, shorter and more formally correct 
alternatives), and it was almost certainly that shallow understanding 
that inspired the real cargo-cult structure to the left. However, One 
context where the final (right-most) concatenation is purposeless is 
when it is found in an imported JS file, which is of course where 
Google's code search is finding it. So that too is pushing cargo-cult 
programming in the contexts where it is being found above.

Richard. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web