Strunk, William, Jr. (1 July 1869-26 Sept. 1946), educator and grammarian, was born in Cincinnati, Ohio, the son of William Strunk, Sr., and Ella Garretson Strunk. He graduated from the University of Cincinnati in 1890 with an A.B. and was an instructor in mathematics at the Rose Polytechnical Institute in Terra Haute, Indiana (1890-1891). He then went to Cornell University in Ithaca, New York, where he was an instructor in English (1891-1898) while earning his Ph.D. there (1896). He spent the 1898-1899 academic year studying at the University of Paris.
Strunk returned to Cornell and remained there for the rest of his professional life; he was to die in Ithaca. Named an assistant professor of English in 1899, he was promoted to full professor in 1909 and retired in 1937. In 1900 Strunk married Olivia Emilie Locke; they had three children. During his early years at Cornell, Strunk produced editions of Thomas Babington Macaulay and Thomas Carlyle's Essays on Samuel Johnson (1895); John Dryden's Essays on Drama (1898), All for Love (1911), and The Spanish Fryar (1911); James Fenimore Cooper's The Last of the Mohicans (1900); Cynewulf's Juliana (1904); and Shakespeare's Romeo and Juliet (1911) and The Tragedy of Julius Caesar (1915). Through the Cornell Co-operative Society, Strunk published his English Metres (1922), a down-to-earth explanation of the subject. He also coedited a festschrift, Studies in Language and Literature in Celebration of the Seventieth Birthday of James Morgan Hart, November 2, 1909 (1910).
By far the most challenging of Strunk's editorial tasks was his work on Cyenwulf's Juliana, written in Old English, which Strunk had meticulously studied. The most pleasant result of his editorial work was his being hired in 1935 as a consultant by Irving Thalberg for a Hollywood film production of Romeo and Juliet (1936). Strunk's function was to assure that the spirit of Shakespeare's play would not be violated. Although he expected to be in Hollywood for six weeks, Strunk was so genially accepted as "the Professor," and had such a good time, that he remained almost an entire year. In 1937 he reduced Shakespeare's Antony and Cleopatra to a two-act format. Excessive cutting, however, which included the omission of Enobarbus's suicide, caused the Broadway production to close quickly.
First and foremost, Strunk was a classroom teacher. His courses in English composition at Cornell, over a period exceeding four decades, made him a legend. To enable his students to write correct, concise, and vigorous prose, he put together The Elements of Style, a little textbook of forty-three pages. Privately printed in 1918, it succinctly spelled out rules of usage and principles of composition, discussed form, and offered a common-sense approach to punctuation and rhetoric. In parallel columns, Strunk gave examples of sloppy style and then correct style. A proponent of writing in the active voice, he encouraged the use of definite, concrete language, keeping to one tense, and other means of achieving a lucid, compact style. He also discussed such mechanical matters as margins and references and how to deal with colloquialisms.
The Elements of Style proved to be so popular, and so much in demand, that it was commercially published in 1920, and (with the assistance of Edward A. Tenney) Strunk revised and updated it in 1935. The little textbook was destined to become a classic, however, when in 1957 E. B. White, who had been one of Strunk's students at Cornell in 1919 and had gone on to fame as a writer, published an essay about his former teacher, "Will Strunk," which appeared in the New Yorker on 15 July 1957. The editors of the Macmillan Company located with some difficulty an old copy of The Elements of Style and persuaded White to reissue it with an introduction. He did so by modifying his New Yorker encomium in 1959. The book became a runaway success. In a second edition, published in 1972, White explained that in 1959 he had "tried . . . to preserve the flavor of [Strunk's] discontent, while slightly enlarging the scope of the discussion." He replaced outdated examples with fresher ones, making use of a few revisions Strunk himself had noted but never added. White did the same again for a third edition (1979). In going over Strunk's rules, White says he could visualize Strunk's "puckish face," short hair with middle part and bangs, blinking eyes, steel-rimmed glasses, nervously nibbled lips, and repeated adjurations to his students to be concise.
Strunk was a skillful scholar-educator but will be remembered almost exclusively as the author of The Elements of Style, which is now known as "Strunk and White" and which has improved the writing of countless thousands of grateful writers. In 1999 the editors of the Modern Library placed The Elements of Style by William Strunk and E. B. White number twenty-one on their "List of 100 Best Works of 20th Century Nonfiction," considerably below The Education of Henry Adams but just above Principia Mathematica by Alfred North Whitehead and Bertrand Russell, a work all but unreadable except to highly trained specialists. The Elements of Style will endure for precisely the opposite reasons.
Bibliography
The Cornell University library lacks papers by Strunk but does have a small number of letters to him by William Dean Howells. A final revision of E. B. White's "Will Strunk" is in White's The Points of My Compass (1962). Essays by three scholars in Cynewulf: Basic Readings, ed. Robert E. Bjork (1996), make brief references to Strunk's edition of Juliana--one in indirect praise, two in disagreement. Bob Thomas, Thalberg; Life and Legend (1969), mentions Strunk's work in Hollywood. An obituary is in the New York Times, 27 Sept. 1946.
I do believe there were many posts at the time (on Slashdot, no less) pointing out the same gross errors in fact and problematic reporting. Why go elsewhere when you can get your criticism at home?
Someone forgot to insert the leading http:// protocol identifiers for the links in the story, and MSIE 5.5 (here) is generating goofy URLs by inserting http://slashdot.org/ in front of them there links!
Would it be possible to make Nautilus or another non-javascript browser examine the javascript source code and guess what it does?
Methinks not easily (especially if it were a non-javascript browser... how would it know how to parse the scripting:)
A more sensible approach would be to go ahead and code a full script parser (which kind of scripting? javascript? jscript? ECMAscript? VBscript?) into the browser, but allow the setting of security privleges on the various objects in the browser's DOM to permit or deny access.
So, if I hate rollovers, I can forbid write access to image objects (however modeled) but allow access to form-related objects to permit client-side validation. OTOH, this could become a web designer's nightmare:P
Netscape has (in the past) followed this tack with regards to a subset of scripting methods and objects, requiring signed scripts to access them through javascript. Certainly, client-side scripting languages should offer a bit more flexibility than the all-or-nothing approach of "off" or "on"... at present, Microsoft actually allows more flexbility in setting privilege levels in a manner similar to this -- it is unfortunate that they fail to document it all "up front" for the end-user.
re: pulling out embedded URLs and/or multiple images -- several scripts are not so open about these things, building URLs or image names from pieces... the only way to yank these values out as wholes (rather than constituent parts) would be to implement something that could parse [foo]script on its own. but then you would have a [foo]script browser of your own!:)
How about just trying "personal information" in the index of the help file?
Originally, I was referring to the use of the Search feature to ferret out anything in the immediate documentation that had to do with persistent userinfo.
Your suggestion, though it makes sense, doesn't turn up any meaningful information, either. At least not in *my* IE5.5 help files.
I work for *another* direct email marketing company [shudder?] -- not advaya -- and can tell you with about 98% certainty what that does for advaya... it is used to measure "open" rates on HTML email: gif requested == email opened. The query string appended at the end "personlizes" the 'bug' and permits measuring of "unique" open rates for a particular mailing.
This is not to say that additional information is being pulled or corrollated, but given that direct email marketing is still in its infancy and the minimal levels of 'synergy' between direct email campaigns and other sources of personal information, I don't think you need to worry just yet that advaya knows what you had for lunch today.:P
As to what the string contains... nothing more than a unique identifier to a database entry somewhere. There's really no point in placing the actual contents of the database in the string itself.
Somewhat offtopic, and oft-mentioned on SlashDot... if you are looking for an example of web 'bug' implementation, look no father than the HTML direct email marketers send out... 'bugs' of this sort are a threat only insofar as they might be tied into long-term tracking databases. You overlook the fact that the images need not be 1x1 in size, as more clever implementations can return any image while still capturing the desired information
The purported threat here is that 'persistent userdata' may permit access to information other than that commonly available to web 'bugs'... that may or may not be the case, but I would suspect that any meaningful exploit of this feature would require someone or someones capable of tracking the information across sites and/or someone or someones maliciously accessing stored preferences from other sites.
Don't see any evidence of either as of yet, only the potential for future (ab|mis)use.
the only good thing about jscript is that you can always view source.
Offtopic - although viewing such source is not always so easily done as said. included scripts (using the SRC attribute) will not show up in their full glory to those with scripting turned off initially, requiring one to download and examine the included script(s)... not exactly user-friendly.
Further Offtopic - unfortunately, the security model of browsers/javascript does not (yet) permit one to selectively deny scripts access to arbitrary objects within the DOM -- although I can only imagine a number of power-users would be very interested in just such an option.
Have I Been Trolled? - I think javascript does have its place when client-side processing can alleviate the back-and-forth of server-side processing (preliminary validation of form submissions being one case).
Microsoft defended the feature and pointed out that the vast majority of Web surfers already are knowingly vulnerable to the same level of exposure.
"This feature has a trade-off, like almost every other feature on the Web--in this case, between functionality and a minor, potential privacy exposure" [...]
Not to rant, but I cannot understand how such specious reasoning would find its way out of the mouth of a Microsoft representative. How could they possibly argue that since users are already at much greater risk from other features/exploits, one more "minor" inconvenience shouldn't matter?
Clearly documented explanations of the security features that one can toggle in the Internet Options -> Security tab would be one thing, but the lack of context-specific, right-click help (try it and see) or even the word persistence in the indexed help file (search and see) is somewhat silly.
Why would I have to journey to the developer's corner (link lifted from article) to learn what features are present in my browser? Maybe it's time that end-users insist on better [more immediate] documentation from Microsoft, especially with regards to things categorized under the heading of security
ps - SlashDot still has its woes when dropping in long URLs. God bless the preview button
... a remark about the implicit irony of a BestBuy ad banner ("Passing on these DVDs... would be criminal") flashing atop this article would have been made by now.
Guess everyone else is browsing with the banners blocked and/or I'm the only one to have the (mis)fortune of the banner appearing right as I open to read the comments.
Sometimes humor is simply the result of happenstance...
In addition to the other response (image == web counter), 1 x 1 pixel images are also used for web page layout. It is (or was, at least) the only way to get certain things (like precise alignment) done in HTML.
Typical tired response is that images of such dimensions for pixel-perfect placement is usually (these days) done to get around Netscape not honoring table cell height and widths for cells lacking content -- workaround here is to use the proprietary Netscape SPACER tag in place of images for pixel-perfect layout.
Tired response #2 is that this is not quite the same thing as a 1x1 buglet, as the dimensions involved are those *represented in the HTML* and not the *actual dimensions* of the linked image. In order to know the latter, the client/recipient would have to download the image in question -- instant logging activity. To effectively block buglets in advance, you would have to know that it is a buglet (1x1 dimensions) by looking at the markup HEIGHT and WIDTH hints and guessing that the image(s) in question are buglets before making the request for them.
Unless the pixel-perfect layout you seek is in nice 1x1 chunks -- not a 1x1 transparent GIF stretched using HEIGHT and WIDTH to arbitrary dimensions -- the level of identity between 1x1 web bugs and your general purpose 1x1 shim image cannot be ascertained without requesting the image and verifying its dimensions.
Of course, the web bug functionality is probably better served by using a lightweight, "real" image (for example, a closing horizontal rule or company logo) and not something as obvious as a 1x1 graphic pasted on to the end of a document, page, or HTML mailing
By supported, I meant by webmasters. The VAST majority of pages are designed to run well on IE (and Netscape, for that matter, yes). That comes along with market share, tho.
Standards compliance (or as close as one can get with the current state of standards) takes one a long way toward 'running well on IE' without short-changing other WWW clients [browsers]. The VAST majority of pages are designed with at least some consideration of these standards in mind, though most frequently as they pertain to graphical clients (as opposed to character-cell clients such as Lynx or aural 'readers').
There is very little that one can do to ensure that web documents 'run well' under IE as opposed to a competing graphical browser (such as Netscape or Opera) as most tasks are bound by the rendering engine(s) built into the various clients. Most performance considerations that are within the control of web designers/implementors (document weight, code/object re-use, image compression, etc.) more or less apply just as well to client X as they do to IE.
The best that can be said for design tailored to IE is that one can achieve results unavailable to competing clients (either because IE is a closer approximation to existing standards than its competitors or because it offers proprietary extensions to the standards) or the results can be prototyped and handled for IE more efficiently by developers than for competing clients (case in point being IFRAME v. LAYER madness). Only in cases where IE offers greater standards compliance and/or a competitor's compliance is buggy (as in offered, but not reliably) can one really argue for a performance advantage to IE.
Only in cases where these additional capabilities are actually required can one argue for a benefit in slanting his or her code to favor IE. Given that general purpose web design forces one to always consider legacy clients (let alone AOL), IE wizardry is best saved for intranets and not the Internet. Although, I've read the opinions of many Slashdotters that suggest that even this level of reliance on Microsoft (rather than a standards body) to dictate the terms of web development to be mistaken.
But at what cost? I guess I see the state of affairs as being one where non-IE clients are unable to deliver the goods feature-wise or make half-assed attempts to do so. Rather than slant coding in favor of IE it is far more profitable in the long-run to push for more and better from its competitors. The glass is half full, not half empty. IE is not better, its competitors are worse.
I honestly believe that if competitors made serious efforts to release clients capable of carrying off the latest standards most of the advantage that rests with IE would be lost from a development perspective with the added benefit of putting some backbone into those very standards. Whether or not end users adopt these fictive uber-broswers will depend on availability, reliability, utility, and performance.
Of course, it is most likely quite delusional on my part to believe this, as the sheer ubiquity of IE at this stage in the game pretty much guarantees that a serious contender will have to offer something very special (read: proprietary) in order for end users to notice.
Of course this is just an off-topic rant, so I am most likely wrong.
LICQ does have some keyboard shortcuts. Of course, you have to get it in focus. Windows versions of ICQ are nice in that the scope of the keyboard shortcuts are global.
Maybe, but ICQ can be very selfish when it comes to global keyboard shortcuts -- it may block out other programs (in my case, Photoshop) that happen to want to use the self-same keyboard shortcut. Unfortunately, I believe you only have the option in ICQ of global shortcuts or no shortcuts.
Amazon, for instance, tracks all of my purchases, and, in return, gives me the only useful product recommendations I've seen on any commercial web site.
I find it funny that the recommendations I receive from the Amazon are nearly useless, if only because they don't seem to keep in mind what I've already purchased *from them* (recommending past purchases time and again)... then again, I do buy quite a bit from them.:P
One might take the stance that useful services (like the one you point to) might actually demonstrate the benefit of detailed profiling in certain cases. However, I would probably counter that such services should be "opt-in" rather than "opt-out" and openly disclosed, either way.
Yet, the case with Coremetrics is not the same as with the Amazon example offered above (exactly) -- the immediate advantage or interest in Coremetrics tracking appears to rest with the business and not the consumer/visitor. The business wants to track usage to better organize or understand their visitors (and potential consumers) in order to generate more business. This is not as direct a benefit to users as an automated recommendation system. And so, judging from the posts here, today, I can only imagine that certain groups of visitors are less likely to "submit" to such tracking -- if only because the benefit to users is not immediately apparent or altogether intangible.
I think it is the lack of immediate/direct usage of tracking stats that spooks people more than anything else. If the stats aren't being used now (say, feedback in the form of the recommendation system), when will they be used, by whom, and for what purpose?
Seriously off-topic, I know. But I work for a company that carries out direct email marketing, so I guess I've entitled myself to a mini-rant.
Fred Moody was the same guy who wrote a column last year saying that the Relativistic Heavy Ion Collider project should be stopped because it might create a black hole and destroy the earth.
Here is the relevant link to the above-referenced piece:
Of course, I should warn that these link to amazon.com -- but the reviews seem pretty split on the merits of his book-length work, too -- some are even a bit witty.
Now here's a thing: in Netscape (at least the Linux version - I didn't try others), if you turn off JavaScript, it stops CSS from working. Weird, or what!
Because, iirc, CSS is implemented *through* the javascript engine in Netscape 4.xx
3) The I Can't Think Of One Example: There are packages out there (and unfortunately I can't think of one right now) where it is released under different licenses depending on, for instance, the platform you are going to run on.
Slashdot Mirror
Strunk, William, Jr. (1 July 1869-26 Sept. 1946), educator and grammarian, was born in Cincinnati, Ohio, the son of William Strunk, Sr., and Ella Garretson Strunk. He graduated from the University of Cincinnati in 1890 with an A.B. and was an instructor in mathematics at the Rose Polytechnical Institute in Terra Haute, Indiana (1890-1891). He then went to Cornell University in Ithaca, New York, where he was an instructor in English (1891-1898) while earning his Ph.D. there (1896). He spent the 1898-1899 academic year studying at the University of Paris.
Strunk returned to Cornell and remained there for the rest of his professional life; he was to die in Ithaca. Named an assistant professor of English in 1899, he was promoted to full professor in 1909 and retired in 1937. In 1900 Strunk married Olivia Emilie Locke; they had three children. During his early years at Cornell, Strunk produced editions of Thomas Babington Macaulay and Thomas Carlyle's Essays on Samuel Johnson (1895); John Dryden's Essays on Drama (1898), All for Love (1911), and The Spanish Fryar (1911); James Fenimore Cooper's The Last of the Mohicans (1900); Cynewulf's Juliana (1904); and Shakespeare's Romeo and Juliet (1911) and The Tragedy of Julius Caesar (1915). Through the Cornell Co-operative Society, Strunk published his English Metres (1922), a down-to-earth explanation of the subject. He also coedited a festschrift, Studies in Language and Literature in Celebration of the Seventieth Birthday of James Morgan Hart, November 2, 1909 (1910).
By far the most challenging of Strunk's editorial tasks was his work on Cyenwulf's Juliana, written in Old English, which Strunk had meticulously studied. The most pleasant result of his editorial work was his being hired in 1935 as a consultant by Irving Thalberg for a Hollywood film production of Romeo and Juliet (1936). Strunk's function was to assure that the spirit of Shakespeare's play would not be violated. Although he expected to be in Hollywood for six weeks, Strunk was so genially accepted as "the Professor," and had such a good time, that he remained almost an entire year. In 1937 he reduced Shakespeare's Antony and Cleopatra to a two-act format. Excessive cutting, however, which included the omission of Enobarbus's suicide, caused the Broadway production to close quickly.
First and foremost, Strunk was a classroom teacher. His courses in English composition at Cornell, over a period exceeding four decades, made him a legend. To enable his students to write correct, concise, and vigorous prose, he put together The Elements of Style, a little textbook of forty-three pages. Privately printed in 1918, it succinctly spelled out rules of usage and principles of composition, discussed form, and offered a common-sense approach to punctuation and rhetoric. In parallel columns, Strunk gave examples of sloppy style and then correct style. A proponent of writing in the active voice, he encouraged the use of definite, concrete language, keeping to one tense, and other means of achieving a lucid, compact style. He also discussed such mechanical matters as margins and references and how to deal with colloquialisms.
The Elements of Style proved to be so popular, and so much in demand, that it was commercially published in 1920, and (with the assistance of Edward A. Tenney) Strunk revised and updated it in 1935. The little textbook was destined to become a classic, however, when in 1957 E. B. White, who had been one of Strunk's students at Cornell in 1919 and had gone on to fame as a writer, published an essay about his former teacher, "Will Strunk," which appeared in the New Yorker on 15 July 1957. The editors of the Macmillan Company located with some difficulty an old copy of The Elements of Style and persuaded White to reissue it with an introduction. He did so by modifying his New Yorker encomium in 1959. The book became a runaway success. In a second edition, published in 1972, White explained that in 1959 he had "tried . . . to preserve the flavor of [Strunk's] discontent, while slightly enlarging the scope of the discussion." He replaced outdated examples with fresher ones, making use of a few revisions Strunk himself had noted but never added. White did the same again for a third edition (1979). In going over Strunk's rules, White says he could visualize Strunk's "puckish face," short hair with middle part and bangs, blinking eyes, steel-rimmed glasses, nervously nibbled lips, and repeated adjurations to his students to be concise.
Strunk was a skillful scholar-educator but will be remembered almost exclusively as the author of The Elements of Style, which is now known as "Strunk and White" and which has improved the writing of countless thousands of grateful writers. In 1999 the editors of the Modern Library placed The Elements of Style by William Strunk and E. B. White number twenty-one on their "List of 100 Best Works of 20th Century Nonfiction," considerably below The Education of Henry Adams but just above Principia Mathematica by Alfred North Whitehead and Bertrand Russell, a work all but unreadable except to highly trained specialists. The Elements of Style will endure for precisely the opposite reasons.
Bibliography
The Cornell University library lacks papers by Strunk but does have a small number of letters to him by William Dean Howells. A final revision of E. B. White's "Will Strunk" is in White's The Points of My Compass (1962). Essays by three scholars in Cynewulf: Basic Readings, ed. Robert E. Bjork (1996), make brief references to Strunk's edition of Juliana--one in indirect praise, two in disagreement. Bob Thomas, Thalberg; Life and Legend (1969), mentions Strunk's work in Hollywood. An obituary is in the New York Times, 27 Sept. 1946.
Robert L. Gale
I believe Hemos should have typed "causally" instead.
...cope with the tag soup of its own site design.
Look at the source retrieved from http://browsex.com/
and ask me how it is anywhere close to being
standards compliant or even sound syntactically.
Example- Here is how the retrieved doc opens:
<TABLE> <TR>
<TD width=123> <DIV align=left> <IMG SRC= linux.gif ></IMG></DIV></TD>
<TD> <CENTER> <IMG SRC=browsexb.gif alt="BrowseX"></IMG></CENTER></TD>
<TD width=123><DIV align=right> <IMG SRC= logo64.gif ></IMG></DIV></TD>
</TR></TABLE>
<BODY BGCOLOR="#FFFFFF" LINK="#066e28" >
Then again, if it *can* cope with coding
like this, I'm sure it could handle anything.
Or, just read a Slashdot response to the errant Slashdot story.
I do believe there were many posts at the time (on Slashdot, no less) pointing out the same gross errors in fact and problematic reporting. Why go elsewhere when you can get your criticism at home?
I think the answer you're looking for is "none".
Oh, the dodo, what a lovely bird it was!
He who is without sin ... :P
The correct link for Redhat's bugzilla is this:
I guess that is what I get when I assume that the only thing wrong with the links was the syntax.
Someone forgot to insert the leading http:// protocol identifiers for the links in the story, and MSIE 5.5 (here) is generating goofy URLs by inserting http://slashdot.org/ in front of them there links!
Proper URLs:
Cocoa apps?!?
Cocoa apps!?!
I go koo-koo for Cocoa apps!!!
Sorry. Couldn't resist.
Methinks not easily (especially if it were a non-javascript browser ... how would it know how to parse the scripting :)
A more sensible approach would be to go ahead and code a full script parser (which kind of scripting? javascript? jscript? ECMAscript? VBscript?) into the browser, but allow the setting of security privleges on the various objects in the browser's DOM to permit or deny access.
So, if I hate rollovers, I can forbid write access to image objects (however modeled) but allow access to form-related objects to permit client-side validation. OTOH, this could become a web designer's nightmare :P
Netscape has (in the past) followed this tack with regards to a subset of scripting methods and objects, requiring signed scripts to access them through javascript. Certainly, client-side scripting languages should offer a bit more flexibility than the all-or-nothing approach of "off" or "on" ... at present, Microsoft actually allows more flexbility in setting privilege levels in a manner similar to this -- it is unfortunate that they fail to document it all "up front" for the end-user.
re: pulling out embedded URLs and/or multiple images -- several scripts are not so open about these things, building URLs or image names from pieces ... the only way to yank these values out as wholes (rather than constituent parts) would be to implement something that could parse [foo]script on its own. but then you would have a [foo]script browser of your own! :)
Originally, I was referring to the use of the Search feature to ferret out anything in the immediate documentation that had to do with persistent userinfo.
Your suggestion, though it makes sense, doesn't turn up any meaningful information, either. At least not in *my* IE5.5 help files.
Somewhat offtopic, and oft-mentioned on SlashDot ... if you are looking for an example of web 'bug' implementation, look no father than the HTML direct email marketers send out... 'bugs' of this sort are a threat only insofar as they might be tied into long-term tracking databases. You overlook the fact that the images need not be 1x1 in size, as more clever implementations can return any image while still capturing the desired information
The purported threat here is that 'persistent userdata' may permit access to information other than that commonly available to web 'bugs' ... that may or may not be the case, but I would suspect that any meaningful exploit of this feature would require someone or someones capable of tracking the information across sites and/or someone or someones maliciously accessing stored preferences from other sites.
Don't see any evidence of either as of yet, only the potential for future (ab|mis)use.
Offtopic - although viewing such source is not always so easily done as said. included scripts (using the SRC attribute) will not show up in their full glory to those with scripting turned off initially, requiring one to download and examine the included script(s) ... not exactly user-friendly.
Further Offtopic - unfortunately, the security model of browsers/javascript does not (yet) permit one to selectively deny scripts access to arbitrary objects within the DOM -- although I can only imagine a number of power-users would be very interested in just such an option.
Have I Been Trolled? - I think javascript does have its place when client-side processing can alleviate the back-and-forth of server-side processing (preliminary validation of form submissions being one case).
From the article
Hint, the link is there to remind you to read it
Not to rant, but I cannot understand how such specious reasoning would find its way out of the mouth of a Microsoft representative. How could they possibly argue that since users are already at much greater risk from other features/exploits, one more "minor" inconvenience shouldn't matter?
Clearly documented explanations of the security features that one can toggle in the Internet Options -> Security tab would be one thing, but the lack of context-specific, right-click help (try it and see) or even the word persistence in the indexed help file (search and see) is somewhat silly.
Why would I have to journey to the developer's corner (link lifted from article) to learn what features are present in my browser? Maybe it's time that end-users insist on better [more immediate] documentation from Microsoft, especially with regards to things categorized under the heading of security
ps - SlashDot still has its woes when dropping in long URLs. God bless the preview button
... a remark about the implicit irony of a BestBuy ad banner ("Passing on these DVDs ... would be criminal") flashing atop this article would have been made by now.
Guess everyone else is browsing with the banners blocked and/or I'm the only one to have the (mis)fortune of the banner appearing right as I open to read the comments.
Sometimes humor is simply the result of happenstance...
Typical tired response is that images of such dimensions for pixel-perfect placement is usually (these days) done to get around Netscape not honoring table cell height and widths for cells lacking content -- workaround here is to use the proprietary Netscape SPACER tag in place of images for pixel-perfect layout.
Tired response #2 is that this is not quite the same thing as a 1x1 buglet, as the dimensions involved are those *represented in the HTML* and not the *actual dimensions* of the linked image. In order to know the latter, the client/recipient would have to download the image in question -- instant logging activity. To effectively block buglets in advance, you would have to know that it is a buglet (1x1 dimensions) by looking at the markup HEIGHT and WIDTH hints and guessing that the image(s) in question are buglets before making the request for them.
Unless the pixel-perfect layout you seek is in nice 1x1 chunks -- not a 1x1 transparent GIF stretched using HEIGHT and WIDTH to arbitrary dimensions -- the level of identity between 1x1 web bugs and your general purpose 1x1 shim image cannot be ascertained without requesting the image and verifying its dimensions.
Of course, the web bug functionality is probably better served by using a lightweight, "real" image (for example, a closing horizontal rule or company logo) and not something as obvious as a 1x1 graphic pasted on to the end of a document, page, or HTML mailing
Nothing new (or at least, not all that new) -- altavista has offered link: searching for a much longer period of time.
See: /syntax.html
http://doc.altavista.com/adv_search
Standards compliance (or as close as one can get with the current state of standards) takes one a long way toward 'running well on IE' without short-changing other WWW clients [browsers]. The VAST majority of pages are designed with at least some consideration of these standards in mind, though most frequently as they pertain to graphical clients (as opposed to character-cell clients such as Lynx or aural 'readers').
There is very little that one can do to ensure that web documents 'run well' under IE as opposed to a competing graphical browser (such as Netscape or Opera) as most tasks are bound by the rendering engine(s) built into the various clients. Most performance considerations that are within the control of web designers/implementors (document weight, code/object re-use, image compression, etc.) more or less apply just as well to client X as they do to IE.
The best that can be said for design tailored to IE is that one can achieve results unavailable to competing clients (either because IE is a closer approximation to existing standards than its competitors or because it offers proprietary extensions to the standards) or the results can be prototyped and handled for IE more efficiently by developers than for competing clients (case in point being IFRAME v. LAYER madness). Only in cases where IE offers greater standards compliance and/or a competitor's compliance is buggy (as in offered, but not reliably) can one really argue for a performance advantage to IE.
Only in cases where these additional capabilities are actually required can one argue for a benefit in slanting his or her code to favor IE. Given that general purpose web design forces one to always consider legacy clients (let alone AOL), IE wizardry is best saved for intranets and not the Internet. Although, I've read the opinions of many Slashdotters that suggest that even this level of reliance on Microsoft (rather than a standards body) to dictate the terms of web development to be mistaken.
But at what cost? I guess I see the state of affairs as being one where non-IE clients are unable to deliver the goods feature-wise or make half-assed attempts to do so. Rather than slant coding in favor of IE it is far more profitable in the long-run to push for more and better from its competitors. The glass is half full, not half empty. IE is not better, its competitors are worse.
I honestly believe that if competitors made serious efforts to release clients capable of carrying off the latest standards most of the advantage that rests with IE would be lost from a development perspective with the added benefit of putting some backbone into those very standards. Whether or not end users adopt these fictive uber-broswers will depend on availability, reliability, utility, and performance.
Of course, it is most likely quite delusional on my part to believe this, as the sheer ubiquity of IE at this stage in the game pretty much guarantees that a serious contender will have to offer something very special (read: proprietary) in order for end users to notice.
Of course this is just an off-topic rant, so I am most likely wrong.
Maybe, but ICQ can be very selfish when it comes to global keyboard shortcuts -- it may block out other programs (in my case, Photoshop) that happen to want to use the self-same keyboard shortcut. Unfortunately, I believe you only have the option in ICQ of global shortcuts or no shortcuts.
Someone correct me if I'm wrong.
I find it funny that the recommendations I receive from the Amazon are nearly useless, if only because they don't seem to keep in mind what I've already purchased *from them* (recommending past purchases time and again) ... then again, I do buy quite a bit from them. :P
One might take the stance that useful services (like the one you point to) might actually demonstrate the benefit of detailed profiling in certain cases. However, I would probably counter that such services should be "opt-in" rather than "opt-out" and openly disclosed, either way.
Yet, the case with Coremetrics is not the same as with the Amazon example offered above (exactly) -- the immediate advantage or interest in Coremetrics tracking appears to rest with the business and not the consumer/visitor. The business wants to track usage to better organize or understand their visitors (and potential consumers) in order to generate more business. This is not as direct a benefit to users as an automated recommendation system. And so, judging from the posts here, today, I can only imagine that certain groups of visitors are less likely to "submit" to such tracking -- if only because the benefit to users is not immediately apparent or altogether intangible.
I think it is the lack of immediate/direct usage of tracking stats that spooks people more than anything else. If the stats aren't being used now (say, feedback in the form of the recommendation system), when will they be used, by whom, and for what purpose?
Seriously off-topic, I know. But I work for a company that carries out direct email marketing, so I guess I've entitled myself to a mini-rant.
Here is the relevant link to the above-referenced piece:
More interesting of course is his response to reader mail, available here:
From the latter article, the most interesting line may be the last:
"And here's hoping my editors take this guy's advice and beam my columns into interstellar space. It's my only hope for immortality."
In part, probably because he is published.
One can always peruse the reviews posted for and against his book, I Sing the Body Electronic , or The Visionary Position .
Of course, I should warn that these link to amazon.com -- but the reviews seem pretty split on the merits of his book-length work, too -- some are even a bit witty.
Or, I guess one could simply write him and ask.
Because, iirc, CSS is implemented *through* the javascript engine in Netscape 4.xx
mySQL is an example of this, isn't it?