I was experimenting with abstracting away the MediaWiki specifics so that skin developers only need to worry about css, html (mustache template) and js (not ResourceLoader etc..) - three very common languages that should be easy for people to understand. I replicated many of the existing skins using the new abstraction layer with Neue suffixes if anyone is interested:
https://github.com/jdlrobson/SimpleSkins

My personal belief is no skin designer should need to know PHP let alone MediaWiki...

My personal belief is no skin designer should need to know PHP let alone MediaWiki...

How do you design for a platform you're not familiar with? Even small gadgets fit into the larger environment and need to not conflict with other things and confuse the users; a skin is universal, it encompasses everything.

Look at tumblr.com - it has a beautiful amount of themes [1], and no one who builds them needs to think about the underlying architecture (tumblr is closed source so they can't hah!).

Gadgets break because we don't do well to define interfaces for them for the components they operate on them. HTML is not an API, so relying on $( '#ca-watch' ) to be a watch star is not great. Hooks are equally bad - we rely on hooks to inject links in html rather than operate on models e.g. MainMenu->addItem( new Menu Item( 'Nearby', '<link to nearby>', 'icon-name' ) )

I know plenty of designers who have good ideas but no time to learn how MediaWiki works so it's my strong belief that we should simplify our skins as much as possible.

[1] http://www.tumblr.com/themes/

Tumblr has a lot of themes, yes, and many of them are quite pretty. But a great many of them also fail in terms of usability, and sometimes even functionality.

That's fine, though. I agree that the bar not being high to make something is a good thing.

The problem, however, is you still need a lot more than just 'pretty' to make something actually worthwhile. In order to make a skin that is widely usable, that has good UX and serves both user needs adequately, that doesn't break, you need to be familiar with what it's skinning - both the frontend components and some abstraction of the underlying platform. Look at all the unsolicited redesigns wikipedia gets - they almost always look pretty, but then fall apart as soon as you try to apply reality to them. They often have no concept of core wiki things like history, or languages, or models of editing and workflows. And yet in order to make something that's actually useful to real people, you need to build these things, and more, into the overall design.

What we need to do is make it so this stuff is the labyrinth people need to navigate, not wading through php and html soup, or html and js soup, or really any soup at all.

I was mostly referring to gadget styles, but yeah, a lack of a proper API is as much a problem there as it is here. Really all we need for skins is something simple, consistent, and reasonably thorough, though - it shouldn't even matter what it is. Even something as simple as constructing a skin by calling a bunch of php functions would be pretty straight-forward even to folks who don't know php if the functions are sensible and well-documented, since I imagine they'd largely just be rearranging and rejigging whatever's in the example at that point.

Congratulations! This is one of the 52 proposals that made it through the first deadline of the Wikimedia-Developer-Summit-2016 selection process. Please pay attention to the next one: > By 6 Nov 2015, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.

A very major problem with skins is there is no clear hierarchy with the classes. Instead of everything related being in an expected place, the classes are all right next to each other, the needed functions spread out across several related ones (so you're constantly calling getSkin from baseTemplae etc). If we intend to abstract the creation process, no matter how, this really needs to be cleaned up.

We need clear classes to use. What are SkinTemplate and BaseTemplate? Why are we using OutputPage and Title and Skin all throughout this? Why do we need to do things like $this->getSkin()->getRequest()->getVal( 'action' ) just to see which class we should be requestion the catlist from? We should have something we're using that's most all of this in one place, because now we know what all it should even be (not necessarily so in 2005).

We need interfaces for extensions and skins to use, where extensions can say they're adding a blahThing and the skin gets the whole pile of blahThings and can just place the blahThings wherever regardless of where they came from. Notifications, help icons, whatever. A space on the page for info, a space in the header for new messages.

We need tool types. Every page has a toolbox, but there are site tools and page tools and user tools. Some of these are more important than others, some more commonly used. Instead of just using a hook to add a link to a toolbox or to a page header, it should register the link by type and priority - primary page links like editing or discussions, or secondary user links like user logs or renaming, or site tools like upload or mass delete...

We need clear abstraction of data and consistent, manageable output. getPageContent, getUserPageTools, getCategories, getNotifications. No need to get categories from two different classes and make a custom DB query just to change the outputformat/location. No need to use $this->data and pull from a giant unknowable array.

We need better output functions. Why is the skin msg function different from all others? Why are there special functions at all? Messages are messages.

We need parsers for menus that can be extended or used out of the box, for sidebars, for customised user menus, for global menus or nested menus.

We need fallback support for older browsers built-in. No more manually-created, separate stylesheets. IE8- doesn't support @media sizes, just tell RL which sheet is the fallback, render it a non-@media-sized version from that. Need an extra stylesheet to make safari cooperate? Just tell RL it's for safari, it only gets sent to safari.

We need themes. Skins should be able to support diverse uses, not just across devices, but also places, situations. We need a way to make a dark theme that is part of the skin, a content-only theme that can be toggled on and off, with saved preferences that don't need to be shoehorned into special:preferences. We need flexibility that doesn't require reimplementing an entire extension within the skin.

We need consistent CSS classes and ids. What are our coding conventions, do any apply? What ids are used by core? We need to know, and we need them to not have to be added manually, or to be able to tell core that these are the ids to use with this skin.

We need sane forms, and form styling. oo-ui in core, in all of core, instead of the inconsistent soup of forms and special pages and classes we see today. We need to be able to create themes within the skin, defining the styles, setting everything consistently.

We need icon sets within skins. An extension defines what icon it wants in terms of what it is, not in terms of the specific icon, and the skin provides the icon, unless the skin does not use icons, in which case an icon is not used and instead the label is used by itself.

We need some way to style all the things now styled by core. Wikitables. Datatables. Fieldsets. TablePager. RecentChanges. We need to know what they are, and not have their styles so specific as to override skin styles.

We need documentation, not just of what all is needed, but also not so much to overwhelm. Start with Skin:Example. Keep these things defined, arrange them how you like. Check these pages to make sure everything renders correctly. Visual test cases, not checklists. You're done.

On the ResourceLoader end, we probably want more structure as opposed to less. Currently it looks a bit like this:

• A module of 'legacy' old stuff that has apparently never been cleaned up (contains things like visualClear and RTL fixes and whatnot, loaded by default)
• Several modules of random interface stuff (essentially just some of monobook's styles, which are also used by Vector and other similarly dated skins) - borders and backgrounds for catlinks and other stuff, header styles (only loaded if the skin specifically calls them)
• Modules for interface stuff for specific pages or components (special pages and whatnot, all loaded by default)
• Modules for specific optional things (external link icons, whatever, only loaded if the skin calls them)

What I'm currently thinking would be more like this:

• A module of base stuff, the sorts of things people don't even necessarily think of as 'style' (T118134)
• A set of definitions:
  • Icon sets
  • Colour palettes
  • Overall box styles and placement (for things like thumbnails and galleries; on-page ToCs, catlists, fieldsets; wikitables; etc); would default to something built out of the general border styles and padding and whatever definitions
  • General styles for extensions to construct new interfaces out of - borders, padding, whitespace etc definitions (this way, say, a new discussion interface could still match whatever skin just by building itself out of the components instead of having to set its own styles)
  • Form definitions - ideally to be piped into ooui or whatever, having that replace all the current disparate forms down the road
• A set of modules and classes to interpret and apply those definitions

Skin creators could also optionally apply or not a css class to a block to make it use these - for instance a catlinks left in the content block as class 'catlinks' would get box styles applied (monobook style); a catlinks moved into the sidebar would not unless the general skin boxstyle class is explicitly applied by the skin creator.

It's great to have this meeting, but we need to identify the agenda and desired outcome of it.

[Unsolicited redesign skins] almost always look pretty, but then fall apart as soon as you try to apply reality to them. They often have no concept of core wiki things like history, or languages, or models of editing and workflows

What do you mean by "models"? Are you saying they don't look good presenting action=history or action=edit?

I'm not sure what you mean by "apply reality to them", but it seems we need a list of elements skins should handle and directions on how to test them... I tried to help by adding a picture of a skin to https://www.mediawiki.org/wiki/Manual:Skinning_Part_1#Skin_elements

What are SkinTemplate and BaseTemplate?

I agree, confusing naming. SkinFoo implies the approach of the skin. Thus SkinTemplate isn't the template for a skin, it's the parent class for skins that use a separate template, which is usually named FooTemplate. In the Blueprint skin, SkinBlueprint extends SkinTemplate, but the separate template class it uses, BlueprintSkinTemplate, doesn't extend BaseTemplate because it's facilitating an actual mustache template.

In T114071#1686146, @Jdlrobson wrote:

I was experimenting with abstracting away the MediaWiki specifics so that skin developers only need to worry about css, html (mustache template) and js (not ResourceLoader etc..) ...
https://github.com/jdlrobson/SimpleSkins

I haven't looked at SimpleSkins, but from working with Blueprint I believe a good way forward is to use an actual templating language (mustache), and hide or get rid of the cruft in parent classes while making the actual stuff you need for a template cleanly available. One problem is that although many elements you need for a skin are available in $tpl->data, like catlinks, personal_urls, and username (good!), others are only output in functions like BaseTemplate->printTrail() and BaseTemplate->getIndicators(). We could provide these as mustache/lightncandy helpers, but there's probably a cleaner way to do it.

In T114071#1797507, @Spage wrote:

It's great to have this meeting, but we need to identify the agenda and desired outcome of it.

[Unsolicited redesign skins] almost always look pretty, but then fall apart as soon as you try to apply reality to them. They often have no concept of core wiki things like history, or languages, or models of editing and workflows

What do you mean by "models"? Are you saying they don't look good presenting action=history or action=edit?
I'm not sure what you mean by "apply reality to them"

They usually don't have any way to even access those, or anything that makes a wiki, well, a wiki. That's what I mean by 'reality'. It's a wiki. You need to consider the constraints that applies when designing for one.

It seems we need a list of elements skins should handle and directions on how to test them... I tried to help by adding a picture of a skin to https://www.mediawiki.org/wiki/Manual:Skinning_Part_1#Skin_elements

Manual:Skinning needs a complete overhaul. It can't decide if it's a howto or a list of objects or multiple lists of objects. But yes, we do need a proper list. One list.

What are SkinTemplate and BaseTemplate?

I agree, confusing naming. SkinFoo implies the approach of the skin. Thus SkinTemplate isn't the template for a skin, it's the parent class for skins that use a separate template, which is usually named FooTemplate. In the Blueprint skin, SkinBlueprint extends SkinTemplate, but the separate template class it uses, BlueprintSkinTemplate, doesn't extend BaseTemplate because it's facilitating an actual mustache template.

From looking at them, I'm thinking the front-end interface classes all need a complete overhaul. This includes but is not limited to the skinTemplate and baseTemplate classes. I've filed T118332 to maybe figure out what all that does include.

I haven't looked at SimpleSkins, but from working with Blueprint I believe a good way forward is to use an actual templating language (mustache), and hide or get rid of the cruft in parent classes while making the actual stuff you need for a template cleanly available. One problem is that although many elements you need for a skin are available in $tpl->data, like catlinks, personal_urls`, and username (good!), others are only output in functions like BaseTemplate->printTrail() and BaseTemplate->getIndicators(). We could provide these as mustache/lightncandy helpers, but there's probably a cleaner way to do it.

Hmm, here I was thinking data was absolutely horrible and the way we'd want to move forward was to put actual functions in front of all its calls. This way whatever frontend we want to shove on top of it would have an extra layer (the functions) protecting it from internal changes.

This session has been defined as tentative must-have at T119593. It has also been recommended as nice to have at T119162: WikiDev 16 working area: User interface presentation and would be helpful at T119032: WikiDev 16 working area: Software engineering. This is very good! Question: are the related maintainers and key contributors aware of this proposal? What should be discussed at the Summit, or even before?

In T114071, @Isarra wrote:

•https://www.mediawiki.org/wiki/Special:Code/MediaWiki/81507 - how skin changes have happened in the past

Because we have so few custom skins, nobody's gonna care if we break 'em, right? /s

In T114071#1686289, @Jdlrobson wrote:

Look at tumblr.com - it has a beautiful amount of themes [1], and no one who builds them needs to think about the underlying architecture (tumblr is closed source so they can't hah!).

Tumblr is a fine example if you're looking for a site which allows users to write awful JS that slows down page loads by many seconds, if not minutes on older hardware.

I know plenty of designers who have good ideas but no time to learn how MediaWiki works so it's my strong belief that we should simplify our skins as much as possible.

Sounds like a fine opportunity for learning, both for us as well as them -- for them to learn about MediaWiki, for us to learn about designing and simplifying the skinning process.

In T114071#1690694, @Isarra wrote:

That's fine, though. I agree that the bar not being high to make something is a good thing.

Often, but not always. We need some standards to ensure a certain level of functionality. Just because you can go crazy doesn't mean you should.

What we need to do is make it so this stuff is the labyrinth people need to navigate, not wading through php and html soup, or html and js soup, or really any soup at all.

+2

In T114071#1779879, @Isarra wrote:

We need clear classes to use. What are SkinTemplate and BaseTemplate?

To quote you (from the previous comment I quoted above), "php and html soup". Of course, someone new to MediaWiki might assume those are sane classes for making a skin or something like that...

We need tool types. Every page has a toolbox, but there are site tools and page tools and user tools. Some of these are more important than others, some more commonly used. Instead of just using a hook to add a link to a toolbox or to a page header, it should register the link by type and priority - primary page links like editing or discussions, or secondary user links like user logs or renaming, or site tools like upload or mass delete...

Yeah, dealing with the toolbox is a pain. It's just a toolbox and that's it. As long as you accept that and don't try to change that, everything's fine. If you try to do anything more complicated (like how we did with Aurora at ShoutWiki), I can guarantee you'll end up with a headache. And that's just bad.

We need better output functions. Why is the skin msg function different from all others? Why are there special functions at all? Messages are messages.

This is a case of "let's preserve a legacy API for the sake of it when we could've just tweaked to be consistent and not break anything while doing it", I think. (SkinTemplate/BaseTemplate's msg() outputs a string, whereas for most classes extending RequestContext, the msg() function returns a Message object, which, due to Message::__toString() can be represented as a string...ergo you should be able to make skin's msg() more consistent without breaking b/c. Unbelievable, I know!

We need parsers for menus that can be extended or used out of the box, for sidebars, for customised user menus, for global menus or nested menus.

Well, we all know how that worked out. Improving the skin system? Hah, not gonna happen anytime soon. Something as big as this needs to be a coordinated effort between multiple people to meet the arbitrary "standards"...

We need fallback support for older browsers built-in. No more manually-created, separate stylesheets. IE8- doesn't support @media sizes, just tell RL which sheet is the fallback, render it a non-@media-sized version from that. Need an extra stylesheet to make safari cooperate? Just tell RL it's for safari, it only gets sent to safari.

This would be delicious, but due to the decision to drop support for IE8 in Jan '16 I'm not sure if this is gonna happen.

We need themes.

+2. Let's finally get Extension:Theme merged into core with a proper user-facing UI.

We need consistent CSS classes and ids. What are our coding conventions, do any apply? What ids are used by core? We need to know, and we need them to not have to be added manually, or to be able to tell core that these are the ids to use with this skin.

We have general coding conventions as well as CSS-specific and JS-specific ones (and personally I feel those pages are just too heavy, but I'm not sure how to simplify 'em either, so this is just pointless ranting), but who follows 'em? Do core devs? Do custom skins' devs?
I'm not sure if there's even a semi-accurate listing of IDs/classes/etc. used by core. Wikipedia had (and still has) a page on that, but as you'd expect, it's very much incomplete.
There's also the legacy vs. conventions issue -- i.e. core defines a CSS class called "visualClear" which is used not only by core, but also custom skins, third-party wikis, etc. so blindly renaming it to something that conforms to our modern-day conventions, such as mw-visual-clear, would obviously break a lot of things for essentially no good reason.

We need documentation, not just of what all is needed, but also not so much to overwhelm. Start with Skin:Example. Keep these things defined, arrange them how you like. Check these pages to make sure everything renders correctly. Visual test cases, not checklists. You're done.

This is very much essential, yet also damn tricky to nail down properly. When the "this is what your code should visually look like" (a.k.a coding conventions) pages are as overwhelming as ours are...

We need dedicated folks to do this. Give us money!

In T114071#1872743, @Qgil wrote:

Are the related maintainers and key contributors aware of this proposal?

As far as I know. I don't entirely know who they are, though. We definitely had a thorough go at trying to inform people, across mailing lists, a tech talk, general IRC pestering...

What should be discussed at the Summit, or even before?

What do we even want out of all mediawiki skinning, really? Can relevant folks agree to something?

And will anyone actually pick working on this up as a project? Is there anyone who has resources and stuff to do this? Who do we need to convince to buy into this being important, and thus throw money at it?

Well, not money exactly, but developer time that won't get distracted, or whatever. Paid developers seem less likely to randomly wander off to spend two weeks making masques, formatting hdds, and installing ubuntu on a surface pro because it's just less futile and stressful. I plone burned out just USING this stuff, never even mind trying to fix it.

We need a path forward. I can't make it happen. But there's more here than me.

session notes: https://etherpad.wikimedia.org/p/WikiDev16-skinning

There seemed to be consensus we wanted themes. So themes: T122924

Full notes paste:

Session name: Skinning
Meeting goal:
Meeting style: Consensus: coming to agreement on one solution

Why people make skins, what they expect from them, general problems
[volker] Some of the questions that Jon is raising were covered in the session yesterday. There are a large number of views in MediaWiki which is hard to support. Questions yesterday - responsive, front-end/back-end separation.
[bawolff] Skins should be more customizable. Almost all mw installs use Vector. Installer should allow you to pick a color for the skin or something.
[stephen] Are skins for users or for mw developers?
[amir] some 3rd party sites have customizations
[stephen] You could customize your site on myspace for example
[amir] On Wikipedia you could choose a bunch of skins, but now just power users use monobook
[jon] My primary interest is, comparing WP and MW, MW is less popular with 3rd parties. In freelance work, done a lot of WP theming, and its easier.
[issara] A lot of people are forking vector
[jon] Most people want their own skin. No one wants to look the same
[bawolff] A lot of people do minor CSS changes
[jon] You can't effectively add one CSS and change vector. Big problem. How do we make it easy to make people MW installs look different. Skin should be more like a theme, which it isn't right now
[issara] The skin makes the layout of the page and the styles withing the page. We could decouple those.
[volker] Layout? The HTML dom?
[issara] Yes, if you could de-couple them, it'd be more logical(?), I don't know
[volker] MDN is on MW, and did a lot of customization
[jon] Ryan Lane was involved
[connecting display]
[volker] One of the strengths and weaknesses is that users have freedom to edit markup and content but as a skin developer you run into issues with this markup
[issara] I was seeing the medium source code docs
[bawolff] Skins are like extensions, documentation sucks

[issara] Establish what a skin should be. The boundary b/w skin and content, skin config, colors and stuff…
[bawolff] I'd like to see more prefs for skins
[volker] Themes on top of skins?
[issara] YEa, but we don't want that
[volker] I see a lot of historically grown, complex ways of interacting & UI issues. If we put another layer it'll cause more trouble in the future. We need simple solutions
[issara] A lot of skins just use LESS variables.
[bawolff] We need a hook in prefs to set stuff in skin
[issara] There is no way to modify the LESS files from PHP. Its a mess.
[volker] Elaborate?
[issara] How do you set the colors via PHP, like prefs?
[jon] $wgResourceLoaderLESSVars / $wgResourceLoaderLESSImportPaths
[sam] When less looks up a var, it'll look up this global hash
[issara] So, it can be done. Just need to make it simple
[volker] I am not sure how the loading works, with RL. If you define vars in your skin and then again in PHP, then I am not sure what'll happene??
[sam] You're not adding a file, just editing the hash prior to LESS compilation by the ResourceLoader
[brian] I came to this session because <quotes the agenda>. Can you come up with some user cases for this? LIke users wanting to change the skin according to my brand.
[volker] We are putting the needs into the etherpad, and put our names along with it, and then prioritize somehow.
[sam] Establish scope of a skin, not what it is, but what it should be
[brian] The boundary between skin and other stuff. Scope includes responsibilities
[volker] Take 5 minutes to list down needs and then prioritize
[issara] Scope for which part?
[brian] Just high level, and then figure out if it falls under the purview of a skin

Skin use cases:

(Minor) customisations

• BG: As a developer, I can change fonts used to render article content (e.g. use apple system font on iOS) so that I can make article content appear idiomatic on the platform on which it is presented
  • More generally, stylize standard article UI components & content (edit buttons, text, headers, etc.)
• BG: As a user, I can modify certain parameters of the skin so that I can view the article content in a way that's less fatiguing for my eyes (+BG)
  • Font size, foreground/background colors, etc. [**+1 --bawolff] [+1 --phuedx]
• [bawolff] Skin preferences for color customizations etc. [+2 prtksxna]
• [Volker]: I'd like to be able to completely change the look of all user-facing (foremost front-end) interface elements easily without diving into ancient and diverse PHP classes and functions. Clearer CSS Classes/APIs etc.(+BG)+2JG

*+1 [JR] I want to be able to hack the Vector skin to bring minor improvements to my 3rd party install e.g. remove sidebars (something like https://github.com/jdlrobson/SimpleSkins/tree/master/skins/Daliwould make it obvious to me how to do this). FYI Vector simplified=https://github.com/jdlrobson/SimpleSkins/tree/master/skins/VectorNeue

• [Amir] +1, related to what I wrote.

More control over (article) content

• BG: As a developer I can control element layout & content so that I can manage performance SLAs and optimize content presentation for specific use cases (+BG)
  • Which elements are (ex|in)cluded on the page (e.g. excluding navboxes)
  • How much content to show for a given element (e.g. just a description of a collapsed, lazy-loaded infobox)
  • Order of elements on the page (image container for page image <if present>, "lead section", collapsed infobox, etc...)
  • Lazy-loading images(?) [I think that should be a MW concern, not skin -bawolff, agreed -Volker]
    • [phuedx] I agree with bawolff here, this is a pre-skin transformation problem

• [Amir] As a developer in the Language team, I repeatedly need to do things around the interlanguage links list. I repeatedly run into incompatibilities between Vector, Monobook and other skins in how to access the elements there and how to customize them. This shouldn't really be in the scope of a skin at all. The access to this list should be consistent. It's conceivable that a skin will omit the interlanguage links altogether, but then my code should just have a way to gracefully see that it's not there and move on, rather than crash because of a missing element. Currently I have to do various non-robust checks to avoid such failures, such as checking for skin names, writing convoluted CSS selectors, etc.

[Sounds like a mw.skin API in JavaScript, that was proposed a few times but never agreed on/implemented. ---Bartosz]

Developer happiness

• [Jan] Have a skin be portaeble across mediawiki installations.+2SN
• [phuedx] I'd like to be able to write a skin without requiring MediaWiki core
• [JR] As a developer who is not comfortable with PHP I want to use a webapp as the primary interface for my MediaWiki install e.g. https://reading-web-research.wmflabs.org

Comms

• [JR] It should be obvious from the MediaWiki.org homepage that skins exist at all. +1JG

**[bawolff] Also maybe from installer, call out skins more

• [We have a section for them like extensions right now --Bartosz] +1VE :)

Identity

• [JR] I want to be able to distinguish a Wikimedia skin from a 3rd party skin by appearance alone+2SN +2BW+1JR+1VE

Support

• [JR] As a site admin I don't want my skin to break on a new release+2JD+1JG

**[bawolff]Ultimately I think this is more a general MW concern. Our extension interfaces have the same issue, and deprecation policy should be MW wide

?

• SN In the future, should we only care about admin skinning or also user skinning?
• [Jan] Have a skin as a starting point for further visual/branding customizations.
• [Jan] Switch between skins on a mediawiki installation.

[issara] There are a lot of levels of things here. Which establishes that we don't really know what stuff is?
[volker] Can we combine some of them? Then read through and prioritize.
[sam] Few look similar…
[Jan] I don't know how its currently built, so like a MVC arch
[volker] I don't know how much skin stuff you're doing, the deeper you get, the messier it is. Bottlenecks with performance? A MVC approach sounds great for front end stuff, but not that easy to accomplish
[issara] MVC?
…explainaion…
[brian] Historically, the skin has the side bar and stuff. I am tihnking of skin that applies to the actual article content.
[jon] There is a lot of stuff in the content that could be componentized. The skin has been just the stuff around it.
[bawolff] We probably need a way for extensions to have parts to be skinnable
[issara] We have extension that add tools, but we don't know where the tools are added
[jon] Nav is different in mobile etc
[issara] How do you say if its a site or a page tool
[jon] With a model you can define that
[issara] Should the skin…??
[brian[ We should explicitly separate the issues of MW chrome and article content, and they aren't always presented together
[bawolff] We cache the article contents , and that might be a problem
[volker] Lets go through the list and add our names to stuff we like, three +2s and a few +1s?

• Issara explains that you can leave the chrome out in your skin if you just need to style the content

For * [bawolff] Skin preferences for color customizations etc. [+2 prtksxna]
[bg] If we could to the customization client side
[jan] like a gui?
[bg] Change stuff in vector for example, font size, background
[volker] Are we talking about accessiblity issues or just user prefs
[sam] There is already a way to do that, stylesheet.
[issara] People don't want to put CSS on top of more CSS
[sam[ If a skin author provides styles that can be extended
[issara] We want a sane way to separate it out. How do you change colors, different elements using a particular color, that could be used somewhere else. We have the pieces, they need to come together
[sam] Documentation
[volker] Techincal considerations: With the color customization tool, you run into regressions. You change a BG color and a link disappears.
[issara] The site admin will be changing this
[bg] Let them only select a part, so that they can't mess things up. And that API is built on a lower level API, but at that point you're on your own
[issara] I was going to demo ????
[stephen] Is the purpose to define what that API should be.
[issara] We just need to make it happen.
[bawolff] When we mean themes, and extra CSS file and more LESS variables?
[issara] yep, superficial stuff
[volker] Not just colors. Font sizes. The fool proof approach sounds nice, but its horribly complicates
[issara] If you architect the skin a certain way then this shouldn't be too hard
[bawolff] The community has lot of styles on top of monobook
[bg] If you add more customizations things go out of hand?
[volker] Even with colors. We have so many tools that we'll run into edge cases.
[bg] Like inline styles in templates
[volker] For a UI designers, this is a horror show
[bawfolff] SO makes sense for 3rd parties, not us?
[bg] What is your alternative?

• If someone comes up with a skin, I don't have to maintain the bugs. If I open up customizations, then its my duty as a…? We need to come up with a solid skin baseline.

[issara] We have templates that can't re-use the classes in the skin
[stephen] Can we define what templates the skin would suppoer
[issara] The ones that you can effect are like wiki tables. We need some way to be able to this for navboxes, infoboxes
[stephen] is it a define set?
[sam] Sound like a middle ground between Capiunto and OOJS UI (and maybe Scribunto)
[bg] There is a larger discourse about having tools for content creators. Are we blocked because of the edge cases?
[sam] imho, don't run from them, if we did something for 90% of the cases then there is pressure on the editors to fix the ones that dont.

• Putting pressure on the community issssssss

[sam] Doesn't have to be the comm that we put pressure on
[bawolff] enwp managed to fix templates for mobile. [can you elaborate bawolff? this is not my experience :)]
[bg] If there is a larger ask for these features, should we let editor block a feature that is helpful
[issara] that is a social problem
[volker] Is there error testing for templates? No? We run into this often as UI devs. People copy paste stuff, and we need to style around that without breaking stuff
[bg] There is the existential question, how much control do MW devs have over the UI
[issara] See what people need to do and facilitate that

• How do I make a skin without diving into PHP.

[issara] Take monobook and change CSS?

• Example, you run into a mix of inline styles, markup, that you don't have CSS handlers for, from core, templates, and no clear structure of CSS class that tells you where you are in the doc and how the inherticane work

[issara] Content stuff is a social problem

• Clases coming from ??, we have different selectors that'll override you later

[issara] Different components apply styles in weird order and override stuf

• Dream goal? Block element modifier notation, litle modules in CSS that you can apply to different markup within the view you are layouting. You have inheritance for Block element modifier notation. If I look at CSS classes right now, one in enwp, one in mw.org, 100s of classes that effect a lot of things?
  • http://getbem.com/introduction/ **

[sam] ineffecient from browser performance POV

• bem (and other guidelines) and modern CSS aims for low-specificity re-usable CSS, which is efficient and more easily overridden

[issara] clean everything up
[bawolff] not controversial at all
[jon] no way to make all buttons gray, mw.ui?
[sam] Theres the hard problem of identifying…instructing people…here are some guidelines for writing CSS and markup element
[issara] On a higher level there are no common types
[sam] Need guidelines for migration, identify pages that need it, new form of contribution

• Wont get rid of class soup

[issara] we'll have to break it at some pont

• The new classes could be 2x of what we have but structured…

[issara] There are modules in core [mediawiki.legacy.shared etc.] that's been deprecated for a very long time but still used in skins
[sam] IN the API discussion, there was a need for "so this is what you need". PHP should be accompanied by good docs
[jon] There is no reason why you'd need to know PHP to write a skin

• Its a different use case. We just want to change look and feel. Handlebars/moustache is a step in the right direction.

[jon] Jump from Mustache to HTML is easier than PHP
[issara] Don't want to deal with HTML
[volker] WP themers love HMTL
[issara] Functions to wrap stuff and then call it
[bawolff] Probably need both

• Yeah, one for designers and the other for PHP devs

[bawolff] Just a layer
[bg] Lower level API that devs can use and higher level ones for others
[bawolff] PHP for fine grained control

For * [Jan] Have a skin be portaeble across mediawiki installations.+2SN
[issara] this is a user problem

• guidelines for extension devs to play well with skins. Are there any other portability issues

[stephen] Extract an aspect of the skin
[bg] Enforce that all extension register the components that they'll render on the page
[bawolff] How would be represent this in a machine readable way
[bg] …

Action items with owners:

• Establish the scope of a skin, not what it currently is, but what it should be
• Make themes (extension:theme style) happen with a practical api!

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!

@Isarra: As this has been moved to "Work continues after Summit", where does the discussion continue exactly?
Or are there specific followup tasks to link to?

In T114071#2069745, @Aklapper wrote:

@Isarra: As this has been moved to "Work continues after Summit", where does the discussion continue exactly?

I'm afraid I haven't really had time to work on this, so to my knowledge, this would be it.

I'm gutting the skin architecture and this document will be highly useful for uncovering missing features. I've started documenting use cases best practices for skin development and trying to reduce and strengthen the hooks we have available to make it more straightforward for extensions to integrate with existing skins.

I'm hoping with reduced contracts and providing more flexible data to render, skins themselves will become dumber over time (check out T249673 for my vision).