Form action= ?

shajnday · Aug 13, 2010

What would form action do?

I had an html tag <form><input .... without the requested atributes
action (and .ev.method="").
This tag is working fine but due to restrictions of XHTML transitional
validation i had to change it to <form action="#"><input..... />
</form>

and it works as it worked before, but now it passes HTML validation.

What is the best to put at action="" atribute and method and what's
the puropeses of these two atributes ?
i don't get the purpose part. ?

Denis McMahon · Aug 13, 2010

What would form action do?

I had an html tag <form><input .... without the requested atributes
action (and .ev.method="").
This tag is working fine but due to restrictions of XHTML transitional
validation i had to change it to <form action="#"><input..... />
</form>

and it works as it worked before, but now it passes HTML validation.

What is the best to put at action="" atribute and method and what's
the puropeses of these two atributes ?
i don't get the purpose part. ?

If your form doesn't have an action (ie it's just a wrapper for input /
textarea / select elements) then why are you using form? You can
dispense with it, as the following shows (validates as direct input with
a charset warning).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Test</title>
<script type="text/javascript">
function clicked(obj)
{
alert(obj.name + " " + obj.id + " " + obj.value);
}
</script>
</head>
<body>
<p>
<input type="text" name="t1" id="t1" size="30"><br>
<select name="s1" id="s1">
<option value="1">one</option>
<option value="2">two</option>
<option value="3">three</option>
</select><br>
<textarea name="a1" id="a1" rows="5" cols="80"></textarea><br>
<input type="button" id="b1" name="b1" value="Reset"
onclick="clicked(this)">
<input type="button" id="b2" name="b2" value="Submit"
onclick="clicked(this)">
</p>
</body>
</html>

If you want input / reset buttons with onclicks to drive your
javascript, just use normal buttons with the values set to "Reset" and /
or "Submit" and use their onclick handlers instead. If you're using the
form name to refer to elements, switch to document.getElementById().

Rgds

Denis McMahon

Jonathan N. Little · Aug 13, 2010

Denis said:
If your form doesn't have an action (ie it's just a wrapper for input /
textarea / select elements) then why are you using form? You can
dispense with it, as the following shows (validates as direct input with
a charset warning).

Well not necessarily, it all depends on that the OP is doing with these
controls.

If all you are doing using controls to interact with some JavaScript,
then yes you can dispense with the form element. But if the OP intends
to submit data either via GET or POST then:

A form element *is* required
The the controls must be inside form element
The controls must have name attributes
The form must have a valid action attribute

See <www.w3.org/TR/html401/interact/forms.html#successful-controls>

Browsers will summit a form to the URI of the current document if the
action attribute is not default, but they are not obligated to because
the condition is "undefined" See that action is a required
attribute with a valid URI else the condition is "undefined" under
"Attribute Definitions"

<http://www.w3.org/TR/html401/interact/forms.html#edef-FORM>

Denis McMahon · Aug 13, 2010

Denis McMahon wrote:

If all you are doing using controls to interact with some JavaScript,
then yes you can dispense with the form element. But if the OP intends
to submit data either via GET or POST then:

The whole point of the OPs post, as I understood it, was to find some
pseudo-value to use for the action field so that the html would
validate, that kind of suggests to me that he's not actually submitting
the form.

Because if he was actually submitting the form, I'd expect him to have a
real action value and not need some pseudo-value to get the page to
validate.

Rgds

Denis McMahon

dorayme · Aug 14, 2010

Denis McMahon said:
The whole point of the OPs post, as I understood it, was to find some
pseudo-value to use for the action field so that the html would
validate, that kind of suggests to me that he's not actually submitting
the form.

Possibly, but he might be just testing or making a template and
feels uncomfortable with it lazily lying about invalid.

William Gill · Aug 14, 2010

The whole point of the OPs post, as I understood it, was to find some
pseudo-value to use for the action field so that the html would
validate, that kind of suggests to me that he's not actually submitting
the form.

I suspect the OP, and many others have a misconception of what exactly
validation is.

