[cla][patch] Allow HTML markup in <select></select> widgets

[Jonathan Bond-Caron]

This patch allows:

<select id="markuptest"
	name="markuptest"
	dojoType="dijit.form.FilteringSelect"
	labelAttr="label"
	labelType="html"
>
   <option value="ct" label="<b>Connecticut</b> USA">Connecticut</option>
   <option value="me" label="<b>Maine</b> USA">Maine</option>
</select>

<select id="markuptest"
	name="markuptest"
	dojoType="dijit.form.Select"
>
   <option value="ct" label="<b>Connecticut</b> USA">Connecticut</option>
   <option value="me" label="<b>Maine</b> USA">Maine</option>
</select>

I would like to make this even simpler by supporting:

<select id="markuptest"
	name="markuptest"
	dojoType="dijit.form.FilteringSelect"
>
   <option value="ct" label="<b>Connecticut</b> USA">Connecticut</option>
   <option value="me" label="<b>Maine</b> USA">Maine</option>
</select>

<select id="markuptest"
	name="markuptest"
	dojoType="dijit.form.Select"
>
   <option value="ct" label="<b>Connecticut</b> USA">Connecticut</option>
   <option value="me" label="<b>Maine</b> USA">Maine</option>
</select>

Where by default, both dijit.form.Select and dijit.form.FilteringSelect look for the 'label' attribute, if not found it uses the <option>text value</option>.

The way I would approach it is have dijit.form.Select use:

dojo.declare("dijit.form._OptionsDataStore", null, {
   // look for labelAttr || 'label'
   // else use <option>text content</option>
}

// Used by dijit.FilteringSelect
dojo.declare("dijit.form._FilterOptionsDataStore", dijit.form._OptionsDataStore
   /// Filtering of <option></option>...
}

dijit.form._ComboBoxDataStore = dijit.form._FilterOptionsDataStore

Both widgets would use ~ the same 'data store' for markup, hopefully this will simplify and speedup the code.

[bill]

Aren't rich text labels supported already by using <div>'s rather than <select> and <option>?

<div jsId="s4" name="s4" id="s4" value="AK" dojoType="dijit.form.Select">
	<span value="AL"><b>Alabama</b></span>
	<span value="AK"><font color="red">A</font><font color="orange">l</font><font color="yellow">a</font><font color="green">s</font><font color="blue">k</font><font color="purple">a</font></span>
	<span value="AZ"><i>Arizona</i></span>
	<span value="AR"><span class="ark">Arkansas</span></span>
	<span value="CA"><span style="font-size:25%">C</span><span style="font-size:50%">a</span><span style="font-size:75%">l</span><span style="font-size:90%">i</span><span style="font-size:100%">f</span><span style="font-size:125%">o</span><span style="font-size:133%">r</span><span style="font-size:150%">n</span><span style="font-size:175%">i</span><span style="font-size:200%">a</span></span>
	<span value="NM" disabled="disabled">New<br>&nbsp;&nbsp;Mexico</span>
</div>

That seems like an easier syntax than embedding rich text in an attribute value. Not sure what you are trying to achieve with this alternate way of specifying rich text?

[Jonathan Bond-Caron]

Rich text is only supported by dijit.form.Select with a <div></div>

I needed this for FilteringSelect?, a <select></select> with a fixed size of 1-100 records.

I prefer the <div></div> markup but I think the 'label' or 'labelHTML' alternative attribute should be supported.

2 reasons:

• In my case, I have a server side template which uses ~ {html_select options=$options dojoType="dijit.form.Select" selected=AK} There's lot's of frameworks or applications that generate <select></select> markup from templates.
• It degrades nicely with JavaScript? disabled, rare but still...

[Jonathan Bond-Caron]

Just a note for myself, html markup in an attribute is not valid xhtml: <option value="ct" label="<b>Connecticut</b> USA">Connecticut</option>

Should use <option value="ct" labelHTML="&lt;b&gt;Connecticut&lt;/b&gt; USA">Connecticut</option>

Then "string".replace(/&amp;/g, '&').replace(/&lt;/g,).replace(/&gt;/g,'>');

[Douglas Hays]

Using label will not degrade well and using labelHTML will cause validation errors. The best degradation path would be to specify both label as plain text AND specify the text child of the OPTION tag as rich HTML, and have the widgets ignore the label attribute.

[Douglas Hays]

but that approach opens us up to migration and compatibility issues since you would have to escape < in the OPTION text where before you didn't have to.

[bill]

Couldn't you avoid validation errors with labelHTML by using data-dojo-label-html instead? You are talking about a syntax like this, right?

<option value="ct" data-dojo-label-html="&lt;b&gt;Connecticut&lt;/b&gt; USA">
    Connecticut
</option>

Seems like it would work, although (as I said in a previous comment) it's not pretty putting HTML into an attribute. Maybe it's better to put HTML where you normally expect it, like:

<span><b>Connecticut</b> USA</span>

and then control backwards compatibility with a flag?

[dylan]

We should probably revisit this given the work that jbondc originally put into this. Marking as a candidate for 1.12.

[dylan]

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.