What document type do you use?

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

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.

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. :)

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;
        }

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

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

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.

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

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

{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.

// 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

Patch and unit test added.

Fixed in trunk (1.12.0): r24840

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.