I'm sure Yucca will correct me if I misstate it, but validation checks
that a document conforms precisely to the structure defined by a
particular DTD. Much like a spell checker validates that words in a
document conform to a particular dictionary. So if I use a term that
means something to an audience, but not necessarily to the dictionary
(i.e. fubar = f'ed up beyond all recognition), the spell checker will
point out the "validation error." At that point I can add fubar to the
dictionary, or recognize the "error" is deliberate and ignore it.
Similarly, when validating against a particular DTD, and I get a
validation error that was deliberate, I can ignore it or create a
modified version of the DTD that matches the variation. The inherent
risk is that if I leave the "error" in the document, then ask an
application (i.e. a browser) that relies on the original DTD (or even my
modified version) to parse the document I don't know how it will react
to the non-conforming entry, and how it reacts today may not be how it
will react after the next update.

The value of validation is finding all the unintentional deviations.

shajnday · Aug 14, 2010

I suspect the OP, and many others have a misconception of what exactly
validation is.

I'm sure Yucca will correct me if I misstate it, but validation checks
that a document conforms precisely to the structure defined by a
particular DTD. Much like a spell checker validates that words in a
document conform to a particular dictionary. So if I use a term that
means something to an audience, but not necessarily to the dictionary
(i.e. fubar = f'ed up beyond all recognition), the spell checker will
point out the "validation error." At that point I can add fubar to the
dictionary, or recognize the "error" is deliberate and ignore it.
Similarly, when validating against a particular DTD, and I get a
validation error that was deliberate, I can ignore it or create a
modified version of the DTD that matches the variation. The inherent
risk is that if I leave the "error" in the document, then ask an
application (i.e. a browser) that relies on the original DTD (or even my
modified version) to parse the document I don't know how it will react
to the non-conforming entry, and how it reacts today may not be how it
will react after the next update.

The value of validation is finding all the unintentional deviations.

I have put astray the form element as i have thought that it is the
necessary block element in which goes input...
As i had thought that the form element is a process element of some
kind and that it does some important actions so as when submitting
button to print or to close a page. I checked(what previously did not
came to my mind) and left only the input element and it works the
same. Validation shows pass!

One another thing was strange which made me to leave the form element
at first, when i submited the close button i sometimes got the "Are
you sure you want to close this window?"question, for which i had
thoughts that is the action of form element.

I don't receive this question anymore, i think it's a browser inner
action at some point to trigger it...

shajnday · Aug 14, 2010

I have put astray the form element as i have thought that it is the
necessary block element in which goes input...
As i had thought that the form element is a process element of some
kind and that it does some important actions so as when submitting
button to print or to close a page. I checked(what previously did not
came to my mind) and left only the input element and it works the
same. Validation shows pass!

One another thing was strange which made me to leave the form element
at first, when i submited the close button i sometimes got the "Are
you sure you want to close this window?"question, for which i had
thoughts that is the action of form element.

I don't receive this question anymore, i think it's a browser inner
action at some point to trigger it...- Sakrij citirani tekst -

- PrikaÅ¾i citirani tekst -

Yeah,
Thanks for that mr.Gill,
I did learned that.
I do have a lot of warnings but the page is fully functional in three
most exposed browsers and it is showed the very same, and i'am happy
about that. Not that i don't like validation buttons as they do look
great on the page, but it's only an aestehetic appendix.
As the knowledge tree is growing so i make valuations what is worth to
leave, and what is worth to rewrite or fix. Sometimes things jump from
byitself in front of me but i enjoy in it, everything is cheerful and
fun at my place.
Thanks for precious advice though.

Jukka K. Korpela · Aug 14, 2010

William said:
Similarly, when validating against a particular DTD, and I get a
validation error that was deliberate, I can ignore it or create a
modified version of the DTD that matches the variation.

Indeed. But many people want to validate due to some external requirement.
They don't understand the reasons for the requirement (maybe there isn't
one), and they don't even understand the content of the requirement; they
just want to "pass validation", or get a "clean report".

If the requirement really means that you must "validate against HTML 4.01",
then you just cannot have a <form> element without an action attribute. You
can use a fake value there (since validation does not check the attribute
value at all, except for some minor formalities), or you can dispense with a
<form> element if your form fields are purely JavaScript-driven (and then
you have an accessibility issue, but that's a completely different
perspective).

The inherent
risk is that if I leave the "error" in the document, then ask an
application (i.e. a browser) that relies on the original DTD (or even
my modified version) to parse the document I don't know how it will
react to the non-conforming entry,

Theoretically yes, but in practice, browsers don't use DTDs. Some browsers
have validation add-ons, but they don't affect the rendering.

The risk is that you are using an element, or an attribute, or a syntax of
an element that won't be supported by all browsers. People say that HTML
4.01 DTDs reflect the constructs that browsers actually support, but this is
just partly true. There are HTML 4.01 features that aren't supported at all,
or aren't supported by very commonly used browsers. And there are features
that are virtually universally supported but not part of HTML 4.01.

The value of validation is finding all the unintentional deviations.

Right - it is meant to protect against typos and similar mistakes.

William Gill · Aug 15, 2010

Indeed. But many people want to validate due to some external
requirement. They don't understand the reasons for the requirement
(maybe there isn't one), and they don't even understand the content of
the requirement; they just want to "pass validation", or get a "clean
report".

As I have observed many times over the years "There is no reason. It's
just policy."

Most likely someone implemented the requirement as a metric, without
understanding any of the implications. Similar to "lines of code per
day" as a metric for programmers.

Theoretically yes, but in practice, browsers don't use DTDs. Some
browsers have validation add-ons, but they don't affect the rendering.

I didn't really expect that browsers used DTDs in real time, but I would
guess that programmers use them when they are designing the code, even
if not when the code is run.

Neredbojias · Aug 15, 2010

As I have observed many times over the years "There is no reason.
It's just policy."

Most likely someone implemented the requirement as a metric, without
understanding any of the implications. Similar to "lines of code per
day" as a metric for programmers.

I didn't really expect that browsers used DTDs in real time, but I
would guess that programmers use them when they are designing the
code, even if not when the code is run.

If browsers didn't use dtds, there would be absolutely no point in
putting one in an html page and that isn't the case. Browsers may not
use dtds as intended or to the fullest extent, but they do use them. I
hope you and Jukka do not propagate yet another html myth.

Jukka K. Korpela · Aug 15, 2010

Neredbojias said:
If browsers didn't use dtds, there would be absolutely no point in
putting one in an html page and that isn't the case.

There is no point in putting a DTD in an HTML page. Try it, and you will see
that browsers can get very wild.

Browsers may not
use dtds as intended or to the fullest extent, but they do use them.

Prove it. Provide any evidence of a browser actually even _reading_ a DTD.

(My guess is that you have confused a DTD with a DOCTYPE declaration.
Browsers do "use" DOCTYPE declarations, in their wild guesswork on whether
the authors wants the page to be shown in a very broken mode, a somewhat
broken mode, or in "standards" mode which is not intentionally broken, or at
least they say so. This has absolutely nothing to do with using a DTD. It is
just a play on DOCTYPE declarations as strings, as if they were magic
incantations.)

William Gill · Aug 15, 2010

If browsers didn't use dtds, there would be absolutely no point in
putting one in an html page and that isn't the case. Browsers may not
use dtds as intended or to the fullest extent, but they do use them. I
hope you and Jukka do not propagate yet another html myth.

I will try to express this so that even you parse it correctly. I will
try not to use big words, or concepts so as to not confuse, and so that
your somewhat limited parser will be able to validate.

A DTD (document type definition) describes the precise structure a
conforming document must follow. Think of it as the rules. In theory
every document could have a unique set of rules (DTD), but so long as
they are publicly available a parser (for this discussion we are talking
about a browser) could obtain the rules and parse each document
dynamically. Coding such a parser would be a monumental task. In
reality a limited number of DTDs have been agreed to as "standard." So
when a programmer writes the code to parse documents, he has copies of
all the appropriate rules handy, and codes (in most cases) accordingly.
It is not necessary for the browser to read the rules for each
document as it is parsed, since it is assumed that neither the rules nor
the browser's own code have changed. In a sense the browser doesn't
"use" the DTD, it has it incorporated into its own code. However, since
there are several "standards" in use, the browser must decide which
branch of its own code to follow. I haven't coded any browsers, but
they appear to use the DOCTYPE declaration for this, and though it
could, it doesn't retrieve the DTD with each request, because the DTD is
of no use to the browser anymore since it cannot rewrite its own code to
accommodate the DTD if it had changed.

So when you parse the term "use" in this context, is anything Yucca, or
I have said invalid?

Try it for yourself. Start with a simple valid HTML document and view
it w/Firefox web developer toolbar. Does it indicate standards compliant
mode? Now start editing the DOCTYPE declaration to see how you can get
it to switch to quirks mode.

Jukka K. Korpela · Aug 15, 2010

William said:
A DTD (document type definition) describes the precise structure a
conforming document must follow.

To the extent it can, yes. The formalism used in DTDs is pretty limited, and
it cannot express all syntactic requirements.

In theory
every document could have a unique set of rules (DTD), but so long as
they are publicly available a parser (for this discussion we are
talking about a browser) could obtain the rules and parse each
document dynamically. Coding such a parser would be a monumental
task.

Not really monumental, though considerable effort. Such parsers (generic
SGML parsers) existed long before HTML was invented. People who wrote
browsers just decided not to use them.

In a sense the browser
doesn't "use" the DTD, it has it incorporated into its own code.

It doesn't use a DTD at all. And it's the other way around: DTDs in HTML
recommendations have more or less been retrofitted to describe, partly
incorrectly or inexactly, what browsers generally deal with, or can be
expected to deal with. Browsers tend to be much more permissive than they
would if the used DTDs, but roughly speaking, when you deviate considerably
from HTML recommendations in your document, browsers will often be
permissive _in different ways_.

However, since there are several "standards" in use, the browser must
decide which branch of its own code to follow.

No, they don't do such things. Each browser uses its built-in browser.

I haven't coded any
browsers, but they appear to use the DOCTYPE declaration for this,

No, they use that declaration to make a choice between _rendering modes_.
Parsing is not affected at all, even in cases where some markup is not
honored in some mode. For example, when IE 8 refuses, in "standards" mode,
to use the line breaking opportunities suggested by <wbr> markup
(nonstandard but widely supported tag), this hardly happens due to any
difference in parsing. Rather, the browser parses the tag as usual, then
just ignores it.

and though it could, it doesn't retrieve the DTD with each request,

They don't retrieve it at all.

Neredbojias · Aug 16, 2010

There is no point in putting a DTD in an HTML page. Try it, and you
will see that browsers can get very wild.

Prove it. Provide any evidence of a browser actually even _reading_ a
DTD.

(My guess is that you have confused a DTD with a DOCTYPE declaration.
Browsers do "use" DOCTYPE declarations, in their wild guesswork on
whether the authors wants the page to be shown in a very broken mode,
a somewhat broken mode, or in "standards" mode which is not
intentionally broken, or at least they say so. This has absolutely
nothing to do with using a DTD. It is just a play on DOCTYPE
declarations as strings, as if they were magic incantations.)

Um, yes, you're right. Well, -half right. Over on this side of the
Atlantic, "dtd" is commonly used to refer to the Doctype _Declaration_
as well as the Doctype _Definition_. Whether this is technically
correct or not I don't know but it certainly is more commonplace than
the latter. Anyway, I did mean Doctype _Declaration_, and since your
posts were unspecific about the issue in general, I thought you did,
too.

Neredbojias · Aug 16, 2010

I will try to express this so that even you parse it correctly. I
will try not to use big words, or concepts so as to not confuse, and
so that your somewhat limited parser will be able to validate.

Ha ha, pretty funny, Willie. However, I don't parse, I think. But
macht nicht for now because I'll admit I was a bit snide, too (-though
it was with a smile and a wink.)

A DTD (document type definition) describes the precise structure a
conforming document must follow. Think of it as the rules. In theory
every document could have a unique set of rules (DTD), but so long as
they are publicly available a parser (for this discussion we are
talking about a browser) could obtain the rules and parse each
document dynamically. Coding such a parser would be a monumental
task. In reality a limited number of DTDs have been agreed to as
"standard." So when a programmer writes the code to parse documents,
he has copies of all the appropriate rules handy, and codes (in most
cases) accordingly.
It is not necessary for the browser to read the rules for each
document as it is parsed, since it is assumed that neither the rules
nor the browser's own code have changed. In a sense the browser
doesn't "use" the DTD, it has it incorporated into its own code.
However, since there are several "standards" in use, the browser must
decide which branch of its own code to follow. I haven't coded any
browsers, but they appear to use the DOCTYPE declaration for this,
and though it could, it doesn't retrieve the DTD with each request,
because the DTD is of no use to the browser anymore since it cannot
rewrite its own code to accommodate the DTD if it had changed.

So when you parse the term "use" in this context, is anything Yucca,
or I have said invalid?

As I informed Yukka, his imprecision as to what he actually meant by
"dtd" was the cause of the mix-up.

Try it for yourself. Start with a simple valid HTML document and
view it w/Firefox web developer toolbar. Does it indicate standards
compliant mode? Now start editing the DOCTYPE declaration to see
how you can get it to switch to quirks mode.

Well, it used to be by removing the link. Html5's doctype is simply
<!DOCTYPE html> so I would guess that no longer applies and you could
have anything after the "html" for validity.

Captain Paralytic · Aug 16, 2010

and how it reacts today may not be how it
will react after the next update.

Sadly that is true of all updates, even where your script may be
valid. Microsoft have many products that specialise in this.

Jukka K. Korpela · Aug 16, 2010

Neredbojias said:
As I informed Yukka, his imprecision as to what he actually meant by
"dtd" was the cause of the mix-up.

There was no imprecision, in what I wrote, or in what you wrote. "DTD" is a
technical term, and I used it in its correct meaning. Your statement
involving it was incorrect; it was pointless to try to explain that on your
side of the pond, others get this wrong too.

You were not imprecise in your statements about the significance of DTDs to
browsers. Just completely wrong. This is actually simpler than being just
half right would have been, since you just need to abandon your old idea and
get the new one, instead of modifying the old one.

The difference between a DTD and a DOCTYPE declaration is not just a matter
of terms, but even if it were, you would still be wrong in playing with
technical terms and not knowing their defined meanings, or not caring about
them.

shajnday · Aug 16, 2010

There was no imprecision, in what I wrote, or in what you wrote. "DTD" is a
technical term, and I used it in its correct meaning. Your statement
involving it was incorrect; it was pointless to try to explain that on your
side of the pond, others get this wrong too.

You were not imprecise in your statements about the significance of DTDs to
browsers. Just completely wrong. This is actually simpler than being just
half right would have been, since you just need to abandon your old idea and
get the new one, instead of modifying the old one.

The difference between a DTD and a DOCTYPE declaration is not just a matter
of terms, but even if it were, you would still be wrong in playing with
technical terms and not knowing their defined meanings, or not caring about
them.

tutto completo.

William Gill · Aug 16, 2010

Ha ha, pretty funny, Willie. However, I don't parse, I think.

Ah! That was your first mistake. Better you should leave that thinking
stuff to people who are qualified. <G>

BTW I should have indicated my previous jab was intended to be in good
spirit.

Move a Form action="ThatPage.php" to an <input type="??" > inline	1	Oct 15, 2023
Change form action	0	Jul 2, 2022
Registration form	13	May 19, 2021
Registration Form	7	Aug 30, 2023
A simple form question	2	Nov 7, 2023
Clear Error Message Upon New Input on Form?	1	Sep 30, 2022
How can I remove the specific error message after regex validation is done?	1	Jan 25, 2023
How to submit form after calling curl post	4	Jan 1, 2023

Form action= ?

shajnday

Denis McMahon

Jonathan N. Little

Denis McMahon

dorayme

William Gill

shajnday

shajnday

Jukka K. Korpela

William Gill

Neredbojias

Jukka K. Korpela

William Gill

Jukka K. Korpela

Neredbojias

Neredbojias

Captain Paralytic

Jukka K. Korpela

shajnday

William Gill

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads