General question about javascript V HTML form

Discussion in 'Javascript' started by The Natural Philosopher, Sep 1, 2007.

  1. 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, Sep 1, 2007
    #1
    1. Advertising

  2. The Natural Philosopher

    RobG Guest

    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/scripts.html#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, Sep 2, 2007
    #2
    1. Advertising

  3. 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/scripts.html#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..
    >
    >
     
    The Natural Philosopher, Sep 2, 2007
    #3
  4. 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/scripts.html#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.
     
    The Natural Philosopher, Sep 2, 2007
    #4
  5. 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!;-)
     
    The Natural Philosopher, Sep 3, 2007
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Baldy
    Replies:
    1
    Views:
    388
    Lucas Tam
    Oct 17, 2004
  2. Replies:
    2
    Views:
    392
    Roedy Green
    Oct 24, 2007
  3. Pat Scott
    Replies:
    0
    Views:
    121
    Pat Scott
    May 24, 2004
  4. Replies:
    5
    Views:
    209
  5. Robin
    Replies:
    2
    Views:
    129
    richard
    Feb 23, 2011
Loading...

Share This Page