Front-end standards group/2016-05-24

2016-05-24 Attending: Volker E., James F., Bartosz D., Jan D., Timo T.

Social
No topics today

Hash fragment routing
https://phabricator.wikimedia.org/T114007 T114007: Have a standard way of doing hash fragment routing in MediaWiki (JF) Learnings: Phabricator pretty interesting to work with, not the end of the World. Patches pending to replace custom code in Special:Preferences & MobileFrontend TT: MediaViewer might be another place where it will replace custom code In many ways, you don't want to be accessible by JS. Query Parameter instead For many use cases hash fragments are not the wanted https://phabricator.wikimedia.org/T135692 - expose history API via OOjs Router in some way (for setting main query string, not hash) JF: Patch outstanding for unit tests

We've got stylelint up & running!
csslint has been around for years. Several (a few) projects are still using it. stylelint is the new kid on the block, althought already in v6. It offers a plethora of configuration options and is pretty First mention (request) for strong CSS linting by Volker in first meeting ;) https://www.mediawiki.org/wiki/Front-end_standards_group/2015-10-02#Requests_and_Actions

stylelint rules (VE)
Conventions and stylelint configuration:
 * https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/CSS
 * https://github.com/wikimedia/stylelint-config-wikimedia

Issues: JF, VE: We gonna leave it up the project owners to decide, which syntax to support in stylelint. CSS is default, anything else goes into project's configuration
 * In UploadWizard, we experienced issues with stylelint parsing LESS as CSS, and producing silly false lint errors. The fix: https://gerrit.wikimedia.org/r/#/c/290593/1..4/Gruntfile.js,cm – should this be done somewhere centrally, maybe in grunt-stylelint? --Bartosz

Proposed rules to enable: https://github.com/wikimedia/stylelint-config-wikimedia/issues/4 https://github.com/wikimedia/stylelint-config-wikimedia/issues/5 VE proposed this quite some time ago: https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/CSS/Archive_1#CSS.2FLess_property_order_proposal JF: Don't care which order, but an order would be good. But changing would be messy. TT: Not sure, if sold on order. There's flexibility to go for distinct order in subgroups, like `width` and `height` are ==> Continue on stylelint Github's issues page
 * http://stylelint.io/user-guide/rules/string-quotes/
 * http://stylelint.io/user-guide/rules/max-nesting-depth/
 * http://stylelint.io/user-guide/rules/declaration-block-properties-order/

General Inquiries
JF: I believe it's not covered by cookie policy. Should talk to lawyers about that. => JF reaches out to legal https://phabricator.wikimedia.org/T136185 TT: A tag would make sense,
 * Does usage of localStorage fall under our cookie policy? i.e.: Are there circumstances where the use of localstorage would violate the cookie policy? https://phabricator.wikimedia.org/T133729#2324800 and https://wikimediafoundation.org/wiki/Cookie_statement
 * Git repo best practices - Should a 'master' branch just track what's in production, and a 'wmf' branch act as a working branch?

Follow-up
TT: Posted proposal on the task. => People read it and please give feedback
 * "under discussion" on https://phabricator.wikimedia.org/tag/front-end-standards-group/
 * T27349 ResourceLoader: Support loading of messages in parsed formats

Postponed
Volker's task about font-size problem - https://phabricator.wikimedia.org/T97631