Issues

ZF-8709: Change label on radio button from explicit to implicit

Issue Type: Bug Created: 2010-01-05T01:40:04.000+0000 Last Updated: 2012-09-06T14:18:22.000+0000 Status: Resolved Fix version(s): - 1.12.0 (27/Aug/12)

Reporter: Jon Gilbert (jon.gilbert@net-entwicklung.de) Assignee: Frank Brückner (frosch) Tags: - Zend_View

  • FixForZF1.12
  • zf-crteam-priority

Related issues: Attachments: - FormRadio.php.patch

Description

Current default output doesn't work in IE6: My button

Correct output: My button

Suggested fix: Change default label placement from 'append' to 'prepend' (in /library/Zend/View/Helper/FormRadio.php)

Comments

Posted by Marco Kaiser (bate) on 2010-01-05T01:47:53.000+0000

What document type do you use?

Btw. IE6 sucks and should not be supported in any way.

Posted by Jon Gilbert (jon.gilbert@net-entwicklung.de) on 2010-01-05T03:01:19.000+0000

I agree that IE6 sucks, but that's another story ;-) Document type is XHTML 1.0 Transitional but that should also be irrelevant. In the current output the label includes the element it is labelling which seems to me to be semantically wrong. There's a simple example on http://www.w3schools.com/tags/tag_label.asp - it is irrelevant where the label is in relation to the radio button, but they should be two distinct elements, not nested.

Posted by Marco Kaiser (bate) on 2010-01-05T03:10:45.000+0000

The Label helper produces different html for different doctypes. Do you use in your layout/view the $this->doctype() helper? If not try with. I think this isnt a bug. :)

Posted by Jon Gilbert (jon.gilbert@net-entwicklung.de) on 2010-01-05T07:17:26.000+0000

Doctype is hardcoded in the layout template, but I disagree that this is relevant. doctype affects the closing tag:

    $endTag = ' />';
    if (($this->view instanceof Zend_View_Abstract) && !$this->view->doctype()->isXhtml()) {
        $endTag= '>';
    }

but building the button and label does not depend on it: // Wrap the radios in labels $radio = '<label' . $this->_htmlAttribs($label_attribs) . ' for="' . $optId . '">' . (('prepend' == $labelPlacement) ? $opt_label : '') . '_htmlAttribs($attribs) . $endTag . (('append' == $labelPlacement) ? $opt_label : '') . '';

However, I agree that $labelPlacement is actually irrelevant - not sure what I was thinking about there ;-) The code that actually needs fixing is the above definition of $radio. Here's my solution:

        // create radio button and label and put them together in the required order
        $label = '<label'
                . $this->_htmlAttribs($label_attribs) . ' for="' . $optId . '">'
                . $opt_label
                . '</label>';
        $radio =  '<input type="' . $this->_inputType . '"'
                . ' name="' . $name . '"'
                . ' id="' . $optId . '"'
                . ' value="' . $this->view->escape($opt_value) . '"'
                . $checked
                . $disabled
                . $this->_htmlAttribs($attribs)
                . $endTag;
        if ('prepend' == $labelPlacement) {
            $radio = $label . $radio;
        } else {
            $radio .= $label;
        }

Posted by James Boykin (jfm) on 2010-07-24T15:59:35.000+0000

Yes this bug makes it difficult to use many jquery plugins. Would love to see this fixed! Manual patching for now...

Posted by Kim Hwan (ihwan) on 2010-08-20T03:30:49.000+0000

This bug makes it difficult to use many jquery plugins. For example, jquery ui radio buttons has this problem. http://jqueryui.com/demos/button/radio.html

Posted by Daniel Zahariev (daniel.zahariev) on 2011-03-08T02:50:24.000+0000

Hi all, i had the same issue with this in terms of jQuery usage and used the following code for reordering: $('input[type="radio"]', 'some scope').each(function(){ var radio = $(this), label = elem.parent(); radio.detach(); label.before(radio); }); Hope this helps someone.

Posted by Kai Uwe (kaiuwe) on 2011-03-08T04:10:54.000+0000

Please read the HTML specification carefully! This is valid HTML and XHTML! These are "implicit labels": www.w3.org/TR/html401/interact/forms.html#h-17.9.1" rel="nofollow">HTML 4: 17 Forms - 17.9.1 The LABEL element

Posted by Jon Gilbert (jon.gilbert@net-entwicklung.de) on 2011-03-08T23:54:07.000+0000

No, those aren't implicit labels. Implicit labels don't have a "for" attribute - that makes them explicit

Posted by Kai Uwe (kaiuwe) on 2011-03-09T02:33:27.000+0000

{quote}No, those aren't implicit labels. Implicit labels don't have a "for" attribute - that makes them explicit{quote} Right! The "for" attribute is not needed and makes here also no sense.

<pre class="highlight">
// Wrap the radios in labels
$radio = '_htmlAttribs($label_attribs) . ' for="' . $optId . '">' // "for" can be removed!
        . (('prepend' == $labelPlacement) ? $opt_label : '')
        . '_htmlAttribs($attribs)
        . $endTag
        . (('append' == $labelPlacement) ? $opt_label : '')
        . '';

www.w3.org/TR/html4/interact/forms.html#adef-for" rel="nofollow">HTML 4: 17 Forms - 17.9.1 The LABEL element - for

Posted by Frank Brückner (frosch) on 2012-05-09T16:37:08.000+0000

Patch and unit test added.

Posted by Adam Lundrigan (adamlundrigan) on 2012-05-31T14:15:17.000+0000

Fixed in trunk (1.12.0): r24840

Posted by Bernd Matzner (bmatzner) on 2012-09-06T14:18:22.000+0000

While reasonable, this fix does break existing javascript applications that rely on the for attribute to be available.

I would at least expect a migration note that the view helper output has changed.

Finding out the hard way that some generated HTML code has changed is unpleasant.

Have you found an issue?

See the Overview section for more details.

Copyright

© 2006-2016 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.

Contacts