Front-end standards group/2016-05-24
2016-05-24 Attending: Volker E., James F., Bartosz D., Jan D., Timo T.
Social
editNo topics today
Action & Code
editFollow-up
editHash fragment routing
edithttps://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!
editcsslint 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
New quests
editstylelint rules (VE)
editConventions and stylelint configuration:
- https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/CSS
- https://github.com/wikimedia/stylelint-config-wikimedia
Issues:
- 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
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
Proposed rules to enable:
https://github.com/wikimedia/stylelint-config-wikimedia/issues/4
- http://stylelint.io/user-guide/rules/max-nesting-depth/
- http://stylelint.io/user-guide/rules/declaration-block-properties-order/
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
General Inquiries
edit- 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
JF: I believe it's not covered by cookie policy. Should talk to lawyers about that.
=> JF reaches out to legal
- Git repo best practices - Should a 'master' branch just track what's in production, and a 'wmf' branch act as a working branch?
https://phabricator.wikimedia.org/T136185 TT: A tag would make sense,
Follow-up
edit- "under discussion" on https://phabricator.wikimedia.org/tag/front-end-standards-group/
- T27349 ResourceLoader: Support loading of messages in parsed formats
TT: Posted proposal on the task. => People read it and please give feedback
Postponed
editVolker's task about font-size problem - https://phabricator.wikimedia.org/T97631