Bug #14491

XHTML 1.0 strict compliance of FORM objects (hidden fields)

Added by Ernesto Baschny over 16 years ago. Updated almost 15 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


FORM objects generate hidden fields that are not enclosed by any other block-level tags. This is not legal according to XHTML 1.0 strict, so e.g. pages with a mailform content object fail to validate. Attached is a patch to solve this problem (it just adds a <div> around the hidden fields block).

(issue imported from #M678)


0000678-hiddenfields-xhtml.diff (390 Bytes) 0000678-hiddenfields-xhtml.diff Administrator Admin, 2005-01-13 13:41
class.tslib_content.php.hiddenfields.patch (387 Bytes) class.tslib_content.php.hiddenfields.patch Administrator Admin, 2005-05-18 17:10

Updated by Michael Scharkow over 16 years ago

Any counterarguments against this fix?

edited on: 03.02.05 23:32


Updated by Martin Kutschker over 16 years ago

Hm, in 3.7 the hidden fields simply appear after the form tag. So it's up to the surrounding xhtml to supply a block-level tag.


Updated by Sacha Vorbeck over 16 years ago



Updated by Ernesto Baschny over 16 years ago

Error from w3's validator is (XHTML 1.1 strict!):

document type does not allow element "input" here; missing one of "ins", "del", "h1", "h2", "h3", "h4", "h5", "h6", "p", "div", "address", "fieldset" start-tag

In my case, the content area where this mailform is placed in is already inside a <div id="content"> so there is a surrounding block-level tag. But still, the input fields cannot "hang around" after the form tag. They must be enclosed inside a blockl-level tag, e.g. a <div>.


Updated by Martin Kutschker about 16 years ago

Improved patch adds display:none to the div.


Updated by Karsten Dambekalns about 16 years ago

One can probably see this in different ways, but requiring a block level element around a hidden field seems nonsense to me. Pffft.

Other than that, the patch looks good and should do no harm.


Updated by Michael Stucki about 16 years ago

Fixed in 3.8 but only if the "accessibility" property is set.


Updated by Martin Kutschker about 16 years ago

While valid XHTML is currently mainyl an accessibility issue, this xhtml bug should be fixes regardless of the setting of the accessibility flag. So the bug must remain open until this depency is removed.

The div does no harm, so why the check?


Updated by Michael Stucki about 16 years ago

OK, convinced me. I didn't realise that display:none was set!

Also available in: Atom PDF