daniel at nadir-seen-fire
Sep 28, 2012, 7:51 PM
Post #6 of 13
On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner
Re: HTMLMultiSelectField as <select multiple="multiple"/>
[In reply to]
<daniel.werner [at] wikimedia> wrote:
>> Message: 8
>> Date: Wed, 23 May 2012 21:49:57 +0200
>> From: Platonides <Platonides [at] gmail>
>> To: wikitech-l [at] lists
>> Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select
>> Message-ID: <jpjf1s$b23$1 [at] dough>
>> Content-Type: text/plain; charset=ISO-8859-1
>> On 23/05/12 19:16, Daniel Werner wrote:
>> > Right now I am implementing a new option (as part of
>> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd
> like to
>> > use a <select multiple="multiple"/> html element with options. Right
>> > MediaWiki always generates a list of selectboxes instead of that when
>> > the HTMLMultiSelectField class. We are talking about 280+ selectable
>> > here, so for now we came to the conclusion that a real multi <select/>
>> > would be nicer and less space consuming for now
>> > I have already managed to implement this multiple select,
>> > modifying HTMLMultiSelectField adding a new option 'usecheckboxes'
>> > can be set to false to disable the known behavior and use a select
>> > instead.
>> > enabled, we could still do something nicer, for example with something
>> > jQuery chosen plugin here.
>> > My question would just be, how I should implement these changes
>> > Is it ok with the new option for HTMLMultiSelectField or should this
>> > new class inheriting from HTMLMultiSelectField? I think
>> > HTMLMultiSelectField sounds more like describing what I just
>> > rather than a bunch of select boxes, but of course renaming the
>> > one could "break" extensions (even though both are fully compatible
>> > interchangeable). So one option would be simply naming the new one
>> > HTMLMultiSelectField2 if we don't want to stick with an additional
>> > here.
>> No. You shouldn't need to know that HTMLMultiSelectField2 is a
>> MultiSelect but HTMLMultiSelectField uses checkboxes.
>> Your useCheckboxes looks good.
>> I recommend you to make it a tri-state value, so you could force
>> checkboxes, select or let it decide (eg. checkboxes for < 100 elements,
>> select for more)
> Alright, just submitted this for review to gerrit:
> I implemented it as tri-state now. By default 'usecheckboxes' will be
> not set to a number. This could be changed (would make sense imo) but for
> now I didn't want to do this since it could for example affect the
> search namespace user preference in wikis with many search namespaces. I
> think the plain multiple select HTML element is not that nice because it
> not very obvious that you can do multiple selects by holding the control
> having JS enabled I think before using this as default for huge
> options. I think if all of that were implemented, 15 or 20 would be a
> default value for the option.
Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use
it anywhere. If we're using JS to make a better UI it would actually be
much better to output usable checkboxes and then turn the checkboxes into
a special JS multi-select. Instead of outputting an unusable multi-select
and compensating for it.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list
Wikitech-l [at] lists