
daniel at nadir-seen-fire
Sep 28, 2012, 7:51 PM
Post #6 of 13
(191 views)
Permalink
|
|
Re: HTMLMultiSelectField as <select multiple="multiple"/>
[In reply to]
|
|
On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner <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 >> multiple="multiple"/> >> 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 >> now >> > MediaWiki always generates a list of selectboxes instead of that when > using >> > the HTMLMultiSelectField class. We are talking about 280+ selectable > items >> > 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' >> which >> > can be set to false to disable the known behavior and use a select > element >> > instead. >> > >> > This would mainly be for the JavaScript-less ui. If javascript were >> > enabled, we could still do something nicer, for example with something > like >> > jQuery chosen plugin here. >> > >> > My question would just be, how I should implement these changes > preferably. >> > Is it ok with the new option for HTMLMultiSelectField or should this >> be > a >> > new class inheriting from HTMLMultiSelectField? I think >> > HTMLMultiSelectField sounds more like describing what I just >> implemented >> > rather than a bunch of select boxes, but of course renaming the >> existing >> > one could "break" extensions (even though both are fully compatible >> and >> > interchangeable). So one option would be simply naming the new one >> > HTMLMultiSelectField2 if we don't want to stick with an additional > option >> > 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: > https://gerrit.wikimedia.org/r/#/c/8924/ > > I implemented it as tri-state now. By default 'usecheckboxes' will be > true, > 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 > default > search namespace user preference in wikis with many search namespaces. I > think the plain multiple select HTML element is not that nice because it > is > not very obvious that you can do multiple selects by holding the control > key. There should be some JavaScript ui element replacing this for users > having JS enabled I think before using this as default for huge > multiselect > options. I think if all of that were implemented, 15 or 20 would be a > good > default value for the option. > > Cheers > Daniel 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 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|