Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Eric Bednarz Newsgroups: comp.lang.javascript Subject: Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Date: Thu, 17 Nov 2011 23:14:57 +0100 Organization: Eric Conspiracy Secret Labs Lines: 87 Message-ID: References: Reply-To: ebednarz@gmx.net Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net E8zKW3Vu3FCD7eGo43QEVQ/giwpj5UUIzyqTeMnaQg6LMzq7kE Cancel-Lock: sha1:pF9aiOTZCcsO7hH0jeSIwbB55kY= sha1:R2MTlrAn0hUtiF4EdiOR1q0u/lw= X-Eric-Conspiracy: There is no conspiracy User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (darwin) Xref: x330-a1.tempe.blueboxinc.net comp.lang.javascript:8395 "Richard Cornford" writes: > Eric Bednarz wrote: >> Richard Cornford writes: >> >>> document.write( >>> "" >>> ); >>> >>> 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. >> >> I’m getting the impression that you think that the purpose of >> splitting and concatenating the generic identifier is somehow >> related to escaping the ETAGO delimiter (‘ > "Somehow related" seems applicable. Well, I don’t understand what you mean by “some justification in some contexts”. In the context of a CDATA content model it doesn’t make any sense at all because CDATA ends with ETAGO foolowed by a name start character. So that habit wouldn’t have made it valid HTML (4) either. >> while it is much more likely to be related to Norton ‘Internet >> Security’ inserting it’s dreaded SymError function after the >> first instance of anything that looks like the start tag of a >> script element (and ususally messing things up in the process). > > In a cause and effect relationship I would expect the cause to > pre-date the effect. This concatenation 'trick' was common when I > started working with javascript in 2001. Well, I’m unlikely to ever catch up with that head start. :-) References I’ve seen connecting this practice with NIS were from around 2004 to 2006, as far as I can remember. > The odds are that it > pre-dates Norton 'internet security' But why? Were there *practical* problems that are not related to validation? > and my observations of Norton's > inserted scripts have been that it has been varying over time. That’s inherent with cat and mouse games. For a while it seems to have been possible to prevent NIS from modifying the first script element in the HTML source by preceding it with an HTML comment containing script markup (this kind of thing is pretty hard to verify now, but it sounds plausible; ad-hoc parsing is usually broken and gets fixed feature by feature later). > I also don't think that the mindset where people are scripting only > for the default configurations of the most recent versions of 4 or 5 > known browsers will tend to leave then thinking about the possible > actions of 'security' proxies (or being willing to take action to > accommodate them if they did). It doesn’t create much overhead, and might have been a best practice that is so good that nobody checks what it is for ;-) On the other hand, it’s really not easy to know which cargo cult bits are redundant or not, and why. Somewhere around 2007 I removed HTML comments out of script elements in the course of a redesign of a website. I got kicked royally for that because the client had some really crappy HTML to PDF conversion software that included the script content after that. > In any event, HTML mark-up modification is still not relevant to the > contents of an imported javascript. But it is supposed to have been *only* about external script, the premise being that NIS was looking for the first occurance of something that looks like a start tag of a script element, which isn’t a problem in a HTML context.