The Agora styles http://www.mediawiki.org/wiki/Agora are implemented in a 'mediawiki.ui' module. Kaldari points out that we have overlapping button styles in jquery.ui.button, e.g. 'mw-ui-button mw-ui-primary' vs 'ui-button ui-button-red'.
|· · ·|
|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|
|Declined||None||T114934 Implement a slider widget in OOJS UI|
|· · ·|
- Mentioned In
- T241632: Remove use of jQuery UI from Page Forms
T219604: Remove unused jquery.ui.* and jquery.effects.* modules
T215084: Stop depending on jQuery in OOUI
T200868: [EPIC] Make jQuery an optional dependency
T185913: CentralNotice: Replace date picker and multiselect widgets with OOUI widgets in Admin UI
T158618: SocialProfile Special:UpdateProfile should switch from jQuery UI Datepicker to PHP DateInputWidget
T114335: [AOI] Prototype for RevisionSlider
- Mentioned Here
- rMW9e712ce6382f: Deprecate various ResourceLoader modules
(In reply to comment #1)
jQuery UI should die. We should take the good bits and put them into
Is there an easy way to grep for what parts of jquery.ui we're using anywhere? If we can get a list, I will help do an audit of we are doing with jquery.ui that needs to be supported by mediawiki.ui (and potentially oo.ui/ve.ui, which is being split out of VE right now).
You can grep for jquery.ui in the checkout of core and all WMF-deployed extensions, and use regular Special:Search for a wiki (just make sure the right namespaces are checked). However, that might miss extensions, gadgets and user scripts that don't declare their dependencies (they should always be declared when possible, but not everyone is aware of this). There are definitely places that use it; however, the fact that it is loaded by default (e.g. on the main page) is a problem (bug 55550).
This isn't going to be an overnight transition. mediawiki.ui needs to mature a lot, and jquery.ui is being used a lot of places (including gadgets and userscripts). Thus, it will probably need to be kept around for a while (though not loaded by default), even when mediawiki.ui has feature parity and is being used by extensions.
Does "everything" includes on-wiki gadgets depending on modules such as jquery.ui.dialog, jquery.ui.tabs, jquery.ui.button? There are quite a few which will need to be updated:
(also, this task needs a better description for users coming here without any context)
No. As normal, we'll deprecate once git is clean of depending the deprecated code, and not wait for gadgets, site scripts and user scripts to be updated. However, we'll advertise (widely) with a long period of deprecation before it's removed, and give suggestions on how to convert.
FYI: RefToolbar, which is a default gadget on English Wikipedia, and a very important tool for editors, relies on jQuery UI for dialogs. It also doesn't have a maintainer since the tool's creator has retired. Community Tech could probably take on the task of updating it, but if we're going to replace the WikiText editor before jQuery UI is deprecated, it would be a waste of time.
There are lots of gadgets on lots of wikis that use jQuery.ui. Regardless of whether MediaWiki itself uses jQuery.ui, I think it would still be a good idea to make it available as a module for gadgets indefinitely.
Yeah, it's going to be hard for communities that don't actually have people supporting their gadgets (though that situation isn't really meant to happen), and it isn't appropriate yet for some edge cases to migrate to OOUI. However, at some point we're going to have to stop shipping it, and not just by moving it on-wiki.
For the record, keeping anything has a non-zero maintenance cost. In particular for jQuery UI because we're using an outdated version.
Given our version is now far beyond jQuery's LTS/EOL, we need to either start taking over maintenance of this legacy version as soon as possible (starting with an overdue security review), or we need to start migration to a newer version. It sounds like we want to avoid migration due to unmaintained gadgets (or we could encourage migration to OOUI). Although arguably migrating to a newer jQuery UI version should be much simpler compared to migrating to OOUI, either would require hands-on coding, and either would result in truly unmodified code to break.
I'm not proposing anything right now, but it should be unsurprising that we cannot indefinitely support unmaintained gadgets by indefinitely shipping upstream-unsupported software as-is, without maintenance or responsibility for finding and addressing likely security vulnerabilities.