PDA

View Full Version : [DHTML] Annoying Clock



evermind65536
05-13-2008, 11:36 PM
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
05-14-2008, 04:30 AM
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
05-14-2008, 10:20 AM
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
05-14-2008, 11:50 AM
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
05-14-2008, 06:00 PM
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
05-14-2008, 06:59 PM
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
05-15-2008, 12:08 AM
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
05-15-2008, 12:32 AM
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
05-15-2008, 12:49 AM
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
05-15-2008, 02:04 PM
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.

jscheuer1
05-15-2008, 03:48 PM
I'm not pretending that you aren't aware of the issue, or that you didn't make mention of it in your code. But people will read these posts and perhaps never even look at the full script code, or if they do, may gloss over your warning. In either case, that is where someone might get misled.

Now, as to your question, it's not browser detection, it is known as feature or object detection. The philosophy behind it is that it really doesn't matter what browser someone is using as long as it supports the feature or object that your code uses. In practice this results in code that branches on the actual object being used at that point in the code, not on some arbitrary test that may or may not determine if a particular browser can do what comes next or not.

If you Google

object detection javascript

You will probably come upon a number of useful articles and examples.

evermind65536
05-15-2008, 04:28 PM
But people will read these posts and perhaps never even look at the full script code, or if they do, may gloss over your warning. In either case, that is where someone might get misled.

For the former it's out of subject then, for the latter, what you say is just an assumption. I should have then just written no comment in there.


Now, as to your question, it's not browser detection, it is known as feature or object detection. The philosophy behind it is that it really doesn't matter what browser someone is using as long as it supports the feature or object that your code uses. In practice this results in code that branches on the actual object being used at that point in the code, not on some arbitrary test that may or may not determine if a particular browser can do what comes next or not.

If you Google

object detection javascript

You will probably come upon a number of useful articles and examples.

Thank you.