Re: Clear all optgroups and options from a select list

Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:
<snip>
The example you gave was an example that required each
optgroup element to have and ID, that would be the
wrong thing to do.
<snip>

So you did, sorry. Weren't we discussing the clarity/readability of
javascript source code recently?

<snip>
For example:
http://darwinist.googlepages.com/htmldesktop.html

Feel free to criticise

You have never actually said what this thing is supposed to
be for.

It's to demonstrate all you need to know to start making
your own web-based desktop system, or any subset thereof
(a windowed-based application, for example).

Now there is a frightening notion.

Then you are easily frightened.

I didn't look at your actual code too
much,

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.

I just verified that it did have the serious memory leak I was
expecting on IE, did not address the select element issue, and that you
could not drag one window over the contents of another because the mouse
co-ordinates were not available in the containing frame (that is, it
failed on the three primary issues of an in browser 'windowing' system
in IE). I suspect that much else that would be useful in any actual
application would also be missing, such as an ability for code executing
in a 'window' to respond to window dragging, re-sizing, closing and
focusing (moving to the front) actions.

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.

It's far from perfect but it includes all
basic functionality required, plus an "immediate"
box, and a manual.

It looks like it is indented to be the bases for an
in-browser windowing system for web-applications. It
doesn't look capable enough for any actual example of
such,

Under Help->Examples there are several working examples
for making windows, making objects draggable, a hello
world program, etc.

There is quite a gap between 'hello world' and a web application
multi-facetted enough to warrant a windowing GUI.

"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.

I'm sure you could make a better one that is free and even more
lightweight and efficient, but where is it?

Also the windowing system itself works, as does the
desktop.

but I suppose could be extended for specific
applications. However, as it is only really suited
for Mozilla/Gecko browsers as it stands

There isn't any browser-specific code, and although it's
not coded to an apparently well-known ie bug,

At least two well known IE bugs, but the number doesn't matter as any
one is sufficient to make the result viable for use on Windows IE only
Intranets, or multi-browser Intranets that include IE (i.e. the actual
market) for as long as your "I'm not particularly interested in coding
to the bugs of a product whose manufacturers don't even pretend it's
good anymore" stands.

Do you know if they've fixed it in ie 7?

it's fairly lightweight and quite
responsive in either major browser.

Maybe as it stands, but an actual application would be expected to have
something going on in those windows, which is what will slow the total
down.

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.

(Incidentally "either major browser" sounds like the 'both browsers'
attitude prevalent at the end of the last century.)

You're right, I'm not sure what the opera problem is but I think it's
an opera bug.

I don't see it being of much practical benefit in
a world where IE support is normally expected (and
sometimes sufficient).

It's meant as a free codebase. I've seen nothing really
that does all desktop-environment stuff in a short, free,
clear fashion. Most is heavy or proprietary, or both, and
most try to reinvent the wheel.

There is the dilemma; if you attempt to anticipate and provide all that
an application may need the result will be 'heavy', and much of what is
included will be unnecessary in any real application, but so long as it
is omitted all you have is a demonstration that it is possible to drag
and re-size IFRAMEs in a container of some sort on a particular set of
browsers.

You may be surprised how much of a struggle it can be to a novice
javascript programmer. 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.

or contribute.

You don't appear to be someone who takes advice, so
anything approaching collaboration is out of the question.

I appreciate your advice, even if you don't like what I do
with it. I happen to consider that what "works" is very
important.

My long experience of people declaring that something "works" or
"doesn't work" on this group has diminished the significance of the
word. So many things "work", by some criteria or another, that 'works'
is barely the starting point for a choice of implementation strategies.

Indeed my standard should have been stated more explicitly. Two main
browsers = as much of the desktop-share as any program written for any
specific operating system could hope to reach, maybe more.

Much of the time people are declaring things to 'work' only because they
have not tested them vigorously/seriously. Indeed you don't seem to have
tried stressing your code much, as the two megabyte memory leak in IE
per window instance should have become evident once you had opened and
closed 100 windows or so.

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.

Javsacript specs are what browsers should implement, but
actual browser support is what programmers need to worry
about.

The two are far too interrelated for the specifications to be dismissed
in favour of studying implementations (assuming you had access to, and
time to study, all browser implications). As far as the javascript
specification is concerned the implementations that assert that they
comply with ECMA 262 actually have very few deviations from the
specification (and mostly insignificant ones) so knowing how a
javascript engine should be expected to behave is a very good guide to
99%+ of the actual behaviour of implementations, including the ones that
are unavailable for actual testing.

Specifications are one half of what will work, the other half is what
has in fact been implemented in enough popular browsers to rely on it
in the wild.

It seems that moving windows around by reference rather
than ID would be a speed improvement and probably slightly
less code,

As in general whenever you can pass, access or store a string value you
can also pass, access or store an object reference the use of string
references just adds a layer of needless complexity and a runtime
overhead.

Thanks for the tip.

so you can rest-assured my application will reflect this
when I next have a play with it.

OK, but doesn't that make you suspect "all you need to know to ..."

Finish the sentence you are quoting.

I don't respond to authority though. Never have, never will

Not even to listen?

I'll listen to anyone, you don't have to pretend you're the arbiter of
correct javascript.

(unless you're paying me).

In the event of needing more javascript programmers I would be looking
for someone with more practical experience (though it would not be me
paying anyway, just interviewing).

Oh I just meant I'll take orders for money (within reason), but I've
got too many jobs right now, in order to get as much of that experience
you mention, as possible.

As you can probably tell I'm not a js programmer anyway, it's just one
of the many languages you have to use when dealing with php.

Richard.

.

Relevant Pages

  • Re: Windows Control im Web Form
    ... Na ja wer der Sandbox, die JavaScript und anderes sicher machen soll, nicht ... das nun angeblich die meisten Browser ... >>>Ich denke damit ist kein Einsatz von Windows Forms in Internet Seiten ...
    (microsoft.public.de.german.entwickler.dotnet.asp)
  • Re: XP Service Pack 3
    ... IE7 is not a browser update. ... the versions on Windows Vista and also on Windows XP SP2. ... > Internet Explorer is already outdated, ...
    (microsoft.public.windowsxp.general)
  • Re: BROWSTAT: ...Could not connect to registry, error = 53 (New question)
    ... Unable to determine build of browser master: ... NetBT setting, is not consistently effective. ... Microsoft Windows Network/Kingdom/? ... Now file sharing Works! ...
    (microsoft.public.windowsxp.network_web)
  • Re: Is a Firewall Necessary with Dial-Up?
    ... Windows Scripting Host, too. ... If vbs worms have no operating system installed in Windows, ... It's like giving webpage operators ... I handle this problem by having one browser ...
    (comp.security.firewalls)
  • Re: Is a Firewall Necessary with Dial-Up?
    ... Windows Scripting Host, too. ... If vbs worms have no operating system installed in Windows, ... It's like giving webpage operators ... I handle this problem by having one browser ...
    (comp.security.firewalls)