Page MenuHomePhabricator

Create parser tag(s) that render OOUI PHP widgets
Open, MediumPublic

Description

It's easy to create a button or link in wikitext using mw-ui- classes. It's harder to do so using OOUI's markup, so we don't have a good story to move button templates and other wikitext UI elements to OOUI. A solution is to implement parser tag(s) that render OOUI PHP widgets (and also load the necessary ResourceLoader modules).

The OOUIPlayground extension (no longer maintained) implements something like this in its <ooui-demo> tag for the Wikimedia Design Style Guide (not being used on the styleguide anymore) (T88026: Create a nonprocedural markup for OOJS-UI), see discussion in T98395: MediaWiki UI styles loaded in head but unused on most pages.

Related Objects

Event Timeline

Spage raised the priority of this task from to Medium.
Spage updated the task description. (Show Details)
Spage added subscribers: Prtksxna, Spage, Ltrlg and 3 others.

For production? The answer is almost certainly 'no'…

I think allowing creation of arbitrary widgets is a bad idea. Instead we'll have extensions like InputBox (once converted to use OOUI) which would allow creating a small set of input widgets.

Arbitrary widgets no, but as long as we're careful not to allow anything that is not already possible in wikitext, I see no reason not to do this. People are already using buttons and icons on plenty of meta pages, so why not make it easier and make the result better? This would also let us solve T98395 eventually. We'd probably want only buttons and standalone icons – there's little use case for anything else when you can't even construct a <form> (InputBox notwithstanding).

T105413 is the reason not to allow creation of arbitrary widgets. This should definitely be a (small) whitelist of possible elements and methods available. Otherwise the surface area of potential attacks is much too high.

I envision something like this.

<ooui-button link="Main Page" title="View the main page" flags="progressive primary">Wikipedia's main page</ooui-button>
<ooui-button link="https://en.wikipedia.org/w/index.php?title=Main_Page&action=history" icon="history">View edit history</ooui-button>
<ooui-icon icon="heart" size="2x" />

For <ooui-button>, the link parameter would be treated similarly to [[File:Foo.jpg|link=...]] syntax, and map to href option of ButtonWidget. Tag contents would be used as label, and should probably support wikitext formatting (although we should process it to remove nested links). Everything else would map fairly directly to various other options (with a whitelist, just in case, but allowing everything that a ButtonWidget can ordinarily do).

For <ooui-icon>, size would specify size multiplier (icons are normally 24x24px and this would also be the case here, unless overridden this way). This would just be a shortcut for <span style="font-size: 2em"><ooui-icon ... /></span> or some such. OOUI doesn't provide a way to set icon size directly in pixels, and neither would this.

All existing icons would be allowed for both, with the necessary icons packs getting loaded to provide them.

<ooui-button link="Main Page" title="View the main page" flags="progressive primary">Wikipedia's main page</ooui-button>
<ooui-button link="https://en.wikipedia.org/w/index.php?title=Main_Page&action=history" icon="history">View edit history</ooui-button>
<ooui-icon icon="heart" size="2x" />

I don't think we should include the "ooui" name in the parser tags. Users should not care that it is backed by OOUI, just that they want a <button> or <icon>.

I don't think we should include the "ooui" name in the parser tags. Users should not care that it is backed by OOUI, just that they want a <button> or <icon>.

Wouldn't that make harder to swap OOUI for a different library?

I don't think we should include the "ooui" name in the parser tags. Users should not care that it is backed by OOUI, just that they want a <button> or <icon>.

I agree, but I'm also wary of "overloading" the <button> tag with something that isn't HTML <button>. We unintentionally did that in LST (the <section> tag) and now that's preventing us from allowing the HTML <section> tag in wikitext (T25932). On the other hand, overloading <pre> seems to have caused no such ill effects…

Wouldn't that make harder to swap OOUI for a different library?

Probably not, as long as the hypothetical library supports the same features. We could limit the allowed attributes to make such hypothetical transition easier.

Aw, hell, maybe I'll actually do this.

Change 249452 had a related patch set uploaded (by Bartosz Dziewoński):
Implement <button> tag in wikitext for OOjs UI clickable buttons

