Does anyone know the reasoning behind the strict doctype not allowing input elements to be direct descendents of a form element. I find it annoying that i have to wrap a submit button which is a block level element inside another block level element say a fieldset or a div. However, I cannot find an answer anywhere as to why this actually is.
+1
A:
So if you try to put an input directly into a form without a container element, and validate under xhtml 1.0 strict, you get this warning:
document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag ✉ The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element.
One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").
And if you look here at the W3C definition of a form element (http://www.w3.org/TR/html4/interact/forms.html#h-17.3) you can see that that the element's content model is defined as "%block".
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->
If you follow the "%block" link (http://www.w3.org/TR/html4/sgml/dtd.html#block) that leads you to the elements that are defined as those types of elements. And those are:
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
So, as you can see, the W3C doesn't define an input or a button as a block level element. You can search that page for "input" and find that it's content type of "formctrl":
<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">
And, really, input elements default display as more inline-block than block, considering they don't cause line breaks before/after them. So, there are more than just inline elements and block-level elements.
So, in the end, a form needs it's direct children to be block level elements, and input elements don't qualify. I hope that clears everything up.
RussellUresti
2010-06-06 00:31:04
yes it does give more insight as to the reasoning, but, and I would imagine I speak for most developers out there, input elements are seen as block elements and behave as such in almost all browsers and settigns.
David
2010-06-06 00:52:13
Yeah, the tendency is to think of elements as either block-level or inline, but there's a lot more variety than just those 2. Input elements are block-level in that they have a height and width you can adjust, but if you have something like "Enter Name: <input />" they all appear on the same line without needing to do any floating, so in that way it behaves like an inline element. Myself, I see them as inline-block elements. Though I do agree that a <div> or <p> or any other block level element should not be needed for an <input> to validate, I think it should be fine right inside the <form>.
RussellUresti
2010-06-06 02:22:12
This answer just boils down to, "The spec said so." I find it most unsatisfying. 1) What possible real-world reason would there be to restrict a form's "content model" to block, especially if there is a "formctrl" option also available?!! 2) I constantly use forms that are defacto inline. It galls the heck out of me that I have to CSS around block elements to do that.
Brock Adams
2010-06-06 05:23:14
@Brock The answer to "why is it that way" is because the people who run the W3C and are part of the HTML Working Group decided that's how it should be, but that's a horrible answer. Also, all tags have defined content models, that's how validation is determined, putting the right tags in the right locations. It provides structure.
RussellUresti
2010-06-06 05:44:09
@RussellUresti: Yes, I know all about structure, validation, and specs. I (and I think the OP) want to know if anyone has a *justification* for the spec. Or is this just another example of bureaucrats getting it wrong?
Brock Adams
2010-06-06 05:58:57
@Brock: Exactly. What is the actual reasoning for this. Obviously people have sat down and decided that form elements should behave this way but what is it that caused them to decide this. I cant see any reason for it.
David
2010-06-06 09:24:12
Actually I think the standard has got it right here. If inputs were defined as block level elements, that would mean that, say, a radio button would be on one line and the label text for that radio button on the next line by default (without specific CSS to set floats/widths etc etc). Inputs are defined as inline because typically they naturally sit within the flow of explanatory text etc within a block. To have a valid form, just place each input / label combination (you *are* using labels, right?) into a block such as a div or p, within the form element. Nothing wrong with that IMHO.
mattandrews
2010-09-16 02:10:26