«

Ok, I have another form to write, and one of its features will be pop up
or drop down select-from-list stuff.

Could be done with javascript, could be done with <SELECT>
<OPTION> etc etc..

It will have to have an onselect() anyway, but apart from a better
control of appearance, what other pros and cons are there?

Coding it up looks a shade simpler in HTML rather than script, but thats
all I can see...

The Natural Philosopher wrote:
> Ok, I have another form to write, and one of its features will be pop up
> or drop down select-from-list stuff.
>
> Could be done with javascript, could be done with <SELECT>
> <OPTION> etc etc..
>
> It will have to have an onselect() anyway,

Onselect is not a vaild attribute for a select element, it is for input
and textarea elements when some text in them is selected:

<URL: http://www.w3.org/TR/html4/interact/...#adef-onselect >


> but apart from a better
> control of appearance, what other pros and cons are there?
>
> Coding it up looks a shade simpler in HTML rather than script, but thats
> all I can see...

Using HTML ensures it will work in a greater range of browsers and those
with script support missing or turned off, though you may wish to
augment it with script to provide a better UI for those that have it
available and turned on.


--
Rob
"We shall not cease from exploration, and the end of all our
exploring will be to arrive where we started and know the
place for the first time." -- T. S. Eliot

RobG wrote:
> The Natural Philosopher wrote:
>> Ok, I have another form to write, and one of its features will be pop
>> up or drop down select-from-list stuff.
>>
>> Could be done with javascript, could be done with <SELECT>
>> <OPTION> etc etc..
>>
>> It will have to have an onselect() anyway,
>
> Onselect is not a vaild attribute for a select element, it is for input
> and textarea elements when some text in them is selected:
>
sorry. Onchange()

> <URL: http://www.w3.org/TR/html4/interact/...#adef-onselect >
>
>
>> but apart from a better control of appearance, what other pros and
>> cons are there?
>>
>> Coding it up looks a shade simpler in HTML rather than script, but
>> thats all I can see...
>
> Using HTML ensures it will work in a greater range of browsers and those
> with script support missing or turned off, though you may wish to
> augment it with script to provide a better UI for those that have it
> available and turned on.

Mm. I can specify what browsers - as long as IE6/firefox/safari/opera
work, thats ok..

I was more thinking of speed issues..
>
>

Randy Webb wrote:
> The Natural Philosopher said the following on 9/1/2007 10:08 PM:
>> RobG wrote:
>>> The Natural Philosopher wrote:
>>>> Ok, I have another form to write, and one of its features will be
>>>> pop up or drop down select-from-list stuff.
>>>>
>>>> Could be done with javascript, could be done with <SELECT>
>>>> <OPTION> etc etc..
>>>>
>>>> It will have to have an onselect() anyway,
>>>
>>> Onselect is not a vaild attribute for a select element, it is for
>>> input and textarea elements when some text in them is selected:
>>>
>> sorry. Onchange()
>>
>>> <URL: http://www.w3.org/TR/html4/interact/...#adef-onselect >
>>>
>>>
>>>> but apart from a better control of appearance, what other pros and
>>>> cons are there?
>>>>
>>>> Coding it up looks a shade simpler in HTML rather than script, but
>>>> thats all I can see...
>>>
>>> Using HTML ensures it will work in a greater range of browsers and
>>> those with script support missing or turned off, though you may wish
>>> to augment it with script to provide a better UI for those that have
>>> it available and turned on.
>>
>> Mm. I can specify what browsers - as long as IE6/firefox/safari/opera
>> work, thats ok..
>
> IE6? Hmmmm And what if scripting is disabled? The question isn't
> "what browsers will it work in?", a better question is "where will it
> potentially break?"

The user base will be small, relatively trusted, and known to us.
So not a huge deal to say 'use this or that and turn this or that on'

But I take your point.


>
>> I was more thinking of speed issues..
>
> Speed of coding, display, maintenance, selection, or ...... ?
>
Display.

