Front-end standards group/2015-12-16
Agenda
editSocial
editNew quests
editReview of the current group format for the last months (VE)
RL: further figuring out the connection to the ArchCom
Probably at Dev Summit kicking off the 2016 process. Explaining how FE standards dev group works today and is this the way to go?
FE standards dev group outreach: FS: wikitech-l, more things summarized on MW page and then just short message on wikitech-l
RL: A Flow board (or similar) for conversations
Holding meeting on 2015-12-28? (VE)
keeping that optional in for now, TT/RK def on vacation
Action & Code
editUser Interface working area @ WikiDev 16
https://phabricator.wikimedia.org/T119162 (VE, TT, RL)
70/80 minutes slots to fill. Mobile FE as most important selected topic by TT & VE up-front. RL planning on discussing this at the ArchCom meeting later today.
RL suggested that we might be combining Skinning/presentation - possible combination of
- T114071: Let's discuss the skin creation process
- T114065: The future of MobileFrontend
...and that this group may decide to use the Monday User Interface spot to talk through this one. Timo pointed out that any next generation skinning process would need to support the Mobile Frontend case, so that aspect of the combination is good, but there are other items in the MobileFrontend task that could be distractions from the overall skinning process. Having a smaller breakout session for "MobileFrontend other stuff" could work.
Follow-up
editStandardize on how to access/register JavaScript interfaces (TT, JR)
https://phabricator.wikimedia.org/T108655
BD & TT had a meeting, JR gave positive signs for what the mobile team needs. JR: some little issues with the "return" pattern for module exports.
TT: proposal was updated to not use the return-pattern anymore, https://phabricator.wikimedia.org/T108655#1838005
JR: update the description
TT: Done
LocalStorage-based key-value store (AG)
Phab task filed: https://phabricator.wikimedia.org/T121646
JR: What about mw.storage?
TT: main requirement is TTL.
TT: mw.storage is just a try/catch handler
New quests
editPhab upstream task: Show patches/or at least patch links in task desc on top like 'patch-in-review' tag (VE)? JR: Some things have happened upstream. The 'patch-in-review' tag is added by a bot implemented by us. You should try to file a bug against the bot.
ResourceLoader: Support loading of messages in parsed formats (e.g. parsed, incontentlanguage, ..) (JR)
https://phabricator.wikimedia.org/T27349
JR: MediaWiki,
AG:
TT: Are all supported in JS now. For elaborate messages that take no dynamic user-parameters, export as HTML from a data module instead and store in a JS var. See VisualEditorDataModule for example.
`background-size`
mixin should not generate vendor prefixes (JR, VE)
https://phabricator.wikimedia.org/T121473
Resolved in ChangeRequest.
VE: Is there a chance to add something like Autoprefixer in RL?
TT: It would be doable. Possible performance issues background-gradient
Browser vendors have agreed, that no new prefixes will be introduced
you'd also need to have a way to opt-out where you don't want it, in contrast to mixins
on the other hand, if you have to opt-in, there's a tendency to forget
RK: In related news, this happened: https://gerrit.wikimedia.org/r/#/c/259192
VE: Let's make Opera 12 the next browser to un-support
Postponed to/scheduled for next meeting
edit- Skinning System: current problems, possible future solutions
- TP: we should switch to BlueJeans for capacity reasons (+3mtg)
Participants
edit- Andrew (AG)
- Florian (FS)
- Roan (RK)
- RobLa (RL)
- Timo (TT)
- Volker (VE)