Richard Cornford wrote :
IE will probably never abandon its own event model (or
implement W3C Event specification),
I don't think that is necessarily true. Browsers like Opera, Safari,
Chrome, etc. demonstrate that the two event models can happily co-
exist. Microsoft's problem is that the have a large number of
(presumably very profitable) corporate customers who have made their
own investment in internal web applications, many of which have been
written to be IE specific. If Microsoft change IE so that it is not
back-compatible with its previous versions they risk alienating their
commercial customers by breaking significant proportions of their
existing Intranet software and so imposing avoidable additional costs
on them (in repairing/replacing that software). As things stand the
investment in that software is one added incentive to stick with the
Windows operating system, but if that software is to be broken anyway
then the relative costs of switching to another operating system swing
in a direction Microsoft would not appreciate.
In changing IE, Microsoft can add anything new without risking much,
but they cannot significantly change what they already have. The W3C
event model is pure addition, unlike, for example, the proposed W3C
standard for position reporting in the DOM (which defines things like
- offsetLef - properties in a way that is incompatible with what IE
traditionally does).
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.
so it could be a relevant investment for any user
agent to implement IE's model as well as the W3C's.
That has always been true. So much code has been written to be IE only
that emulating as much of IE's object model as possible lets them
looks less broken in the face of a web that is not at all tolerant of
new/unexpected browsers.
Still, implementing only the W3C's model would have been a
fine choice to me, the W3C event model is stronger than IE's
model
Mostly yes. There is the inverse possibility that some script may
infer that the browser was Firefox/Mozilla from the absence of the IE
model and then attempt to employ the some of the many Firefox/Mozilla
specific features. I don't recall ever seeing anyone doing that so it
probably isn't a big risk.
(this is much more debatable for the Range Specification,
for instance), it is now well-known, so I don't think a browser
would lose any audience not implementing the IE's model.
The browser would have to arrange that when code guessed at the type
of browser the guess it made was that the browse was Mozilla/Friefox.
That may well mean not implementing IE originating features, and so
sacrificing compatibility with IE only code.
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.
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.
The choice of implementing window.event, as part of a broader
IE-compatibility strategy, is a heavy one, and if only partly
completed, a risky one.
Yes, there are a number of things that have to go with it. One example
being having callable collections, as IE only code has a strong
tendency to use those.
That was to be expected, and is a good illustration of why
browser sniffing has been advocated against since years now.
Still, a browser just spoofing a property without implementing
the relevant functionality behind it, would be a foolish thing.
That depends a bit on what uses the object/feature is put to. Numerous
objects have been employed in object inference browser sniffing in a
way that made that use more significant than their intended purpose.
For example, IceBrowser had a global - ActiveXObject - function, which
could hardly be expected to instantiate ActiveX objects in a Java
based browser running on non-Windows systems. It seems the object was
there to confound the, then fashionable, strategy of inferring that
the browser was IE 5+ from the existence of that constructor. A
situation much like that of - window.external - use.
Of course, an innovative functionality, proposed by some
vendor, is fine to copy; this is the way progress can be
accomplished.
Very true, and why we have pretty much standardised AJAX without any
ratified standard for the interfaces it uses.
Thank you, it's nice to read you again! I'm not sure I'll stick
around for long though, as you know javascript was just a hobby
to me (one I enjoyed very much), and I have now other projects
I'm dedicated to. Still, I just happen to have some free time
currently, and I really wanted to give my greetings to old
fellow regulars
I have downloaded and started to read all sorts of ES3.1 related
documents. I still have a long way to go, but I sure feel
intrigued when I see your quoting the 'disciplined' word. IMHO,
discipline should normally relate to practices, not tools;
It probably was not the best choice of word, but nothing better sprang
to mind at the time.
I'll have a look to that 'strict' mode.
I will have to find the time to have a really good look at it myself
(that is, go through all the algorithms and see how normal cross-
browser code will be handled by it (and what could be done instead
where it cannot).
The exception sorting would be a very good thing to me, it's
actually quite fundamental when we adopt a try/catch programming
style.
Yes, if the language is going to be expected to throw more exceptions
(at lest in strict mode) then the ability to handle them becomes more
important. I don't mind the former if the try-catch system was up to
the job but as it is now there is every chance that the dangerous
habit of just suppressing errors rather than handling them becomes the
norm. Identifying exceptions that have been thrown is particularly
problematic and if more exceptions are were being thrown while trying
to examine characteristics of the first exceptions in order to
identify them then the catch blocks are going to get very complex.
I can only agree with that! The effort of producing a specification
leads to the effort of reading/discussing it, and enforces by the
programmers the feeling that things are evolving. That helps
staying alert.
I honestly rejoice about it. While a lot of good work had been
put into the ES4 specification, I was somehow a bit sad to see
that the quite unique javascript paradigm, a clever mix of
object and functional programming, remained underestimated,
unexplored.
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.
Java is a good thing; but "javascript!=java" means
much more than many originally thought.
Well, all I did was simply enjoy (and enjoy very much)
discussing and trying out patterns, not to mention bothering
you as much as I could
Receiving credit for this would be
unexpected, and inappropriate.
Was anyone else doing any more than playing around with the
possibilities because they found that entertaining?
I hope, however, that *you* will receive the credit you're
entitled to, for being the first to describe in depth javascript
closures and related patterns (ah, these Russian dolls...).
<snip>
In the end I suspect that the thing that will make the difference is
whether my ideas about how client-side code should be designed/
structured get more widely adopted. 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). 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.
Richard.
