Re: Slightly ugly output

Discussion in 'HTML' started by rf, Aug 2, 2010.

  1. rf

    rf Guest

    "lrhorer" <> wrote in message
    news:...
    >
    > This isn't urgent, because the code works, but it is slightly
    > unpleasant looking, to me, anyway. I have a page with two radio
    > buttons side-by-side. One links to one page and the second to another.


    What do you mean? How to radio buttons "like to a page"?

    > By my understanding, a single form can only link to a specific page, so


    A form does not "link to a page". A form simply calls the server, asking for
    whatever is at a specific URL and passing a few values.

    > I created two different forms for the two buttons, each linking to a
    > different page, and put them in the same table. Evidently, this is
    > causing them to show up with one slightly higher than the other. Now I
    > could eliminate the problem by putting them in the same form, linking
    > to an intermediate cgi script, and then immediately forwarding to one
    > page or the other based upon which button was clicked. Is there a
    > cleaner, simpler way, though?


    Depends entirely on what you are wanting to happen.

    > <table><tr bgcolor="#00ff00">
    > <td Width=100 align="center">Room<td Width=40 align="center">Hour<td
    > Width=40 align="center">Min<td Width=40>Temp
    > <tr><FORM ACTION="/cgi-bin/commit.cgi">


    Invalid. A tr cannot directly contain a form element.

    >
    > [...Whole bunch of stuff deleted]
    >
    > </table>
    > <table>
    > <tr><td Width=110 align="center"><input type="submit" name="Submit"
    > value="Submit">
    > <input type="hidden" NAME="Action"
    > value="/usr/share/thermostat/weekday">
    > <input type="hidden" NAME="Therms" value="8">
    >
    > </form>


    Where is the beginning of this form?

    > <form ACTION="/cgi-bin/pupdate.cgi">
    > <td Width=110 align="center"><input type="submit" name="Abort"
    > value="Abort">
    > <input type="hidden" NAME="Therms" value="8">
    > <input type="hidden" NAME="Testing" value="Program">
    > </form></table>


    Invalid. A table cannot directly contain a form element, and where is the
    opening tag for that form element?

    > </body>
    >


    With forms within tables: the form must be entirely within a single cell of
    the table. It can not be spread across one two or more cells or rows, as you
    are doing.


    With such grossly invalid code it is entirely up to the browser how it
    looks, after the browser has error-corrected it that is.

    Take it over to the validator, fix the errors and see if the problem
    disappears.
    rf, Aug 2, 2010
    #1
    1. Advertising

  2. rf

    rf Guest

    "lrhorer" <> wrote in message
    news:...
    >>> This isn't urgent, because the code works, but it is slightly
    >>> unpleasant looking, to me, anyway. I have a page with two radio
    >>> buttons side-by-side. One links to one page and the second to
    >>> another.

    >>
    >> What do you mean? How to radio buttons "like to a page"?

    >
    > I said "link" not "like"


    And I made a typo. So sue me.

    >> With forms within tables: the form must be entirely within a single
    >> cell of the table. It can not be spread across one two or more cells
    >> or rows, as you are doing.

    >
    > That doesn't make much sense to me, at all.


    It's very simple. If you have a form *inside* a table then it must be
    entirely within one single <td>.

    If you wish a table to be inside a form then the entire table must be inside
    the form.

    <table><tr><td><form></form></td></tr></table> is valid.
    <form><table> ... </table></form> is valid.
    <table><form><tr> is not valid.

    > How, then, is one to pass
    > parameters from multiple rows of a table (one checkbox per row, for
    > example - see


    Put the entire table inside the form. That's the only valid way.

    > http://68.203.168.150/cgi-bin/pupdate.cgi?Therms=8&Program=Program Thermostat )
    > to another spreadsheet? With one form per tr, I would only be able to
    > pass 1 value to the profile.cgi script when the user clicked <Delete>.
    >
    > How would you implement the two pages? Using multiple divs? That would
    > make the scripts horribly more complex, especially for the pupdate.cgi
    > script.


    Why? You could name your Add submit buttons differently for each section and
    fork in your script accordingly.


    >> With such grossly invalid code it is entirely up to the browser how it
    >> looks, after the browser has error-corrected it that is.

    >
    > Grossly invalid or not, it looks just fine on both Firefox and IE,
    > other than this one tiny anomaly on the commit.cgi page.


    And it might continue to look just fine, until one of those browsers changes
    its error correction.

    On closer inspection (now that you have provided a URL) I see that you are
    nesting forms as well. You cannot nest forms. A form may not contain another
    form, and this time the browsers error correction *will* bite you. Such a
    construct is not specified so the browser can to whatever it feels like,
    such as closing the first form prematurely, totally ignoring the nested
    form. Add in the fact that you are spreading these forms invalidly through
    tables it's pot luck what will happen.

    As to why the submit and abort buttons are at different positions on the
    provile.cgi page, switch on borders on all elements (either via CSS, or
    using firebug) and you will note that those two buttons live in two cells
    within a table row.

    The second cell contains a form, which in turn contains the abort button.
    This form has a default bottom margin so visually the abort button sits at
    the top of the cell with some space below it. That is what sets the height
    of the table row.

    The first cell contains only a submit button, centered vertically within the
    row. Visually there is a submit button with space above and below it.

    Hence the different heights.
    rf, Aug 2, 2010
    #2
    1. Advertising

  3. rf

    Neredbojias Guest

    On 01 Aug 2010, lrhorer <> wrote:

    >>> This isn't urgent, because the code works, but it is
    >>> slightly
    >>> unpleasant looking, to me, anyway. I have a page with two radio
    >>> buttons side-by-side. One links to one page and the second to
    >>> another.

    >>
    >> What do you mean? How to radio buttons "like to a page"?

    >
    > I said "link" not "like" What I mean is, clicking on one
    > radio button
    > causes the web server to run cgi script #1 ( /cgi-bin/commit.cgi - as
    > you can see below), while clicking the other causes cgi script #2
    > (/cgi-bin/pupdate.cgi) to run. Unless I am somehow mistaken this
    > means the two actions must be specified by separate forms.
    >
    >>> By my understanding, a single form can only link to a specific
    >>> page, so

    >>
    >> A form does not "link to a page". A form simply calls the server,
    >> asking for whatever is at a specific URL and passing a few values.

    >
    > OK, it passes control back to the web server which in turn
    > serves up
    > another web page based on the output from the form. At the UI level,
    > that sounds like a "link", to me. OK, it's not an href. Sue me.
    >
    >>> I created two different forms for the two buttons, each linking to
    >>> a different page, and put them in the same table. Evidently, this
    >>> is causing them to show up with one slightly higher than the other.
    >>> Now I could eliminate the problem by putting them in the same
    >>> form, linking to an intermediate cgi script, and then immediately
    >>> forwarding to one
    >>> page or the other based upon which button was clicked. Is there a
    >>> cleaner, simpler way, though?

    >>
    >> Depends entirely on what you are wanting to happen.

    >
    > See
    >
    > http://68.203.168.150/cgi-bin/pupdate.cgi?Therms=8&Program=Program The
    > rmostat
    >
    > Note how the <Add> and <Delete> button appear level on the
    > same line
    > for each table? (In this case, they both call the same script, and
    > so are both part of the same form.) Now click on any one of the
    > <Add> buttons. In this page, although the <Submit> and <Abort>
    > buttons appear thematically to be the same as the <Add> and <Delete>
    > buttons on the former page, in fact they are quite different, because
    > each must call different cgi scripts while passing very different
    > variables. What I want to "happen" at the UI layer is for the
    > <Submit> and <Abort> buttons to be level with one another,
    > side-by-side. What I want to "happen" at the web server layer is for
    > the commit script to run if the user clicks on <Submit> and for the
    > previous web page to be re-loaded if the user clicks <Abort>.
    >
    >>> <table><tr bgcolor="#00ff00">
    >>> <td Width=100 align="center">Room<td Width=40
    >>> align="center">Hour<td Width=40 align="center">Min<td Width=40>Temp
    >>> <tr><FORM ACTION="/cgi-bin/commit.cgi">

    >>
    >> Invalid. A tr cannot directly contain a form element.

    >
    > OK, if I move it outside the tr, the two are still not level.
    > They
    > just switch positions vertically.
    >
    >>> [...Whole bunch of stuff deleted]
    >>>
    >>> </table>
    >>> <table>
    >>> <tr><td Width=110 align="center"><input type="submit" name="Submit"
    >>> value="Submit">
    >>> <input type="hidden" NAME="Action"
    >>> value="/usr/share/thermostat/weekday">
    >>> <input type="hidden" NAME="Therms" value="8">
    >>>
    >>> </form>

    >>
    >> Where is the beginning of this form?

    >
    > Right above. You pointed it out yourself.
    >
    >>> <form ACTION="/cgi-bin/pupdate.cgi">
    >>> <td Width=110 align="center"><input type="submit" name="Abort"
    >>> value="Abort">
    >>> <input type="hidden" NAME="Therms" value="8">
    >>> <input type="hidden" NAME="Testing" value="Program">
    >>> </form></table>

    >>
    >> Invalid. A table cannot directly contain a form element, and where
    >> is the opening tag for that form element?

    >
    > Just above. There are only two forms on this page. One which calls
    > the commit script and the other which calls the pupdate script
    >
    >>> </body>
    >>>

    >>
    >> With forms within tables: the form must be entirely within a single
    >> cell of the table. It can not be spread across one two or more cells
    >> or rows, as you are doing.

    >
    > That doesn't make much sense to me, at all. How, then, is
    > one to pass
    > parameters from multiple rows of a table (one checkbox per row, for
    > example - see
    > http://68.203.168.150/cgi-bin/pupdate.cgi?Therms=8&Program=Program The
    > rmostat ) to another spreadsheet? With one form per tr, I would only
    > be able to pass 1 value to the profile.cgi script when the user
    > clicked <Delete>.


    Think about it. What you have now (trimmed) is:

    <table><form></table><table></form></table>

    ....a classic example of improper nesting. You might try using 1 table
    for everything, -1 row and 2 cells, each cell containing a form. That
    is the simplest way I can see although not necessarily the most
    expeditious. You can also put (a) table(s) ~within~ a form if you find
    that abets your cause.

    > How would you implement the two pages? Using multiple divs? That
    > would make the scripts horribly more complex, especially for the
    > pupdate.cgi script.
    >
    >> With such grossly invalid code it is entirely up to the browser how
    >> it looks, after the browser has error-corrected it that is.

    >
    > Grossly invalid or not, it looks just fine on both Firefox
    > and IE,
    > other than this one tiny anomaly on the commit.cgi page.
    >
    >> Take it over to the validator, fix the errors and see if the problem
    >> disappears.

    >
    > How am I to fix it when I haven't a good notion of how to get
    > the same
    > results in some entirely different way? I don't do web pages for a
    > living. This is only my third web site, for a small one-off project,
    > the last one I did was four or five years ago, and it's unlikely I am
    > going to do any more in the near future, so vast amounts of research
    > are not practical. I can live with it as it is, if it comes to that,
    > especially since my housemates and I are the only ones who will ever
    > see or use it. (I have security disabled for the time being, but one
    > this goes live, it won't even be available on the internet.)


    Yes, but you'll always be wondering if your housemates are laughing
    behind your back...

    --
    Neredbojias

    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Aug 2, 2010
    #3
  4. rf

    rf Guest

    "lrhorer" <> wrote in message
    news:...
    >>>> With forms within tables: the form must be entirely within a single
    >>>> cell of the table. It can not be spread across one two or more cells
    >>>> or rows, as you are doing.
    >>>
    >>> That doesn't make much sense to me, at all.

    >>
    >> It's very simple. If you have a form *inside* a table then it must be
    >> entirely within one single <td>.

    >
    > I'm not looking to put a form inside a table. I am looking for the
    > form to span a table (actually, more than one table), with form
    > elements (checkboxes) assigned to elements of the table. The problem
    > is, putting two entities side-by-side requires the two entities both to
    > be part of the same table row.
    >
    >> If you wish a table to be inside a form then the entire table must be
    >> inside the form.

    >
    > That's not what you said.


    No, it's not what I said last time. That is because I was extending the
    information to cater for "the other way round". My prior statement was about
    forms inside tables. This new one is about tables inside forms, which is
    what you really want anyway.

    > You said the entire form must be inside a
    > single cell. On the pupdate.cgi sheet, placing all the tables wholly
    > within the extents of the form is no problem.


    OK. Problem solved.

    >> <table><tr><td><form></form></td></tr></table> is valid.
    >> <form><table> ... </table></form> is valid.
    >> <table><form><tr> is not valid.
    >>
    >>> How, then, is one to pass
    >>> parameters from multiple rows of a table (one checkbox per row, for
    >>> example - see

    >>
    >> Put the entire table inside the form. That's the only valid way.

    >
    > See above. The question, though, still remains. Assume I place
    > the
    > tables entirely within the extents of form #1, with one element of a
    > one line table being on the left hand side of the sheet (it can be half
    > the width of the form above it, if need be) at the bottom. Now how do
    > I place a second form on the same line with the table to the right of
    > the one line, narrow table?


    You don't. You have exactly one form, containing a big table, or a number of
    tables, or whatever you want. How you organise your input fields is up to
    you, but rememeber that they *all* can have different names, and your submit
    buttons can *all* have different names, and your server side processing can
    choose which input fields to consider depending on what submit button was
    activated.

    >>> to another spreadsheet? With one form per tr, I would only be able
    >>> to pass 1 value to the profile.cgi script when the user clicked
    >>> <Delete>.
    >>>
    >>> How would you implement the two pages? Using multiple divs? That
    >>> would make the scripts horribly more complex, especially for the
    >>> pupdate.cgi script.

    >>
    >> Why? You could name your Add submit buttons differently for each
    >> section and fork in your script accordingly.

    >
    > Unless I am missing something, a single form can only spawn to a
    > single
    > page. It can't spawn conditionally to one of two pages.


    I didn't say it could. Your form causes one single server side process to
    run. That server side process forks (with a big if statement, or maybe a
    case) depending on which submit button was activated. If the submit button
    named "delete_weekays" was successfull then you consider the checkboxes
    named "line_weekdays[]". Similarly for delete_weekends and line_weekends[].

    >> On closer inspection (now that you have provided a URL) I see that you
    >> are nesting forms as well.

    >
    > I am not nesting any forms. Every <form ...> is followed by a
    > </form>
    > prior to any other form being opened.


    Ah, yes, on looking at the source code you do exactly that.

    I was looking at the HTML tab on firebug, effectively the DOM *. Since your
    HTML is invalid it seems that firefox has decided that the forms *are*
    nested. It must have thrown out the first </form>, since it is in an invalid
    position (you cannot have a </form> between a </tr> and a </table>) and
    inserted a </form> just before the </body> to close the still open outer
    form.

    * the DOM contains a body containing a table (your heading) and a form.

    The form contains two tables. The first contains your input fields and their
    associated headings. The second table contains two cells, the ones I
    mentioned before as causing your alignment problem. The first cell contains
    the "submit" button. The second cell contains a form that contains the
    "abort" button. It is this form that is nested within the outer form

    As I said, with invalid code it is up to the browser to do whatever it
    wants. And, in this case, it's doing something entirely different that what
    you think you have specified. You may think you have not nested the forms.
    The browser thinks differently.

    This is also probably why you failed to spot the alignment error. From
    looking at the source code it is not even there. Only when the browser has
    error corrected your code to what it is happy with, and introduces that
    nested table, does your problem appear.


    Now, do you think it might be a good idea to take your code over to the
    validator and fix *all* the errors? :)
    rf, Aug 2, 2010
    #4
  5. lrhorer wrote:
    > Unless I am missing something, a single form can only spawn to a single
    > page. It can't spawn conditionally to one of two pages. If it can,
    > please let me know how. I can spawn an intermediate cgi script which
    > parses its input and spawns to one sheet or the other based on its
    > input (indeed, that is exactly what I do in the pupdate.cgi page), but
    > I have not come across anything which will allow me to create a single
    > form which spawns to file1 if one of its submit buttons is clicked and
    > to file 2 if another submit button within the very same form is
    > clicked. If there is a way, please tell me what it is.


    "only spawn to a single page" If you mean a form can only have one
    action, yes*. I showed you have to accomplish what you wish properly
    with a frontend script:

    <http://groups.google.com/group/alt.html/browse_frm/thread/a23726057b69fd5b/a0d99e25d077a933?hl=en&tvc=1&q=Slightly+ugly+output#a0d99e25d077a933>

    [*] Technically can be done with JavaScript, but very-very brittle and
    not at all recommended.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Aug 2, 2010
    #5
  6. On 02/08/10 08:28, lrhorer wrote:

    >> It's very simple. If you have a form *inside* a table then it must be
    >> entirely within one single <td>.

    >
    > I'm not looking to put a form inside a table. I am looking for the
    > form to span a table (actually, more than one table), with form
    > elements (checkboxes) assigned to elements of the table. The problem
    > is, putting two entities side-by-side requires the two entities both to
    > be part of the same table row.
    >
    >> If you wish a table to be inside a form then the entire table must be
    >> inside the form.

    >
    > That's not what you said. You said the entire form must be inside a
    > single cell. On the pupdate.cgi sheet, placing all the tables wholly
    > within the extents of the form is no problem.


    No, you are getting confused.

    There are two ways you can mix forms and tables. He has tried to explain
    to you these two possibilities:

    1) whole table inside a single form, eg:

    <form>
    <table>
    <!-- table content -->
    </table>
    </form>

    2) whole form inside a single td, eg:

    <table>
    <tr>
    <td>
    <form><!-- form content --></form>
    </td>
    <!-- more tds in row -->
    </tr>
    <!-- more trs in table -->
    </table>

    >>> How, then, is one to pass
    >>> parameters from multiple rows of a table (one checkbox per row, for
    >>> example - see

    >>
    >> Put the entire table inside the form. That's the only valid way.

    >
    > See above. The question, though, still remains. Assume I place the
    > tables entirely within the extents of form #1, with one element of a
    > one line table being on the left hand side of the sheet (it can be half
    > the width of the form above it, if need be) at the bottom. Now how do
    > I place a second form on the same line with the table to the right of
    > the one line, narrow table?


    You can't. If your whole table is enclosed within a form, then that is
    the only form that encloses the table. You can't have another form
    inside a td inside the table.

    >>> to another spreadsheet? With one form per tr, I would only be able
    >>> to pass 1 value to the profile.cgi script when the user clicked
    >>> <Delete>.
    >>>
    >>> How would you implement the two pages? Using multiple divs? That
    >>> would make the scripts horribly more complex, especially for the
    >>> pupdate.cgi script.

    >>
    >> Why? You could name your Add submit buttons differently for each
    >> section and fork in your script accordingly.

    >
    > Unless I am missing something, a single form can only spawn to a single
    > page. It can't spawn conditionally to one of two pages. If it can,
    > please let me know how. I can spawn an intermediate cgi script which
    > parses its input and spawns to one sheet or the other based on its
    > input (indeed, that is exactly what I do in the pupdate.cgi page), but
    > I have not come across anything which will allow me to create a single
    > form which spawns to file1 if one of its submit buttons is clicked and
    > to file 2 if another submit button within the very same form is
    > clicked. If there is a way, please tell me what it is.


    Originally you were talking about radio buttons, now you're talking
    about submit buttons.

    Your best solution may be to give each of the submit buttons a different
    value, and check on the value of submit in your server side script, then
    call one of the other two scripts accordingly.

    Failing that, you could (and I know some people won't like this) use
    each submit button to call a javascript function like this:

    <input type="submit" onclick="submit_to(this,'url-to-script1.cgi')">
    <input type="submit" onclick="submit_to(this,'url-to-script2.cgi')">

    The javascript function would look something like:

    <script type="text/javascript">
    function submit_to(btn,file)
    {
    btn.form.action=file;
    return true;
    }
    </script>

    Rgds

    Denis McMahon
    Denis McMahon, Aug 2, 2010
    #6
  7. Denis McMahon wrote:
    > Your best solution may be to give each of the submit buttons a different
    > value, and check on the value of submit in your server side script, then
    > call one of the other two scripts accordingly.
    >
    > Failing that, you could (and I know some people won't like this) use
    > each submit button to call a javascript function like this:
    >
    > <input type="submit" onclick="submit_to(this,'url-to-script1.cgi')">
    > <input type="submit" onclick="submit_to(this,'url-to-script2.cgi')">
    >
    > The javascript function would look something like:
    >
    > <script type="text/javascript">
    > function submit_to(btn,file)
    > {
    > btn.form.action=file;
    > return true;
    > }
    > </script>


    No, this is not your *best* solution! In fact is highly *not*
    recommended. Do not rely on client-side JavaScript to change an action
    of a form. It is neither dependable nor secure.

    The *best* solutions are either two separate forms or a single form with
    action to a receiving frontend script that processes content based upon
    the user input...

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Aug 2, 2010
    #7
  8. lrhorer wrote:

    Please do not trim attributes otherwise you cannot tell who said what!

    [attributes restored]
    > Denise Wrote:
    >> lrhorer wrote:


    <snip>

    >> No, you are getting confused.

    >
    > No, I'm not confused. I understand that a form can span one or more
    > tables or a form can be contained wholly within a single table.


    No the second condition precisely is "form can be contained wholly
    within a single table *cell*". A form cannot span cells when inside a table.

    <snip>

    > That's not what I asked. I understand the symmetry imposed by the
    > rules. I am asking how to do this:
    >
    > Drop-Down1 Drop-Down2 Drop-Down3 Drop-Down4 Drop-Down5
    > <Submit for Drops> <Submit for Abort>
    >
    > The<Submit for Drops> is the submit for the form containing all the
    > drops. The<Submit for Abort> is a submit for a second form containing
    > only hidden controls. That's it.


    Well if you have two forms you are going to have problems with giving
    the appearance second form's submit button *within* the rectangle of the
    first. If you use CSS positioning MSIE does not play nice with
    positioned form controls.

    >
    >> Originally you were talking about radio buttons, now you're talking
    >> about submit buttons.

    >
    > Here we go again. A submit button is a type of radio button. It's a
    > buttton one pushes to get a device (originally a radio) to do
    > something.


    No it is not. They are both form input controls but a submit button
    action *submits* the form, a radio button does not.

    >
    >> Your best solution may be to give each of the submit buttons a
    >> different value, and check on the value of submit in your server side
    >> script, then call one of the other two scripts accordingly.

    >
    > I already mentioned that. More than once, and the first time in the
    > very first paragraph of my very first post. Sixth sentence. It
    > requires an additional intermediate script.


    Yes it does.

    > If there is no elegant way
    > to handle it otherwise, then to be sure I can handle it that way.


    Yes, it is what I have been telling you is the definitive solution. So
    go do it and move on.


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Aug 2, 2010
    #8
  9. lrhorer wrote:

    Stop trimming attibutes.

    > Jonathan wrote:


    <snip>

    >> I showed you have to accomplish what you wish properly
    >> with a frontend script:

    >
    > You did? I don't see another response from you in the thread, unless
    > you mean the one where you say, "The best solutions are either two
    > separate forms or a single form with
    > action to a receiving frontend script that processes content based upon
    > the user input..."
    >


    Yes.

    >>

    > <http://groups.google.com/group/alt.html/browse_frm/thread/a23726057b69fd5b/a0d99e25d077a933?hl=en&tvc=1&q=Slightly+ugly+output#a0d99e25d077a933>
    >>

    > This link doesn't come up properly in my browser.
    >


    It just goes to the above post.

    >> [*] Technically can be done with JavaScript, but very-very brittle and
    >> not at all recommended.

    >
    > I'd rather do the intermediate script, in any case. It's a little
    > bulky and tedious, but easier to troubleshoot and, as you say, less
    > brittle.
    >


    Absolutely. It is really the only solution.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Aug 2, 2010
    #9
  10. On 02/08/10 18:23, lrhorer wrote:

    > Here we go again. A submit button is a type of radio button. It's a
    > buttton one pushes to get a device (originally a radio) to do
    > something.


    No, in html forms, a radio button is a specific sort of input element
    used to enforce a selection of one from many options. It does not
    trigger a form submit. It is created with code such as:

    <input type="radio" value="somevalue" name="groupname">

    where every radio button in group "groupname" is linked such that when
    any of the buttons is clicked, it is selected or checked, and all other
    buttons in the group are unchecked.

    A submit button is just a button. It is not, when talking about html
    forms, a radio button. Likewise, a radio button does not submit a form.

    As an aside, buttons existed before radios. The history of a "radio
    button" is that originally, on some types of radio, each "button" on a
    radio would select a different channel, and you could only listen to one
    channel at once. Hence, on a radio as used in the term "radio button"
    when referring to html, the button signifies an object where you can
    only select one from many options.

    You may perceive this to be a similar situation to selecting either
    submit or abort, but you are not actually using "radio buttons" in the
    sense in which the phrase is used in html, you are just using buttons.

    >> Your best solution may be to give each of the submit buttons a
    >> different value, and check on the value of submit in your server side
    >> script, then call one of the other two scripts accordingly.

    >
    > I already mentioned that. More than once, and the first time in the
    > very first paragraph of my very first post. Sixth sentence. It
    > requires an additional intermediate script. If there is no elegant way
    > to handle it otherwise, then to be sure I can handle it that way.


    Yes, ultimately I think you have three possible solutions:

    a) two submit buttons with different values, server side script, take
    action based on the value of the submit field

    b) two submit buttons with the abort button calling client side script
    to change the form's action property prior to the form submit

    c) if you don't need to pass any data from the form to the abort script,
    replace the abort button with a plain link to the abort script, and use
    css to make the submit button and abort link look the same.

    Regards

    Denis McMahon
    Denis McMahon, Aug 2, 2010
    #10
  11. On 02/08/10 18:52, Jonathan N. Little wrote:
    > lrhorer wrote:


    >> I already mentioned that. More than once, and the first time
    >> in the
    >> very first paragraph of my very first post. Sixth sentence. It
    >> requires an additional intermediate script.

    >
    > Yes it does.
    >
    >> If there is no elegant way
    >> to handle it otherwise, then to be sure I can handle it that way.

    >
    > Yes, it is what I have been telling you is the definitive solution. So
    > go do it and move on.


    It may not need an intermediate script.

    eg:

    <form method="whatever" action="processform.cgi">
    <input type="submit" value="Submit" name="submitBtn">
    <input type="submit" value="Abort" name="abortBtn">
    </form>

    at the start of processform.cgi, code along the lines of:

    if abortBtn is defined in the received form data and contains the value
    "Abort" then invoke the abort cgi handler and exit, otherwise continue
    with submit processing

    Rgds

    Denis McMahon
    Denis McMahon, Aug 2, 2010
    #11
  12. Denis McMahon wrote:
    > On 02/08/10 18:52, Jonathan N. Little wrote:
    >> lrhorer wrote:

    >
    >>> I already mentioned that. More than once, and the first time
    >>> in the
    >>> very first paragraph of my very first post. Sixth sentence. It
    >>> requires an additional intermediate script.

    >>
    >> Yes it does.
    >>
    >>> If there is no elegant way
    >>> to handle it otherwise, then to be sure I can handle it that way.

    >>
    >> Yes, it is what I have been telling you is the definitive solution. So
    >> go do it and move on.

    >
    > It may not need an intermediate script.
    >
    > eg:
    >
    > <form method="whatever" action="processform.cgi">
    > <input type="submit" value="Submit" name="submitBtn">
    > <input type="submit" value="Abort" name="abortBtn">
    > </form>
    >
    > at the start of processform.cgi, code along the lines of:
    >
    > if abortBtn is defined in the received form data and contains the value
    > "Abort" then invoke the abort cgi handler and exit, otherwise continue
    > with submit processing



    True, whether you creation one script that does all or a frontend to
    call the others does not matter. The important point is one action per
    form. The later method of a intermediate script just may be easiest to
    deploy if the other two script are already written rather than recreate
    the wheel. Have one script call another is no biggie.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Aug 2, 2010
    #12
  13. On 02/08/10 19:32, lrhorer wrote:
    >> As an aside, buttons existed before radios.

    >
    > Radio buttons did not exist before radios, though, nor did html.
    >
    >> The history of a "radio
    >> button" is that originally, on some types of radio, each "button" on a
    >> radio would select a different channel, and you could only listen to

    >
    > I am aware of the history of the term. Thus my point.
    >
    >> one channel at once. Hence, on a radio as used in the term "radio
    >> button" when referring to html, the button signifies an object where
    >> you can only select one from many options.

    >
    > Properly, it is a button which, when pressed by the user causes the
    > device (in this case a web page) to do something. It is a macroscopic
    > term that is agnostic of the underlying mechanics. If it looks like a
    > radio button and acts like a radio button, then it's a radio button.


    No. In the context of html forms, a radio button is a specific type of
    form input used for selecting one of many exclusive options.

    It is not "a button that you press to do something" for any generic
    value of "something", it is a button that specifically is used to select
    one option from a group of mutually exclusive options.

    A FORM SUBMIT BUTTON IS NOT A RADIO BUTTON!

    Rgds

    Denis McMahon
    Denis McMahon, Aug 2, 2010
    #13
  14. rf

    dorayme Guest

    In article <>,
    Sherm Pendley <> wrote:

    > Sort of - its name comes from the behavior of old-school radio preset
    > buttons, where pushing one of them would result in the others popping
    > out. Yes, I owned a car that had one of those... Get off my yard! :)


    There was nothing so definite as this mechanical choosing and it
    led to a more secure citizenry! The road rage one sees all around
    these days is due to drivers' feeling jumpy, not really knowing
    their place in the world. Yes, as a direct result of the prissy
    modern electronic controls.

    What will we have next, *gestures* to change stations, mumbling
    voice controls where the damn radio is so smart that *it* will
    pick up the insecurity of the driver and the feedback loops
    between radio and driver will result in disaster: fatal accidents
    with multiple deaths and injuries and family paybacks. The
    direction this world is taking hardly bears thinking about.

    Well, what is the point relevant here? What can web developers do
    about this? Just this: when making forms, *please* embed definite
    click sounds into the form so that choosing one thing makes a
    definite impression. For the deaf, make the buttons such that the
    clicked ones look definitely happy or alert and the others
    decidedly disappointed or asleep.

    --
    dorayme
    dorayme, Aug 3, 2010
    #14
  15. rf

    rf Guest

    "lrhorer" <> wrote in message
    news:...
    > rf wrote:
    >
    >> Now, do you think it might be a good idea to take your code over to
    >> the validator and fix *all* the errors? :)

    >
    > My engineering conscience got the better of me. I had a few minutes, so
    > I took a look at the errors. In fact, there were very few in the
    > script, but since the script looped numerous times, it generated lots
    > of apparent errors. I fixed almost all of them. The validator still
    > complains about a missing document type header, but since Apache barfs
    > if I put anything but "Content-type: text/html" as the first line of
    > the HTML section of the script, I really don't know of a way around it.


    Er, Content-type: is an HTTP header, not part of the HTML. I don't know why
    you need to be writing out your own headers, PHP for one does this for you.
    What "script" language are you using?

    But I'm talking about HTML validation. The HTML is the bit that comes after
    the blank line that terminates the headers. The bit that should be:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
    <html>...
    You should have a doctype in there, and a valid and full one, otherwise you
    will be running the browsers in quirks mode, meaning that IE for one will
    carefully reproduce all the bugs it has had back to version 5.5. It usually
    means all bets are off as far as cross browser consistent layout of your
    page is concerned.

    Have a google for quirks mode. No, not quirksmode.com the web site although
    that does make for a good read, look for quirks mode as against strict mode.


    I see that you now have your submit and abort buttons nicely aligned. Good
    work, and firebug now thinks you have exactly one form in there.

    Do you really live with a girl called Tiffany? Quaint :)
    rf, Aug 5, 2010
    #15
  16. rf

    dorayme Guest

    In article <>,
    Sherm Pendley <> wrote:

    > The !DOCTYPE belongs on the first line,
    > always, no exceptions.


    No exceptions? What about like:

    <?php $thisPage="black"; ?>
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">

    Does this cause harm?

    --
    dorayme
    dorayme, Aug 5, 2010
    #16
  17. rf

    rf Guest

    "dorayme" <> wrote in message
    news:...
    > In article <>,
    > Sherm Pendley <> wrote:
    >
    >> The !DOCTYPE belongs on the first line,
    >> always, no exceptions.

    >
    > No exceptions? What about like:
    >
    > <?php $thisPage="black"; ?>
    > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    > "http://www.w3.org/TR/html4/strict.dtd">
    >
    > Does this cause harm?


    Why would it? The doctype is still the first line *in the HTML*.
    rf, Aug 6, 2010
    #17
  18. rf

    rf Guest

    "lrhorer" <> wrote in message
    news:...
    > Sherm Pendley wrote:
    >
    >>> the !DOCTYPE declaration as the *SECOND* HTML line, after the Content
    >>> marker. Everything I read was telling me to place it as the first
    >>> line.

    >>
    >> What you've read is correct. The !DOCTYPE belongs on the first line,
    >> always, no exceptions.

    >
    > If I do that, then it won't run at all, always, no exceptions. If
    > the
    > HTTP header does not precede every other HTML line, then the web server
    > will barf on the file. If the first line of the file is not
    >
    > #! /bin/bash
    >
    > (or some other valid shell), then the file won't run at all.
    >
    >>>> carefully reproduce all the bugs it has had back to version 5.5. It
    >>>> usually means all bets are off as far as cross browser consistent
    >>>> layout of your page is concerned.
    >>>
    >>> Since I'm only using one browser, I really couldn't care much
    >>> less
    >>> about that, either.

    >>
    >> Okay, but *this group* does care. If you want bad advice that only
    >> works in one browser, you'll need to go somewhere else to find it.

    >
    > So instead, I should take advice like that above, which won't work
    > with
    > any browser? I didn't ask for advice setting up my headers. Indeed,
    > looking at your responses in this thread, I don't see any useful advice
    > whatsoever, only criticisms. Perhaps in the past you have offered real
    > advice, but one cannot judge that to be the case by your responses in
    > this thread. Presuming this forum is indeed intended to be devoted to
    > offering helpful advice, perhaps I am not the one who should seek
    > another forum?


    You are confused, and it's not Sherms fault.

    Read my other post again. We are not talkinging about HTTP headers here. We
    are talking about HTML.

    Doctype is part of the HTML, not the HTTP headers.

    Doctype must be the first line of the *HTML*.

    [HTTP headers]
    [one blank line]
    [HTTP]

    where [HTTP] looks similar to
    <!DOCTYPE ...
    <html>
    <head>
    ....
    rf, Aug 6, 2010
    #18
  19. rf

    rf Guest

    "rf" <> wrote in message
    news:SKH6o.2654$...
    >
    > "lrhorer" <> wrote in message
    > news:...
    >> Sherm Pendley wrote:
    >>
    >>>> the !DOCTYPE declaration as the *SECOND* HTML line, after the Content
    >>>> marker. Everything I read was telling me to place it as the first
    >>>> line.
    >>>
    >>> What you've read is correct. The !DOCTYPE belongs on the first line,
    >>> always, no exceptions.

    >>
    >> If I do that, then it won't run at all, always, no exceptions. If
    >> the
    >> HTTP header does not precede every other HTML line, then the web server
    >> will barf on the file. If the first line of the file is not
    >>
    >> #! /bin/bash
    >>
    >> (or some other valid shell), then the file won't run at all.
    >>
    >>>>> carefully reproduce all the bugs it has had back to version 5.5. It
    >>>>> usually means all bets are off as far as cross browser consistent
    >>>>> layout of your page is concerned.
    >>>>
    >>>> Since I'm only using one browser, I really couldn't care much
    >>>> less
    >>>> about that, either.
    >>>
    >>> Okay, but *this group* does care. If you want bad advice that only
    >>> works in one browser, you'll need to go somewhere else to find it.

    >>
    >> So instead, I should take advice like that above, which won't work
    >> with
    >> any browser? I didn't ask for advice setting up my headers. Indeed,
    >> looking at your responses in this thread, I don't see any useful advice
    >> whatsoever, only criticisms. Perhaps in the past you have offered real
    >> advice, but one cannot judge that to be the case by your responses in
    >> this thread. Presuming this forum is indeed intended to be devoted to
    >> offering helpful advice, perhaps I am not the one who should seek
    >> another forum?

    >
    > You are confused, and it's not Sherms fault.
    >
    > Read my other post again. We are not talkinging about HTTP headers here.
    > We are talking about HTML.
    >
    > Doctype is part of the HTML, not the HTTP headers.
    >
    > Doctype must be the first line of the *HTML*.



    Damn

    [HTTP headers]
    [one blank line]
    HTML:
    
    where [HTML] looks similar to
    <!DOCTYPE ...
    <html>
    <head>
    ....[color=blue]
    >
    > [/color]
    rf, Aug 6, 2010
    #19
  20. On 06/08/10 00:02, lrhorer wrote:
    > Sherm Pendley wrote:
    >
    >>> the !DOCTYPE declaration as the *SECOND* HTML line, after the Content
    >>> marker. Everything I read was telling me to place it as the first
    >>> line.

    >>
    >> What you've read is correct. The !DOCTYPE belongs on the first line,
    >> always, no exceptions.

    >
    > If I do that, then it won't run at all, always, no exceptions. If the
    > HTTP header does not precede every other HTML line, then the web server
    > will barf on the file. If the first line of the file is not
    >
    > #! /bin/bash
    >
    > (or some other valid shell), then the file won't run at all.


    Hold on ...

    The http header is not what we're referring to by an html line.

    What you're being told is that the <!DOCTYPE ....> declaration should
    come before the opening <html> tag.

    eg, the following parts should be output in the following sequence:

    <!DOCTYPE ....>
    <html>
    <head>
    <title>....</title>
    </head>
    <body>
    </body>
    </html>

    Note that I haven't included various optional <head> elements or any
    <body> elements, these of course can be inserted anywhere in that
    sequence that they're valid.

    There seems to be confusion about the html <head> and the http headers.

    The http headers are text strings that exist outside the scope of the
    html document (although meta elements in the html <head> element may use
    http-equiv to emulate them).

    The html <head> element is part of the document structure.

    When a server responds to a request from a browser, first it sends http
    headers, then it may send a document which, if it is html (as opposed to
    say text, pdf, an image, some streaming audio or video etc) will contain
    an <html>......</html> element, inside which is a head and a body
    element, inside which is the content etc etc etc.

    What you are being told is that you should send the "<!DOCTYPE.....>"
    html element *before* the opening <html> tag of the document.

    > So instead, I should take advice like that above, which won't work with
    > any browser? I didn't ask for advice setting up my headers. Indeed,
    > looking at your responses in this thread, I don't see any useful advice
    > whatsoever, only criticisms. Perhaps in the past you have offered real
    > advice, but one cannot judge that to be the case by your responses in
    > this thread. Presuming this forum is indeed intended to be devoted to
    > offering helpful advice, perhaps I am not the one who should seek
    > another forum?


    You're not being told to set a header, you're being told to send a
    <!DOCTYPE....> element as the first element of your html document, that
    is *before* the opening "<html>".

    so, find the line in your cgi script that sends the text "<html>" and,
    before that line, insert one to send "<!DOCTYPE.....>"

    If that breaks apache, your apache is nerfed, as I have done this
    successfully in cgi's I have written in perl, c, ada, fortran, lua,
    python, pascal and bash script.

    I got bored one day and decided to hello world in multiple languages,
    then I went on to form processing ... :)

    #!/bin/bash
    echo "Content-type: text/html";
    echo "";
    echo "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"
    \"http://www.w3.org/TR/html4/strict.dtd\">";
    echo "<html>";
    echo "<head>";
    echo "<title>First 'bash' cgi</title>";
    echo "</head>";
    echo "<body>";
    echo "<p>Hello, World.</p>";
    echo "</body>";
    echo "</html>";

    #!/usr/bin/perl
    print "Content-type: text/html\n\n";
    print "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"
    \"http://www.w3.org/TR/html4/strict.dtd\">\n";
    print "<html>\n";
    print "<head>\n";
    print "<title>First 'perl' cgi</title>\n";
    print "</head>\n";
    print "<body>\n";
    print "<p>Hello, World.</p>\n";
    print "</body>\n";
    print "</html>\n";

    etc etc etc

    Rgds

    Denis McMahon
    Denis McMahon, Aug 6, 2010
    #20
    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. =?Utf-8?B?Q2hhcmxpZSBEaXNvbg==?=

    Datagrid with fewer records than page size is ugly

    =?Utf-8?B?Q2hhcmxpZSBEaXNvbg==?=, Feb 29, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    439
    Alvin Bruney [MVP]
    Feb 29, 2004
  2. cr88192
    Replies:
    3
    Views:
    561
    cr88192
    Sep 7, 2005
  3. Esmail
    Replies:
    2
    Views:
    455
    Esmail
    Aug 13, 2009
  4. Denis McMahon

    Re: Slightly ugly output

    Denis McMahon, Aug 2, 2010, in forum: HTML
    Replies:
    2
    Views:
    411
    Denis McMahon
    Aug 2, 2010
  5. Andy

    Re: Slightly ugly output

    Andy, Aug 2, 2010, in forum: HTML
    Replies:
    11
    Views:
    740
    Neredbojias
    Aug 4, 2010
Loading...

Share This Page