xforms:select widgets has internal select widget. Now we get xforms:label content and then add it to internal select widget ('nodeValue' property of xforms:label serves for that) for all cases expept xforms:label for xforms:choices (see comment http://lxr.mozilla.org/mozilla/source/extensions/xforms/resources/content/select.xml#391). I thought we should process xforms:label for xforms:choices as other xforms:label elements. But I guess there is a problem with such way. F.x. someone can define styles for xforms:label and if we'll get content of xforms:label then we loose thease styles. I guess it's wrong. In other hand we cannot just copy xforms:label into internal select widget because in come cases internal select widget can be broken. Probably we should let choose proper way for internal select widget. What behaviour should be?

(In reply to comment #0) > But I guess there is a problem with such way. F.x. someone can define styles > for xforms:label and if we'll get content of xforms:label then we loose thease > styles. I guess it's wrong. Me too :) > In other hand we cannot just copy xforms:label into internal select widget > because in come cases internal select widget can be broken. How is that?

(In reply to comment #1) > > > In other hand we cannot just copy xforms:label into internal select widget > > because in come cases internal select widget can be broken. > > How is that? > Wee saw already one problem. It is a bug 316616. I guess we can find some others.

I don't know I am talking about the same 'bug' but when I press the labels for the checkboxes inside an select element nothing happens. I would expect that while pressing/clicking a label the checkbox (or radio in case of select1) would be set to selected=true. This is however not defined in the w3c recomendation. It's just a nice feature of the old label elements in html. Could this could be done inside the xbl (control)binding?

(In reply to comment #3) > I don't know I am talking about the same 'bug' but when I press the labels for > the checkboxes inside an select element nothing happens. > I would expect that while pressing/clicking a label the checkbox (or radio in > case of select1) would be set to selected=true. > This is however not defined in the w3c recomendation. It's just a nice feature > of the old label elements in html. > You talk about feature like in bug 284068. But that bug isn't supposed for labels inside items of <select appearance="full"/>. Please file new bug for this, at least I cannot remember something like was posted. > > Could this could be done inside the xbl (control)binding? Yes, I think that's a way how it should be fixed.

Maybe we need to consider an example. Lets look at this: <xf:select ref="/data"> <xf:item style="font-family:Arial"> <xf:label style="font-size: 12px"><html:i><xf:output ref="builtLabelInstanceData2" style="color: red"/></html:i></xf:label> <xf:value>1</xf:value> </xf:item> </xf:select> What does everyone think that we should see? I'd argue that we should create a html:option, and pass on the calculated style of the xf:label to it (if that is possible, which I think it is). I'd then say that we clone the content as is. If we had the same example, but with a SNB attribute, I'd say that we pass on the calculated style of the xf:label on to the html:option and then set the nodeValue of the option to the nodeValue of the bound node. And thus ignore the children elements of the xf:label.

(In reply to comment #5) > If we had the same example, but with a SNB attribute, I'd say that we pass on > the calculated style of the xf:label on to the html:option and then set the > nodeValue of the option to the nodeValue of the bound node. And thus ignore > the children elements of the xf:label. > What is SNB attribute? If I'm looking farther ahead then I'm more sure html controls as they are cannot be used to realize all requirements of xforms controls. From time to time we look for workaround way instead actual problem solving. For example, we write own implementation of editable html:select for select1 and we don't use the code of html:select. For example, we copy xforms:labels content of xforms:select into underlying widget because we afraid to broke underlying widget. Aaron, your suggetion to copy computed style from label to option is good but in this case we cannot handle if label styles are changed and it's bad. Ideal situation as I can see is we shouldn't have underlying widgets for select controls. Probably we should investigate how we can resuse code of html widgets and how we can write our own widgets on their base.

(In reply to comment #6) > (In reply to comment #5) > > > If we had the same example, but with a SNB attribute, I'd say that we pass on > > the calculated style of the xf:label on to the html:option and then set the > > nodeValue of the option to the nodeValue of the bound node. And thus ignore > > the children elements of the xf:label. > > > > What is SNB attribute? Single node binding attribute -> @bind or @ref. > > If I'm looking farther ahead then I'm more sure html controls as they are > cannot be used to realize all requirements of xforms controls. From time to > time we look for workaround way instead actual problem solving. For example, we > write own implementation of editable html:select for select1 and we don't use > the code of html:select. For example, we copy xforms:labels content of > xforms:select into underlying widget because we afraid to broke underlying > widget. > > Aaron, your suggetion to copy computed style from label to option is good but > in this case we cannot handle if label styles are changed and it's bad. > > Ideal situation as I can see is we shouldn't have underlying widgets for select > controls. > > Probably we should investigate how we can resuse code of html widgets and how > we can write our own widgets on their base. > Having our own code for select would probably be a good idea in the long run. We'd certainly have more flexibility. But given our limited resources I'd be happy to just be compatible with the other xforms processors for now.

comment #3 suggests that label text should be clickable to activate that selection, another comment suggested opening a new bug for that 'feature'. Couldn't tell if a new bug had been opened, but I'd like to vote for that feature too. That is, when generating the anonymous content 'form' for a select[1] appearance=full, the label text should be a real html:label element. Id's will have to be dynamically generated somehow and associated with the appropriate radio/checkbox type html:input box.

(In reply to comment #8) > comment #3 suggests that label text should be clickable to activate that > selection, another comment suggested opening a new bug for that 'feature'. > Couldn't tell if a new bug had been opened, but I'd like to vote for that > feature too. > > That is, when generating the anonymous content 'form' for a select[1] > appearance=full, the label text should be a real html:label element. Id's will > have to be dynamically generated somehow and associated with the appropriate > radio/checkbox type html:input box. > You talk about bug 344387. The fix will be available in 0.7 version.

Alex, can you update this bug? Is this still a problem now since you put in your native widget patch for selects?

(In reply to comment #10) > Alex, can you update this bug? Is this still a problem now since you put in > your native widget patch for selects? > The bug is valid until we'll stop to use native widget approach.

RIP xforms