I suppose the question boils down to me having to make a style decision
for the site: Now MOST of it will run across an internal network, with
justa few staff using it, although I will need to access it remotely to
support it..but one or two pages will be used by subcontractors etc, to
upload and download specific items.

The decision is really the whole look and feel of the site - whether to
make it basically 'form plus as little script as possible, just where
context sensitive menus are required' or 'javascript, with as little
naked FORM stuff as possible,in order to get a uniform look and feel
across it'.

Maintenance is not likely to be a deal different either way: If I need
to use context sensitive stuff, I have to have a similar amount of
php.mysql HTML and javascript really. I am equally green at HTML as php
as javascript. So is merely a question of which manual I open...

You have raised one possibly pertinent issue, compatibility.

The other issues so far are pretty indecisive for me at this point.
I guess I want a good reason to go one way or the other.

Randy Webb wrote:
> The Natural Philosopher said the following on 9/2/2007 6:05 AM:
>> Randy Webb wrote:
>>> The Natural Philosopher said the following on 9/1/2007 10:08 PM:
>
> <snip>
>
>>>> I was more thinking of speed issues..
>>>
>>> Speed of coding, display, maintenance, selection, or ...... ?
>>>
>> Display.
>>
>> I suppose the question boils down to me having to make a style
>> decision for the site: Now MOST of it will run across an internal
>> network, with justa few staff using it, although I will need to access
>> it remotely to support it..but one or two pages will be used by
>> subcontractors etc, to upload and download specific items.
>
> If you have such a limited client base then I find it ironic that you
> would list IE/Firefox/Opera/Safari as the target browsers. Reeks of the
> "Oh, its an intranet" defense.
>

well the majority of users will be IE6, because they have PC's.

A few outside users will use whatever they have. Mainly IE6 on PC's an
safari on macs.

Opera is there because its one have for test purposes.

>> The decision is really the whole look and feel of the site - whether
>> to make it basically 'form plus as little script as possible, just
>> where context sensitive menus are required' or 'javascript, with as
>> little naked FORM stuff as possible,in order to get a uniform look and
>> feel across it'.
>
> Not that "pixel perfect" mentality is it? People that use different
> browsers expect the same page to look/act differently because it is a
> different browser.
>
They may: I try not to. It doesn't take a huge amount of work to tie the
thing down to work reliably and predictably in all cases. Ive found
using pixel sizes, and specifying the correct font family families seems
to make it fairy bullet proof. What I want to avoid is gross
differences..stuff that bearely wors at all in a given browser.

I had a really ODD bug yesterday. Still not sure what caused it.

I had a couple of onclick() statements calling javascript routines of
VERY similar names..just the final few characters of the function name
were different. Safari refused to work on ONE routine. Until I changed
the routine name. Firefox was totally happy and reported no errors..


>> Maintenance is not likely to be a deal different either way: If I need
>> to use context sensitive stuff, I have to have a similar amount of
>> php.mysql HTML and javascript really. I am equally green at HTML as
>> php as javascript. So is merely a question of which manual I open...
>
> The PHP manual is definitely easier to navigate than a JS manual. And,
> writing PHP for a wider audience of browsers is a lot simpler.
>

MM. Thats really where I got to as well. I have decided that the
internal stuff can be a bit clunkier and use as much native HTML as
possible whereas when I get to the customer facing stuff I'll spend more
time on it to tune it for super appearance.

Right now implementation speed is more an issue, so i've gone for a more
HTML based approach, just adding in script to make it a little more
obvious as to what is happening..

>> You have raised one possibly pertinent issue, compatibility.
>>
>> The other issues so far are pretty indecisive for me at this point.
>> I guess I want a good reason to go one way or the other.
>
> Where do you want the bulk of your processing happening? On the server
> (along with server load) or on the client? If it is an intranet then you
> can put the processing on the client and free up the server pretty
> reliably if you control the client environment.
>

Mmm. Server probably. Although I have the javsacript manual and not the
php one,it already seems to me that the php is less impenetrable. And
less 'class based'. Coming from a strict C background that makes it a
bit faster for me to code. And at least, with php, there IS only one
interpreter that I have to code for...the one installed in the system!