Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.2.16

Bug #1124 Default renderer does not provide valid xhtml: hidden cells
Submitted: 2004-04-03 23:41 UTC
From: thesaur at php dot net Assigned: avb
Status: Closed Package: HTML_QuickForm
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 50 + 3 = ?

 
 [2004-04-03 23:41 UTC] thesaur at php dot net
Description: ------------ XHTML does not allow input to be outside a cell in a table. The following code: $form = new HTML_QuickForm('student'); $form->removeAttribute('name'); $form->addElement('hidden', 'KursID', $kursid); $form->addElement('text', 'name', 'Name:', array('size' => 50, 'maxlength' => 255)); $table->addRow(array($form)); generates the following output: ...snip... 48: <form action="example.php" method="post" id="student"> 49: <table border="0"> 50: 51: <input name="KursID" type="hidden" value="239" /> 52: <tr> 53: <td align="right" valign="top"> 54: <span class="required">*</span> 55: Name: 56: </td> 57: <td valign="top" align="left"> 58: <span class="nowrap"><input size="50" maxlength="255" name="name" type="text" /></span> 59: </td> 60: </tr> ...snip... This does not pass validation for either XHTML 1.0 Transitional or Strict. Of course, later versions of XHTML are even more picky. It would be nice if this would at least be fixed. It effectively prevents QuickForm from being used for XHTML sites. Not quite sure how to fix it, of course. Perhaps a separate {hidden} unit would be a good idea. It could then be placed outside the table.

Comments

 [2004-04-05 10:40 UTC] thesaur at php dot net
The solution I've come up with involves creating a separate table for each field/group. CSS takes care of the width. Of course, that will require an additional step (declaring cell widths), but I think it's the only solution at the moment that doesn't break everything. I am considering submitting an XHTML renderer. The other option (preferred) is to incorporate it into the default renderer much like clearAllTemplates. At some point it will necessarily become the default mode of rendering, and we shouldn't ignore it too long. Then the additional (optional) step would be to declare the label field width via CSS (inline style attribute).
 [2004-04-10 11:10 UTC] avb
I don't like such solution. A better approach will be to group all hidden fields (as some renderers do) and put them into some hidden <div> element. See ITDynamic_example.php
 [2004-05-08 13:34 UTC] avb
As a better approach was not proposed, I'll add a {hidden} placeholder to the default form template in the Default renderer and will 1) Group the hidden fields and assign it to this placeholder if it is present 2) Append the grouped field to the form's HTML before wrapping it if the placeholder is absent. Thus no BC break if someone used a custom template.
 [2004-05-12 10:37 UTC] avb
Fixed in CVS. Added a <div> that contains the {hidden} placeholder and the <table> with visible elements. BC is kept.
 [2005-02-16 21:50 UTC] pear at stevesapartment dot com
One suggestion (although the bug is closed, I know...) Why not wrap the grouped hidden elements inside a <fieldset> tag (it was designed for that purpose, I believe - better than using div everywhere) and then place this fieldset block directly after the <form> tag? That would seem to solve the problem for XHTML compliance and I'd think it wouldn't break the default template or anybody's display either... the only caveat would be that <fieldset> would probably need to be styled as display:none...