Front-end standards group/2016-01-13

Agenda

Social

New quests

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

Action & Code

New quests

Review of WikiDevSummit '16 from User Interface working area (VE, TT, RL…) https://phabricator.wikimedia.org/T119162

https://phabricator.wikimedia.org/T119162#1917207 Goals:

• 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.
• 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.

Take away points:

• Encourage skins to theme OOUI. Allow skins to provide an OOUI theme.
• 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.

Postponed to/scheduled for next meeting

• https://phabricator.wikimedia.org/T65491, https://phabricator.wikimedia.org/T74547 (VE)
• Skinning System: current problems, possible future solutions
• TP: we should switch to BlueJeans for capacity reasons (+3mtg)

Discussion

Encourage skins to theme OOUI. BD: The OOUI themes are disconnected from skins currently.
TT: being able to modify vs. override
MediaWiki theme can live somewhere
VE: allow easy customization of "look" (colors, shadows), but not necessarily "feel". Independent developers might be quite happy with changing just the colors, box-shadows, etc. without necessarily changing the UX of rather complex widgets
TP: we should probably focus on styling of Elements in OOUI, not Widgets. Widgets are built out of Elements, so styling them should result in mostly styled Widgets.
VE: Are we talking about sharing styles between selectors in OOUI, as a way to improve file size. The way it currently works, does work well for JS, but in CSS it's following not a good pattern. If we do shared styled selectors, how would this play into "Split oojs-ui module into smaller ones for individual widgets" https://phabricator.wikimedia.org/T113681
JF: We would have to reprocess the Less files for "collecting" the selector
Probably results in lot of CSS files
BD: This result sounds kinda scary
JF: Issue of icons, where you cannot get around with Less vars
TT: We could provide Less functions here
RL: So what about a functionality of converting styles from other frameworks to an OOUI style?
VE: The last couple of months UI Std has worked on a way to standardize Less variables across WMF products in order to make shared variables consumable.
RL: How about WordPress or Bootstrap? Do we want a conversion tool for WP theme to MediaWiki?
VE: I don't think that is an easy-accomplishable goal, WordPress themes are very different, it's not even easily doable from WP theme to another theme
TT: By having abstract Less functions…
BD: Didn't May come up with something for Bootstrap?
VE: After looking at the different WMF products that [sharing a variablized Less file] became our best-promising approach
TT: Less isn't powerful enough for icons, it needs a build step. It would probably make sense to have SVG files in a build script upfront.
VE: If you TT, don't see a build script as a no-go, I'd like to look deeper into improving current SVG handling, as there are recurring SVG
TP: I think exposing Less variables in MediaWiki, like MediaWiki:Common.css is a great idea, but we don't have []
TT: It'd be interesting to expose current skins Less vars within RL.
> Everybody agrees on this. >TT comes up with a task
BD: better after modularizing OOjs UI
JF: impact on modularization?
BD: prob not, but easier to modularize

Participants

• Bartosz (BD)
• James (JF)
• RobLa (RL)
• Timo (TT)
• Trevor (TP)
• Volker (VE)