Opened 10 years ago

Last modified 3 years ago

#11118 open enhancement

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

Reported by: Jonathan Bond-Caron Owned by:
Priority: high Milestone: 1.15
Component: Dijit - Form Version: 1.5.0b2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

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.

Attachments (1)

select_label.patch (4.4 KB) - added by Jonathan Bond-Caron 10 years ago.

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by Jonathan Bond-Caron

Attachment: select_label.patch added

comment:1 Changed 10 years ago by 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?

comment:2 Changed 10 years ago by 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...

comment:3 Changed 9 years ago by 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,'>');

comment:4 Changed 9 years ago by bill

Description: modified (diff)

comment:5 Changed 9 years ago by Douglas Hays

Owner: set to Douglas Hays

comment:6 Changed 9 years ago by Douglas Hays

Milestone: tbd1.7

comment:7 Changed 9 years ago by Douglas Hays

Milestone: 1.71.8

comment:8 Changed 9 years ago by bill

Component: DijitDijit - Form

comment:9 Changed 8 years ago by Douglas Hays

Milestone: 1.8tbd

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.

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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?

Last edited 8 years ago by bill (previous) (diff)

comment:12 Changed 6 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:13 Changed 6 years ago by Douglas Hays

Status: assignedopen

comment:14 Changed 4 years ago by dylan

Milestone: tbd1.12

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

comment:15 Changed 3 years ago by dylan

Milestone: 1.131.15

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

Note: See TracTickets for help on using tickets.