Forms in table cells modify cell height - grrr

Forms in table cells modify cell height - grrr

am 06.07.2007 23:34:48 von Tim Streater

I post an example here which is giving me ulcers. I've cut it down to
the minimum possible to illustrate the problem.

There are two tables. In the first, the rows with the buttons render
with extra space at the bottom of the cell, below the text area and the
button. Why is this space there and how do I get rid of it? I sort of
succeed in this with the second table, but I have to delete the s
to achieve it.

Under OS X, Safari and Firefox give me the extra space in every row of
the first table, Safari gives none in the second while Firefox only
gives none for buttons 5 and 6. IE renders both tables identically.

Under XP I only tried Firefox and it appears to behave the same as on
the Mac.

I cut down the style sheet referred to and it now contains just:

..mtext {FONT: 11px verdana,tahoma,arial; color: #000000;}

Any clue about how to remove the unwanted space appreciated. If there
are better ways of doing this I can store that up and try to apply it
later.

Thanks -- tim


====== start of html =====



















some text
value='1'>
value='2'>
value='3'>

















some text


Re: Forms in table cells modify cell height - grrr

am 06.07.2007 23:55:25 von Adrienne Boswell

Gazing into my crystal ball I observed Tim Streater
writing in news:timstreater-
E9D5D5.22344806072007@individual.net:

> I post an example here which is giving me ulcers. I've cut it down to
> the minimum possible to illustrate the problem.

A URL would be much better, but...

>
> There are two tables. In the first, the rows with the buttons render
> with extra space at the bottom of the cell, below the text area and the
> button. Why is this space there and how do I get rid of it? I sort of
> succeed in this with the second table, but I have to delete the
s
> to achieve it.

Form is a block element. If you want to use a table with form you have
to put the form element outside the table element.

>
> Under OS X, Safari and Firefox give me the extra space in every row of
> the first table, Safari gives none in the second while Firefox only
> gives none for buttons 5 and 6. IE renders both tables identically.
>
> Under XP I only tried Firefox and it appears to behave the same as on
> the Mac.

Again, a URL would be helpful.

>
> I cut down the style sheet referred to and it now contains just:
>
> .mtext {FONT: 11px verdana,tahoma,arial; color: #000000;}

You know, don't you that IE can't resize pixels, and are you sure that
11px is going to be large enough for me to see?

>
> Any clue about how to remove the unwanted space appreciated. If there
> are better ways of doing this I can store that up and try to apply it
> later.
>

Yes, get rid of the tables and use the right tool for the job - label
elments and CSS.

>
>====== start of html =====
>
>

No DocType?

>
>

No title element? How am I supposed to know where I am?

>
>
>


>
>
>
>
>



>
>
>
>
>
>
>
>
some text


What is the action of the form? What is the method of the form?



What is the name of this input element. Form contents are sent in
name/value pairs.

> value='1'>

Seems this might need some client side script to work. See
http://www.w3.org/TR/html401/interact/forms.html#push-button .

> value='2'>
> value='3'>

>
>



What's this? Two empty paragraphs? Why? If you need spacing put it in
the bottom margin of the preceding element.

>
>


>
>
>
>
>
>
>
>
>
>
>
>
>
some text




>
>
>

So, now my question becomes - what the heck are you trying to do here?
None of these forms have actions or methods. No names for the input
elements, so no way to send name/value pairs.

If you want to have a nice looking form that lines up the elements, use
labels and CSS. An example is here:
http://intraproducts.com/usenet/requiredform.asp . This can be easily
ported to PHP, or any other server side language, and the HTML/CSS are
all there to see.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 01:16:20 von Ben C

On 2007-07-06, Tim Streater wrote:
> I post an example here which is giving me ulcers. I've cut it down to
> the minimum possible to illustrate the problem.
>
> There are two tables. In the first, the rows with the buttons render
> with extra space at the bottom of the cell, below the text area and the
> button. Why is this space there and how do I get rid of it? I sort of
> succeed in this with the second table, but I have to delete the s
> to achieve it.

Please, no!

Common sense should tell you that if you are deliberately making the
HTML invalid then you are going in the wrong direction.

> Under OS X, Safari and Firefox give me the extra space in every row of
> the first table, Safari gives none in the second while Firefox only
> gives none for buttons 5 and 6. IE renders both tables identically.

Firefox in quirks mode gives form a bottom margin of about 0.5em.

You can fix your problem in two ways, of which you should do at least
the second and possibly both:

form { margin: 0 }

in the styles

or use the strict mode doctype, i.e. put this right at the top of every
document:

"http://www.w3.org/TR/REC-html40/strict.dtd">

Do that anyway-- if you don't you get quirks mode, which is full of
annoying and surprising quirks like that bottom margin on forms. You
might call it ulcers mode.

I saw this problem on some of the admin pages that my embedded
router/modem thing produces. The author of those had "solved" the
problem by applying a top margin of -15px to the next element in the
document!

Even worse someone suggested on one of these NGs the other day "fixing"
the same problem by using broken form/table structure. It seems you were
starting to circle the same drain. I wonder how many of the broken
forms/tables I see every day on the web are caused by people trying
anything to make that bottom margin go away.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 01:23:59 von Tim Streater

In article ,
Adrienne Boswell wrote:

> Gazing into my crystal ball I observed Tim Streater
> writing in news:timstreater-
> E9D5D5.22344806072007@individual.net:
>
> > I post an example here which is giving me ulcers. I've cut it down to
> > the minimum possible to illustrate the problem.
>
> A URL would be much better, but...
>
> >
> > There are two tables. In the first, the rows with the buttons render
> > with extra space at the bottom of the cell, below the text area and the
> > button. Why is this space there and how do I get rid of it? I sort of
> > succeed in this with the second table, but I have to delete the
> s
> > to achieve it.
>
> Form is a block element. If you want to use a table with form you have
> to put the form element outside the table element.

See below.

> > Under OS X, Safari and Firefox give me the extra space in every row of
> > the first table, Safari gives none in the second while Firefox only
> > gives none for buttons 5 and 6. IE renders both tables identically.
> >
> > Under XP I only tried Firefox and it appears to behave the same as on
> > the Mac.
>
> Again, a URL would be helpful.
>
> >
> > I cut down the style sheet referred to and it now contains just:
> >
> > .mtext {FONT: 11px verdana,tahoma,arial; color: #000000;}
>
> You know, don't you that IE can't resize pixels, and are you sure that
> 11px is going to be large enough for me to see?

This is taken from the front end of our assets database that helps us to
manage our Europe-wide network. No complaints about this so far. I doubt
if any of our user base is using IE, although obviously I test what I am
doing against it.

> >
> > Any clue about how to remove the unwanted space appreciated. If there
> > are better ways of doing this I can store that up and try to apply it
> > later.
> >
>
> Yes, get rid of the tables and use the right tool for the job - label
> elments and CSS.

I want to know what's going on. If there's a better technique I can look
at that in parallel. For the moment that's not relevant.

> >
> >====== start of html =====
> >
> >
>
> No DocType?

I indicated above that I cut this example down to the bare minimum of
text to demonstrate my issue.

> >
> >
>
> No title element? How am I supposed to know where I am?

See above.

> >
> >
> >


> >
> >
> >
> >
> >
some text

>
> What is the action of the form? What is the method of the form?

[snip childish twaddle interspersed with my example]

> So, now my question becomes - what the heck are you trying to do here?
> None of these forms have actions or methods. No names for the input
> elements, so no way to send name/value pairs.

You do know what the word "example" means, do you? None of your foolish
comments are germane to the issue.

Oh gee, no action attribute for the form? No method? No names to the
input elements? No action script for the buttons? Well duh! Silly me! I
guess the HTML and Javascript books on my desk aren't meant to be
doorstops after all.

> If you want to have a nice looking form that lines up the elements, use
> labels and CSS. An example is here:
> http://intraproducts.com/usenet/requiredform.asp . This can be easily
> ported to PHP, or any other server side language, and the HTML/CSS are
> all there to see.

Hmm, doesn't look much different to the many forms I already have
implemented using mysql, PHP, and Javascript.

If you mean that putting a form inside a table cell gives unpredictable
results then say so. That would have been useful. Otherwise next time
try to keep your snide remarks to yourself.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 01:45:38 von Tim Streater

In article ,
Ben C wrote:

> On 2007-07-06, Tim Streater wrote:
> > I post an example here which is giving me ulcers. I've cut it down to
> > the minimum possible to illustrate the problem.
> >
> > There are two tables. In the first, the rows with the buttons render
> > with extra space at the bottom of the cell, below the text area and the
> > button. Why is this space there and how do I get rid of it? I sort of
> > succeed in this with the second table, but I have to delete the s
> > to achieve it.
>
> Please, no!

:-)

Hey, I didn't say I was *happy* about that. That was just the result of
some experimenting.

> Common sense should tell you that if you are deliberately making the
> HTML invalid then you are going in the wrong direction.

Yes. I gave up testing at that point and sought help. This came up
because I have a page with a list of open trouble tickets displayed,
where our NOC hasn't recently updated them. Many of these are for future
network maintenance and so it would be nice to flag them in the database
so they don't show. The list is just a table and I added a cell in each
row containing a form with a button to submit the form - and BOOM!
suddenly each row was rather taller. A bit ugly.

> > Under OS X, Safari and Firefox give me the extra space in every row of
> > the first table, Safari gives none in the second while Firefox only
> > gives none for buttons 5 and 6. IE renders both tables identically.
>
> Firefox in quirks mode gives form a bottom margin of about 0.5em.
>
> You can fix your problem in two ways, of which you should do at least
> the second and possibly both:
>
> form { margin: 0 }
>
> in the styles
>
> or use the strict mode doctype, i.e. put this right at the top of every
> document:
>
> > "http://www.w3.org/TR/REC-html40/strict.dtd">

I'll look into that. Some of my pages may have that but almost certainly
not all.

> Do that anyway-- if you don't you get quirks mode, which is full of
> annoying and surprising quirks like that bottom margin on forms. You
> might call it ulcers mode.
>
> I saw this problem on some of the admin pages that my embedded
> router/modem thing produces. The author of those had "solved" the
> problem by applying a top margin of -15px to the next element in the
> document!
>
> Even worse someone suggested on one of these NGs the other day "fixing"
> the same problem by using broken form/table structure. It seems you were
> starting to circle the same drain. I wonder how many of the broken
> forms/tables I see every day on the web are caused by people trying
> anything to make that bottom margin go away.

OK. So are you saying that I shouldn't put a

inside a table cell?
I want to have an action button in my table row. I want to have valid
html though, as in my experience hacks will bite you sooner or later. I
made each cell have its own form, because I couldn't find in any of the
docs I have whether a form can be submitted by any one of several
buttons. All the examples I ever saw only had one button, and the docs
didn't appear to cover the point.

Thanks for your help.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 02:02:13 von Adrienne Boswell

Gazing into my crystal ball I observed Tim Streater
writing in
news:timstreater-681394.00235907072007@individual.net:

> In article ,
> Adrienne Boswell wrote:
>
>> Gazing into my crystal ball I observed Tim Streater
>> writing in news:timstreater-
>> E9D5D5.22344806072007@individual.net:
>>
>> > .mtext {FONT: 11px verdana,tahoma,arial; color: #000000;}
>>
>> You know, don't you that IE can't resize pixels, and are you sure
>> that 11px is going to be large enough for me to see?
>
> This is taken from the front end of our assets database that helps us
> to manage our Europe-wide network. No complaints about this so far. I
> doubt if any of our user base is using IE, although obviously I test
> what I am doing against it.

And hopefully, it's in an external stylesheet that the browser can cache.

>
>> >
>> > Any clue about how to remove the unwanted space appreciated. If
>> > there are better ways of doing this I can store that up and try to
>> > apply it later.
>> >
>>
>> Yes, get rid of the tables and use the right tool for the job - label
>> elments and CSS.
>
> I want to know what's going on. If there's a better technique I can
> look at that in parallel. For the moment that's not relevant.
>

If you want to know what's going on, the best thing to do is to separate
content from presentation. So, you could say in CSS:

form {margin-bottom:1em}

>> >
>> >====== start of html =====
>> >
>> >
>>
>> No DocType?
>
> I indicated above that I cut this example down to the bare minimum of
> text to demonstrate my issue.
>
>> >
>> >
>>
>> No title element? How am I supposed to know where I am?
>
> See above.
>
>> >
>> >
>> >


>> >
>> >
>> >
>> >
>> > .

Then set margin:0 on form to lose that bottom margin and you should have
no problems.

> I want to have an action button in my table row. I want to have valid
> html though, as in my experience hacks will bite you sooner or later. I
> made each cell have its own form, because I couldn't find in any of the
> docs I have whether a form can be submitted by any one of several
> buttons. All the examples I ever saw only had one button, and the docs
> didn't appear to cover the point.

Not sure if you can have multiple submit buttons in a single form or
not.

http://www.cs.tut.fi/~jkorpela/forms/tables.html might also be worth a
look.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 11:21:18 von dorayme

In article ,
Ben C wrote:

> Not sure if you can have multiple submit buttons in a single form or
> not.
>
> http://www.cs.tut.fi/~jkorpela/forms/tables.html might also be worth a
> look.

Whenever I have to do a form, I find myself often enough looking
into Korpela's kitchen on this... one day I will let him see one
of my forms.

--
dorayme

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 14:08:38 von jkorpela

Scripsit Ben C:

> Firefox in quirks mode gives form a bottom margin of about 0.5em.

That's an interesting observation to be added to my little page on what may
happen in Quirks Mode, http://www.cs.tut.fi/~jkorpela/quirks-mode.html

But on my Firefox 2, under Win XP, the margin appears to be rather exactly
1em. Actually, that's the value set at the end of the CSS file that
purportedly describes many of the features of Quirks Mode in Firefox:

/* Quirk: give form margin for compat (b=41806) */
form{
margin: 0 0 1em 0;
}

( http://lxr.mozilla.org/seamonkey/source/layout/style/quirk.c ss )

It's presumably meant to continue the tradition of web browsers to leave
that much spacing below a form. It used to be a frequently asked question
how to get rid of it, especially in the old days when CSS was poorly
supported, and different tricks were often suggested, often creating much
bigger problems than the original one. Nowadays, of course,

> form { margin: 0 }

solves the problem.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 14:47:40 von Tim Streater

In article ,
Adrienne Boswell wrote:

> Gazing into my crystal ball I observed Tim Streater
> writing in news:timstreater-
> C4D85E.00453807072007@individual.net:
>
> > I
> > made each cell have its own form, because I couldn't find in any of the
> > docs I have whether a form can be submitted by any one of several
> > buttons. All the examples I ever saw only had one button, and the docs
> > didn't appear to cover the point.
> >
> >
>
> A form can have umpteen submit buttons.

Thanks, that's useful to know. Despite possible appearances :-) I am
keen to have stuff which is as standard as possible.

> It's a matter of the server side
> script to sort it all out. But... again, important to name the submit
> buttons, so when the script _does_ get the information, it knows which
> one did the submitting (if that's important to your script).
>
> So:
>
>

> ...various form elements...
>
> ...more interesting elements...
>
>
>
> Then you will get either sub1/Submit or sub2/Submit in your form
> collection.

Right, I always use unique names anyway. SO far I've avoided having more
than one submit so I'll have to think through the implications there for
passing data.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 14:50:35 von Tim Streater

In article <5f84q8F3b9p09U1@mid.individual.net>,
Bergamot wrote:

> Adrienne Boswell wrote:
> >
> >
> > ...more interesting elements...
> >
> >
> > Then you will get either sub1/Submit or sub2/Submit in your form
> > collection.
>
> Alternately, use the same name and assign different values. This gives
> you a means to easily do switch/case processing.

That might well be useful in some cases. Mostly my values come from our
database so wouldn't be suitable, however.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 16:26:34 von Ben C

On 2007-07-07, Jukka K. Korpela wrote:
> Scripsit Ben C:
>
>> Firefox in quirks mode gives form a bottom margin of about 0.5em.
>
> That's an interesting observation to be added to my little page on what may
> happen in Quirks Mode, http://www.cs.tut.fi/~jkorpela/quirks-mode.html
>
> But on my Firefox 2, under Win XP, the margin appears to be rather exactly
> 1em. Actually, that's the value set at the end of the CSS file that
> purportedly describes many of the features of Quirks Mode in Firefox:
>
> /* Quirk: give form margin for compat (b=41806) */
> form{
> margin: 0 0 1em 0;
> }

Yes, you're right it is 1em. While investigating it the first time,
Firebug showed the "computed style" to be 15px, but increasing the font
size increased the margin, and after a bit of trial and error it seemed
to be 1em.

I did make a note of it but couldn't remember what it was which is why I
said "about 0.5em".

> ( http://lxr.mozilla.org/seamonkey/source/layout/style/quirk.c ss )

Thanks for the link.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 18:33:46 von Tim Streater

In article ,
Adrienne Boswell wrote:

> Gazing into my crystal ball I observed Tim Streater

[snip]

> Actually, that all is very important. Browsers do different things when
> required attributes are missing.

Even in terms of rendering, you mean?

> Both action and method are required attributes.

Hmm, I understood action to be optional. And that without it, the
default action was that the same form reloaded. Additionally, I could
well want to go to different places depending on the button pushed or
the data that the form passes off to some Javascript. I don't want to
show an action that will never be taken - that just confuses whoever
follows me on the code. I could imagine something like
action="none" ... > to make this explicit but can;t recall ever having
seen such an option.

> >> So, now my question becomes - what the heck are you trying to do
> >> here? None of these forms have actions or methods. No names for the
> >> input elements, so no way to send name/value pairs.
> >
> > You do know what the word "example" means, do you? None of your
> > foolish comments are germane to the issue.
>
> I suggest you read the specs then. I also suggest next time you supply a
> URL.

Difficult to do from home, as it happens.

> > Oh gee, no action attribute for the form? No method? No names to the
> > input elements? No action script for the buttons? Well duh! Silly me!
> > I guess the HTML and Javascript books on my desk aren't meant to be
> > doorstops after all.
>
> By your original post, no one knows whether or not you know if these
> things are required or not -- again, another good reason to supply a URL.

Yes, I see that - but I did try to emphasise that I had cut down the
example to the minimum required to demonstrate my problem. I have seen,
in other groups, people post 1000 lines of code and ask why it doesn't
work, with no explanation, and having done no work to isolate the
matter. In my experience, working to isolate the problem makes most of
them obvious.

Having spent a couple of hours late at work reading my HTML/JS books
yesterday and making a simple example, I then continued at home. Only
there did I notice that I had inadvertently left out a in one
place. Putting that back changed things. This was the point at which,
with a concise example behaving in a loopy fashion, that I sought
assistance.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 18:33:52 von Tim Streater

In article ,
Ben C wrote:

> On 2007-07-06, Tim Streater wrote:
> > In article ,
> > Ben C wrote:
> [...]
> >> Firefox in quirks mode gives form a bottom margin of about 0.5em.
> >>
> >> You can fix your problem in two ways, of which you should do at least
> >> the second and possibly both:
> >>
> >> form { margin: 0 }
> >>
> >> in the styles
> >>
> >> or use the strict mode doctype, i.e. put this right at the top of every
> >> document:
> >>
> >> > >> "http://www.w3.org/TR/REC-html40/strict.dtd">
> [...]
> >> Even worse someone suggested on one of these NGs the other day "fixing"
> >> the same problem by using broken form/table structure. It seems you were
> >> starting to circle the same drain. I wonder how many of the broken
> >> forms/tables I see every day on the web are caused by people trying
> >> anything to make that bottom margin go away.
> >
> > OK. So are you saying that I shouldn't put a
inside a table cell?
>
> Not at all, inside

.
>
> Then set margin:0 on form to lose that bottom margin and you should have
> no problems.

Funnily enough I tried this at work before going home (my posts to this
group were from home late Fri evening). I must have formatted it
incorrectly somehow as it appeared to have no effect.

The doctype makes Firefox behave, but not Safari, but the margin:0 sorts
out Safari too.

> > I want to have an action button in my table row. I want to have valid
> > html though, as in my experience hacks will bite you sooner or later. I
> > made each cell have its own form, because I couldn't find in any of the
> > docs I have whether a form can be submitted by any one of several
> > buttons. All the examples I ever saw only had one button, and the docs
> > didn't appear to cover the point.
>
> Not sure if you can have multiple submit buttons in a single form or
> not.
>
> http://www.cs.tut.fi/~jkorpela/forms/tables.html might also be worth a
> look.

Thanks for your help and these links - most informative. Everyone's
contributions of "further reading" links are much appreciated.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 19:54:27 von jkorpela

Scripsit Tim Streater:

>> Both action and method are required attributes.
>
> Hmm, I understood action to be optional.

There's some confusion here. In a
element, the method="..." attribute
is and always was optional, with the default value being "GET". The
action="..." attribute is required, and it has been required ever since HTML
4.0.

> And that without it, the
> default action was that the same form reloaded.

Well, the same _page_. In HTML 3.2, the action="..." attribute was optional,
with the default value being the URL of the page on which the form appears.
Browsers might still behave that way, but it's not a good idea to use
invalid markup and to rely on behavior that is holdover from some previous
version.

> Additionally, I could
> well want to go to different places depending on the button pushed or
> the data that the form passes off to some Javascript.

You might want that, but can you do that reliably?

> I don't want to
> show an action that will never be taken - that just confuses whoever
> follows me on the code. I could imagine something like > action="none" ... > to make this explicit but can;t recall ever having
> seen such an option.

There is no such option. By HTML versions from HTML 4.0 onwards, the meaning
of a form element is undefined unless it has an action attribute with a http
URL.

If a form exists only for the purpose of JavaScript-based interaction, then
the form, and perhaps the entire page, should be JavaScript-generated so
that it does not appear when it does not work. Even then, a conforming
action="..." attribute _is_ useful. It's a sentinel against errors that may
arise when the form is, after all, used in a browser where scripting is not
enabled. (For example, a page might be generated by JavaScript code but the
user might then disable scripting. To take a less far-fetched example, an
author might just goof things up and e.g. omit the JavaScript code that
prevents normal form submission.)

The sentinel attribute could be action="error.html" where error.html is a
document that explains that an unexpected error occurred. You might write a
longer explanation if you like, but most users probably wouldn't understand
it. What matters is that users are informed about an error, instead of just
weird behavior or everything going well on the surface while everything is
broken.

> Yes, I see that - but I did try to emphasise that I had cut down the
> example to the minimum required to demonstrate my problem. I have
> seen, in other groups, people post 1000 lines of code and ask why it
> doesn't work,

Posting a URL is still the best approach in HTML problems. If you don't have
a URL, create one. It doesn't take that long to compose a valid document and
upload it on a server.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 22:38:14 von lws4art

Tim Streater wrote:
> In article <5f84q8F3b9p09U1@mid.individual.net>,
> Bergamot wrote:
>
>> Adrienne Boswell wrote:
>>>
>>> ...more interesting elements...
>>>
>>>
>>> Then you will get either sub1/Submit or sub2/Submit in your form
>>> collection.
>> Alternately, use the same name and assign different values. This gives
>> you a means to easily do switch/case processing.
>
> That might well be useful in some cases. Mostly my values come from our
> database so wouldn't be suitable, however.

Why would the *source* of the value matter at all, database or
predetermined or otherwise? Maybe stop playing this silly guessing game
of try to debug your *imaginary* code and you put up a *live* example
somewhere, (temp folder on your site, your ISP free webspace, or some
free server) and we can give you some real advice.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 23:12:22 von Bergamot

Tim Streater wrote:
> In article ,
> Adrienne Boswell wrote:
>
>> Browsers do different things when required attributes are missing.
>
> Even in terms of rendering, you mean?

Just look what happens in different browsers when the alt attribute is
omitted from , and images aren't loaded for some reason.

--
Berg

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 23:35:42 von Tim Streater

In article ,
"Jukka K. Korpela" wrote:

> Scripsit Tim Streater:
>
> >> Both action and method are required attributes.
> >
> > Hmm, I understood action to be optional.
>
> There's some confusion here. In a element, the method="..." attribute
> is and always was optional, with the default value being "GET". The
> action="..." attribute is required, and it has been required ever since HTML
> 4.0.
>
> > And that without it, the
> > default action was that the same form reloaded.
>
> Well, the same _page_. In HTML 3.2, the action="..." attribute was optional,
> with the default value being the URL of the page on which the form appears.
> Browsers might still behave that way, but it's not a good idea to use
> invalid markup and to rely on behavior that is holdover from some previous
> version.

Right. If that's invalid then I'll certainly add it.

> > Additionally, I could
> > well want to go to different places depending on the button pushed or
> > the data that the form passes off to some Javascript.
>
> You might want that, but can you do that reliably?
>
> > I don't want to
> > show an action that will never be taken - that just confuses whoever
> > follows me on the code. I could imagine something like > > action="none" ... > to make this explicit but can;t recall ever having
> > seen such an option.
>
> There is no such option. By HTML versions from HTML 4.0 onwards, the meaning
> of a form element is undefined unless it has an action attribute with a http
> URL.

OK.

> If a form exists only for the purpose of JavaScript-based interaction, then
> the form, and perhaps the entire page, should be JavaScript-generated so
> that it does not appear when it does not work. Even then, a conforming
> action="..." attribute _is_ useful. It's a sentinel against errors that may
> arise when the form is, after all, used in a browser where scripting is not
> enabled. (For example, a page might be generated by JavaScript code but the
> user might then disable scripting. To take a less far-fetched example, an
> author might just goof things up and e.g. omit the JavaScript code that
> prevents normal form submission.)
>
> The sentinel attribute could be action="error.html" where error.html is a
> document that explains that an unexpected error occurred. You might write a
> longer explanation if you like, but most users probably wouldn't understand
> it. What matters is that users are informed about an error, instead of just
> weird behavior or everything going well on the surface while everything is
> broken.

Well, I can tell them to contact me, although they know to do that
anyway. The user base is our engineers, our NOC's engineers, and some of
our customers' engineers. They all know who I am.

> > Yes, I see that - but I did try to emphasise that I had cut down the
> > example to the minimum required to demonstrate my problem. I have
> > seen, in other groups, people post 1000 lines of code and ask why it
> > doesn't work,
>
> Posting a URL is still the best approach in HTML problems. If you don't have
> a URL, create one. It doesn't take that long to compose a valid document and
> upload it on a server.

Right, I'll bear that in mind.

Re: Forms in table cells modify cell height - grrr

am 08.07.2007 01:16:47 von dorayme

In article <5fadurF3b4kc3U1@mid.individual.net>,
Bergamot wrote:

> Tim Streater wrote:
> > In article ,
> > Adrienne Boswell wrote:
> >
> >> Browsers do different things when required attributes are missing.
> >
> > Even in terms of rendering, you mean?
>
> Just look what happens in different browsers when the alt attribute is
> omitted from , and images aren't loaded for some reason.

This might illustrate some of the differences:

http://tinyurl.com/34z6kf

--
dorayme

some text

>>
>> What is the action of the form? What is the method of the form?
>
> [snip childish twaddle interspersed with my example]

Actually, that all is very important. Browsers do different things when
required attributes are missing. Both action and method are required
attibutes.

>
>> So, now my question becomes - what the heck are you trying to do
>> here? None of these forms have actions or methods. No names for the
>> input elements, so no way to send name/value pairs.
>
> You do know what the word "example" means, do you? None of your
> foolish comments are germane to the issue.

I suggest you read the specs then. I also suggest next time you supply a
URL.

>
> Oh gee, no action attribute for the form? No method? No names to the
> input elements? No action script for the buttons? Well duh! Silly me!
> I guess the HTML and Javascript books on my desk aren't meant to be
> doorstops after all.

By your original post, no one knows whether of not you know if these
things are required or not -- again, another good reason to supply a URL.

>
>> http://intraproducts.com/usenet/requiredform.asp . This can be
>> easily ported to PHP, or any other server side language, and the
>> HTML/CSS are all there to see.
>
> Hmm, doesn't look much different to the many forms I already have
> implemented using mysql, PHP, and Javascript.
>
> If you mean that putting a form inside a table cell gives
> unpredictable results then say so.

It means to use the right tool for the job. Tables are for tabular data.
They work with forms where you have a lot of data, eg:



















PurchaseTitleDescription
Gone with the Wind Classic story of love in the Civil War
Casablanca Love story set in Casablanca during WWII





>That would have been useful.
> Otherwise next time try to keep your snide remarks to yourself.

Usenet is not a 24/7 help desk. Usenet is for discussion of topics. If
you happen to find a solution to your problem, that's a bonus.


--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 02:08:23 von Adrienne Boswell

Gazing into my crystal ball I observed Tim Streater
writing in news:timstreater-
C4D85E.00453807072007@individual.net:

> I
> made each cell have its own form, because I couldn't find in any of the
> docs I have whether a form can be submitted by any one of several
> buttons. All the examples I ever saw only had one button, and the docs
> didn't appear to cover the point.
>
>

A form can have umpteen submit buttons. It's a matter of the server side
script to sort it all out. But... again, important to name the submit
buttons, so when the script _does_ get the information, it knows which
one did the submitting (if that's important to your script).

So:


....various form elements...

....more interesting elements...



Then you will get either sub1/Submit or sub2/Submit in your form
collection.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 02:24:04 von Bergamot

Adrienne Boswell wrote:
>
>
> ...more interesting elements...
>
>
> Then you will get either sub1/Submit or sub2/Submit in your form
> collection.

Alternately, use the same name and assign different values. This gives
you a means to easily do switch/case processing.

--
Berg

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 06:53:02 von Neredbojias

On Sat, 07 Jul 2007 00:02:13 GMT Adrienne Boswell scribed:

>>That would have been useful.
>> Otherwise next time try to keep your snide remarks to yourself.
>
> Usenet is not a 24/7 help desk. Usenet is for discussion of topics.
> If you happen to find a solution to your problem, that's a bonus.

I will have to remember the karma of that little bit of text up thare ^.
You're cooler than I am.

--
Neredbojias

Q: Do you speak Turkish?
A: Gobble gobble, dude.

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 07:26:34 von Blinky the Shark

Tim Streater wrote:

> If you mean that putting a form inside a table cell gives unpredictable
> results then say so. That would have been useful. Otherwise next time
> try to keep your snide remarks to yourself.

Would you like to apply for a refund?

--
Blinky RLU 297263
Killing all posts from Google Groups
The Usenet Improvement Project: http://blinkynet.net/comp/uip5.html

Re: Forms in table cells modify cell height - grrr

am 07.07.2007 11:07:37 von Ben C

On 2007-07-06, Tim Streater wrote:
> In article ,
> Ben C wrote:
[...]
>> Firefox in quirks mode gives form a bottom margin of about 0.5em.
>>
>> You can fix your problem in two ways, of which you should do at least
>> the second and possibly both:
>>
>> form { margin: 0 }
>>
>> in the styles
>>
>> or use the strict mode doctype, i.e. put this right at the top of every
>> document:
>>
>> >> "http://www.w3.org/TR/REC-html40/strict.dtd">
[...]
>> Even worse someone suggested on one of these NGs the other day "fixing"
>> the same problem by using broken form/table structure. It seems you were
>> starting to circle the same drain. I wonder how many of the broken
>> forms/tables I see every day on the web are caused by people trying
>> anything to make that bottom margin go away.
>
> OK. So are you saying that I shouldn't put a

inside a table cell?

Not at all, inside
is fine, but nest the tags properly--
before
is fine, but nest the tags properly--
> before