For simpler gadgets, user styles, common project/wiki styles, templates like Clickable button or pages in Help and Wikipedia namespaces it would be sometimes suitable to use just CSS-only version of the buttons and other elements from OOjs UI. We discussed some possibilities for cswiki on #wikimedia-tech IRC (log here). I tried to create template using OOjs UI for clickable button at cswiki here, but the result has got some bugs (especially in focus/hover/active state). The icons and labels are also hard to add into this template
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
I'm not sure this makes sense as something we could deliver. The whole point of OOUI is to abstract the DOM representation into a constructor; applying random CSS to random HTML elements is exactly what we're trying to avoid. This is like asking for just the paint job of the car.
Comment Actions
What would you suggest for templates like Clickable button? I don't know if you understand the purpose of this issue correctly but I'd like to have a simple way, how to convert Clickable button template into OOUI. In MWUI or older UIs there always were a class (e.g. .mw-ui-constructive), which applied on anything changed it into clickable button. But for OOUI there isn't any way, how to make Clickable button template in OOUI without using wikipedia's Common.js. Is there a possibility to load OOUI from Lua module? It would be another chance, how to achieve this in a template.
Comment Actions
I'd suggest not trying to make it look like an official part of the software, but that's not a popular opinion.
In MWUI or older UIs there always were a class (e.g. .mw-ui-constructive), which applied on anything changed it into clickable button.
But for OOUI there isn't any way, how to make Clickable button template in OOUI without using wikipedia's Common.js.
OOUI isn't for wiki-land styling. It's for application-level code.
Is there a possibility to load OOUI from Lua module? It would be another chance, how to achieve this in a template.
Well any gadget can of course use OOUI.
Comment Actions
But there are still attempts to use OOUI, MWUI or any older UI. Usually in project, help or portal namespaces. And not only by Clickable button template, but also using raw code we try to avoid. I've thought about this issue and got an idea. What about creating global styling guidelines (which don't have to be only for wikis) about how to make some UI elements. It could be backed up by some examples and some little UI classes included in mediawiki. Of course every project could adjust them to their needs. But some global common little helpers wouldn't be bad.
Comment Actions
@Dvorapa: Let me rephrase what @Jdforrester-WMF said ("OOUI isn't for wiki-land styling. It's for application-level code."):
OOUI is a generic approach how to build components the way you no longer have to care about their look (among other things, this is the relevant one ATM). What you are asking for, is to have the currently used skin available, which - as far as I looked in sources is, since selectors are pure classnames, nothing is tighten to particular elements, so even links should be achievable. Also bear in mind, that OOUI is at first intended for user interface (as the name suggests), not for the editable content (which doesn't imply that it can't be used, but it obviously needs some tweaks and tricks). And also mind, that only buttons can be achieved in editable wikitext, since no other elements (form elements) are permitted, thus you are actually asking for a subset of current OOUI skin.
It should be also taken into consideration, that there is a reason to have different view of user interface vs. editable content. It's actually to prevent confusing of the user, so (s)he can clearly distinguish between what is fixed and what editable, what is part of MediaWiki interface and what has been added as a content by users.
You mentioned issues with https://cs.wikipedia.org/wiki/%C5%A0ablona:Klikateln%C3%A9_tla%C4%8D%C3%ADtko - first of all, its code is quite different from the real OOUI-generated code, so no doubt it does not behave same. You mentioned "some bugs (especially in focus/hover/active state). The icons and labels are also hard to add into this template" - please elaborate. I've tested myself and encountered no issue (I haven't tested every single combination in every major browser engine though), everything worked like it should.
In fact, the CSS exists and is delivered. The only thing is, that both CSS and HTML need some tweaks and tricks for having the OOUI buttons look exactly the same in editable content. And that is achievable locally, which is not global MediaWiki issue, hence (and per @Jdforrester-WMF's comments) the entire task would deserve declining, however I'm setting Low priority, just in case somebody would be willing to incorporate such styling into core stylesheets.
Comment Actions
Yes. I think this is closely related to T116549: Provide a color palette and design for buttons that are purely highlighted links, to distinguish them from actual UI buttons - which I filed out of frustration at well-intentioned editors mis-using the UI classes and colors - e.g. using the destructive class simply because they wanted a bright red and highly visible button.
You mentioned "some bugs (especially in focus/hover/active state). The icons and labels are also hard to add into this template" - please elaborate. I've tested myself and encountered no issue (I haven't tested every single combination in every major browser engine though), everything worked like it should.
This is probably (at least partially) related to these 2 questions at Extension talk:InputBox: https://www.mediawiki.org/wiki/Topic:So8wytkvzm7fpixr and https://www.mediawiki.org/wiki/Topic:T2pl2op4z0od815q - which is also covered by the task I linked.
Comment Actions
This is not going to happen. OOUI is planned to be replaced by Vue.js based user-interface component library. And we're not planning on extended styling capacities of elements CSS only for interaction reasons, but there's early conversations of how to tackle gadget support by Vue components.