Jump to content

Front-end standards group/2015-11-18

From mediawiki.org

Agenda

[edit]

Social

[edit]

No social items on agenda this time.

Action & Code

[edit]

Follow-up

[edit]

jQuery.tipsy (BD)
https://phabricator.wikimedia.org/T77402 https://gerrit.wikimedia.org/r/251911 > Timo: we need to figure out tooltips for mobile. But perfteam wants to remove it for reasons of maintenance and pageload performance. Ori has a patch for ULS – Merged! > Volker: agreed. we need two solutions, we seem to have three. Is this tech-only or design too?

New quests

[edit]

MW support for Composer equivalent for JavaScript packages / Investigate JavaScript library management options
https://phabricator.wikimedia.org/T807

  • Trevor: npm has changed quite a bit and *could* meet our needs now
  • Timo: issues with npm have mostly been resolved (not perfect but good) Issues:
  *  Dependencies: doesn't figure out browser support.  Indirect dependencies.
  *  Resource Loader updates
  • Volker: This is a big architectural issue that needs to be addressed from multiple points of view and probably going into an RfC
  • Timo: (require and exports handling)

Blocked by https://phabricator.wikimedia.org/T108655 as well T108655

ResourceLoader: Implement support for Source Maps (TT, VE) related: https://phabricator.wikimedia.org/T49437
https://phabricator.wikimedia.org/T47514

  • Timo: Source Maps: load minified/obfuscated and then map it functionality to other pieces. Step toward a new minifier
  • Volker: easier to go to original source. Dependency is (?) , right?
  • Timo: can't deploy aggressive minifiers like uglifyjs without source maps, but uglify has source maps built in
  • Timo: Don't need an RFC, we can just do this
  • Volker: But you said uglify has issues? 10% gain in minifications not worth technical investment?
  • Timo: Blocked on figuring out how to do this in a performant way in prod. Current minifier is in PHP, very fast. Minifier can be in the critical path, so can't be slow.
    Lots of ideas around to address this, but gains are relatively low, and this is blocked on source maps and ending cache rollovers.

Change printable link to JavaScript `print()` (VE)
https://phabricator.wikimedia.org/T24256

  • Volker: in portlets, we have nice printable view which strips out noprint stuff from DOM. We should come up with JavaScript functionality instead of printable=yes. We won't take noprint class out.
  • Volker: question: obstacles on printable=yes view?
  • Timo: task points out "now that IE5 support has been dropped..." :-)
  • Volker: templaters need the noprint class. We shouldn't be putting it in stuff we make, though. do we still need code in the core for printable view?
  • Timo: I can code review the patch to removing printable view
  • Volker: still need to iterate on TheDJ's patch. That will be my homework for next time.

Browser grades in support matrix (TT, VE)
https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

  • Timo: I tried to document our guidelines based on status quo, breaking browsers up in grades and support priority. Some confusion about it now
  • Volker: I hadn't been facing the issues of differentiating browsers. Can we improve on it to make it easier for newcomers? Possible solution is not to change the browser labels, just changing grades in the title


Postponed to next meeting

[edit]

Standardise on how to access/register JavaScript interfaces (TT, JR)
https://phabricator.wikimedia.org/T108655

Participants

[edit]
  • Andrew (AG)
  • Bartosz (BD)
  • Ed (ES)
  • Roan (RK)
  • Rob (RL)
  • Trevor (TP)
  • Timo (TT)
  • Volker (VE)
Retrieved from "https://www.mediawiki.org/w/index.php?title=Front-end_standards_group/2015-11-18&oldid=1954513"