I believe the official name is 'MediaWiki UI' now. It even has its own Bugzilla component.

I don't think you're right that they "do not make sense with most skins", but there are definitely some skins that MediaWiki UI styles don't fit.

I think the best way to resolve this would be to make the MediaWiki UI modules' styles overridable with $wgResourceModuleSkinStyles [1] – this way skins that implement really custom look would be able to change (or just disable) the styling.

This basically requires changing 'styles' => array( … ) in module definitions to 'skinStyles' => array( 'default' => array( … ) ). (jQuery UI modules are actually done this way, with custom style overrides in Vector – they're a good example to follow here.)

[1] https://www.mediawiki.org/wiki/Manual:$wgResourceModuleSkinStyles

(In reply to Bartosz Dziewoński from comment #1)

I believe the official name is 'MediaWiki UI' now. It even has its own
Bugzilla component.

Are you sure about that? That name suggests it should concern the base skinning modules and framework; this concerns only a very small subset of the overall UI.

I don't think you're right that they "do not make sense with most skins",
but there are definitely some skins that MediaWiki UI styles don't fit.

They don't make sense with ANY of my skins, and most of them aren't that out there (take greystuff, for instance - it's basically as simple as you can get and still have a designed skin, and it still clashes with the form UI there).

I think the best way to resolve this would be to make the MediaWiki UI
modules' styles overridable with $wgResourceModuleSkinStyles [1] – this way
skins that implement really custom look would be able to change (or just
disable) the styling.

As a general rule, skins implement their own visual styles, this being the entire point of a skin. Some may look similar to others (such as vector and monobook), but it's not the norm, and it definitely should not be the expectation.

These styles are being designed for specific skins - namely vector and minerva - and are designed for those skins for a reason.

Distinctive visual styles (really custom looks like this) have no place in core, because skins aren't part of core (the base skinning modules are very generic and do not contain distinctive design elements for this reason).

Isarra, Bartosz is correct about both the bugzilla component and the naming convention.

I'm sorry that you feel that medaiwiki.ui is in conflict with your custom skins, but as I said before, the fact that they are built around LESS should make them easy to configure once they've reached a higher level of maturity as a component.

Thanks for clarifying. I suppose mw.ui does make as much sense as any as a name for the infrastructure for such element styling (since such things can be right difficult to name at all meaningfully), but it needs to be decoupled from the styles themselves. Such distinctive styles have no place in core.

(In reply to Isarra from comment #2)

I think the best way to resolve this would be to make the MediaWiki UI
modules' styles overridable with $wgResourceModuleSkinStyles [1] – this way
skins that implement really custom look would be able to change (or just
disable) the styling.

As a general rule, skins implement their own visual styles, this being the
entire point of a skin. Some may look similar to others (such as vector and
monobook), but it's not the norm, and it definitely should not be the
expectation.

MediaWiki itself also implements quite a bit of visual styling. Things like wikitables and thumbnails are the most obvious (although technically you can opt out of them by not including basic style modules), but there are also, say, the styles for tables like the one on Special:ListFiles (which can't be opted out of at all at the moment).

These styles are being designed for specific skins - namely vector and
minerva - and are designed for those skins for a reason.

Distinctive visual styles (really custom looks like this) have no place in
core, because skins aren't part of core (the base skinning modules are very
generic and do not contain distinctive design elements for this reason).

I was under the impression that MediaWiki UI, while geared towards Vector, is supposed to be reasonably neutral and usable with most skins. Admittedly, they're completely unlike default buttons styles on every OS I've ever seen.

The generic styles for wikitables and thumbnails and toc and all that stuff are just that, though - generic. They're simple and tend to work with a lot of different designs because they don't do anything special. (This also makes them easier to override.)

The mw.ui styles that I have seen are very different from those, and definitely not simple. A default set of mw.ui styles matching the tone of the other interface elements might make sense for core, indeed, but what we have currently is not that, and this is a problem.

(In reply to Bartosz Dziewoński from comment #5)

I was under the impression that MediaWiki UI, while geared towards Vector,
is supposed to be reasonably neutral and usable with most skins. Admittedly,
they're completely unlike default buttons styles on every OS I've ever seen.

I think they are usable with a good number of skins. However, while the class names and HTML structure must be usable on all skins, I've said consistently that different skins can (and probably should in certain cases) implement their own appearance using skinStyles.

skinStyles can already be used to add additional styles (but not erase the 'styles' ones). However, I'm fine with changing it to use 'default' if that's useful (to allow replacing certain parts). It may make sense to have a mixture eventually, not sure.

If we need to pull some stuff out into Vector, that's fine too. However, last time we tried to do that (before the skin refactor), we hit the problem that other widely used skins (i.e. Monobook, but also others) did not implement custom styling for important features (buttons).

Isarra, if you're interested in concretely making a particular skin work better with MW UI, I will help support your work on that.

(In reply to Matthew Flaschen from comment #7)

Isarra, if you're interested in concretely making a particular skin work
better with MW UI, I will help support your work on that.

I don't expect to have time to work on the actual styling in other skins, but I can help remove roadblocks (such as skinStyles structure).

(In reply to Matthew Flaschen from comment #7)

(In reply to Bartosz Dziewoński from comment #5)

I was under the impression that MediaWiki UI, while geared towards Vector,
is supposed to be reasonably neutral and usable with most skins. Admittedly,
they're completely unlike default buttons styles on every OS I've ever seen.

I think they are usable with a good number of skins. However, while the
class names and HTML structure must be usable on all skins, I've said
consistently that different skins can (and probably should in certain cases)
implement their own appearance using skinStyles.

I have yet to see any skin with which these styles ARE visually compatible (Winter would probably be the exception here, but it doesn't seem to currently be implemented as a skin).

I agree that other skins should usually be implementing their own styles, but lacking that, these styles should not be applied to all skins by default - it's a breaking change for existing skins, and makes new ones that much harder to create as well.

skinStyles can already be used to add additional styles (but not erase the
'styles' ones). However, I'm fine with changing it to use 'default' if
that's useful (to allow replacing certain parts). It may make sense to have
a mixture eventually, not sure.

If we need to pull some stuff out into Vector, that's fine too. However,
last time we tried to do that (before the skin refactor), we hit the problem
that other widely used skins (i.e. Monobook, but also others) did not
implement custom styling for important features (buttons).

Do the other skins necessarily need it at all? Usually if someone is using monobook, for instance, one of the main selling points is the simplicity, and applying this removes that simplicity. Sure, the colour-coded buttons according to their function are nice, but not everyone cares.

Isarra, if you're interested in concretely making a particular skin work
better with MW UI, I will help support your work on that.

Is there any documentation on how to do that, or use the underlying framework? From where I'm standing it looks like the only option is to manually override all the styles, and when they keep changing and getting more complex, that's pretty horrible.

(In reply to Isarra from comment #9)

Sure, the colour-coded buttons according to their function are nice, but not everyone cares.

And yet someone complained about *not* having them at bug 47698 (see also bug 55554, where this was brought up again and the colors were added to non-Vector), because the alternative was gray.

Bear in mind that "no MW UI styles" at all may not always do what you want. For example Special:UserLogin has a "Join $SITENAME" button. However, it's really just a styled link, so if it's completely unstyled it will look like a link.

So rather than debate between "no MW UI styles" and "current MW UI styles" for e.g. FooSkin, I'd rather support people who want to make appropriate styles for FooSkin (unless there's a broad consensus that FooSkin should have either "no MW UI styles" or "current MW UI styles"; honestly not many people have voiced opinion on which of the three).

Is there any documentation on how to do that, or use the underlying
framework? From where I'm standing it looks like the only option is to
manually override all the styles, and when they keep changing and getting
more complex, that's pretty horrible.

The basic tool is https://www.mediawiki.org/wiki/Manual:$wgResourceModuleSkinStyles , along with the discussion above about whether you're augmenting or replacing styles (that is important re what I said about 'default').

Importantly, there are also mixins at https://git.wikimedia.org/tree/mediawiki%2Fcore.git/e2e6f7767ef58659904422c36d390c230b59852f/resources%2Fsrc%2Fmediawiki.less which you can use (note the mediawiki.less/mediawiki.ui directory, which has mixins and variables). These can be imported with e.g.:

@import "mediawiki.ui/variables";

(In reply to Matthew Flaschen from comment #10)

(In reply to Isarra from comment #9)

Sure, the colour-coded buttons according to their function are nice, but not everyone cares.

And yet someone complained about *not* having them at bug 47698 (see also
bug 55554, where this was brought up again and the colors were added to
non-Vector), because the alternative was gray.

That was when overriding the default styles. I'm saying not all skins will even want to do that.

That being said, this also comes up with regard to js gadgets, which will often use special buttons even when the skin may not, and they will need a sane coloured button default.

Bear in mind that "no MW UI styles" at all may not always do what you want.
For example Special:UserLogin has a "Join $SITENAME" button. However, it's
really just a styled link, so if it's completely unstyled it will look like
a link.

And what's wrong with having a simple link when you're going for low-key? To take it even further, I've designed a skin where the login form didn't look like a form at all, but just a page you write your credentials on. But that was for a game, and in the context of the game, that made sense.

There are a lot of ways these things can go.

So rather than debate between "no MW UI styles" and "current MW UI styles"
for e.g. FooSkin, I'd rather support people who want to make appropriate
styles for FooSkin (unless there's a broad consensus that FooSkin should
have either "no MW UI styles" or "current MW UI styles"; honestly not many
people have voiced opinion on which of the three).

All three should be options. We need a sane default (in core, that can be used by whatever skin if desired, and will be included in the main one(s)) as well as something to be included as the initial example for new skins (as in, with the Example skin), however. Currently we have neither of these.

Theming extensions should also be able to apply common/new MW UI styles to skins, if needed, however. This would be useful for site branding in particular, because then an organisation could take a generic skin like vector and easily apply their own branding to everything. This could also be a way for the WMF to start distinguishing its own wikis from everyone else's using the default skins.

Is there any documentation on how to do that, or use the underlying
framework? From where I'm standing it looks like the only option is to
manually override all the styles, and when they keep changing and getting
more complex, that's pretty horrible.

The basic tool is
https://www.mediawiki.org/wiki/Manual:$wgResourceModuleSkinStyles , along
with the discussion above about whether you're augmenting or replacing
styles (that is important re what I said about 'default').

Importantly, there are also mixins at
https://git.wikimedia.org/tree/mediawiki%2Fcore.git/
e2e6f7767ef58659904422c36d390c230b59852f/resources%2Fsrc%2Fmediawiki.less
which you can use (note the mediawiki.less/mediawiki.ui directory, which has
mixins and variables). These can be imported with e.g.:

@import "mediawiki.ui/variables";

But if that's variables, what about the framework? What all can we change? How do we include the js for the form elements (since a lot simply CANNOT be styled with css alone)? How do we create our own styles from the ground up, not just change some colours and crap? Or is that all in there somewhere?

(In reply to Isarra from comment #11)

That being said, this also comes up with regard to js gadgets, which will
often use special buttons even when the skin may not, and they will need a
sane coloured button default.

That's kind of what I'm getting at below (the login page was just an example). JS gadgets and user scripts (even on-wiki content, for mediawiki.ui.button specifically) have access to the MW UI modules. However, if a JS gadget makes a MW UI button, it's going to look however MW UI buttons look in the skin. If there are no MW UI styles in that skin, it's going to look totally unstyled.

There's not going to be an exception where FooSkin MW UI buttons from core pages normally look like X, but gadgets running on a FooSkin wiki look like Y. All FooSkin MW UI buttons are going to look the same (except that constructive looks different from progressive, etc.).

All three should be options. We need a sane default (in core, that can be
used by whatever skin if desired, and will be included in the main one(s))

That's the existing implementation.

Is there any documentation on how to do that, or use the underlying
framework? From where I'm standing it looks like the only option is to
manually override all the styles, and when they keep changing and getting
more complex, that's pretty horrible.

The basic tool is
https://www.mediawiki.org/wiki/Manual:$wgResourceModuleSkinStyles , along
with the discussion above about whether you're augmenting or replacing
styles (that is important re what I said about 'default').

Importantly, there are also mixins at
https://git.wikimedia.org/tree/mediawiki%2Fcore.git/
e2e6f7767ef58659904422c36d390c230b59852f/resources%2Fsrc%2Fmediawiki.less
which you can use (note the mediawiki.less/mediawiki.ui directory, which has
mixins and variables). These can be imported with e.g.:

@import "mediawiki.ui/variables";

But if that's variables, what about the framework? What all can we change?

There are also mixins at mediawiki.ui/mixins (e.g. button-colors, which will let you make MW UI-style buttons, but have your own color choices). (I realize some skins might want to go for a totally different button approach, but this is one tool)

See https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/resources%2Fsrc%2Fmediawiki.less%2Fmediawiki.ui%2Fmixins.less

How do we include the js for the form elements (since a lot simply CANNOT be
styled with css alone)?

MediaWiki UI has no JavaScript currently, though it may be necessary for future work.

How do we create our own styles from the ground up,
not just change some colours and crap? Or is that all in there somewhere?

If you're doing it from the ground up, basically the same as any other LESS or CSS (you can use either).

You would then use +foo or foo (see https://www.mediawiki.org/wiki/Manual:$wgResourceModuleSkinStyles) depending on whether you're replacing the whole module, or augmenting it (MW UI itself is broken into multiple modules, which will probably make your job easier, since you can choose to e.g. replace the button module, but leave the checkbox module intact).

This requires the 'default' thing I mentioned earlier, which I'll try to do soon, since it doesn't actually hurt anything (even if no one actually makes a skin-specific MW UI).

This bug doesn't seem actionable right now.

I would suggest that the existing modules are adapted to use skin styles, so skins can make their own modifications, omit the styles altogether if they wish but default should be the current status quo.

FYI in future I anticipate MediaWiki UI will just become a theme on top of OOUI, hence the lack of JS.

Bartosz hit the nail on the head in comment #1.

gerritadmin wrote:

Change 161173 had a related patch set uploaded by Mattflaschen:
Change MediaWiki UI to use skinStyles so skins can customize

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

(In reply to Jon from comment #13)

This bug doesn't seem actionable right now.

I would suggest that the existing modules are adapted to use skin styles, so
skins can make their own modifications, omit the styles altogether if they
wish but default should be the current status quo.

I think this is in fact the main actionable item, so I've submitted a patch.

gerritadmin wrote:

Change 161173 merged by jenkins-bot:
Change MediaWiki UI to use skinStyles so skins can customize

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

You can now override or disable MediaWiki UI styling in your skin. There are more interesting examples on [[mw:Manual:$wgResourceModuleSkinStyles]], but the minimal code to disable everything MWUI is:

$wgResourceModuleSkinStyles['yourskinname'] = array(
'mediawiki.ui' => array(),
'mediawiki.ui.checkbox' => array(),
'mediawiki.ui.anchor' => array(),
'mediawiki.ui.button' => array(),
'mediawiki.ui.input' => array(),
);

I think requiring skins to use this snippet to disable MediaWiki UI is a reasonable solution, better than moving all of the styles out of MW core to Vector skin or disabling them by default and requiring that skins use a similar magic incantation to enable them.

If you've got some designs/styles you'd want to use, I'll be happy to help port them.

(In reply to Bartosz Dziewoński from comment #17)

You can now override or disable MediaWiki UI styling in your skin.

That's backwards, though, and still not backwards-compatible. Doing it as opt out as opposed to opt in means skin developers will need to go back and add that to every single skin, and add that to every new skin that isn't intended to use it (which will be most) will also need to add it. That's not reasonable.

(In reply to Isarra from comment #18)

(In reply to Bartosz Dziewoński from comment #17)

You can now override or disable MediaWiki UI styling in your skin.

That's backwards, though, and still not backwards-compatible. Doing it as
opt out as opposed to opt in means skin developers will need to go back and
add that to every single skin, and add that to every new skin that isn't
intended to use it (which will be most) will also need to add it. That's not
reasonable.

MediaWiki has never been fully backwards compatible with skins, AFAICT. Every new release of MediaWiki can (and often does) add new HTML elements that can be skinned.

The ideal is that every skin will decide whether they want to use the default implementation. If not, they will decide whether to go completely unskinned (which I don't recommend for the reasons I already stated) or to skin mediawiki.ui with their own skin-specific stylings using the standard mechanism (I expect skins will start doing this).

You have not proposed a concrete implementation of MW UI (other than none at all, which I am not convinced of) that you think core should ship with.

If I understand correctly, Isarra is suggesting there should be an alternative UI option, which uses the previous/classic styling.
Secondly, she is suggesting that the "classic styling" should be the default shipped with mediawiki for re-users, at least until such time as MW UI is a cohesive and complete implementation of the total overhaul that it eventually aims to be. (i.e. when many more of the cards in https://trello.com/b/EXtVTJxJ/mediawiki-ui are complete)

(In reply to Bartosz Dziewoński from comment #5)

I was under the impression that MediaWiki UI, while geared towards Vector,
is supposed to be reasonably neutral and usable with most skins. Admittedly,
they're completely unlike default buttons styles on every OS I've ever seen.

Indeed. Some mediawiki users will prefer the OS style defaults. Those OS styles are inconsistent with each other, but the users of each distinct OS will be used to the visuals. E.g. A corporate intranet using mediawiki, might dislike having experimental interface changes, and red and green and blue controls, suddenly a part of their interface, when they're used to plain white and gray or shiny-blue.

[Does Mac still rock the shiny-blue? Ah, yup still aqua. (Tangent: https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP30000359-TP6 Hmm, similarities in ChromeOS. http://www.chromium.org/chromium-os/user-experience/ui-elements and the "still trying" MS http://msdn.microsoft.com/library/windows/desktop/dn742399.aspx and Gnome's too (spread across dozens of subpages >.< ) https://developer.gnome.org/hig-book/stable/controls.html.en and android https://developer.android.com/guide/topics/ui/controls.html )]

(In reply to Matthew Flaschen from comment #12)

This requires the 'default' thing I mentioned earlier, which I'll try to do
soon, since it doesn't actually hurt anything (even if no one actually makes
a skin-specific MW UI).

(In reply to Matthew Flaschen from comment #19)

You have not proposed a concrete implementation of MW UI (other than none at
all, which I am not convinced of) that you think core should ship with.

If I'm correct about all of the above (unlikely!) she's hoping for that 'default' thing, at least until the MW UI overhaul is further along.
HTH. :)

(In reply to Quiddity from comment #20)

If I understand correctly, Isarra is suggesting there should be an
alternative UI option, which uses the previous/classic styling.
Secondly, she is suggesting that the "classic styling" should be the default
shipped with mediawiki for re-users, at least until such time as MW UI is a
cohesive and complete implementation of the total overhaul that it
eventually aims to be. (i.e. when many more of the cards in
https://trello.com/b/EXtVTJxJ/mediawiki-ui are complete)

Bartosz has already explained how the styles can be disabled, partially or entirely.

However, it should be re-iterated that disabling all of them (with no replacement) can lose information. To add another example, we're close to merging https://gerrit.wikimedia.org/r/#/c/158632/ (adds icons, including buttoned icons, fixes bug 55535).

There is no native browser control for buttons with both icons and text (AFAIK) (or various other things that will be coming). In other words, there is no classic styling for this, and no previous styling since we never had this feature in the old days.

(In reply to Bartosz Dziewoński from comment #5)

I was under the impression that MediaWiki UI, while geared towards Vector,
is supposed to be reasonably neutral and usable with most skins. Admittedly,
they're completely unlike default buttons styles on every OS I've ever seen.

E.g. A corporate intranet using mediawiki,
might dislike having experimental interface changes, and red and green and
blue controls, suddenly a part of their interface, when they're used to
plain white and gray or shiny-blue.

And I expect there will be a skin that caters for this (while considering the issue of what information to preserve, as I mentioned above).

Vector (the default skin) is going to continue with the current style, and it will also remain the default style until there's a consensus on another default.

(In reply to Matthew Flaschen from comment #12)
If I'm correct about all of the above (unlikely!) she's hoping for that
'default' thing, at least until the MW UI overhaul is further along.
HTH. :)

The 'default' thing is done.

Quiddity got a lot of it, I think.

(In reply to Matthew Flaschen from comment #19)

MediaWiki has never been fully backwards compatible with skins, AFAICT.
Every new release of MediaWiki can (and often does) add new HTML elements
that can be skinned.

Apples and oranges. New html elements, even new styled things, normally have very generic styles, if any, and do not require anything special of most skins. Consider the screenplay extension Bartosz and I worked on: it adds a completely new page layout, with its own styles and everything, but it stills works out of the box on nearly every skin I tested it on because it only changes the things it needs to (mainly text placement and font - everything else is inherited). The only one that failed was BlueSky, which uses particularly large text and a fixed-width, resulting in the lines not fitting in the page.

That's not the issue here. The breaking changes for skins are more along the lines of backend refactorings that remove required functions, hard-coded styles that can't be easily overridden, and deprecations of things that never got replacements.

And that needs to stop.

In this case that the skin-specific styles now at least can be disabled is an improvement, but that is still backwards: they shouldn't be enabled at all unless the skin specifically wants them.

There are specific skins for which they are designed. There are many, many more skins for which they were not designed for. Why do the many, many skins need to manually disable something when the far fewer number could enable it, instead, to the same effect and requiring much less overall effort?

Generic default styles would fix this, but they don't currently exist, so having nothing by default really is the best solution at present.

You have not proposed a concrete implementation of MW UI (other than none at
all, which I am not convinced of) that you think core should ship with.

What does that even mean? How do you "propose a concrete implementation"?

If I had a working framework for styling form elements, I could probably create some mocks of a more generic set of default styles, but as is I don't understand what is going on with the backend for this at all.

(In reply to Matthew Flaschen from comment #21)

Vector (the default skin) is going to continue with the current style, and
it will also remain the default style until there's a consensus on another
default.

Where was the consensus for the current style?

(In reply to Isarra from comment #22)

In this case that the skin-specific styles now at least can be disabled is
an improvement, but that is still backwards: they shouldn't be enabled at
all unless the skin specifically wants them.

For the time being, it's not a skin-specific style.

having nothing by default really is the best solution at present.

That's your opinion. No other skin writers have expressed that opinion, as far as I know.

You have not proposed a concrete implementation of MW UI (other than none at
all, which I am not convinced of) that you think core should ship with.

What does that even mean? How do you "propose a concrete implementation"?

Either provide CSS or LESS, or at least a mockup.

If I had a working framework for styling form elements, I could probably
create some mocks of a more generic set of default styles, but as is I don't
understand what is going on with the backend for this at all.

There is nothing special about either MediaWiki's LESS support, or the MediaWiki UI modules. MediaWiki doesn't even use custom PHP LESS functions anymore, and you can still write skins in 100% CSS.

I don't understand what part of the backend you feel blocks your work on an alternative skin for MediaWiki UI.

(In reply to Matthew Flaschen from comment #24)

(In reply to Isarra from comment #22)

In this case that the skin-specific styles now at least can be disabled is
an improvement, but that is still backwards: they shouldn't be enabled at
all unless the skin specifically wants them.

For the time being, it's not a skin-specific style.

having nothing by default really is the best solution at present.

That's your opinion. No other skin writers have expressed that opinion, as
far as I know.

Jack Phoenix (who probably holds the record on number of skins created and maintained) agrees; he just gave up on trying to argue with people about skin-related things long ago because nobody ever listens. I keep trying, because I'm insane. Also it actually has gotten better more recently, but only kind of.

If I had a working framework for styling form elements, I could probably
create some mocks of a more generic set of default styles, but as is I don't
understand what is going on with the backend for this at all.

There is nothing special about either MediaWiki's LESS support, or the
MediaWiki UI modules. MediaWiki doesn't even use custom PHP LESS functions
anymore, and you can still write skins in 100% CSS.

I don't understand what part of the backend you feel blocks your work on an
alternative skin for MediaWiki UI.

mwui has to have some kind of framework for the form elements, or it would be impossible to reliably style anything beyond the buttons (css is just not that well supported for form elements on all browsers). But I've seen other form elements in the prototypes. How was this done?

(In reply to Isarra from comment #25)

That's your opinion. No other skin writers have expressed that opinion, as
far as I know.

Jack Phoenix (who probably holds the record on number of skins created and
maintained) agrees; he just gave up on trying to argue with people about
skin-related things long ago because nobody ever listens.

Thanks, that's good to know. Has he commented as such publicly?

I don't understand what part of the backend you feel blocks your work on an
alternative skin for MediaWiki UI.

mwui has to have some kind of framework for the form elements, or it would
be impossible to reliably style anything beyond the buttons (css is just not
that well supported for form elements on all browsers). But I've seen other
form elements in the prototypes. How was this done?

I'm not sure what you mean by framework. We're not using any third-party libraries (except for the LESS implementation itself, http://leafo.net/lessphp/). It is all standard LESS. It does include use of mixins (a function that can be used to reuse CSS/LESS code) and variables.

For things like mw-ui-checkbox, it just uses clever LESS, compiling to CSS. See https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/resources%2Fsrc%2Fmediawiki.ui%2Fcomponents%2Fcheckbox.less .

The markup for that actually is relatively standard too, just with a wrapping div:

<div class="mw-ui-checkbox">

<input name="someInput" value="1" id="someInput" type="checkbox">
<label for="someInput">The label for the input</label>

</div>

(In reply to Isarra from comment #23)

(In reply to Matthew Flaschen from comment #21)

Vector (the default skin) is going to continue with the current style, and
it will also remain the default style until there's a consensus on another
default.

Where was the consensus for the current style?

I'm talking about consensus on the issue of whether it should be Vector-only, vs. the default implementation.

1. We tried minimalistic styles for MediaWiki UI in non-Vector skins, and people objected that they didn't look like Vector

MZMcBride: "The blue button is no longer blue. [...] Why is it acceptable to use the blue and green in Vector but not in Monobook? [...] Vector and Monobook are very similar in design. I don't understand why it's acceptable to use bright green and blue in Vector, but not in Monobook." (bug 47698)

Dan Garry: "Coloured buttons are important as part of a move we're doing towards making Wikimedia sites have a more fluid user experience, so it'd be great if MonoBook could be modified to incorporate those." (bug 55554)

(Both of the bugs have comments from other people, too, obviously).

2. Most importantly, no one has mocked up or implemented what alternative implementation it should like by default. Rough Consensus and Running Code (or Running Styles as the case may be).

If you want to do a pure mockup (no CSS or LESS yet, just a drawing), the various sections of https://tools.wmflabs.org/styleguide/desktop/index.html are good things to mock up.

You also did not reply to my point that "no styles whatsoever" causes you to completely lose features:

"There is no native browser control for buttons with both icons and text (AFAIK) (or various other things that will be coming). In other words, there is no classic styling for this, and no previous styling since we never had this feature in the old days."

Note this is now merged (https://gerrit.wikimedia.org/r/#/c/158632). Simply dropping all MW UI would break this feature.

If we did choose a more minimalist default (which I would be more supportive of if I confirm it's backed by more than one skin writer), I would probably keep Vector and Monobook the same for now, given the above. I'm not sure how best to implement that.

Mmkay, that helps. I'll add setting up some default styles (and probably framework specs, since there doesn't seem to be anything there, either) to my ever-growing to-do list.

As for Jack Phoenix commenting publicly, I'm afraid you'll likely find it to be an uphill battle getting skin developers to comment on ANYTHING anymore after everything skin-related being generally ignored so much over for years. That's not a reason to continue to do so, and the situation is at least getting better now, but it's something to bear in mind when working on this stuff.