Project

General

Profile

Actions

Bug #14491

closed

XHTML 1.0 strict compliance of FORM objects (hidden fields)

Added by Ernesto Baschny about 19 years ago. Updated over 17 years ago.

Status:
Closed
Priority:
Should have
Category:
Frontend
Target version:
-
Start date:
2005-01-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
3.8.0rc1
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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)


Files

Actions #1

Updated by Michael Scharkow about 19 years ago

Any counterarguments against this fix?

edited on: 03.02.05 23:32

Actions #2

Updated by Martin Kutschker about 19 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.

Actions #3

Updated by Sacha Vorbeck about 19 years ago

keyword:accessibility

Actions #4

Updated by Ernesto Baschny about 19 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>.

Actions #5

Updated by Martin Kutschker almost 19 years ago

Improved patch adds display:none to the div.

Actions #6

Updated by Karsten Dambekalns almost 19 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.

Actions #7

Updated by Michael Stucki almost 19 years ago

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

Actions #8

Updated by Martin Kutschker almost 19 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?

Actions #9

Updated by Michael Stucki almost 19 years ago

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

Actions

Also available in: Atom PDF