* Horizontal layout; yes.
* 3 images show at once; no.
* Clicking buttons slides images in appropriate directions; not reliably.
* Cyclic path; no.
<html><head><title>Simple doc</title>
<style type="text/css">
li {display:inline;}
img {width:111;height:77}
CSS requires all non-zero dimension values to state the units in which
they are measured. IE may sometimes assume all values without units are
pixel values but other browsers are known to be stricter.
ul {position:relative;left:0}
</style>
<script type="text/jscript">
There is nothing in the following code that is unique to JScript(tm) and
so no good reason for using type=text/jscript" and having a number of
browsers regard the type of the script as unsupported.
function gn(dr){
ulElem=document.getElementById("slideShowCnt").style
Why is - ulElem - global when it could be local, and as it is a - style -
object why does its name imply that it is a reference to an element?
effect=setInterval(function(){ulElem.left=parseInt(ulElem.left||0)
Why is - effect - global when it could be local. This one highlights the
reason for never giving a variable more scope than it absolutely needs,
as being global means that a second call to the - gn - function will
re-assign the new value returned from - setInterval - to the one global
variable, meaning that any running - setInterval - will not be terminated
by a subsequent call to - clearInterval -, and the - setTimeout -
scheduled call to - clearInterval - from the preceding use of - gn - will
prematurely stop the setInterval action from the later call to - gn -. If
the - effect - variable were local then at least the inner function used
with setTimeout would be referring to its corresponding - effect -
variable, and cancelling the correct scheduling.
Not that this change would solve the issues with this design, but they
would stop it from being truly chaotic, as it is now.
Attempting a one millisecond interval is going to flog the browser for no
good reason. Human perception is such that the illusion of continuous
motion is achieved at about 20 frames pre second. Attempting to
re-position anything more often than about 30 frames per second is not
going make anything appear any smoother, and the odds are that the
combination of browser, CPU and OS could not deliver that anyway (with
the OS being a significant impediment).
Also, here the distance travelled is going to be variable. The system is
given a fixed (though imprecise) period in which to make as many one
pixel moves as it can. If the OS is ticking the clock at 10 millisecond
intervals it may get 100 1px steps in, and if at 56 milliseconds it may
manage 17, but both would assume zero time for the execution of the
positioning function and the browser's attempt to re-draw the results.
The actual time taken for these operations will depend on the CPU speed,
the speed of other system components and the loading on the computer
(background tasks and the like), at minimum.
setTimeout(function(){window.clearInterval(effect)},1000)
}
</script>
</head>
<body>
<ul id="slideShowCnt">
<li id="slide0"><img .../></li>
^
Why the pseudo xhtml mark-up in a document that appears to be targeted at
IE only (because of the CSS errors and text/jscript script type), given
that IE does not support xhtml?
<li id="slide1"><img .../></li>
<li id="slide2"><img .../></li>
<li id="slide3"><img .../></li>
<li id="slide4"><img .../></li>
<li id="slide5"><img .../></li>
</ul>
<button value="next" onclick="gn(1)" />Next</button>
This is where using pseudo xhtml shows itself to be the folly it is. If
this document ever were interpreted as xhtml it would not be well-formed
(which is required of all XML documents), and even if error corrected it
would not be functional, as the <button /> tag must be interpreted as a
content-less element, and so potentially have no manifestation on which a
user could click. Certainly clicking on the "Next" text outside the empty
button element would be ineffective.
If a document's viability is predicated upon its only ever being
interpreted as (possibly tag-soup) html (and never xhtml), either because
of the mark-up it contains or its scripted reliance upon the behaviour of
an HTML DOM as opposed to an XHTML DOM, then it doesn't really makes
sense to mark it up as xhtml (or include mark-up resembling xhtml).
<button value="prev" onclick="gn(0)" />Prev</button>
The official default type of a BUTTON element is SUBMIT. IE gets this
wrong and assumes it to be BUTTON, but other browsers will assume SUBMIT
and then interacting with these buttons would submit any form that
contained them. In the absence of a form, as here, there will be no
submission, but still it is advisable to always give a BUTTON element an
explicit TYPE attribute to avoid ambiguities in its default behaviour.
What happens here if the user clicks back and forth between buttons (or
repeatedly on the same button) within the second that it takes each
transition to run? At the moment the outcome is chaos, but even with
global variables changed to local variables the outcome is less than
desirable.
Richard.
