Nowadays there's a lot of effort being done towards improving and standarizing the UI throughout MediaWiki and extensions. PageForms and its users could benefit a lot from embarcing OOUI.
|Open||None||T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core (replacing it with OOUI).|
|Open||None||T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core|
|Open||None||T122014 Convert all extensions/skins to OOUI|
|Open||None||T192752 Convert Extension:Page_Forms to use OOUI|
I would say the main benefit is consistency in how forms look and behave. If you are already using HTMLForms the code change is actually trivial, and if not, HTMLForms can simplify the code.
Well, I guess there are two questions here: should Page Forms start using OOjs/OOUI, and should it stop using jQuery UI? For the second question, I very much doubt it, but I put together a list of the jQuery UI modules (if that's the word) used by Page Forms - here they are:
- jquery.ui.sortable - used for multiple-instance templates (which can be rearranged by the user), as well as by the jsGrid library, for the "spreadsheet" display
- jquery.ui.datepicker - used by the "datepicker" and "datetimepicker" input types
- jquery.ui.widget - required by the Dynatree JS library, which is used by the "tree" input type (Dynatree is deprecated and needs to be replaced by the Fancytree library, but Fancytree too requires jquery.ui.widget)
- jquery.ui.autocomplete - used for autocompletion within #forminput, as well as for the "text with autocomplete" and "textarea with autocomplete" input types (though these two may go away at some point)
Can any of these be implemented using OOUI?
As for using OOUI anyway to make the display of Page Forms more consistent (your point, @Nikerabbit) - I'm not against adding more JS dependencies, and I do always want to make Page Forms fit in with the overall look-and-feel of MediaWiki as much as possible, but I wonder if there aren't easier ways to do it. In the Cargo extension, for instance, we made the "submit" button big and blue to match the current style by just adding some HTML classes (92e983dc96b2). Maybe similar things in Page Forms could do most of the work?
In hindsight I glanced over the fact that the whole extension is about forms. When I wrote above I was mostly thinking pages such as Special:CreateProperty are likely easy to convert.
As for the user defined forms... that would be a lot of harder I believe But a solution that allows (or even better, automatically uses) styling that matches rest of MediaWiki would be good to have there too. While I have styled buttons using classes only, the same approach does not work, for example, for checkboxes.
Well, maybe it's worth converting at least the simple helper forms, like Special:CreateProperty and Special:CreateCategory, to the HTMLForms/OOjs/OOUI system. (I doubt that's what @Sophivorus was talking about, but I don't know for sure.)
That's too bad about checkboxes - I see here how they look with OOUI (https://www.mediawiki.org/wiki/OOUI/Widgets/Inputs#Checkbox_inputs), and it would be good to match that in one way or another.
One thing I'd like to convert to OOUI is the date and datetime fields of PageForms. I've had a go at adding a new datetimewidget input type, to use the DateTimeInputWidget that's in core MediaWiki. I don't think it's the best approach though, and wonder what you think about the idea of adding a ooui=yes parameter to fields so that any could be switched to OOUI as desired, and without breaking current functionality?
Personally, I think doing away with jQuery UI completely is a good idea (but it should be a gradual thing and not break anything of course).
@Samwilson - I just tried out that patch, and the "datetimewidget" input type looks... underwhelming. It doesn't include a "picker" interface, so it's really just a row of inputs, a lot like the current "datetime" input. It's not comparable to "datetimepicker", unless I'm missing something. What are the advantages of this input type?
Hm, maybe it's not loading correctly, because it does have a datepicker dropdown that should show when you focus one of the date parts (but not the number parts).
I think one advantage is that it matches the design of the rest of MediaWiki (or at least, the direction that it's all going in! it'll be a while before everything is converted), but the main things are around accessibility and i18n. For example, look at the ordering of things (and arrow directions) in the following:
jQuery UI is dead (there hasn't been a release for nearly 3 years) and it'll have to be left behind at some point. I'm not really sure what the best way to do it is, but I'm happy to help. :) The above patch is just an idea to talk about really.
@Samwilson - aha, okay! I had originally put the "datetimewidget" input in a complex test form, but there was some unrelated JS error that kept it from working. I tried it on a simpler form, and now it works. There's some strange behavior in the UI that may have been fixed already in newer versions of MediaWiki - the most conspicuous is that, no matter what the set date is, the picker always starts by showing the current month. Maybe that's been fixed, or maybe there's a way around it. But it seems good enough, and as you note its handling of RTL languages is superior.
I see no reason to have two separate datepicker input types - if this OOUI input gets added to Page Forms, it should have the names "datepicker" and "datetimepicker", and replace the current input types.
I had no idea that development on jQuery UI ended three years ago... that's very interesting. Actually, Page Forms doesn't make that much direct use of jQuery UI - the "sortable" functionality has already been replaced by a different library that works better, and if this datepicker stuff gets replaced, that just leaves some of the autocompletion functionality, which I wanted to remove/replace anyway. Instead, the big things are the Fancytree and jsGrid libraries, both of which use jQuery UI, and neither of which I know of any real replacement for.