[DHTML] Annoying Clock

[evermind65536]

1) CODE TITLE: Annoying Clock

2) AUTHOR NAME/NOTES: Szabolcs Peter (evermind65536) / See In Code

3) DESCRIPTION: Cursor Following Analog Clock (with Date)

4) URL TO CODE: None

or, ATTACHED BELOW (see #3 in guidelines below): [Removed]

Final cross-browser re-release of an old script i wrote back in 2004. Both positive and negative opinions are welcome, however i'm not gonna make any further development on this. I just like it this way.

[jscheuer1]

It certainly is annoying. Not at all cross browsers except if your page is in quirks mode. Only IE appears to move the clock around smoothly and in a 'timely' (pun intended) manner. Others are jerky and sluggish. Clever though.

[evermind65536]

For me it seems like running best in Opera. I guess it depends on many factors, like hardware, resource usage of other softwares etc. It is not all that great in efficiency i admit. Perhaps it uses too many elements. I'm just curious, in what and which versions of browsers it doesn't work? I guess it must be NS4.

If it runs on one more browsers / tabs at the same time, it of course gets jerky.

[jscheuer1]

I did have a lot of processes going on. But that is not unusual in todays modern computing environments. IE 7, as is often the case under Windows (XP Media sp3) anyway, seemed to handle the math like water off a duck's back. I did not test in Safari 3 Win. Opera 9.27 was the slowest here, with FF 2x not much better.

I don't believe NS4 could handle the script at all. It will not do document.all or document.getElementById under any circumstances.

The number of elements is probably not so much an issue (except that so many of them are moving) as the number of calculations per CPU cycle, and the fact that you are animating more than one thing at a time in various directions while still trying to hold it all together visually. Both Opera and FF had trouble keeping the hands in the clock body as it moved.

[evermind65536]

I don't believe NS4 could handle the script at all. It will not do document.all or document.getElementById under any circumstances.

Has NS4 detection and attempts to use appropriate mouse and scrolling detection for it, but has no layer creation for that version. I've just tested on it, it's completelly dead. Perhaps i should look after the proper HTML for NS4 but i guess not many uses such outdated browser these days.

The number of elements is probably not so much an issue (except that so many of them are moving) as the number of calculations per CPU cycle, and the fact that you are animating more than one thing at a time in various directions while still trying to hold it all together visually. Both Opera and FF had trouble keeping the hands in the clock body as it moved.

It is basically refreshing every elements per script cycle (positioning for the dial and hands, positioning and complete rewriting for the date layer). I do not use any parent layer for them. All element groups have their own offset settings to the two master positioning variables (centX and centY).

[jscheuer1]

If I were you, I'd be more inclined to convert to document.getElementById than to worry about supporting NS4. Even document.all is version 4. IE version 4. All 'version 5' browsers and later support document.getElementById. This includes all FF, Opera, Safari, Konquerer, iCab, etc. Once you do that, it will work on a valid page (one with a valid URL DOCTYPE) in virtually all browsers as well, as long as you specify units for all style dimensions and positions, and tighten up your tests for compatibility with window.innerHeight vs document.body/documentElement.clientHeight issues. Generally, instead of assuming that if a browser supports document.all it needs one way and if not needs the other, you should just ask the browsers if they support the actual method you are considering using, if not offer the other, and finally null or return if neither is supported.

What you were saying about not having a container might be a key issue in reducing the drifting apart of the elements when the CPU or the CPU/browser timing is constrained for some reason.

[evermind65536]

Upon what you've told, it's gonna look something like this (tested on the latest IE, FF, NS, OP - so far okay):

if(document.getElementById&&!document.all){
function moveFFNS(ev){
eX=document.body.scrollLeft+ev.clientX;
eY=document.body.scrollTop+ev.clientY;
}
document.onmousemove=moveFFNS;
}

if(document.getElementById&&document.all){
function moveIEOP(){
eX=document.body.scrollLeft+event.x;
eY=document.body.scrollTop+event.y;
}
document.onmousemove=moveIEOP;
}

Once you do that, it will work on a valid page (one with a valid URL DOCTYPE) in virtually all browsers as well, as long as you specify units for all style dimensions and positions, and tighten up your tests for compatibility with window.innerHeight vs document.body/documentElement.clientHeight issues.

Sorry but that's rather the job of who wants to insert the code into his or her own HTML.

What you were saying about not having a container might be a key issue in reducing the drifting apart of the elements when the CPU or the CPU/browser timing is constrained for some reason.

Sure, although i'm not gonna make a version with a container layer. Actually that's why i've put the code up on DD. I'm myself not making webpages anymore. If anyone feels like picking the code up, is encouraged to develop it for his or her own taste and skills. It's all noted in the code. Although i doubt it will ever get such a popularity, smartened up or not...

[djr33]

Sorry but that's rather the job of who wants to insert the code into his or her own HTML.

To some degree, but it is a good idea to create a page with the proper doctype etc, from which anyone can use the script on a proper page-- if it works on exceptions too, great, but it should be designed to work on a standard page. Certainly a script that doesn't work on a standard page is rather worthless-- because nonstandard comes in too many flavors to have any idea what to do with it.

[jscheuer1]

Well you did say:

Both positive and negative opinions are welcome, however i'm not gonna make any further development on this. I just like it this way.

So to each their own.

But then later I thought you started to say a few things that made it seem like you wanted information on how to upgrade it, at least somewhat. So, now I'm confused - nothing new.

I do know that:

if(document.getElementById&&!document.all){
function moveFFNS(ev){
eX=document.body.scrollLeft+ev.clientX;
eY=document.body.scrollTop+ev.clientY;
}
document.onmousemove=moveFFNS;
}

if(document.getElementById&&document.all){
function moveIEOP(){
eX=document.body.scrollLeft+event.x;
eY=document.body.scrollTop+event.y;
}
document.onmousemove=moveIEOP;
}

is bad coding because it makes assumptions about browsers that do one thing one way, that they will also doing another thing another way. This often works out, but there is no logic in it, and there are almost always exceptions

Something more appropriate (in general terms):

if(window.innerHeight){
use window.innerHeight here
}
else if (document.body.clientHeight){
use document.body.clientHeight here
}
else {
do something here to get out of trying to do this at all
}

But then, with a valid URL DTD, there is the issue of document.body vs. document.documentElement in browsers that cannot do window.innerHeight/Width.

That's pretty easy to work out as well. But, since I think you are saying that you aren't really interested, I'll just leave it at a general statement of principle for others reading this in the hope that they may not be misguided by your more scatter-shot approach to code branching.

[evermind65536]

Could you show a link to a literature about it? So far i haven't come accross a script that does browser detection exactly this way. Or could you show a script example?

Btw, i don't think i misguide anyone, i've clearly stated in the code that it is just not the best way of it, so we should just quit pretending that others weren't warned. Ty.