How to remove the spacing between <form> tag?

[kaiwing18]

Hello all,

I have the following simple html how can I display the second table
content like the first one. As i have add the <form>payment</form>
tag. Any method to remove the spacing.


<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | payment]</td>
</tr>
</table>

<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | <form>payment</form>]</td>
</tr>
</table>

Thx,

Wing

 

[Chaddy2222]

Hello all,

I have the following simple html how can I display the second table
content like the first one. As i have add the <form>payment</form>
tag. Any method to remove the spacing.


<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | payment]</td>
</tr>
</table>

<table border="0" cellspacing="0" cellpadding="0">
<tr>

Learn some better coding from:
http://www.htmldog.com

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Wed, 17 Oct 2007 13:09:32 GMT
scribed:

Hello all,

I have the following simple html how can I display the second table
content like the first one. As i have add the <form>payment</form>
tag. Any method to remove the spacing.


<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | payment]</td>
</tr>
</table>

<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | <form>payment</form>]</td>
</tr>
</table>

Thx,

Wing

Set margins and padding to 0 on the form. If the line feeds are a problem,
it _may_ be possible to render the form as inline (display:inline.

 

[walosaw]

This is a quck fix though it would be better to have all your style
sheet code in a seperate css file
change
<td>[history | <form>payment</form>]</td>
to
<td>[history | <form style="display:inline">payment</form>]</td>

Cheers

 

[John]

Hello all,

I have the following simple html how can I display the second table
content like the first one. As i have add the <form>payment</form>
tag. Any method to remove the spacing.

<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | payment]</td>
</tr>
</table>

<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | <form>payment</form>]</td>
</tr>
</table>

Thx,

Wing

This is a quck fix though it would be better to have all your style
sheet code in a seperate css file
change
<td>[history | <form>payment</form>]</td>
to
<td>[history | <form style="display:inline">payment</form>]</td>

Cheers

 

[Steve Swift]

change

<td>[history | <form>payment</form>]</td>
to
<td>[history | <form style="display:inline">payment</form>]</td>

I've lost the beginning of this thread, so don't know the original question.

Whenever I'm using a <FORM> inside a <TABLE> I always place the <FORM>
inside the <TABLE> tag but *outside* any <TD></TD> or <TR></TR> constructs.
I discovered (by trial and error) that placing the <FORM> inside one of
your cells or rows would lead most browsers to dump some inexplicable
extra space somewhere, usually at the end of the last cell on the first
row. It's most noticeable if the affected cell is centred - it fails to
align with others in the same column.

So:
<TABLE>
<FORM>
<TR><TD>

Add closing tags to taste.

 

[dorayme]

change
<td>[history | <form>payment</form>]</td>
to
<td>[history | <form style="display:inline">payment</form>]</td>

I've lost the beginning of this thread, so don't know the original question.

Whenever I'm using a <FORM> inside a <TABLE> I always place the <FORM>
inside the <TABLE> tag but *outside* any <TD></TD> or <TR></TR> constructs.
I discovered (by trial and error) that placing the <FORM> inside one of
your cells or rows would lead most browsers to dump some inexplicable
extra space somewhere, usually at the end of the last cell on the first
row. It's most noticeable if the affected cell is centred - it fails to
align with others in the same column.

So:
<TABLE>
<FORM>
<TR><TD>

Add closing tags to taste.[/QUOTE]

It is like making a casserole really, anything goes eh?

 

[Ben C]

change
<td>[history | <form>payment</form>]</td>
to
<td>[history | <form style="display:inline">payment</form>]</td>

I've lost the beginning of this thread, so don't know the original question.

Whenever I'm using a <FORM> inside a <TABLE> I always place the <FORM>
inside the <TABLE> tag but *outside* any <TD></TD> or <TR></TR> constructs.

Please don't do that! It's invalid HTML. The browser has to guess what
you meant, somehow patch up the document tree, decide which controls are
to go in which forms, and if the result looks and works the way you
want, it's only because of a lot of luck.

It could all change tomorrow or be completely different in a browser you
haven't tested on.

You're not alone, I see a lot of web pages where people have done this
(and similar but worse things). Don't propagate the bad advice.

I discovered (by trial and error)

Not always the best way to discover things.

that placing the <FORM> inside one of
your cells or rows would lead most browsers to dump some inexplicable
extra space somewhere, usually at the end of the last cell on the first
row.

It's not inexplicabe, it's just a bottom margin in the quirks mode
stylesheet put there probably for compatibility with older browsers.

Get rid of it with form { margin-bottom: 0 } as explained in an earlier
post.

See also http://www.cs.tut.fi/~jkorpela/forms/tables.html

 

[walosaw]

Hello all,