https://gerrit.wikimedia.org/r/249452

Change 249453 had a related patch set uploaded (by Bartosz Dziewoński):
Implement <icon> tag in wikitext for OOjs UI icons

https://gerrit.wikimedia.org/r/249453

The patches are missing localisation messages and parser tests. Perhaps someone will mercifully add them.

A representative snippet I've been using for testing: (some of these check the error cases)

<button>Button</button>
<button link="Main Page"></button>

<button link="Main Page">foo[[Main Page]]foo</button>

<button link="Main Page">multi

line</button>

text <button link="Main Page">Button</button> text

<button link="Main Page" title="View the main page" flags="progressive primary">Wikipedia's main page</button>
<button link="https://en.wikipedia.org/w/index.php?title=Main_Page&action=history" icon="history">View edit history</button>

<button link="Button" icon=history frameless />


<icon/>
<icon></icon>
<icon>history</icon>
<icon size="2" title="History">history</icon>
<icon size="0.5">history</icon>

Argh. This is only going to increase the overlap between "content" and "interface", which causes all sorts of localization and caching issues (see T114640 for some discussion). I understand why this feature is wanted, but it would be nice if we could take a step back and think about the architecture to see if we can recover the separation between content and interface elements.

I agree, but I'm also wary of "overloading" the <button> tag with something that isn't HTML <button>. We unintentionally did that in LST (the <section> tag) and now that's preventing us from allowing the HTML <section> tag in wikitext (T25932). On the other hand, overloading <pre> seems to have caused no such ill effects…

Then use mw-button instead of ooui-button. We don't overload <pre>, our parser pretty much generates HTML <pre> for wikitext <pre>, although some wikitext handling changes inside. We certainly don't generate some *other* HTML tag for wikitext <pre>.

<section> (cf. T32597: <section> tag name collides with HTML5 <section> tag which is sitting here open for ages... :-/) and <source> (cf. T39042: Remove <source> syntax from SyntaxHighlight (GeSHi), unfortunatelly declined although reported in times when it was not spreaded so much) extension tags AFAIR came before HTML5 which introduced these tags, so it was pretty much not influenceable, while <button> is known for ages instead, and we must avoid any kind of overrides to such tags.


Side note: The best approach would be to use mw: namespace in all tags we use (ie. <mw:poem>, <mw:score>, <mw:math>, <mw:ref> etc...) to be future-compatible-safe, but that's other story....

Current versions of the patches use <mw-button> and <mw-icon>.

I would definitely like to know arguments which would speak against using of own namespace as mentioned before.

Because our markup is not XML (for example, you can't nest tags) and I don't want to pretend it is. I also don't want to have to write the documentation that would explain the difference between this and the other kind of namespaces we have.

Change 249453 had a related patch set uploaded (by Jforrester; owner: Bartosz Dziewoński):
[mediawiki/core@master] Implement <mw-icon> and <mw-button> tags in wikitext for OOUI icons/buttons

https://gerrit.wikimedia.org/r/249453

In my honest opinion, this task should be declined and the focus given to Codex and T317270: [TDMP] Modern user interfaces for all users instead.

I'm sure the 2 people working on Codex will get around to it aaaany time now. I've proposed my patch almost 7 years ago and no one was interested enough to approve it.

Change 249453 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] Implement <mw-icon> and <mw-button> tags in wikitext for OOUI icons/buttons

Reason:

https://gerrit.wikimedia.org/r/249453

In my honest opinion, this task should be declined and the focus given to Codex and T317270: [TDMP] Modern user interfaces for all users instead.

What about repurposing this task to ask for Codex buttons instead of OOUI/mw-ui-* ones? The need is still there, only the underlying library changed.

Change 963840 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Implement <mw-button> tags in wikitext for Codex button

https://gerrit.wikimedia.org/r/963840

Change 963840 abandoned by Jdlrobson:

[mediawiki/core@master] Implement <mw-button> tags in wikitext for Codex button

Reason:

Will post some thoughts on Phab shortly.

https://gerrit.wikimedia.org/r/963840