Page MenuHomePhabricator

Make it lovely to develop with OOjs UI
Closed, DuplicatePublic


Asking developers "What were your problems?" is rarely fruitful. So I encourage everyone to add a comment to this bug as they run into an issue, then the OOjs UI developers can decide whether issues should be addressed by code changes, samples, or documentation; and if necessary create tasks for them.

Note OOjs UI is objectively the best-documented software that WMF has ever produced, with generated doc, interactive samples, demo code, a living style guide, as well as wiki pages.

Event Timeline

Spage raised the priority of this task from to Needs Triage.
Spage updated the task description. (Show Details)
Spage added projects: OOUI, Documentation.
Spage subscribed.

CSS styling that was removed from OOjs UI core but is still used in (almost) every application uses to a point where I wonder, "Why is my app looking completely different from everyone else's." because they all use styling that I never knew about.


  • object orientation (obviously the framework's hallmark, and likely the most maintainable way of doing things, but arguably not the easiest one to start with; thankfully a lot of documentation is now available)
  • 'dirty' interaction between jQuery/DOM methods and UI objects (e.g. $div.append($button.$element))
  • high frequency of changes to classes and styles (hopefully will fade out over time)
  • MediaWiki-specific feel, lack of general-purpose features (e.g. numerical input fields)
  • lack of clean, markup-based UI system (e.g. standard HTML + mediawiki.ui), again PHP/JS-specific feel
  • lack of clean, markup-based UI system (e.g. standard HTML + mediawiki.ui), again PHP/JS-specific feel

This might be addressed by T101666: Create parser tag(s) that render OOUI PHP widgets.

Regarding object orientation, it's hard to adopt one piece of OOjs UI. E.g. if you want a set of buttons that update the dialog they're in, you probably want to create your own widget whose constructor takes the button parameters, creates a SelectWidget that in turn does a .each on the button parameters to create new OOUIButtonOption, then on choose it emits an event that the dialog connects to some state update. "The answer to problems using OOjs UI is more OOjs UI" (Roan)

VisualEditor provides lots of examples of this sort of refinement of OOjs UI, but it's complex.

Jdforrester-WMF renamed this task from pain points developing with OOjs UI (tracking) to Make it lovely to develop with OOjs UI.Mar 2 2016, 2:17 AM
Jdforrester-WMF triaged this task as Low priority.
Jdforrester-WMF set Security to None.

I'd like to point out that while OOjs UI may seem awkward at first, magic happens when you start working with object orientation rather than trying to work around it. Documentation abounds, what is missing is a list of best practices users coming from other libraries may not be familiar with.