I have the following simple html how can I display the second table
content like the first one. As i have add the <form>payment</form>
tag. Any method to remove the spacing.

<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | payment]</td>
</tr>
</table>

<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>[history | <form>payment</form>]</td>
</tr>
</table>

Thx,

Wing

This is a quck fix though it would be better to have all your style
sheet code in a seperate css file
change
<td>[history | <form>payment</form>]</td>
to
<td>[history | <form style="display:inline">payment</form>]</td>

Cheers

 

[Steve Swift]

It is like making a casserole really, anything goes eh?

Precisely! And if, on occasions, you make a mistake (as my mother
frequently did), and the result is tastier, that becomes your new
recipe! http://www.swiftys.org.uk/wiz?106
Perhaps next time I'll say "Add a soupçon of closing tags"

Remember, the only "standard" that I'm designing to (in my commercial
activity, at least) is "Must work in IE6 and the current Firefox", so
pragmatic design outweighs hypothetical stuff. So the <FORM> tag goes
(a) where it works, and (b) where it causes none of my target audience
to get weird effects, then I move on to something else.

As far as Microsoft and the Firefox developers are concerned, I should
imagine one of their highest priorities is "Mustn't screw up legacy
pages with new releases otherwise the customers will switch to the
competition" so I'm happy they're looking after me.

 

[dorayme]

It is like making a casserole really, anything goes eh?

Precisely! And if, on occasions, you make a mistake (as my mother
frequently did), and the result is tastier, that becomes your new
recipe! http://www.swiftys.org.uk/wiz?106
Perhaps next time I'll say "Add a soupçon of closing tags"

Remember, the only "standard" that I'm designing to (in my commercial
activity, at least) is "Must work in IE6 and the current Firefox", so
pragmatic design outweighs hypothetical stuff. So the <FORM> tag goes
(a) where it works, and (b) where it causes none of my target audience
to get weird effects, then I move on to something else.
[/QUOTE]

Oh you rebel you!

 

[rf]

Precisely! And if, on occasions, you make a mistake (as my mother
frequently did), and the result is tastier, that becomes your new recipe!
http://www.swiftys.org.uk/wiz?106
Perhaps next time I'll say "Add a soupçon of closing tags"

Remember, the only "standard" that I'm designing to (in my commercial
activity, at least) is "Must work in IE6 and the current Firefox", so
pragmatic design outweighs hypothetical stuff. So the <FORM> tag goes (a)
where it works, and (b) where it causes none of my target audience to get
weird effects, then I move on to something else.

You may wish to look at this:
http://barefile.com.au/dumpdom.html

This merely dumps (rather crudey) the DOM for the page.

The page is basically what you presented earlier, a couple of invalid tables
like:
<table>
<form action='dumpdom.html' method=get>
<tr><td>
<input type=text name=textfield>
<input type=submit name=subbutton>
</td></tr>
</form>
</table>

Use IE first. You will see that the (generated) <tbody> is a child of the
<form> and so the input elements are also decendents of the form. So
everything "works as expected". IE has ignored your error.

However now use FF. You will see that the <tbody> is now not a child of the
form. In fact the form has been "closed" before the <tbody>. The input
elements are no longer decendants of the <form>. FF has "corrected" your
error. The fact that the "forms" are actually submitted is quite strange. FF
must be internally keeping some alternate representation of the page to
cater for just this error. It is, after all, a quite common one. FWIW opera
and Windows safari do the same thing. Hmmm, I wonder what happens if one
converts to and serves up the above as XHTML

As far as Microsoft and the Firefox developers are concerned, I should
imagine one of their highest priorities is "Mustn't screw up legacy pages
with new releases otherwise the customers will switch to the competition"
so I'm happy they're looking after me.

With that approach you will eventually get bitten in the arse by something
you coded so sloppily years ago. In fact you have already been bitten, you
just don't know it yet.

See that "count" button? It finds the first form and alerts the number of
children that form element has. IE reports this to be 1. Yep, that <tbody>.
You could construct some javascript to drill down from the form element and
find all the, say, input elements and do something to them, like perhaps
validate them. All OK when you test this with IE.

Now swap to FF. FF reports (correctly) that the form element has 0 (zero)
children. Your validation code will silently fail (having found zero input
elements) and you will be scratching your head for days trying to figure out
why, unless you had previously looked at my aforementioned page and really
knew what was happening in the DOM.

Bite Bite

 

[Ben C]

The page is basically what you presented earlier, a couple of invalid tables
like:
<table>
<form action='dumpdom.html' method=get>
<tr><td>
<input type=text name=textfield>
<input type=submit name=subbutton>
</td></tr>
</form>
</table>

