About this board

Previous discussion was archived at Talk:OOjs UI/Archive 1 on 2016-12-12.

Question about infusion and OOUI for PHP

Cavila (talkcontribs)

Over the last couple of days, I've been trying to implement navigation tabs using OOUI\TabPanelLayout, OOUI\PanelLayout and OOUI\IndexLayout in PHP. My setup is a custom extension and the tabs are intended to be rendered on pages of a custom MW namespace. However, both panels are shown, stacked vertically, and clicking any of the headers has no effect on the appearance of the panels, whether framed or frameless. The browser’s inspector shows what looks like some unprocessed json data still being attached to the data-ooui attribute. Also, there’s a couple of seconds delay in page load before OOUI finally kicks in and the plain HTML gets transformed.

I could go into a lot more detail here, but the issue here is that what is required to make things work, namely infusion, is not being triggered. Wikimedia’s own OOUI demo shows that the same broken behaviour applies unless you hit the ‘Infuse’ button at the top. I had already made each widget infusable and also added the setInfusable function at the end, to be on the safe side, but it would be helpful to know what other steps need to be taken.

The documentation on this website and on the Wikimedia site does not suggest solutions, AFAICS. Should something like be included as a dependency? What do you recommend we should do? Is it advisable to use OOUI at all?

Reply to "Question about infusion and OOUI for PHP"

Setting up online environment to develop OOUI interfaces

Yug (talkcontribs)

I wanted to create a clean jsfiddle environment with OOUI.js but failed.
Cannot find a clean list of its dependencies on OOUI and associated pages : they assume we code on the wiki.
Added OOUI JS library v0.42 from cdnjs but doesn't work.
Is there something I'am not aware of ?

Yug (talkcontribs)

I created a OOUI starter on jsfiddle :

I added a link at the bottom of the main page. It think it fits into that list but please review.

Reply to "Setting up online environment to develop OOUI interfaces"
Summary by FreedomFighterSparrow

OOUI is "Object-Oriented User Interface", see OOUI/About the library (talkcontribs)

What OOUI stands for? Obviously the UI stands for User Interface, but the OO?

DannyS712 (talkcontribs)

Setting the first day of the week in the calendar input

Yaron Koren (talkcontribs)

Hi - for the OOUI DateInputWidget (currently used in UploadWizard and maybe elsewhere), is there a way to change the first day of the week shown in the calendar input from Sunday to other days (since in many countries it's Monday or even Saturday)?

Matma Rex (talkcontribs)

The start of week shown in the calendar depends on user language, e.g. it's Monday in Polish and Sunday in English.$186

The logic for this comes from the Moment.js library. It allows you to customize this: but I'm not sure what's a good way to do that without hacking up MediaWiki's files.

Also, if it's an acceptable option for you, apparently the en-gb locale is also using Monday as the first day of the week.

Yaron Koren (talkcontribs)

@Matma Rex - okay, thank you, that's good to know - both in general and about the en-gb "hack".

Reply to "Setting the first day of the week in the calendar input"

OOUI widgets are painful to style via MediaWiki:Common/SkinName.css

1 (talkcontribs)

Wdgets implemented with OOUI, such as the new recent changes widget and its filters, are painful to style for wiki admins who maintain a custom theme but only have interface admin access. As far as I understand, the "correct" method for styling OOUI is described in OOUI/Themes and would require access to the server. I haven't studied this method of styling OOUI since it is of no use to me, but I assume it would be better than using MediaWiki interface message pages to override the default style.

By "painful" I mean several things, compared to modifying the core mediawiki CSS:

  • OOUI has far greater number of CSS rules than the entire core MediaWiki + skin!
  • Styling comparable wiki interface elements (in mw-ui, I believe) before OOUI was doable with a few simple CSS rules
    • Now the same level of interface skinning takes hundreds of high-specificity CSS rules
  • Redoing all the images takes a lot of work
    • Also requires questionable hosting choices or embedding into CSS as data-URIs. (Again, for wiki content admins with no access to the server)
  • The selectors are long with high specificity
    • Resulting in barely human-readable CSS
    • No easy way to style larger groups of elements at once (simplifying the style and selectors)
  • OOUI, especially when partially reskinned through MediaWiki interface pages, has measurable impact on page loading speed on slower end-user hardware.
    • The reskinned OOUI is loaded on every page load, and the full original OOUI CSS is also loaded when needed.

I don't know how common my position is (MediaWiki content admin also maintaining custom skin w/o direct server access) and I don't know the backend well enough to suggest a solution. Perhaps OOUI stylesheets could be moved to MediaWiki interface messages to at least allow ResourceLoader could handle it better in cases like this? In any case, the seperation of interface widget style from the rest of the skin seems counterproductive.

In my opinion OOUI styles are also too complex for what they do and could be greatly simplified with minimal loss of features, but I understand there may be use cases that require such a heavy interface library. OOUI definitely is on a different level than the rest of MediaWiki styling, for good or for bad.

Reply to "OOUI widgets are painful to style via MediaWiki:Common/SkinName.css"
GZWDer (talkcontribs)

See phab:T241180 - does it mean after migration from jQuery UI and MediaWiki UI to OOUI, we will migrate all special pages to Vue.js?

Jdforrester (WMF) (talkcontribs)

We don't know yet. Possibly we'll be able to re-tool OOUI to use Vue.js, possibly we'll create a new library for the same use cases, possibly something else. We're still at the exploratory stages.

Volker E. (WMF) (talkcontribs)

What @Jdforrester (WMF) said, we're currently exploring and evaluating different paths. In the short-term we're commited to continue development and maintainenance of OOUI as it's used widely in our ecosystem. When alternatives have been reached a production-ready level, it will highly-probable be deprecated. (talkcontribs)

Will there be an attempt to remove jquery from ooui and switch to vanilla javacript?

Jdforrester (WMF) (talkcontribs)

No. We're already exceedingly sparing in where we use jQuery (only when it's faster than falling back to writing bespoke wrappers around native methods). As MediaWiki isn't planning to get rid of jQuery ever, the work to remove the last few uses when it's always around in the main environment for which we've built it isn't worth it. (talkcontribs)

