General question about javascript V HTML form

  • Thread starter The Natural Philosopher
  • Start date
T

The Natural Philosopher

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

RobG

The said:
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:

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

The Natural Philosopher

RobG said:
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()
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..
 
T

The Natural Philosopher

Randy said:
The Natural Philosopher said the following on 9/1/2007 10:08 PM:

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.

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

The Natural Philosopher

Randy said:
The Natural Philosopher said the following on 9/2/2007 6:05 AM:

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

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..
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!;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top