David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
>David Mark wrote:
>>Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
>dhtml wrote:
>>rf wrote:
>>>"GArlington" wrote:
>>>On Oct 20, 10:45 am, MartinRineh...@gmail.com wrote:
>>>>I can load a dialog by loading an HTML page or by constructing the
>>>>dialog with JavaScript.
>>>>What should I be thinking about when I look at this choice?
>>[...]
>>Loading it in HTML does not necessitate an extra http req. Just put it
>>in the HTML. Requires less javascript to be downloaded.
>>...
>><body>
>><h1Heading </h1>
>><pyour content here </p>
>><div id="panel">
>> panel content here.
>></div>
>></body>
>>...
>You forgot to consider non-graphical user agents, including text browsers
>(which usually do not support CSS) and search engines.
True enough, you should always test pages in Lynx (or a simulator) for
just this reason (most pages will read like the gibberish that they
are.)
However, the quoted example would be fine in this regard, [...]
Isn't it obvious that it would not be fine? The panel is a dialog that
No.
Apparently not to you (yet).
>>>should only be displayed when necessary (requested by a user action).
Not necessarily. That may not be possible.
It is entirely possible if the dialog is not in the original HTML document.
Have you even read the thread?
Of course I have. There is exactly one post by the OP and the problem
is outlined in one vague sentence. Perhaps you had a different
interpretation?
There is nothing that needs interpretation here. Apparently you do need to
be guided from A to B to C (and D). So be it.
(A) The OP was asking himself (and the participants of this newsgroup) what
would be the best way to load (read: display) a dialog. The
alternatives that he saw were a) loading a HTML document ("page") or b)
constructing the dialog with JavaScript (sic!).
(B) "GArlington" said that if the OP loaded a HTML document another request
to the Web server was necessary. "rf" also emphasized that a dialog
that only worked with "JavaScript" would not be interoperable.
However, "dhtml" suggested that it would be possible to avoid another
request if the dialog was included in the original HTML document.
(C) I pointed out that there are commonly used user agents that do not
support CSS (among them search engines) and therefore would not hide
the dialog (which cannot be shown if it is to be *loaded*, in the
common sense of the word). That would mean that the solution suggested
by "dhtml" would therefore not be a viable one.
(D) You jump in and say that despite the facts I pointed out the example
that included the dialog in the original HTML would be fine in that
regard, which is obviously a contradiction. When confronted with
an explanation why it is not fine, you insist and state that it may
not be possible to prevent the *form* from being there although it
is obvious that this is another contradiction; it was established
before that it is entirely possible to display the form or whatever
only on demand.
>>>However, with this markup the "panel" will be displayed always (as a
paragraph) in e.g. Lynx.
Yes, Lynx does not support script. That's why the form will always be
there. So what?
So there would be a dialog (not a form) that does not belong there, which
The word "dialog" has no real meaning here. A form in a div?
A dialog is merely a part of an application that requests input from a user,
usually triggered *on their request* (by a menu item, button or another
widget). That derives from the original meaning of the word in the sense
that the computer talks to the user (e.g. asks a question) and vice-versa
("OK" or "Yes" would mean "yes" or "acknowledged"). A dialog clearly does
not need to be a form.
>would be a Bad Thing. Do you need to be guided from A to B to C now?
What sort of misplaced hubris is this? And perhaps you have never
seen a Web page with a form at the bottom. [...]
Apparently you are unable to place proper meaning on the word *d*i*a*l*o*g*
in a GUI. A sad thing for sure, and a reason for worries if you would
develop such applications, but your problem alone.
Score adjusted
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
