On 27 Feb 2004 09:00:09 -0800, Saqib Ali <syed_saqib_ali@yahoo.com> wrote:
[color=blue]
> Michael Winter <M.Winter@blueyonder.co.invalid> wrote in message
> news:<opr30bnlap5vklcq@news-text.blueyonder.co.uk>...
>[color=green]
>> On Thu, 26 Feb 2004 20:22:20 -0500, Randy Webb <hikksnotathome@aol.com>
>> wrote:
>>[color=darkred]
>>> Michael Winter wrote:[/color]
>>
>> [snip]
>>[color=darkred]
>> >> That's because it *is* invalid HTML. Valid HTML documents need a
>> >> DOCTYPE declaration, a default character set (sometimes sent[/color][/color]
>
> <SNIP>
>
> Can you tell me what I need to do to make it valid?
> I copied your head and your doctype stuff into my code and
> the validator complained that all the attributes that I am using were
> invalid. It said that this is most commonly caused by using
> vendor-specific attributes without setting the document type
> appropriately. So what is the appropriate document type??[/color]
As I stated in my first post, you will be unable to use the Strict DTD as
you use the deprecated attributes, bgcolor and language. You either need
to use the Transitional DTD, or style sheets. The latter, in my opinion,
should be used by all new web sites: there is no need for presentational
HTML (unless special circumstances apply).
[snip]
[color=blue][color=green][color=darkred]
>>>> <meta http-equiv="Content-Style-Type" content="text/javascript">
>>>
>>> Is that a typo? Content-Style-Type of text/javascript?[/color]
>>
>> What? Smeg.
>>
>> Unfortunately, that's not a typo....[/color]
>
> Could you please post the correction??[/color]
The correct content type for CSS is text/css. The META element should read:
<meta http-equiv="Content-Style-Type" content="text/css">
I read through your document and compiled the following HTML errors and
script problems. I then made an equivalent page that will validate as HTML
Strict. You can view it at this address:
http://www.mlwinter.pwp.blueyonder.c...li/offset.html
It's not great. It would need work before it could be classed as
"production quality" (comments from other members are more than welcome),
but it is better.
If the example page you gave was for personal use, some of the comments
below might not apply, as long as you acknowledge their validity in
general use.
[color=blue]
> <SCRIPT language="JavaScript1.2">
> <!--[/color]
The language attribute is deprecated. You should use the type attribute:
<script type="text/javascript">
The practice of hiding scripts with SGML comment delimiters is obsolete.
Don't bother in future.
[color=blue]
> var IE = document.all?true:false;[/color]
This will *not* detect IE, it just infers that if the document.all
collection is supported, the browser is IE. As Opera also supports
document.all, it is clear what problems can be encountered with this
approach. Use feature detection, instead.
[color=blue]
> if (!IE) document.captureEvents(Event.MOUSEMOVE)
> document.releaseEvents(Event.MOUSEMOVE);
> document.onmousemove = getMousePos;[/color]
IE doesn't support document.releaseEvents, but you call it anyway.
Besides, I'm not sure how necessary it is for you to use captureEvents()
and releaseEvents() in Gecko browsers. Newer versions of Mozilla and
Netscape will call getMousePos() when the mousemove event is fired if that
last line is used by itself.
[color=blue]
> var mouseX = 0[/color]
Why is this variable global? It is only used in the getMousePos()
function. It should be local.
[color=blue]
> if (IE) // grab the x pos.s if browser is IE
> mouseX = event.clientX + document.body.scrollLeft;
> else // grab the x pos.s if browser is NS
> mouseX = e.pageX;[/color]
Another example of potentially bad guess work.
[color=blue]
> document.getElementById('MOUSE_XPOS').childNodes[0].data = mouseX;[/color]
You haven't checked for support of any of these methods or properties. As
earlier versions of IE have poor support for DOM components, that is a bad
idea.
[color=blue]
> function getLeftXCoord(element) {
> currElement = element;
> xOffSet = 0;[/color]
Both of these variables are needlessly global. currElement isn't
necessary, anyway.
[color=blue]
> document.getElementById('TRAVERSAL_TEXT').childNod es[0].data =
> '\tTag=' + currElement.tagName + ',\tOffset=' +
> currElement.offsetLeft + ',\tCummulative Offset=' + xOffSet + '\n';
> while (currElement.parentNode != null)[/color]
More assumed support. That assignment is also duplicated (bad algorithm).
Using \n alone to add a new line in a PRE element doesn't work in IE: it
requires \r. Using \r alone doesn't work in Netscape and Mozilla. Using
both (\r\n) adds a space in the latter two. As it happens, Opera supports
all three combinations properly.
In my page, I used Node.nodeName in place of Element.tagName so that the
#document node was shown.
[color=blue]
> </HEAD>
> <FORM name="myForm">
> <BODY>[/color]
If the BODY element is included, which is recommended, content mark-up
*must* appear within the start tag. You should also use the id attribute
in preference to name.
[color=blue]
> <table border=1 >[/color]
The use of table in this document is "element abuse": there is nothing
tabular about the data contained in it. DIVs would be more appropriate. I
kept the table in my version of the page as it shows the DOM node
traversal nicely.
[color=blue]
> <TD bgcolor="gray" name="TABLE_CELL" id="TABLE_CELL">[/color]
The bgcolor attribute is deprecated. Use the background-color style
property instead.
Table cells do not, and never have had as far as I know, a name attribute.
Only id is valid.
[color=blue]
> <TD bgcolor="pink">Mouse X Position: <PRE name="MOUSE_XPOS"
> id="MOUSE_XPOS">0</PRE>[/color]
Like table cells, PRE has never had a name attribute.
[color=blue]
> <input type="text" value="xxx" name="TABLE_TEXT" id="TABLE_TEXT"
> onMouseOver="javascript
:getElementById('TABLE_TEXT ').value=
> getLeftXCoord(document.getElementById('TABLE_CELL' ));"[/color]
There are no HTML problems here, but the script code is faulty:
1) Using "javascript
:" in an intrinsic event does not specify the language
in any browser other than IE. The defined way of specifying the default
language is shown in my template (the second META element).
2) getElementById() is not a global. You must fully specify it with
"document.". You must also test for support before using it.
3) You made life more difficult for yourself than it needed to be. That
intrinsic event could have been written:
function getRefById( id ) {
if( document.getElementById ) {
return document.getElementById( id );
} else if( document.all ) {
return document.all[ id ];
}
return null;
}
...
onmouseover="this.value=getLeftXCoord(getRefById(' TABLE_CELL'));"
[color=blue]
> </BODY>
> </FORM>[/color]
These should be interchanged.
Some of the problems above are repeated in places.
To address the original question, the offset calculations seem to behave
correctly in IE 6, Opera 7.23 and Mozilla 1.6. For some reason, Netscape
7.0 decides that the table body, cell and row are at an offset of -1 each,
so the result is off by 3 pixels.
Mike
--
Michael Winter
M.Winter@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
