Front-end standards group/2016-01-13

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.

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)