Front-end standards group/2016-01-27

Attending: Volker E., Krinkle, James F., Andy R.G., Bartosz, Ed S., Jon Robson, Julien, RobLa, Trevor




  • VE to talk to Sarah to try coming up with a more-human time for this meeting in the next couple of weeks.

New questsEdit

  • Rotate time schedule every second meeting? (VE, ST)

Every second meeting would be later like 9:30 am (PT) and exclude India, the other one is on the edge for Europe then

  • Make this a weekly meeting? (VE)

TT, TP bi-weekly in order to implement, because we are in other meetings as well. And it has worked well so far. +1 JR, ES VE: So it stays a once in two weeks meeting

Action & CodeEdit


Expose current skins Less vars within RL.
> Everybody agrees on this. >TT comes up with a task

Review of WikiDevSummit '16 from User Interface working area (VE, TT, RL…)

Treat as first-class citizens: Apps, mobile web, desktop web, logged-in users. All with the same infrastructure and performance.
Ability to change skins without breaking extensions and gadgets. Provide page-level APIs instead of HTML or DOM being the API. +1 [+1 prtk] [+1]
Make themes (extension:theme style) happen with a practical API! coming from T114071
TP: Reading team has taken action on some of the sub
JR: There were no clear goal outcomes and there's nothing planned this quarter. From a product perspective it doesn't fit into our current goals
JF: Is this something we can tackle as group, as a "tech debt wishlist"/roadmap that's agreed as areas to tackle?
TP: I would find that very helpful
TT: we don't have a good skin system. There's the central system to begin with, which is tightly coupled to the core.
TP: There's an RFC or even several ones
RL: Which RFCs would that be?
JF: First, we need agreement on the third question below, the scope of a skin.
TT: Agree with James, there's a lot of things that are currently part of a skin and shouldn't. Example skin class(?).
TP: Breaking it down, get started.
JF: Agreeing with Timo and Trevor. Some of the changes might be really big. Either drop functionality from core.
TT: Would take on some of this.
TT: identify low-hanging fruits to tackle first
=> Action: Volker makes another meeting where people interested in this topic (scope of a skin & breakdown of tasks) join in, and we gonna lay-out a possible roadmap.
Timo would go for some of the possible low-hanging fruits in the upcoming weeks.
Avoid parser cache corruption and inconsistency when skins change. (Relates to T114542). Skin being a run-time layer that is not stuck in HTML page cache. [+1 TT] be done
within MW core as start of separation.+1 Establish the scope of a skin, not what it currently is, but what it should be?

Take away points:
Encourage skins to theme OOUI. Allow skins to provide an OOUI theme. Discussed about in Action: initiate task [+1 prtk]+1
Extensions to adopt OOUI and should use Less variables from core to make them look "right", without hardcoding details of specific any skins or themes.
Expose Less variables to MediaWiki:Common.css (.less) and gadgets. Allows them to make components that "fit in" with all current and future skins. Mobile friendly. +1

module registration
PS28 Anyone looked at it aside from Bartosz and Timo (or want to look at it?)

Anyone looked at it aside from Florian ?

Postponed to/scheduled for next meetingEdit