Yes, abstraction is a great way to provide a simple interface to a subset of the functionality of a complex system of such a simple interface is needed.

If the simplified tool that designers want can be provided by abstracting a subset of OOjs UI, I think that's neat. We just need to understand that the simplified library should be built from the full library - not the opposite.

Simple problems naturally suggest simple solutions, making a complex solution like OOjs UI initially appear to be unnessecary. However as those problems inevitably grow in complexity; the functionally that OOjs UI already offers, or supports being added relatively easily, starts to become critical.

- Trevor

On Wednesday, November 11, 2015, S Page <> wrote:
On Wed, Nov 4, 2015 at 9:49 AM, Bartosz Dziewoński <> wrote:

Yeah, I was under the mistaken assumption that this is meant to be used in MediaWiki code, in production, and not as a mockup tool. ...

It seems that the goal was to bring Bootstrap as close to OOjs UI MediaWiki theme as possible,

I'm still confused. Comparing with :

* The colors are different. button-type="primary" is a different blue #165C91 than OOjs UI and MediaWiki.ui's #347BFF
* The semantics are different. In wikimedia-ui, button-type="primary" makes it blue, but in OOjs UI/MediaWiki UI, "primary" isn't a color, it's the indicator that this is the one button that gets a colored background. I don't see a way in wikimedia-ui to produce a colored non-primary button.
* The icons are different. No Alert, Clear, Help, Settings, OngoingConversation, etc. Even matching icons have different names: magnifying-glass vs. search.
* Buttons that aren't bold is quite a change.

So wikimedia-ui lets you mock up something rich and complex, but the simple things in it are different than what OOjs UI and MediaWiki UI produce. May, are these differences intentional? Can this library pull in some MediaWiki CSS with a load.php call for some basic consistency?
On Wed, Nov 4, 2015 at 9:04 AM, Trevor Parscal <> wrote:
  1. ...
  2. The kinds of controls that can be expressed in plain HTML/CSS is a fraction of what can be expressed using OOjs UI or any other JavaScript-based approach. Even simple things, like designing a type-ahead feature, can't be done using HTML/CSS alone.
This leads me to feel strongly that this while it might be cool for the production library (OOjs UI) to be used in some way to make the designer's work easier, it's not required ...

Sure, but how cool would it be if OOjs UI were expressible as WebComponent-ish things. view-source: is somehow turning tags like <wikicard> into HTML elements, so its <button> could write out the divs and spans of OOjs UI elements (or at least the basic "mw-ui-button mw-ui-progressive" classes of MediaWiki UI). If you look at the source of Andrew Garrett/Prateek Saxena's LSG [1], you see it's full of, e.g.
<ooui-demo type="button">
  "label" : "Normal Button",
  "flags": ["constructive", "primary"],

and the <ooui-demo> parser tag turns that into an actual live OOjs UI button [2]. I don't know if any next-gen HTML <buzzword> library works like that.  It's challenging, but HTML mockups don't have to be so divorced from the real OOjs UI.


[2] I just noticed MatmaRex is working on "Create parser tag(s) that render OOUI PHP widgets" \o/ ! Whatever syntax that uses probably will be a better example of representing OOjs UI.

=S Page  WMF Tech writer