Paul Irish: "it requires a very heavy recalculate style because it's using the :hidden selector. You should use your own logic to compute visibility that doesn't rely on getComputedStyle()."
It looks like the reason for this is T45013. Is the client-side hack still needed? Can enwiki's system be reformed?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Krinkle | T87412 Eliminate call to $.getVisibleText() in ve.init.mw.Target.prototype.onNoticesReady | |||
| Resolved | Krinkle | T91715 Implement (part of) the English Wikipedia's edit notice system in MediaWiki core and transition the wikis to use it |
Can enwiki's system be reformed?
Sure. But we've been ignoring it because it's a large piece of work without high-priority value (new feature in MediaWiki core re-implementing community template hacks on one wiki).
Brief backstory:
MediaWiki core has an edit notice system. It's configurable by local wikis using the namespace prefix "Editnotice". E.g. MediaWiki:Editnotice-0 applies to the entire main namespace (NS_MAIN=0) and MediaWiki:Editnotice-4-Calendar applies to the "Project:Calendar" page (NS_PROJECT=4).
English Wikipedia community (and a few other wikis that copied this system) want to make this more discoverable and thus "created" all the namespace-wide pages with placeholders outputting a link to "create" the notice (which effectively exists already). This link is hidden by default for regular users using site-wide custom CSS. And then community elected admins (who have the ability to create the individual pages) have a shared stylesheet (Group-sysop.css) that sets display: block; on them.
For regular users using the plain wikitext editor via EditPage (action=edit), the html for the "create" link is output as being an edit noticed, but because it's display:none, it is effectively not present.
In VisualEditor, the edit notices are consumed from the EditPage API as an array of one or more notices. On English Wikipedia there is always an edit notice, and it's non-empty (it contains html). However depending on the stylesheets loaded, it may or may not be intended to be made visible.
The work-around I came up with is to write the jquery-getVisibleText plugin, and use that to determine whether a notice is visually "empty" and filter those out. This because our interface treats notices as separate widgets and displaying an empty one would result in the interface drawing a rectangular box with close button that looks broken.
Change 200654 had a related patch set uploaded (by Krinkle):
mw.Target: Remove visible text filter for edit notices
Change 200655 had a related patch set uploaded (by Krinkle):
mw.Target: Defer parsing of edit notices to MWNoticesPopupTool
Change 200654 merged by jenkins-bot:
mw.Target: Remove visible text filter for edit notices
Change 200655 merged by jenkins-bot:
mw.Target: Defer parsing of edit notices to MWNoticesPopupTool