Front-end standards group/2016-05-10

From MediaWiki.org
Jump to navigation Jump to search

Attending: Julien G., Timo T., Roan K., Jan D., Andrew R.-G., Trevor P, James F., Bartosz D., Jon Robson

Social[edit]

No topics today

Action & Code[edit]

New quests[edit]

Convert to OOUI (JR) – T107037 and see workboard[edit]
  • JR: Some blockers to move this along, like you can't have two HTMLForms
  • JR: What is the general policy of bringing the forms to OOjs UI?
    • One-by-one iteratively to not put too much stress on users
Add options, and a "replace: true" option to oojs-router::navigate() (JG)[edit]
  • Goal: replace the current entry in the document history instead of creating a new one.
  • Julien: Current code uses location.hash, maybe use location.replace?
  • TT: Use History API over location.replace, as there are browser inconsistencies
  • JG: We need to support IE 9, History API has issues
  • TT: You can abstract the difference between these interfaces in OOjs router. perhaps like router.replace, router.push, router.on('change').
Eslint? https://phabricator.wikimedia.org/T118941[edit]
Feasibility of client-side rendering this feature https://people.wikimedia.org/~jgirault/languages/#lang on wikipedia.org as general question? (JD)[edit]
  • AG: ESI?
  • TT: ESI have been very problematic in RL earlier
  • <html class="client-nojs">
  • <script>document.documentElement.className = document.documentElement.className.replace( /(^|\s)client-nojs(\s|$)/, "$1client-js$2" );</script>

Follow-up[edit]

https://phabricator.wikimedia.org/T27349 (RK, TT) ResourceLoader: Support loading of messages in parsed formats (e.g. parsed, incontentlanguage, ..)[edit]
  • TT: Main problem: end up HTML in an object, that expects plain text.
  • RK: plain text sometimes, HTML at other times, that's a problem.
  • JF: semi-relevant: long-term desire to not rely on wikitext at all (so these should be possibly HTML/etc.), and the ContentHandler world means we might want to make the HTML-ness of the message built-in.
    • RK: HTMLness of the message [?]
      • JF: Messages that has never meant to be HTML, and are now HTML
    • TT: one other point of complication. you can't parse any new arguments in. We probably won't the concept of HTML message in the long-term
    • RK: Proposal for proposal: Come up with easier way Export messages in alternate formats, includes parse and contentlanguage.
    • RK: Could make parse die at some later point.
    • TT: Proposal published at https://phabricator.wikimedia.org/T27349#2286245