Use IE first. You will see that the (generated) <tbody> is a child of the
<form> and so the input elements are also decendents of the form. So
everything "works as expected". IE has ignored your error.

However now use FF. You will see that the <tbody> is now not a child of the
form. In fact the form has been "closed" before the <tbody>. The input
elements are no longer decendants of the <form>. FF has "corrected" your
error. The fact that the "forms" are actually submitted is quite strange. FF
must be internally keeping some alternate representation of the page to
cater for just this error.

I think that's right. It appears to close the form immediately, and also
makes it display: none (otherwise CSS anonymous table boxes would be
generated all over the place). Then it leaves the form contents where
they are for the purposes of layout, but for the purposes of submitting
them, associates them with something like "the most recently-seen
buggered-up form".

It is, after all, a quite common one.

I know, and all because of a harmless and easily-overridden bottom
margin.

 

[still me]

Bite Bite

Comments on the below? I see that IE and FF count the children
differently, but is it invalid ?

<form id=form1 action='dumpdom.html' method=get>
<table>

<tr><td>
<input type=text name=textfield1>
<input type=submit name=subbutton1>

<button onclick='childcount()'>count</button>
</td></tr>

</table>
</form>

 

[rf]

Comments on the below? I see that IE and FF count the children
differently, but is it invalid ?

<form id=form1 action='dumpdom.html' method=get>
<table>

<tr><td>
<input type=text name=textfield1>
<input type=submit name=subbutton1>

<button onclick='childcount()'>count</button>
</td></tr>

</table>
</form>

FF sticks in a text node for each line feed at the end of those lines up
there. IE doesn'nt. If you visit the FF site there is a discussion about
this in the bit where they talk about the diferences between FF and IE.

 

[Ben C]

Comments on the below? I see that IE and FF count the children
differently, but is it invalid ?

It is valid.

 

[pidipady]

Place the closing '</form>' at the bottom of your web page just before
the '</body>' tag

Pidipady || http://www.pickpatterns.com

 

[Ben C]

Place the closing '</form>' at the bottom of your web page just before
the '</body>' tag

No, always place the closing </form> where it belongs. Remove the
spacing by setting margin-bottom on the form element to 0.

 

[André Gillibert]

Precisely! And if, on occasions, you make a mistake (as my mother
frequently did), and the result is tastier, that becomes your new
recipe! http://www.swiftys.org.uk/wiz?106

Funny. Posting on comp.infosystems.www.authoring.html some invalid code
that displays correctly because of bugs in specific HTML renderers is as
ridiculous as posting on talk.grammar.english an awful grammar error,
claiming that it's fine because Microsoft Word's grammar check feature
doesn't find it.

Remember, the only "standard" that I'm designing to (in my commercial
activity, at least) is "Must work in IE6 and the current Firefox"

What will happen when FF and IE6 will upgrade?

As far as Microsoft and the Firefox developers are concerned, I should
imagine one of their highest priorities is "Mustn't screw up legacy
pages with new releases otherwise the customers will switch to the
competition"

Wrong.
For FF, it's: "Respect standards better".
Standards are hard enough to respect. Respecting cr*p code is secondary,
especially when a parser change increase the standards support but affects
cr*p code (as any parser change does).
Even if there're a few cr*ppy tricks that are well known and that browsers
try to respect, your FORM thing is surely not in this list.
If would be foolish to think that any tester will ever notice that your
cr*p is broken by the new version of FF or IE, unless your site is in of
the top 50 of all web sites.
If your site was in the top 50, then, maybe, IE (but probably not FF)
would try to keep compatibility with your cr*p, at the cost of good
insults aimed at your person, in Microsoft's labs (you can imagine them
yourself), and maybe other tradeoffs in IE, such as reduced performances
and standards conformance.
Overall, you're specifically the type of guy who slow down the
standardization of browsers, increase the number of patches and hacks in
browsers, destroy the Web's openness by preventing alternative browsers
from having any chance of displaying your cr*p, breaks the Web from user
point of view by displaying stupid messages "You must have IE 6.01 beta
3.4 + beta patch 1 or FF 1.5 beta 8 to see this site, but you've IE 6.01
beta 3.5".

so I'm happy they're looking after me.

They're not. They cannot review all the cr*p code in the world. Actually,
they cannot even manage to get a perfect standards conformance, which is
orders of magnitude easier than maintaining compatibility with all the
cr*p that exist in the world.

 

[still me]

Overall, you're specifically the type of guy who slow down the
standardization of browsers, increase the number of patches and hacks in
browsers, destroy the Web's openness by preventing alternative browsers
from having any chance of displaying your cr*p, breaks the Web from user
point of view by displaying stupid messages

Wow, he had all that effect just by posting a web page with misplaced
form tags? That's some serious power!