How to remove the spacing between <form> tag?

In article <471998b9$1 (AT) news (DOT) greennet.net>,
Steve Swift <Steve.J.Swift (AT) gmail (DOT) com> wrote:

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.

Oh you rebel you!

--
dorayme

On 2007-10-19, Steve Swift <Steve.J.Swift (AT) gmail (DOT) com> wrote:

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.

So do you think Microsoft and Mozilla test every new release
specifically against www.swiftys.org.uk and all the other pages you've
ever authored, and if they find a single pixel has moved, they put some
of the bugs back in?

"Steve Swift" <Steve.J.Swift (AT) gmail (DOT) com> wrote

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.

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 :-)

--
Richard.

On 2007-10-19, rf <rf (AT) invalid (DOT) com> wrote:
[...]

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" <wheeledBob (AT) yahoo (DOT) com> wrote

On Fri, 19 Oct 2007 07:18:26 GMT, "rf" <rf (AT) invalid (DOT) com> wrote:

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

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.

--
Richard.

On 2007-10-19, still me <wheeledBob (AT) yahoo (DOT) com> wrote:

On Fri, 19 Oct 2007 07:18:26 GMT, "rf" <rf (AT) invalid (DOT) com> wrote:

Bite Bite :-)

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

It is valid.

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

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

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

On 2007-10-22, pidipady <hastover (AT) gmail (DOT) com> wrote:

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.

Steve Swift wrote:

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

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.

--
If you've a question that doesn't belong to Usenet, contact me at
<tabkanDELETETHISnaz (AT) yahoDELETETHATo (DOT) fr>

In article <ggr4i3dlrldm10k0kik8lnqa4magrugblk (AT) 4ax (DOT) com>,
still me <wheeledBob (AT) yahoo (DOT) com> wrote:

On Thu, 25 Oct 2007 00:12:44 +0200, "André Gillibert"
tabkanDELETETHISnaz (AT) yahodeletethato (DOT) fr> wrote:

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!

No, I think Andre meant that websites that the poster makes, and
those from like minded authors, have the unwanted effect. That
might be a fair point, no? It is like burning coal in private
house chimneys, one house is no likely to cause trouble, but like
minded occupants in lots of other houses doing the same will have
a bad effect.

--
dorayme