Re: Patch for <label> in HTML_QuickForm

On Tue, 15 Mar 2005 15:34:01 -0800, Turadg Aleahmad <turadg@berkeley.edu> wrote: > Alexey Borzov wrote: > > The patch is definitely not sufficient, as it does not take into account > > numerous possibilites. One of the obvious questions: what happens if > > someone is adding labels with <label> tags already appended? > > That is a fair point, but consider this... > > A <label> tag does nothing without a "for" attribute. The @for takes a > DOM element id. That id is generated randomly by QuickForm during > rendering and would thus be innaccessible when setting the label of the > element. > > So the user of QuickForm can't include @for. Granted, there are other > attributes of <label> like @title. > http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.9.1 > > But without @for there's no point because the label is not associated > with any form element. Since QuickForm 3.2 can't have @for, if a user > is including <label> in their element label, it's not doing them any good. This isn't always true. Users who wish to have labels (/me raises his hand) have gotten around this by setting an id "manually". i.e. $el->updateAttributes(array('id' => $el->getName())) which works fine for most elements. I have, in fact, used similar code in various places in my own code and even in PEAR code (DB_DataObjectFormBuilder adds labels for checkboxes in one or two places). > > If they do choose to include <label>, it simply nests within the <label> > I'm generating. In Firefox, the inner one dominates. If this is true in *all* browsers, then should be ok. However, if IE doesn't do this, there's a problem. Why not just alter your code to do a quick if (!strstr($label, '<label ')) before adding a label? > > So I think this point you raise is not reason to reject this valuable > feature in QF 3.2. Do you have any other objections? > -- Justin Patrin