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.
- 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 https://www.mediawiki.org/wiki/Front-end_standards_group/2016-01-13 Action: initiate task [+1 prtk]+1 https://phabricator.wikimedia.org/T100896
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
PS28 Anyone looked at it aside from Bartosz and Timo (or want to look at it?) https://gerrit.wikimedia.org/r/#/c/260071/
Anyone looked at it aside from Florian ? https://gerrit.wikimedia.org/r/260950