darwinist said:
Then you are easily frightened.
Or maybe I am familiar with the harm that follows form over-confidence
that it is a common symptom of individuals who have got beyond the
initial stages of starting to learn javascript, but mistake the ability
to make things that broadly 'work' for knowing javascript.
This much is obvious from the rest of the post. Your
criticisms have some merit, but they would have taken
as long to write (even for a fast typist, which I assume
you are), as reading the majority of the application in
question. There is no need for you to read it, except
that your arguments would have better aim, and probably
would have been shorter as a result.
Elsewhere we have discussed the readability of source code. I looked at
your source code and the prospect of attempting to read it did not
appeal.
However, it is only really necessary to consider attempting to
understand a third party script is there is some prospect that it may be
useful in some way. Having verified that it did not satisfy basic
criteria for the stated task any additional attention directed towards
it would be wasted.
Those could be useful and aren't precluded or made overly
difficult by imposing a complex framework, like some html
windowing packages do. As I said it is to demonstrate all
you need to know to start making one yourself. A lot of
people who want to make web applications don't have the
encyclopedic knowledge of the specifications that you do,
and access to an encyclopedia isn't quite the same thing.
The knowledge and level of understanding someone should possess prior to
attempting the creation of a complex web application may be subject to
some debate, but not knowing how to position, move and size Element, and
nest an IFRAME within them, strikes me as not knowing enough. But it
would not be the absence of that specific knowledge that I would worry
about, rather the grasp of the bigger picture that could be expected to
come with acquiring that knowledge. You don't get from novice to someone
who should be allowed to work on web applications by being handled "all
you need to know" as pre-written code.
"Hello World" is only the first example, as it should be.
The basic functionality of organising things in separate
windows is not that demanding on a browser, and a lot of
basic web-applications could benefit from it.
If you look at the current situation in web development you see a very
large number of people attempting to make AJAX web sites, seemingly only
because they can (and particularly because others have created
frameworks for them that make it even easier). This is the power of
fashion and the AJAX buzzword.
There is going to be a bit of an anti-AJAX back-lash soon, as was
indicated by an article in the (UK) Financial Times earlier in the week
about the security vulnerabilities (various forms of script insertion)
introduced by AJAX (none really introduced by AJAX as they all existed
before, but certainly all exposed more often by a growth in people
writing public sites that use AJAX). That article essentially blamed web
developers for increasingly using a technology that they did not
understand well enough to cover the security aspects of, and framework
authors for shielding them from that understanding.
Which is not to say that AJAX applications should not be created, it is
an ideal technology for Intranet applications and special purpose web
applications. But in many (probably most) cases doing something because
you can is not a good reason for doing it. For a start it goes against
the KISS principle (and when you don't understand the technology you are
using it is difficult to justify labelling the result 'simple') as much
of what has recently been done with AJAX had previously, and more
simply, been done with server-side technology. And then there is the
impact upon reliability, where an AXAX e-commerce site I looked at
recently was so tied up in technology that its author did not actually
understand that the result did not even work with non-default
installations of IE 6. Costing the owners of the site (who presumably
paid for it in good faith) an indeterminate proportion of their
potential income, where the traditional server-based approach to
e-commerce would have allowed them to take money of all their potential
customers (and an AJAX with clean degradation design would have allowed
them to have their cake and eat it too).
Some web applications would benefit from an in-browser windowing system
(I am working on one myself at the moment), but using one because you
can is likely to directly result in issues.
I'm sure you could make a better one that is free and
even more lightweight and efficient, but where is it?
If someone is about to shoot themselves in the foot handing them a
bigger gun is not doing them a favour.
Do you know if they've fixed it in ie 7?
I don't know, but it is unlikely that they would all be fixed (IE 7 is
not a major re-write it is a series of bug fixes and tweaks and some of
those issues are so inherent in the architecture of IE that they would
take a major re-write to actually fix). But it doesn't' matter as IE 7
is only going to be available for XP and 2003 (and presumably
Microsoft's new OS) so it will take even longer for it to becomes
dominate than the couple of years it took IE 6 to outstrip IE 5.
Most of the content can be organised in separate documents
in iframes, which the browsers seem remarkably adept at
handling. The windowing is just for more versatile organisation.
That will not make a significant difference to the way IE slows down
when you accumulate thousands of objects in the system.
You may be surprised how much of a struggle it can be to a
novice javascript programmer.
Why, it is inevitable that I would have been a novice javascript
programmer myself at some point in the past?
Just the individual techniques required are
popular "how to" articles all over the web. Having
given liberal comments my attempt was to draw together a
set of practical how-tos. I can see as a connoisseur of
the language you are holding your nose up at it.
One of the consequences of having been a novice myself is that I have
some idea of what path leads from there to some sort of understanding of
the subject.
Indeed my standard should have been stated more explicitly.
Two main browsers =
But not sufficiently well in IE for actual applications.
as much of the desktop-share as any program written
for any specific operating system could hope to reach,
maybe more.
Maybe I should just declare my bias and write "runs best in firefox,
you broken-software using cretins", and put a link to download firefox
on the page for anyone in danger of these bugs affecting them. At
least it's free and will probably run on their operating system, if
they're allowed to install it.
Specifications are one half of what will work,
Specifications are what should work, and how it should work.
the other half is what has in fact been implemented
in enough popular browsers to rely on it in the wild.
That is the attitude that gets in the way of ever being able to write
cross-browser code.
Thanks for the tip.
Finish the sentence you are quoting.
<snip>
You don't se the logic in questioning "all you need to know" when
additional information suggests changes?
Richard.