There seems to be a push to remove jquery from existing software (like github did). What exactly is the point of doing this? Is it really much slower in terms of execution and loading up the jquery file ? I'm debating whether I should try to remove jquery from my wikipedia setup. The thing is that I use OOUI rather extensively (dialogs and forms) and I'd have to say goodbye to OOUI. I feel like OOUI is too complicated, large and slow to load. My gut tells me I should stop doing anything with OOUI for the time being. I tried to use OOUI as much as possible instead of using other third party libraries, but I find it annoying that I have to load the entire thing just to infuse a form and get a modern look.

Jdforrester (WMF) (talkcontribs)

As I said, we aren't planning to get rid of jQuery from MediaWiki. Attempting to do so on a third party installation is very likely to go poorly. I would not advise it.

Reply to "Will OOUI be deprecated?" (talkcontribs)


I'm migrating a wiki via upgrade. The new installation uses ooui. It's images aren't rendering. I don't know what the requirement is. They appear as invisible user interfaces like with this (wiki/Sword_of_Moonlight/installing) slideshow. I finally realized they weren't showing at all, where previously I thought they were text labels only.

Wiki is en (dot) swordofmoonlight (dot) org

Volker E. (WMF) (talkcontribs)

Could you clarify what you mean by “not rendering”. Can you access one of the images directly? If not there could be several issues involved including a ResourceLoader issue. Are any icons shown. The URL you've provided doesn't seem to use an updated MediaWiki yet. (talkcontribs)

The link is a direct link, that prints the error "Image generation failed". The wiki is upgraded to 1.33.1. The skin is based on an earlier version of MonoBook that I had to transfer to the new version. I think the new version is based on BaseTemplate instead of QuickTemplate but I didn't change that. I don't see anything in BaseTemplate that seems like OOUI would depend on its being there. But that's a possibility. I expect it's more likely something about my environment, but I'm open to anything.

BTW: I hacked in some Unicode triangles so that the slideshow buttons are visible, but those are unrelated to OOUI. Also there's a serious (unrelated) but in the slideshow I've reported here (Topic:Vcppuzq1pmnea4z3) that seems like staff should take very seriously and fix ASAP. (talkcontribs)

*bug. Also, thank you for replying :)

MSchottlender-WMF (talkcontribs)

This sounds like there's a problem of the webserver itself to produce an image (png?) from the original svg. Could you check into whether imageMagick (or whatever library is set up?) works for you in general? (talkcontribs)

ImageMagick is available and in use elsewhere. The upgrade web installer indicated it's in working order. I could try to do a test with an SVG file to see if can convert to a PNG for example... if you think that's a possibility. I don't know how to do that off the top of my head (I don't want to spend an afternoon figuring it out unless necessary.)

MSchottlender-WMF (talkcontribs)

The fact you're getting an empty message "Image generation failed" indicates to me that it's something about the server operation. I can be (very possibly) wrong, but I thought I'd point to this direction as something to verify, since I am not sure what else could prevent this other than making sure you run `composer update` and potentially `npm install`

Reply to "Image generation failed"

Getting OOUI object reference from an element?

2 (talkcontribs)

For example, I simply want to disable a button. Before I could just set the disabled property, but now I need to call the disable method on the button's OOUI object. If the button was a PHP object, I could infuse it to get the object, but for buttons created in JS (by other scripts I have no control over, for instance), infuse doesn't work.

Matma Rex (talkcontribs)

There is no way to do this. If the other script wanted you to be able to disable its button, it would allow you to get the OOUI object.

For example, the other script could do something like this:

fooWidget.$ 'ooui', fooWidget );

…but if it doesn't, there's no way to get the OOUI object from the DOM element.

How I can binding widget to select?

2 (talkcontribs)

Hello. I want to add delete reasons by script.

OO.ui.DropdownWidget.static.infuse( $( '#' + $('#wpDeleteReasonList').parent().attr('id') ) ) OO.ui.MenuOptionWidget({ data: data, label: label }), position);

It works fine, but when i choose one of my “custom reasons”, mediawiki not to provide it in delete log. For example, instead What am I doing wrong? (talkcontribs)

Sorry, wrong wikimarkup. I can’t edit previous message. My code:

OO.ui.DropdownWidget.static.infuse( $( '#' + $('#wpDeleteReasonList').parent().attr('id') ) ) OO.ui.MenuOptionWidget({
    data: data,
    label: label
}), position);
Reply to "How I can binding widget to select?"
Ainz Ooal Gown (talkcontribs)

So I recently found out about OOUI and after that I have completely rewritten my script per OOUI. My script basically adds some buttons. I noticed that all buttons' styles are based on WikimediaUI. I want to use Apex and WikimediaUI together. How to do it? It's not like I don't like this WikimediaUI. It's just I don't prefer this style. Here's the link to my script w:en:User:Masumrezarock100/mobilemorelinks/common.js.

Jdforrester (WMF) (talkcontribs)

Hey there,

The OOUI theme is decided at the MediaWiki skin level, and not available for individual on-wiki tools to adjust, sorry.

Ainz Ooal Gown (talkcontribs)

Hmm, Thanks anyway.

Return to "OOUI" page.