Slightly ugly output
lrhorer
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.
By my understanding, a single form can only link to a specific page, so
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?
<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">
[...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><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>
</body>
rf
"lrhorer" <lrh...@satx.rr.com> wrote in message
news:fqKdnVobpfSUbMjR...@giganews.com...
>
> 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.
Denis McMahon
> 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.
> By my understanding, a single form can only link to a specific page, so
> 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?
Not sure why you're using radio buttons for this. It sounds like
something you'd normally do with plain links, if there's no other form
data involved. Why not:
<p style="text-align:center">
<a href="handler1" class="btnlink">bing</a>
<a href="handler2" class="btnlink">frog</a>
</p>
using css to make the "btnlink" class look and behave like a button when
clicked etc.
.btnlink {
border: medium outset black;
display: inline-block;
text-decoration:none;
background-color:#dddddd;
padding: 2px 5px;
color: black;
}
.btnlink:active {border: medium inset black;}
If one button is a submit for a form, and the other has to call a
different page, try (with the same css):
<p style="text-align:center">
<span class="btnlink"
onclick="document.getElementById('form_id').submit()">bing</span>
<a href="handler2" class="btnlink">frog</a>
</p>
This also means you can put the "submit" button outside the form.
Doubtless someone will be along shortly to tell me my css, html or
javascript is horribly broken, but whatever.
Rgds
Denis McMahon
lrhorer
>> 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+Thermostat
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+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.
> 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.)
lrhorer
>> cleaner, simpler way, though?
> Not sure why you're using radio buttons for this. It sounds like
> something you'd normally do with plain links, if there's no other form
> data involved. Why not:
There is. A fair bit, in fact. Not so much a GET won't work, but a
dozen variables or so have to be passed to the commit.cgi script. They
are in that area that I show as deleted.
> <p style="text-align:center">
> <a href="handler1" class="btnlink">bing</a>
> <a href="handler2" class="btnlink">frog</a>
> </p>
>
> using css to make the "btnlink" class look and behave like a button
> when clicked etc.
>
> .btnlink {
> border: medium outset black;
> display: inline-block;
> text-decoration:none;
> background-color:#dddddd;
> padding: 2px 5px;
> color: black;
> }
> .btnlink:active {border: medium inset black;}
That's getting a lot more involved than I want to be. This isn't for a
commercial application.
> If one button is a submit for a form, and the other has to call a
> different page, try (with the same css):
>
> <p style="text-align:center">
> <span class="btnlink"
> onclick="document.getElementById('form_id').submit()">bing</span>
> <a href="handler2" class="btnlink">frog</a>
> </p>
Wouldn't that put them on different lines?
rf
>>> 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.
Jonathan N. Little
> <p style="text-align:center">
> <span class="btnlink"
> onclick="document.getElementById('form_id').submit()">bing</span>
> <a href="handler2" class="btnlink">frog</a>
> </p>
>
> This also means you can put the "submit" button outside the form.
>
> Doubtless someone will be along shortly to tell me my css, html or
> javascript is horribly broken, but whatever.
>
Yes it is, but far worse is that your "solution" *requires* JavaScript
in order to submit the form.
To OP without a URL to what you are attempting it is hard to advise.
Generally if you need a form to have two options that run difference
scripts far better fussing with two form actions but have a single
"frontend" script and have a radio button group with your two options.
<form action="theDecider.cgi">
<div>
Choose: <input type="radio" name="do" value="this"><label>This</label>
or <input type="radio" name="do" value="that"><label>That</label>
<br>
<input type="submit" value"Make it so!">
</div>
</form>
#theDecider.cgi
...
if( param('do') eq 'this' )
{
# call 'this' script
}
elseif ( param('do') eq 'that' )
{
# call 'that' script
}
else
{
# invalid input handle error
}
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Neredbojias
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
lrhorer
>>> 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. 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.
> <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?
>> 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.
>>> 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.
I am not nesting any forms. Every <form ...> is followed by a </form>
prior to any other form being opened. You must have missed one of the
closures. Indeed, in the pupdate.cgi script, there is only one
<form...> and one </form>, at the beginning and end of the do loop,
respectively. This guarantees that every form open has a form close
prior to the next open. The do loop generates lots of forms, but each
form consists of an open / close pair.
The profile.cgi script only has has two forms, and roughly half way
between the first form open and the second form close are two
consecutive lines:
echo "</form>"
echo "<form ACTION=\"/cgi-bin/pupdate.cgi\">"
> 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.
Yeah, I know that. I wrote it, remember? I want the two buttons to be
on the same line, aligned with the table above. If putting the end of
the first form inside the table row is invalid, per your response
above, then assume I get rid of the one line table containing the last
element of the form, and replace it with either another cell of the
first table or a narrow <p>. Now how do I place the other form on the
same line as the last element of the first form, aligned with the
middle of the 3rd cell in the table above it?
> 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.
That explains it. Thanks.
lrhorer
>> 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>
That wasn't quite my point.
> ...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.
OK, here's the situation. I have some information I want to send to
the server. All that information is entered using several drop-down
boxes on a single line. These are of course all part of a form #1. In
addition to the drop-down boxes, I must have a submit button, of
course, or else the data will never be sent to the web server. I want
that submit button on the left side of the second line. In addition to
calling script #1 to complete the transactions in form #1, however, I
also want to be able to call script #2 by clicking on a second button
just like the first button, on the same line as the first button, just
to the right of the first button.
Now I can put a table row on the second line, put the first button in
the leftmost cell of the tr, and close the table, followed by closing
the form. The problem with that is, the next form will wind up on the
3rd line.
>> 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...
Oh, give me a break.
rf
>>>> 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? :-)
Andy
"lrhorer" <lrh...@satx.rr.com> wrote in message
news:fqKdnVobpfSUbMjR...@giganews.com...
Hi,
You just need to make sure that <form> and </form> are not within elements
that get displayed. So all I did was move the first <form> so it was between
<table> and <tr> (i.e. wouldn't be displayed), added a closing </td></tr> to
your opening <td> so the </form><form> was in between </td> and <td> and
again added the missing </td></tr> so I could move the last closing </form>
in between </tr> and </table>.
Like so...
<table>
<FORM ACTION="/cgi-bin/commit.cgi">
<tr bgcolor="#00ff00">
<td Width=100 align="center">Room<td Width=40 align="center">Hour</td>
<td Width=40 align="center">Min<td Width=40>Temp</td>
<tr>
<td>[...Whole bunch of stuff deleted]</td>
</tr>
</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">
</td>
</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">
</td>
</tr>
</form>
</table>
.... so
Point 1: Always close your opening tags.
Point 2: Place <form> tags where text doesn't get displayed.
Hope this helps
Andy
rf
news:31v5o.9818$zT3.7053@hurricane...
> Hi,
>
> You just need to make sure that <form> and </form> are not within elements
> that get displayed. So all I did was move the first <form> so it was
> between <table> and <tr> (i.e. wouldn't be displayed), added a closing
> </td></tr> to your opening <td> so the </form><form> was in between </td>
> and <td> and again added the missing </td></tr> so I could move the last
> closing </form> in between </tr> and </table>.
All of which is invalid HTML and leaves the author wide open to the whims of
the browsers error correction. Read the rest of the thread. In this case the
OP's problem is *directly* caused by the browser error correcting the OP's
invalid HTML.
Andy
"rf" <r...@z.invalid> wrote in message
news:3av5o.2296$FH2....@viwinnwfe02.internal.bigpond.com...
Ok, no probs. Just style the form element to have a zero bottom margin then
you can put each <form> where you like...
<html>
<body>
<style>
form { margin-bottom: 0; }
</style>
<table>
<tr bgcolor="#00ff00">
<td Width=100 align="center">Room<td Width=40 align="center">Hour</td>
<td Width=40 align="center">Min<td Width=40>Temp</td>
</tr>
<tr>
<td>[...Whole bunch of stuff deleted]</td>
</tr>
</table>
<table>
<tr>
<td Width=110 align="center">
<FORM ACTION="/cgi-bin/commit.cgi">
<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>
</td>
<td Width=110 align="center">
<form ACTION="/cgi-bin/pupdate.cgi">
<input type="submit" name="Abort" value="Abort">
<input type="hidden" NAME="Therms" value="8">
<input type="hidden" NAME="Testing" value="Program">
</form>
</td>
</tr>
</table>
</body>
</html>
Hope this helps
Andy
Jonathan N. Little
> 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:
[*] Technically can be done with JavaScript, but very-very brittle and
not at all recommended.
Denis McMahon
>> using css to make the "btnlink" class look and behave like a button
>> when clicked etc.
>>
>> .btnlink {
>> border: medium outset black;
>> display: inline-block;
>> text-decoration:none;
>> background-color:#dddddd;
>> padding: 2px 5px;
>> color: black;
>> }
>> .btnlink:active {border: medium inset black;}
>
> That's getting a lot more involved than I want to be. This isn't for a
> commercial application.
It's hardly cutting edge css either.
>> If one button is a submit for a form, and the other has to call a
>> different page, try (with the same css):
>>
>> <p style="text-align:center">
>> <span class="btnlink"
>> onclick="document.getElementById('form_id').submit()">bing</span>
>> <a href="handler2" class="btnlink">frog</a>
>> </p>
>
> Wouldn't that put them on different lines?
Why would two items in the same <p></p> be on different lines unless (a)
the paragraph wasn't wide enough for both of them or (b) you put a <br>
in between them?
Yes I did try that code out before I posted it.
Rgds
Denis McMahon
Denis McMahon
>> 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
Sherm Pendley
> "rf" <r...@z.invalid> wrote in message
> news:3av5o.2296$FH2....@viwinnwfe02.internal.bigpond.com...
>> "Andy" <an...@NOSPAMmanyplay.com> wrote in message
>> news:31v5o.9818$zT3.7053@hurricane...
>>
>>> Hi,
>>>
>>> You just need to make sure that <form> and </form> are not within
>>> elements that get displayed. So all I did was move the first <form>
>>> so it was between <table> and <tr> (i.e. wouldn't be displayed),
>>> added a closing </td></tr> to your opening <td> so the
>>> </form><form> was in between </td> and <td> and again added the
>>> missing </td></tr> so I could move the last closing </form> in
>>> between </tr> and </table>.
>>
>> All of which is invalid HTML and leaves the author wide open to the
>> whims of the browsers error correction. Read the rest of the
>> thread. In this case the OP's problem is *directly* caused by the
>> browser error correcting the OP's invalid HTML.
>
> Ok, no probs. Just style the form element to have a zero bottom margin
> then you can put each <form> where you like.
No you can't - your advice will still result in invalid HTML.
> Hope this helps
It doesn't. Bad advice is worse than none, and your advice is beyond
merely bad. The most helpful thing you could do right now is to stop
trying to give advice until you actually learn HTML yourself.
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
Andy
"Sherm Pendley" <sherm....@gmail.com> wrote in message
news:m24ofdh...@sherm.shermpendley.com...
All I said was to add...
form { margin-bottom: 0; }
... to the OPs stylesheet, which is perfectly valid html.
Anyhoo, you can't speak, both of your urls result in...
Site Temporarily Unavailable
We apologize for the inconvenience. Please contact the webmaster/ tech
support immediately to have them rectify this.
error id: "bad_httpd_conf"
Stop trolling ;)
Andy
Sherm Pendley
> All I said was to add...
>
> form { margin-bottom: 0; }
>
> ... to the OPs stylesheet, which is perfectly valid html.
No amount of stylesheet tweaks will fix the invalid HTML that would
result from your advice.
Forms, to be valid, must either contain the entire table, as in:
<form><table>...</table></form>
Or, if they're within the table, must be contained within a td, as in:
<table><tr><td><form>...</form></td></tr></table>
Those are the rules of HTML, as clearly documented in the standards
docs found at <http://w3.org>.
> Anyhoo, you can't speak, both of your urls result in...
>
> Site Temporarily Unavailable
Which says nothing one way or the other about my ability to write
valid HTML. Apparently basic logic is as foreign to you as basic HTML
concepts.
> Stop trolling ;)
Calling me names won't make your advice correct either. Grow up.
Jonathan N. Little
> 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...
Sherm Pendley
> "Andy" <an...@NOSPAMmanyplay.com> writes:
>
>> Anyhoo, you can't speak, both of your urls result in...
>>
>> Site Temporarily Unavailable
>
> Which says nothing one way or the other about my ability to write
> valid HTML. Apparently basic logic is as foreign to you as basic HTML
> concepts.
Also, the current camelbones site is hosted at sourceforge, and *does*
validate:
<http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fcamelbones.sourceforge.net%2Findex.html>
lrhorer
>> 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.
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. The
wording of the original response made it sound as if the respondant
were SAYING that a form could not span a table, which makes no sense.
> There are two ways you can mix forms and tables. He has tried to
> explain to you these two possibilities:
I understand that, as well. I don't do any significant amount of web
publishing, but I am not a fool.
>> 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.
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.
> 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.
> 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.
lrhorer
>> 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*.
In effect, yes.
> 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..."
>
<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.
> [*] 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.
Sherm Pendley
> 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.
That's not the ideal approach. A better approach would be to enclose
the entire table in a single form, then write the server-side action to
include code that checks which of the two buttons were pushed, and
responds accordingly.
> Here we go again. A submit button is a type of radio button.
No it isn't. A radio button is <input type="radio">, and is used to
group together a set of mutually-exclusive options, where clicking
one of the radio buttons selects it and unselects all the others in the
group, without sending the form data to the action URL.
A submit button does something completely different - it sends the
form data to the action URL, *without* affecting the selection status
of any other form control.
> buttton one pushes to get a device (originally a radio) to do
> something.
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! :-)
>> 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.
No it doesn't. You may not know how to write it without an intermediate
script, but that does *not* mean it can't be done.
Jonathan N. Little
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.
Jonathan N. Little
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.
Denis McMahon
> 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
lrhorer
> 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.
That was never really the issue, which is the problem. Fixing the code
symmetry is no big deal. (Actually, the whole thing is no big deal.)
What I am asking is how to move the button for the second action up to
the right of the button for the first action. One way, as I mentioned
in my very first paragraph, is to make both buttons submits to a single
form and cause them to branch to an intermediate form which in turn
calls one of the two target forms. My question is, "Is there a simple
and elegant way to accomplish this using two forms instead of one?"
Two forms are much simpler programmatically.
>> 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.
You're wrapped around an axle, here. Look, assume I have two forms.
One has a target of commit.cgi and a submit button labeled, oddly
enough, "Submit". The other has a target of pupdate.cgi. and a submit
button labeled, "Abort". How can I have the web page display both
buttons side-by-side on the same line, using only html code? That's
*ALL* I'm asking.
I know how to make it work using only a single form.
I don't want to use javascript or any other such utility.
Fixing other errors in the script is far outside the scope of my
question.
>>> 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
I didn't say you said it could. I said that it could not, and
qualified the statement by pointing out there could be something of
which I was unaware. Since apparently I did know from whence I spoke,
there is no need to belabor the point, so can we move on, please?
> 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
OK, not to split hairs, but there is a difference between what I did
and what your tools think I did. Once again, however, it is beside the
point. I will gladly remove the second form from the second cell of
the table row and move the </form> of the first form outside the table
entirely if you can tell me how to display the result as:
<Submit Form 1> <Submit Form 2>
Rather than:
<Submit Form 1>
<Submit Form 2>
Which would be the case with
<Form Action...>
<table>
<Submit...>
</table>
</form>
<Form Action...>
<p> (or <table>)
<Submit...>
</p> (or </table>)
</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.
I hestitate to point out that it does work in both IE and Firefox, not
that this will ever be used on IE. Yes, I know, that is no guarantee
it will continue to work.
> 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.
I'm afraid I lost you, there, but the point would seem moot, in any
case. Tell me how to move the second button up and to the right, and I
can move the </form> declaration for the first form outside the table,
which evidently will make you happy.
> Now, do you think it might be a good idea to take your code over to
> the validator and fix *all* the errors? :-)
Actually, no. I'm doing a number of "illegal" but nonetheless
effective things to get this to display the way I want. I don't want
to spend the hours it would take to research the "correct" methods and
correct them in the code. Maybe one day, if I am bored, or if the
browsers stop accepting the code, then I will. If this were a
commercial application, it would be a different matter, but it isn't.
Even if it were to be available on the net, I might, but this isn't
even getting published on the web. I error corrected the two other
sites I did, but for this it just isn't worth the trouble. Indeed,
I've already expended considerably more effort than the issue is worth.
lrhorer
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.
> 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.
Whatever. It's far beside the entire point of my query, which is
simply, "How do I move the control icon up and to the right?"
Andy
"Sherm Pendley" <sherm....@gmail.com> wrote in message
news:m2mxt56...@sherm.shermpendley.com...
If you look back at my last suggestion, you'll see that each <form> blah
blah </form> is within a containing <td>....
Here's a cut&paste with the form bits spaced out a bit for clarity...
<html>
<body>
<table>
<tr>
</tr>
</table>
</body>
</html>
Love & Kisses
Andy
Denis McMahon
> 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
Jonathan N. Little
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.
Denis McMahon
>> 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
Sherm Pendley
> If you look back at my last suggestion, you'll see that each <form>
> blah blah </form> is within a containing <td>....
Your suggestion is in the archives, so now the whole world can see that
you're not just a fool, but a liar as well:
<http://groups.google.com/group/alt.html/tree/browse_frm/thread/a23726057b69fd5b/4f1ee05f6b98a01e?rnum=21&_done=%2Fgroup%2Falt.html%2Fbrowse_frm%2Fthread%2Fa23726057b69fd5b%3F#doc_c2c065deae3fb097>
> Here's a cut&paste
No, *here* is a cut and paste, straight from the Google archives cited
above, proving that you lie:
<table>
<FORM ACTION="/cgi-bin/commit.cgi">
<tr bgcolor="#00ff00">
<td Width=100 align="center">Room<td Width=40 align="center">Hour</td>
<td Width=40 align="center">Min<td Width=40>Temp</td>
<tr>
<td>[...Whole bunch of stuff deleted]</td>
</tr>
</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">
</td>
</form>
Not only is the form *not* within a containing <td>, closing </form> tag
isn't even within the same table! Your suggested markup is complete
gibberish.
What on earth makes you think you can get away with lying about your
past statements, when what you *really* wrote is archived for the whole
world to see?
dorayme
Sherm Pendley <sherm....@gmail.com> 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
lrhorer
Hmm. Now there's a thought. That's simpler and cleaner.
lrhorer
They're written, but none of the scripts are complete, so merging the
operations of one script into two is nearly dead easy.
Andy
Hi Sherm,
You're looking at my first suggestion, I was referring to my last
suggestion.
Search for my post which was a reply to a post by rf. The datestamp is
02/08/2010 09:27, it is 3KB in size and listed as 1 line.
Here is a cut&paste of the entire message as it appears in Windows Live Mail
newsreader...
"rf" <r...@z.invalid> wrote in message
news:3av5o.2296$FH2....@viwinnwfe02.internal.bigpond.com...
> "Andy" <an...@NOSPAMmanyplay.com> wrote in message
> news:31v5o.9818$zT3.7053@hurricane...
>
>> Hi,
>>
>> You just need to make sure that <form> and </form> are not within
>> elements that get displayed. So all I did was move the first <form> so it
>> was between <table> and <tr> (i.e. wouldn't be displayed), added a
>> closing </td></tr> to your opening <td> so the </form><form> was in
>> between </td> and <td> and again added the missing </td></tr> so I could
>> move the last closing </form> in between </tr> and </table>.
>
> All of which is invalid HTML and leaves the author wide open to the whims
> of the browsers error correction. Read the rest of the thread. In this
> case the OP's problem is *directly* caused by the browser error correcting
> the OP's invalid HTML.
>
>
>
>
>
Ok, no probs. Just style the form element to have a zero bottom margin then
you can put each <form> where you like...
<html>
<body>
<style>
form { margin-bottom: 0; }
</style>
<table>
<tr bgcolor="#00ff00">
<td Width=100 align="center">Room<td Width=40 align="center">Hour</td>
<td Width=40 align="center">Min<td Width=40>Temp</td>
</tr>
<tr>
<td>[...Whole bunch of stuff deleted]</td>
</tr>
</table>
<table>
<tr>
<td Width=110 align="center">
<FORM ACTION="/cgi-bin/commit.cgi">
<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>
</td>
<td Width=110 align="center">
<form ACTION="/cgi-bin/pupdate.cgi">
<input type="submit" name="Abort" value="Abort">
<input type="hidden" NAME="Therms" value="8">
<input type="hidden" NAME="Testing" value="Program">
</form>
</td>
</tr>
</table>
</body>
</html>
Hope this helps
Andy
... I don't lie.
Andy
Sherm Pendley
> You're looking at my first suggestion, I was referring to my last
> suggestion.
... a reference which had SFA to do with my criticism of your first
one, other than being a tacit admission that I was right, that the
first was utter gibberish.
> ... I don't lie.
Lie, spin, deflect - Call it whatever helps you sleep better.
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
Andy
"Sherm Pendley" <sherm....@gmail.com> wrote in message
news:m2zkx43...@sherm.shermpendley.com...
Hi Sherm,
I think you may be having a problem with Google Groups being out of sync
with newsreaders or not fully listing all replies.
If you recall the OP's original post, he was just looking for a fix for the
Submit and Abort buttons not lining up. Because the OP stated that it wasn't
particularly urgent, his code worked and he/she just wanted a simple fix I
suggested that he/she moves the <form> and </form> tags to somewhere in the
code that wouldn't render text (e.g. in between <table> and <tr>), which
solved the problem.
Based on how the OP phrased his/her request I didn't think that validation
would be an issue, plus, to be perfectly honest, his/her code had loads of
errors in it anyway so it was pretty clear that validation wasn't exactly
top of the list of requirements.
I should have known better!
Sure enough (you guys just love that validator) the first reply to my
suggestion from rf (10 mins later) pointed out that my quick fix would
produce validation errors.
Okay I thought, I do remember this issue cropping up before and there being
a correct way to do it, so I Googled it and found this solution...
form { margin-bottom: 0; }
... which as you know removes the unwanted whitespace below form elements.
I then showed the OP's original code with the <form> </form> elements within
a containing <td>
Now this is where things got sticky...
You replied to my updated suggestion post (the one with the style solution),
but somehow you quoted part of (as in cut&paste) my original/first post (the
one with the move the <form> tags solution) and not the actual post you were
replying to.
I didn't realise that you had misquoted me (i.e. didn't spot that you had
replied reference my first post) and couldn't understand why you thought
that adding a valid style declaration would cause validation errors.
My mistake, for which I apologise, is that at this point I thought you were
just spoiling for an argument and wrongly told you to "Stop trolling".
Again you replied saying that the <form> elements must either contain the
whole <table> ... </table> or be within <td> ... </td>.
I thought to myself "What is this guy on about? my last suggestion clearly
has the <form> tags inside a single <td>", so I replied to you stating this
and included a cut&paste of my post to prove it.
Now clearly at this point you still couldn't see/find my updated suggestion
and professed to the whole World that I was a liar and that my cut&paste of
my updated suggestion was false/made up. To back up your claim you
cut&pasted a part of my original post and provided this link...
... which you said would prove that I was lying.
I followed your link, and interestingly although it does list the posts in
this topic, it cuts off right after my first post. I'm not going to suggest
that you manipulated the url to only show what you wanted, so again I'll
chalk this up to a glitch.
Here's a url to the entire topic on Google Groups...
http://groups.google.com/group/alt.html/browse_thread/thread/a23726057b69fd5b#
... which clearly shows my updated suggestion at 09:27am.
I did reply to you to let you know that you were quoting my first post and
not my second and included the time/size etc to help you find it. I also
cut&pasted the entire message (including the headers and previous post) to
prove this to you but again you insisted that I was lying, spinning and
deflecting so that I could sleep at night.
I'm not after an apology as I'm guessing you're the sort of person that will
never admit when you have made a mistake, but I did want everyone else to
know that I do not lie... what you think of me is not important.
Andy
Sherm Pendley
> If you recall the OP's original post, he was just looking for a fix
> for the Submit and Abort buttons not lining up. Because the OP stated
> that it wasn't particularly urgent, his code worked and he/she just
> wanted a simple fix I suggested that he/she moves the <form> and
> </form> tags to somewhere in the code that wouldn't render text
> (e.g. in between <table> and <tr>), which solved the problem.
Nonsense, all it does is create a different problem.
> Based on how the OP phrased his/her request I didn't think that
> validation would be an issue, plus, to be perfectly honest, his/her
> code had loads of errors in it anyway so it was pretty clear that
> validation wasn't exactly top of the list of requirements.
>
> I should have known better!
Yes, you should have. And now that you've admitted that you should
have, my job here is done.
> Now this is where things got sticky...
More nonsense. I knew exactly what I was replying to, where I was
replying to it, and why. If I had meant to reply to some other sub-
thread, I would have done so *in that subthread.* If having separate
subthreads confuses you, that isn't my fault. Learn to use your news
reader.
> Now clearly at this point you still couldn't see/find my updated
> suggestion
I'm not replying to your "updated" suggestion. That's in another sub-
thread. Your inability to understand how threading works is *your*
problem, not mine.
> I followed your link, and interestingly although it does list the
> posts in this topic, it cuts off right after my first post.
Google's search interface only shows a handful of posts at one time.
Try clicking the "Newer" link before you make an even bigger fool of
yourself.
> I'm not
> going to suggest that you manipulated the url to only show what you
> wanted, so again I'll chalk this up to a glitch.
I'm chalking it up to a 1d10t error on your end.
> I did reply to you to let you know that you were quoting my first post
> and not my second
Which is exactly what I intended to do, because I was replying in the
subthread following your first post, not your second.
You're not very bright, are you?
> I'm not after an apology as I'm guessing you're the sort of person
> that will never admit when you have made a mistake
When I *have* made a mistake, I freely admit it. I've done so on any
number of occasions here in this group. Your failure to understand how
threading works is not a mistake on my part.
> but I did want
> everyone else to know that I do not lie
Nearly every statement you've made in this thread has been an attempt
to deflect from the fact that I was right, and the advice *I was actually
commenting on* was gibberish. Like I said before - lie, spin, deflect,
call it what you will, it's all dishonesty of one kind or another.
> ... what you think of me is not important.
Right, you spent all that time writing such a long detailed reply because
you don't care. You really think I believe that?
Andy
"Sherm Pendley" <sherm....@gmail.com> wrote in message
news:m2iq3rc...@sherm.shermpendley.com...
> "Andy" <an...@NOSPAMmanyplay.com> writes:
>
>> If you recall the OP's original post, he was just looking for a fix
>> for the Submit and Abort buttons not lining up. Because the OP stated
>> that it wasn't particularly urgent, his code worked and he/she just
>> wanted a simple fix I suggested that he/she moves the <form> and
>> </form> tags to somewhere in the code that wouldn't render text
>> (e.g. in between <table> and <tr>), which solved the problem.
>
> Nonsense, all it does is create a different problem.
Wrong, the other problems where always there. All I did was address the OP's
alignment issue, I never stated or intended to fix any other problems.
>
>> Based on how the OP phrased his/her request I didn't think that
>> validation would be an issue, plus, to be perfectly honest, his/her
>> code had loads of errors in it anyway so it was pretty clear that
>> validation wasn't exactly top of the list of requirements.
>>
>> I should have known better!
>
> Yes, you should have. And now that you've admitted that you should
> have, my job here is done.
>
You're just being prissy
>> Now this is where things got sticky...
>
You've completely cut out the quotes that prove that you where wrong here
> More nonsense. I knew exactly what I was replying to, where I was
> replying to it, and why. If I had meant to reply to some other sub-
> thread, I would have done so *in that subthread.* If having separate
> subthreads confuses you, that isn't my fault. Learn to use your news
> reader.
>
I've been using newsreaders for over 30 years, I know exactly how they work
I can see when you reply to my post and then edit out all of the quotes and
then paste in parts of my previous post.
>> Now clearly at this point you still couldn't see/find my updated
>> suggestion
>
> I'm not replying to your "updated" suggestion. That's in another sub-
> thread. Your inability to understand how threading works is *your*
> problem, not mine.
Really? Because everyone that uses a real newsreader (not Google Groups,
that's for noobs) can see that our conversation is one complete sub-thread
from my first to last post.
>
>> I followed your link, and interestingly although it does list the
>> posts in this topic, it cuts off right after my first post.
>
> Google's search interface only shows a handful of posts at one time.
> Try clicking the "Newer" link before you make an even bigger fool of
> yourself.
>
Really? Because when I tested your dodgy link, you know, the one that
conveniently shows my first post but none thereafter in IE, FF and Chrome on
two separate PCs plus my Nexus One and PS3 there was no "newer" "older"
links. Of course, the link I provided does show all posts and does have
those links.
>> I'm not
>> going to suggest that you manipulated the url to only show what you
>> wanted, so again I'll chalk this up to a glitch.
>
> I'm chalking it up to a 1d10t error on your end.
>
You would, truth evasion is your specialty.
>> I did reply to you to let you know that you were quoting my first post
>> and not my second
>
> Which is exactly what I intended to do, because I was replying in the
> subthread following your first post, not your second.
>
> You're not very bright, are you?
>
You really are a rude little man
>> I'm not after an apology as I'm guessing you're the sort of person
>> that will never admit when you have made a mistake
>
> When I *have* made a mistake, I freely admit it. I've done so on any
> number of occasions here in this group. Your failure to understand how
> threading works is not a mistake on my part.
>
>> but I did want
>> everyone else to know that I do not lie
>
> Nearly every statement you've made in this thread has been an attempt
> to deflect from the fact that I was right, and the advice *I was actually
> commenting on* was gibberish. Like I said before - lie, spin, deflect,
> call it what you will, it's all dishonesty of one kind or another.
>
There you go again, calling me a liar when everyone can see that I'm not
>> ... what you think of me is not important.
>
> Right, you spent all that time writing such a long detailed reply because
> you don't care. You really think I believe that?
>
Like I said (but you failed to grasp), I don't care what YOU think, but I do
care what everyone else thinks, which is why I spent a little bit of time
presenting my evidence which you just cut out of any reply and refuse to
acknowledge.
> sherm--
>
> --
> Sherm Pendley <www.shermpendley.com>
> <www.camelbones.org>
> Cocoa Developer
Isn't it funny how each person's perception of reality is different?
From my point of view you accused me of lying when I stated that I had
posted a solution where the <form>...</form> was inside a <td>.
I proved to you and everyone else that you were incorrect by providing a
link to the thread in Google Groups...
http://groups.google.com/group/alt.html/browse_thread/thread/a23726057b69fd5b
(the post in question was posted 2nd August at 9:27am)
And yet you still can't see it.
I won't be replying to your posts anymore Sherm, you're just not worth my
time.
Andy
Sherm Pendley
> I've been using newsreaders for over 30 years
And yet, you *still* can't understand how they work. Not too bright,
are you?
I have better things to do than argue with idiots.
*plonk*
Neredbojias
> "Andy" <an...@NOSPAMmanyplay.com> writes:
>
>> I've been using newsreaders for over 30 years
>
> And yet, you *still* can't understand how they work. Not too bright,
> are you?
>
> I have better things to do than argue with idiots.
>
> *plonk*
>
> sherm--
Aww. I was hoping that the Sherm 'N Andy Show would go into
syndication...
--
Neredbojias
Sherm Pendley
> Aww. I was hoping that the Sherm 'N Andy Show would go into
> syndication...
Sorry to disappoint! Maybe I'm getting older, but my patience for the
antics of idiots, and my willingness to try to educate them, are both
growing shorter.
dorayme
Sherm Pendley <sherm....@gmail.com> wrote:
> Neredbojias <nered...@gmail.com> writes:
>
> > Aww. I was hoping that the Sherm 'N Andy Show would go into
> > syndication...
>
> Sorry to disappoint! Maybe I'm getting older, but my patience for the
> antics of idiots, and my willingness to try to educate them, are both
> growing shorter.
You have behaved disgracefully sherm--, Andy did not deserve your
nasty personal abuse. And *you* were openly and flagrantly
dishonest in at least one if not more points and making like that
archetypal 1d10t you repeatedly mentioned.
There is an inner 1d10t in many of you earthlings. From now on,
please be more humble. Remember, the last shall be first and the
first shall be last when that Ultimate Judgement Time comes.
Now, can we all please kneel and pray...
--
dorayme
Sherm Pendley
> In article <m2eief7...@sherm.shermpendley.com>,
> Sherm Pendley <sherm....@gmail.com> wrote:
>
>> Neredbojias <nered...@gmail.com> writes:
>>
>> > Aww. I was hoping that the Sherm 'N Andy Show would go into
>> > syndication...
>>
>> Sorry to disappoint! Maybe I'm getting older, but my patience for the
>> antics of idiots, and my willingness to try to educate them, are both
>> growing shorter.
>
> You have behaved disgracefully
I assume you know how to use a killfile - if you value warm fuzzy
behavior over facts, you know how to ignore me.
dorayme
Sherm Pendley <sherm....@gmail.com> wrote:
> dorayme <dor...@optusnet.com.au> writes:
>
> > In article <m2eief7...@sherm.shermpendley.com>,
> > Sherm Pendley <sherm....@gmail.com> wrote:
> >
> >> Neredbojias <nered...@gmail.com> writes:
> >>
> >> > Aww. I was hoping that the Sherm 'N Andy Show would go into
> >> > syndication...
> >>
> >> Sorry to disappoint! Maybe I'm getting older, but my patience for the
> >> antics of idiots, and my willingness to try to educate them, are both
> >> growing shorter.
> >
> > You have behaved disgracefully
>
> I assume you know how to use a killfile - if you value warm fuzzy
> behavior over facts, you know how to ignore me.
Why would I kf you? Just because you have acted ungraciously,
unnecessarily, cruelly, insensitively and largely without
foundation? You have to be kidding!
(Oh... and btw, you did not establish straight facts to back your
claim that Andy was a no-good lowdown scumbag cheat and liar
whatever else he may have been.)
--
dorayme
Sherm Pendley
> In article <m2aap3m...@sherm.shermpendley.com>,
> Sherm Pendley <sherm....@gmail.com> wrote:
>
>> dorayme <dor...@optusnet.com.au> writes:
>>
>> > In article <m2eief7...@sherm.shermpendley.com>,
>> > Sherm Pendley <sherm....@gmail.com> wrote:
>> >
>> >> Neredbojias <nered...@gmail.com> writes:
>> >>
>> >> > Aww. I was hoping that the Sherm 'N Andy Show would go into
>> >> > syndication...
>> >>
>> >> Sorry to disappoint! Maybe I'm getting older, but my patience for the
>> >> antics of idiots, and my willingness to try to educate them, are both
>> >> growing shorter.
>> >
>> > You have behaved disgracefully
>>
>> I assume you know how to use a killfile - if you value warm fuzzy
>> behavior over facts, you know how to ignore me.
>
> Why would I kf you? Just because you have acted ungraciously,
> unnecessarily, cruelly, insensitively and largely without
> foundation? You have to be kidding!
I think I'll do the honors then - your posts about HTML are generally
spot-on and delivered in an entertaining manner, but the constant
"Miss Manners" lectures are growing too annoying to bother with.
dorayme
Sherm Pendley <sherm....@gmail.com> wrote:
> dorayme <dor...@optusnet.com.au> writes:
>
> > In article <m2aap3m...@sherm.shermpendley.com>,
> > Sherm Pendley <sherm....@gmail.com> wrote:
> >
> >> dorayme <dor...@optusnet.com.au> writes:
> >>
> >> > In article <m2eief7...@sherm.shermpendley.com>,
> >> > Sherm Pendley <sherm....@gmail.com> wrote:
> >> >
> >> >> Neredbojias <nered...@gmail.com> writes:
> >> >>
> >> >> > Aww. I was hoping that the Sherm 'N Andy Show would go into
> >> >> > syndication...
> >> >>
> >> >> Sorry to disappoint! Maybe I'm getting older, but my patience for the
> >> >> antics of idiots, and my willingness to try to educate them, are both
> >> >> growing shorter.
> >> >
> >> > You have behaved disgracefully
> >>
> >> I assume you know how to use a killfile - if you value warm fuzzy
> >> behavior over facts, you know how to ignore me.
> >
> > Why would I kf you? Just because you have acted ungraciously,
> > unnecessarily, cruelly, insensitively and largely without
> > foundation? You have to be kidding!
>
> I think I'll do the honors then - your posts about HTML are generally
> spot-on and delivered in an entertaining manner, but the constant
> "Miss Manners" lectures are growing too annoying to bother with.
Bullshit! You could not keep anyone in your kf for longer than 5
mins? How do I know this? Because I have detailed records of your
weakness and soft-heartedness going back decades. You will never
make a good Hitler however much you try.
(Oh and btw again, I don't deliver *constant* "Miss Manners"
lectures. I just give facts: I thought you were a big fan of
these things? <g>)
--
dorayme
Neredbojias
> Neredbojias <nered...@gmail.com> writes:
>
>> Aww. I was hoping that the Sherm 'N Andy Show would go into
>> syndication...
>
> Sorry to disappoint! Maybe I'm getting older, but my patience for the
> antics of idiots, and my willingness to try to educate them, are both
> growing shorter.
Hehe, yeah, -and I should talk! There's a thread further on where the
OP posted about not getting images unless the index page was explicitly
included in the url. Does he post the url? Someone made some
suggestion, and he offered to email the real url to the guy. Geesh!
lrhorer
> 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.
rf
"lrhorer" <lrh...@satx.rr.com> wrote in message
news:jOOdnYLI-O-O8sfR...@giganews.com...
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 :-)
lrhorer
>> 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?
Bash.
> 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
I couldn't care less about IE, but I finally got it to work by placing
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.
> 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.
> 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 :-)
No. That's my roommate's daughter's name. She moved out when she
turned 19, but I still refer to the room as hers.
Sherm Pendley
> rf wrote:
>
>> 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
>
> I couldn't care less about IE
Avoiding quirks mode isn't a question of pandering to IE's quirks.
It has varying degrees of, um, quirkiness in a variety of browsers. IE
is but one of them.
> 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.
>> 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.
dorayme
Sherm Pendley <sherm....@gmail.com> 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
lrhorer
>> 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?
rf
"dorayme" <dor...@optusnet.com.au> wrote in message
news:dorayme-1CAFD2...@news.albasani.net...
Why would it? The doctype is still the first line *in the HTML*.
Norman Peelman
> 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
Is not a part of the HTML.
>
> (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?
>
The doctype should be the first line of the HTML output, not the
header output.
--
Norman
Registered Linux user #461062
-Have you been to www.apache.org yet?-
rf
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
"rf" <r...@z.invalid> wrote in message
Damn
[HTTP headers]
[one blank line]
[HTML]
where [HTML] looks similar to
Denis McMahon
> 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
Sherm Pendley
> 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.
You are confused - HTML doesn't "run."
> HTTP header does not precede every other HTML line, then the web server
> will barf on the file.
The "content marker" that you mentioned earlier isn't an HTTP header.
It's an HTML <meta ...> element, which is included in the <head> element
and used by browsers in situations where no HTTP headers are sent - for
example, local browsing of files on disk. Whenever any *real* HTTP
headers are sent, they override the corresponding <meta ...> elements.
> #! /bin/bash
>
> (or some other valid shell), then the file won't run at all.
The doctype needs to be the first line OF THE HTML, not the first line
of the program that creates it.
>> 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?
No, you should ask yourself in what way you've misunderstood and/or
misapplied the advice, that results in it not working for you when it
works for everyone else. I'm not picking on you, I'm speaking from my
own personal experience - 99 out of 100 times, when something is acting
screwy, my own mistake has been the cause.
> I didn't ask for advice setting up my headers.
<shrug> Sometimes the advice you need isn't the advice you asked for.
We've all been there at one time or another, so trust me - it ain't
personal! :-)
> looking at your responses in this thread, I don't see any useful advice
> whatsoever, only criticisms.
Criticism of bogus advice *is* useful. Allowing it to stand unremarked
is a disservice to those who otherwise may have been misled by it. As
I've said before, if those who offer bad advice get their feelings hurt
by being corrected, GOOD! Maybe the pain will teach them to check
their facts before giving advice.
> Perhaps in the past you have offered real advice
I have in the past, and I am now. Like I said, the advice you need is
not always the advice you want. What you're missing here is that quirks
mode isn't an IE-only feature. All the "major" browsers have it, and
try hard to emulate IE's bugs - IE 6's broken box model being the
worst - when it's triggered.
So, if you don't care about IE and don't want to cater to its bugs -
a position I *entirely* agree with! - you need to avoid quirks mode.
That means using a doctype that won't trigger it, and putting that
doctype in the correct place, at the first line of your HTML.
Sherm Pendley
> You are confused, and it's not Sherms fault.
Thank goodness for that! The responsibility for my *own* confusion is
hard enough to bear. I don't think I have the shoulders to take on
anyone else's! :-)
Sherm Pendley
> 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 ... :)
Wow, and I thought *I* was a language junkie! Impressive! :-)
Neredbojias
What's with the blank line? If a "blank line" appears before the
doctype (which it would with eg:
<?php $epithet="bitemynuggets"; ?>
<!~DOCTYPE="html">)
...then some browsers will screw it up.
Denis McMahon
No, you need a single blank line between the http headers and the start
of html.
It's how the protocol signals that the http headers have finished and
that what follows is the html code (or other content).
Rgds
Denis McMahon
rf
"Neredbojias" <nered...@gmail.com> wrote in message
news:Xns9DCBB1256168...@news.albasani.net...
> On 05 Aug 2010, "rf" <r...@z.invalid> wrote:
>
>>
>> "rf" <r...@z.invalid> wrote in message
>> news:SKH6o.2654$FH2...@viwinnwfe02.internal.bigpond.com...
>> [HTTP headers]
>> [one blank line]
>> [HTML]
>>
>> where [HTML] looks similar to
>> <!DOCTYPE ...
>> <html>
>> <head>
>> ...
>
> What's with the blank line?
The blank line is part of the HTTP headers. It acts as an "end of headers".
What *follows* the blank line is the payload of the HTTP message, in this
case an HTML page.
Sherm Pendley
A blank line signals the end of the HTTP headers; everything after that
is part of the HTML (or other) document content.
> If a "blank line" appears before the
> doctype (which it would with eg:
>
> <?php $epithet="bitemynuggets"; ?>
>
> <!~DOCTYPE="html">)
>
> ...then some browsers will screw it up.
Yes, any additional blank lines that are sent in addition to the one
that's required will be parsed as part of the HTML document. As the
Highlander says, there can be only one.
Neredbojias
>>>> 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>
>>> ...
>>
>> What's with the blank line? If a "blank line" appears before the
>> doctype (which it would with eg:
>>
>> <?php $epithet="bitemynuggets"; ?>
>>
>> <!~DOCTYPE="html">)
>>
>> ...then some browsers will screw it up.
>
> No, you need a single blank line between the http headers and the
> start of html.
>
> It's how the protocol signals that the http headers have finished and
> that what follows is the html code (or other content).
Well I'll be hornswaggled!
Neredbojias
>
> "Neredbojias" <nered...@gmail.com> wrote in message
> news:Xns9DCBB1256168...@news.albasani.net...
>> On 05 Aug 2010, "rf" <r...@z.invalid> wrote:
>>
>>>
>>> "rf" <r...@z.invalid> wrote in message
>>> news:SKH6o.2654$FH2...@viwinnwfe02.internal.bigpond.com...
>
>>> [HTTP headers]
>>> [one blank line]
>>> [HTML]
>>>
>>> where [HTML] looks similar to
>>> <!DOCTYPE ...
>>> <html>
>>> <head>
>>> ...
>>
>> What's with the blank line?
>
> The blank line is part of the HTTP headers. It acts as an "end of
> headers".
>
> What *follows* the blank line is the payload of the HTTP message, in
> this case an HTML page.
Well I'll be a monkey's uncle!
Neredbojias
> Neredbojias <nered...@gmail.com> writes:
>
>> On 05 Aug 2010, "rf" <r...@z.invalid> wrote:
>>
>>> [HTTP headers]
>>> [one blank line]
>>> [HTML]
>>>
>>> where [HTML] looks similar to
>>> <!DOCTYPE ...
>>> <html>
>>> <head>
>>> ...
>>
>> What's with the blank line?
>
> A blank line signals the end of the HTTP headers; everything after
> that is part of the HTML (or other) document content.
>
>> If a "blank line" appears before the
>> doctype (which it would with eg:
>>
>> <?php $epithet="bitemynuggets"; ?>
>>
>> <!~DOCTYPE="html">)
>>
>> ...then some browsers will screw it up.
>
> Yes, any additional blank lines that are sent in addition to the one
> that's required will be parsed as part of the HTML document. As the
> Highlander says, there can be only one.
Well I'll be dipped in spit!
lrhorer
> 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.
First of all, no one said "HTML line". They just said,"Line".
>
> What you're being told is that the <!DOCTYPE ....> declaration should
> come before the opening <html> tag.
That's clearly accurate. The statement, "The !DOCTYPE belongs on the
first line, always, no exceptions.", however, is at best ambiguous in
this context, especially when relayed to someone rather unfamiliar with
HTML.
More to the point, a condescending attitude is not appropriate. (Let
me hasten to say yours has not been condescending, in the least.)
Every individual of honest intent deserves respect, regardless of their
familiarity with he subject at hand.
> eg, the following parts should be output in the following sequence:
> 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.
If you ask me, that's splitting some pretty fine hairs. They are
strings required for the document to be processed as a CGI script,
whether the interpreter supplies them automatically, or not. By your
definition, they may not be part of the HTML segment, but are most
certainly part of the document and an integral part of the framework
structure.
> 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.....>"
Yeah, I got that.
Norman Peelman
The 'headers' are a separate entity to the document. They are not a
part of the document but can describe what the document should be and
how it should be acted upon.
>> 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.....>"
>
> Yeah, I got that.
--