My said:
john_woo said:
The language attribute isn't valid,
The LANGUAGE attribute is valid HTML. It is a deprecated attribute in
HTML 4 and as such cannon be used with the 'strict' DTD and result in a
valid HTML document. It may be used with the 'transitional' DTD, but
because the TYPE attribute is required in all valid HTML documents the
LANGUAGE attribute is redundant even with the transitional DTD (Except
where it is used to specify a language version, which is almost always a
very bad idea).
it was only ever for IE anyway.
Many browsers recognise and 'use' a language attribute. Some will even
change their behaviour based upon it (particularly with
LANGUAGE="JavaScript1.2"), but that is almost always undesirable (as
some will not so the result is likely be to inconsistent script
interpretation, which would be an avoidable additional headache).
The official attribute is type, and it takes
a mime type:
<script type="text/javascript">
The attribute required in valid HTML is TYPE, and providing a TYPE
attribute renders the LANGUAGE attribute redundant. The value for the
TYPE attribute should be "text/javascript" at the moment for reasons of
expedience. That value has officially declared "obsolete" in 2006, but
none of the 'official' alternatives are sufficiently widely recognised
yet for their use to anything but problematic.
This should take an event as an argument,
Design wise it probably should, but this function is not the event
handler, it is just a function called by the event handler, so there is
no implicit event argument.
if you want it to work on anything but IE.
The absence of an event parameter is not the limiting factor here; it is
the explicit use of - window.event -.
Nobody else has the window.event object except IE.
If you don't count Opera, Safari, Konqueror, NetFront, IceBrowser, etc.
Generally, even browsers that do pass an event object when they call the
even handling function also provide a global 'event' property to refer
to the (same) event. That is simply done for compatibility with IE, and
the issue comes mostly with browsers from the Netscape/Mozilla/Firefox
family which are virtually the only ones that do not provide the global
'even' as an alternative to an argument to the function call.
function f2(e) {
if (window.event) {
e = window.event;
}
As the majority of browser do pass an event object as an argument it
should be more efficient to test that and only go to the -
window.event - alternative if it is not found/passed. (The scope chain
resolution of the - e - parameter should be faster than the resolution
of the property accessor - window.event - even on IE browsers).
// rest of the function
}
That should be:
onmousemove="function2(event);"
So that it will pass the mouseEvent along to the funciton
you're calling.
It probably should, but the reason for using the Identifier 'event' in
the value of an intrinsic even attribute should probably be explained.
It is because when a browser processes the value of an intrinsic event
attribute it uses the character sequence in that value of the body code
for a function it creates to be called when the event happens. This is
the equivalent of a programmer defining their own function and assigning
it to the intrinsic event property of the DOM element. On IE that would
be the equivalent of:-
divElementReference.onmousemove = function(){
function2(event);
};
- on most over browsers (and particularly Mozilla/Firefox/Gecko
browsers) the function created by the browser has a formal parameter
with the name 'event' (to receive the passed event object). Thus on
those browsers the equivalent manual code would be:-
divElementReference.onmousemove = function(event){
function2(event);
};
So when the body of the function is executed on a
Mozilla/Frirefox/Gecko-style browser the resolution of the Identifier
'event' ends with the formal parameter and results it the value of event
object passed as an argument. On IE browsers, where no such parameter
exists, the resolution of the Identifier carries on up the scope chain
until it gets to the global object (which is also the window object) and
as the global/window object has an 'event' property (- window.event -)
the resulting value is the event object referred to by that property.
The result is that in intrinsic event attribute values the easiest way
of normalising the event object between the Netscape-style and the
IE-style is simply to employ the 'event' Identifier. Unfortunately the
same is never true in programmer defined functions assigned to intrinsic
event properties.
Well, I can give you some mouse position code that works
like a charm,
Charms don't work. If we lived in a world where charms and mystical
incantations worked the majority of us would be magicians not
programmers.
can't be of much assistance on the width thing.
function getMousePosition(e) {
var x,y;
if (window.event){
x = window.event.clientX
y = window.event.clientY
x += document.body.scrollLeft;
y += document.body.scrollTop;
IE (6+) browsers (and imitators) can work in "Quirks" (or "BackCompat")
mode and in "Standards" (or "CSS1Compat") mode. The correct scroll
offset is read from the body element in "Quirks" mode and the HTML
element (documentElement) in "Standards" mode. The mode is determined
from the DOCTYPE declaration used (or by its absence).
} else {
x = e.pageX;
y = e.pageY;
<snip>
There is a discrepancy between - pageX/Y - and your IE values consisting
of the default border on the 'root' element (clientTop/Left). That
discrepancy is 2 pixels on a default windows installation, but the
border value is user modifiable so should be dynamically read. It is
normal to adjust IE mouse positions by these values in order to give a
coordinate system that is consistent across browsers.
Richard.
