Validation Error Message For Using Input in Form

[Chris77]

Sitepoint Members,

I'm getting the same error for every <input> I use in a <form>. I haven't seen this error on my xhtml site until recenetly. I wonder if it's an HTML5 error.

<form action="http.................." method="post">

E609 This tag or content is not allowed here. One of the following was expected: <address> <blockquote><del> <div> <dl> <fieldset> <h1> <h2> <h3> <h4> <h5> <h6> <hr> <ins> <noscript> <ol> <p> <pre><script> <table> <ul>

<input type="hidden" name="Return" value="0" />
.
.
.
.

</form>

How do I use the <input> code in a <form> without getting this error?

Thanks,


Chris77

[felgall]

An input tag is not allowed to be directly inside a form tag. It must be enclosed inside another tag - generally a div or fieldset with that tag being nested inside the form.

So for example:

<form action="http.................." method="post"><div>

<input type="hidden" name="Return" value="0"/>

</div></form>

[Chris77]

Felgall,
I would have never thought of that. It seems like <div>s are required for everything.

Thank a bunch,

Chris

[paul_wilkins]

It seems like <div>s are required for everything.

When dealing with forms, the paragraph element is preferred now for marking up each line.
HTML 5 Forms

For example:

<form id="aSampleForm">
    <p><input name="anInputElement"></p>
</form>

The main purpose of a div or a span is to provide a block or inline section of content that is free of any inherent semantics that other tags normally have, which is why you may commonly see them being used.

[ralph.m]

Off Topic:

When dealing with forms, the paragraph element is preferred now for marking up each line.

Wow, the WHATWG page describing what a paragraph is and how to represent it in code almost makes me cry. The hotch potch code on that page looks like something a confused noob would write.

I keep getting confused myself about how screen readers react to <p> within forms, but from memory, it can cause a lot of problems. (Will have to defer to @Stomme poes on that one.) Why didn't the WHATWG just drop this seemingly inane rule that inputs have to be wrapped in something?

[Chris77]

I went with the <div>s. I use Total Validator and it took the <div>s. On the page explaining forms at the end it has a <button> tag. Maybe I don't program enough, but I can't recall ever seeing <button>.

Thanks,

Chris

[paul_wilkins]

Why didn't the WHATWG just drop this seemingly inane rule that inputs have to be wrapped in something?

That's a good question. The form element is specified in HTML4 as containing only block or script, whereas most other elements such as div can contain flow elements (both block and/or inline).

The earlier HTML 3.2 specs show that forms could contain body.content, which include both block and inline elements.

Fieldsets were introduced to aid with accessibility (in the Improved Structure section of Accessibility Improvements), and I believe that steps were taken to prevent inline elements as direct children of forms in order to help enforce that accessibility feature. I would love to see though some documentation that relates to this decision as it occurred between 3.2 and 4.0

[Stomme poes]

When dealing with forms, the paragraph element is preferred now for marking up each line.

Because They are Evil. Srsly wtf.

I keep getting confused myself about how screen readers react to <p> within forms, but from memory, it can cause a lot of problems.

They *should* be okay here. <p>some random bit of error msg or some additional instructions</p> will be missing if the SR has a Forms Mode (and some, like NVDA, don't). But if there's a form control, it will still ignore the <p> tags and should happily read out the labels and offer the inputs for edit.
This though
<p>Required: <label for="foo">Name: </label><input type="text" name="foo" id="foo"></p>
means label's good, input's good, "required" may never get mentioned.

Anyway, WHATWG has zero interest in accessibility with regards to HTML. They believe a11y should be dealt with in completely separate specs. The W3C disagrees so far. Hence the war.

I believe that steps were taken to prevent inline elements as direct children of forms in order to help enforce that accessibility feature.

If that was the reason, it's been quickly lost (assuming we're focussing on screen readers here).

Fieldsets by themselves won't announce anything; the legends are announced (sometimes annoyingly before every single input within the fieldset, arg). Plus fieldsets make Gecko puke when printing.

HTML4 requires legend if fieldset is used.
XHTML1 dropped this requirement silently (fieldset does not get an error if not accompanied by legend now), making fieldsets less useful if accessibility was the main point.
HTML5 no longer requires that inline elements cannot be direct children of forms. Similarly with blockquote. The OP's code would have passed HTML5 validators fine.

[ralph.m]

Thanks poes, great info there.