Re: Cross-Browser onmousedown JavaScript

Richard Cornford wrote :

Hello,

<snip>

In changing IE, Microsoft can add anything new without risking much,
but they cannot significantly change what they already have.

<snip>

I completely agree, of course; changing the existing model would greatly damage customers, because of the lost backward-compatibility with existing applications. The cost, be it financial or image-related, would definitely be unacceptable.

As for adding new features, impacts may not be negligible, a script for instance may use the "evt=evt||window.event" test, in which case wrong properties could be read at a later stage if we have improper feature testing.

Microsoft seem to have become convinced that they should be adopting,
and adhering to, standards in IE more completely than they have in the
past, so the W3C event model might get in. In other areas the business
considerations probably will surface and neutralise the W3C's less
reasoned efforts.

I would say that the cost argument applies here as well; other than the image of respecting so-called standards, I can see no benefit for Microsoft in implementing W3C events, only an additional cost of development and maintenance, all the more that IE's model could be argued to be even more "standard", because apparently more used (or perceived as more used), than the W3C's. It would only make sense to implement the W3C events model if there is a demand for currently unused event features (such as custom events); and if this were happening, nothing would prevent Microsoft from extending the current model, rather than implementing the W3C's model.

<snip>

So far, Mozilla has been successful in this regard.

But even Mozilla had been seeing it as expedient to make concessions
for compatibility with IE only code, with its invisible support for -
document.all - proving a portent for a now extensive exercise in
pragmatism.

Being an idealist trying to resist to cynicism, I naturally have mixed feelings about this pragmatism issue.

This starts from a set of badly designed scripts, by incompetent programmers. (Designing for IE only cannot be defended at all; designing with a universal approach ensures superior robustness, for no additional cost).

Given this situation, two solutions are available: either change/correct the scripts, or change/evolve the browser's model. The choice of changing the model looks like the less painful; after all, scripts do not need to updated, and the browser ends up with more capabilities, right?

The consequences of such a choice, however, are deplorable: incompetent programmers do not feel encouraged to learn more about browser-scripting, or simply improve their skills, and, more importantly, their /attitude/ does not change - and this amateurish, sometimes arrogant attitude, that has been here for so long, is definitely the biggest issue of all issues, way more important than overlapping scripting models or wavering standards, as it delays the upcoming of true professionals (not even talking about experts). And the cost of this, hidden in project or maintenance expenses, is simply enormous.

Implementing "document.all" was all good for Mozilla; it was not for the community.

(sorry for the rant)

Also, code relying only on window.event is likely to be
poor, in regards of generally accepted coding practices,
and therefore is likely to use other IE-only features, which
the browser may not implement and stumble upon.

Yes, but if the alternative to the path of providing partial
compatibility with IE and so supporting, say, 80% of code designed to
be IE only, is to fail when exposed to any of it then that is likely
to seem like the better option.

Well, yes, probably :(

<snip>

I haven't had much to do with Java recently, but I gather that it has
grown (or is growing) closures, so moving in the javascript
direction.

I don't know either, but *that* would be funny :)

<snip>

Recently both the Prototype.js and
JQuery libraries have (more or less) recognised the inherent
superiority of feature detection and set about replacing their browser
sniffing based branching code. These are the creations of people who
have, in the past, attempted to defend UA string based browser
sniffing as the only viable strategy in client-side code authoring
(regardless of being shown that it wasn't).

Well, user agents and even proxies can spoof the UA string (I was happily using IE8 back in 2002), feature detection is really the natural way of doing... Browser detection in itself is extremely rarely needed.

If they can come to see
that one of their fundamental assumptions about how things should be
done then perhaps they can be persuaded to, at least, question some of
their others, and so become open to the idea that there may be
advantages in structures that are not large-scale, interdependent code
libraries.

As a matter of taste, I'd rather re-use some components I have previously written and tested, rather than a full library (my reasons being easier maintenance, simpler integration, better quality assessment and less constraints on programming style). I would not be hostile to library projects though, I just "feel" that (and it's a paradox) it lacks flexibility given browser-scripting subtleties.


Regards,
Elegie.
.

Relevant Pages

  • Re: Picasa 2 query.
    ... appear and there is an error message at the top of the page which ... That doesn't mean the Web Browser itself isn't "fully supported"... ... What it means is that the particular Scripts & things on the Page ... use various "tests" to see what features the Browser has Enabled ...
    (uk.people.silversurfers)
  • Re: Accessing the global object
    ... undetectable/untestable browser bugs, ... This is the question at the heart of why the "big libraries" choose to ... Again with the language features. ... Don't use "big libraries" (or any scripts) that make ridiculous ...
    (comp.lang.javascript)
  • Re: typeof for feature testing host methods
    ... syntax features and features provided by the host environment. ... Apparently you do *not* recognize that language syntax can only be maybe ... will cause your scripts to throw errors. ... interesting piece of browser script design. ...
    (comp.lang.javascript)
  • Re: How to list the statement of all var ?
    ... but as it is a command line tool it does not have access to a browser DOM ... > implementations based on language features of JavaScript 1.1 and JScript ... > script libraries which also ...
    (comp.lang.javascript)
  • Re: Find Element Position
    ... [snip about rying to get the position of an element in abstract view][ ... going to be rounded in whatever way the browser sees fit. ... size the font of the element. ... toString, but other code in the library did. ...
    (comp.lang.javascript)
Loading