mirror of
https://gerrit.wikimedia.org/r/mediawiki/extensions/VisualEditor
synced 2024-09-27 04:06:51 +00:00
7dae6496b3
We don't have a FOUC on the appearing of the 'edit' link. That one is handled quite intelligently: * Via the stylesheet that is also loaded in noscript mode, its (hidden) appearance is already predetermined. So as soon as those elements are seen by the browser they style correctly for users without JavaScript (display: none). * This same stylesheet also hides it for users with JavaScript but where VE is not available (e.g. due to browser support). While ve-not-available is added very early on (before document ready), it could in theory cause a short FOUC, but that's okay. We simply don't know that VE isn't supported until then. We optimise for the common case (JavaScript enabled, VE available), while still ensuring that it is always hidden in noscript, and is hidden as soon as possible when VE turns out not to be available. For some reason, one small detail (the little bit of whitespace added inside the brackets), was left out of this and was implemented by adding the class 'mw-editsection-expanded' to them from a document ready handler. * First step, get rid of the script that adds this class and use ve-available instead. That means they're styled correctly much earlier (we add the class to <html> before document ready). This can still cause a brief FOUC, though in most cases they're correct from the start. * Step two, make brackets expand by default for script users, and let ve-not-available reset it. This way, like with edit tabs, a FOUC will never happen for ve-available. And even for ve-not-available, a FOUC is rare since we add it before document ready via <html> look-ahead styling. There was still a brief reflow jump because of negative margins between two paint events. One was undoing the other at a later time. These negative margins are a remnant of when we were doing animations (follows-up I4b9c47fd65a70). They were added to reduce reflows and content shift, but were now actually causing them. Removed "padding-right" from mw-editsection, and negative margin from the brackets. Also: * Don't add inline 'style="direction: ltr;"' on every single editsection throughout the DOM. This was the only operation we were doing unconditionally. While I doubt the need of it in general, we can at least allow MediaWiki to do it right, and only add the override if needed. This saves quite a few DOM operations. Change-Id: I7a729edc2cd4a66ebc0ad6935ffd02cb9b948bff |
||
|---|---|---|
| .docs | ||
| bin | ||
| build/tasks | ||
| lib | ||
| modules | ||
| .csslintrc | ||
| .gitignore | ||
| .gitmodules | ||
| .gitreview | ||
| .jscsrc | ||
| .jshintignore | ||
| .jshintrc | ||
| ApiVisualEditor.php | ||
| ApiVisualEditorEdit.php | ||
| AUTHORS.txt | ||
| betafeatures-icon-VisualEditor-language-ltr.svg | ||
| betafeatures-icon-VisualEditor-language-rtl.svg | ||
| betafeatures-icon-VisualEditor-ltr.svg | ||
| betafeatures-icon-VisualEditor-rtl.svg | ||
| CONTRIBUTING.md | ||
| Gruntfile.js | ||
| LICENSE.txt | ||
| package.json | ||
| README.md | ||
| VisualEditor.hooks.php | ||
| VisualEditor.i18n.php | ||
| VisualEditor.php | ||
| VisualEditorDataModule.php | ||
VisualEditor
VisualEditor provides a visual editor for wiki pages. It is written in JavaScript and runs in a web browser.
It uses the Parsoid parser to convert wikitext documents to annotated HTML which the VisualEditor is able to load, modify and emit back to Parsoid at which point it is converted back into wikitext.
For more information about these projects, check out the VisualEditor and Parsoid pages on mediawiki.
Developing and installing
For information on installing VisualEditor on a local wiki, please see https://www.mediawiki.org/wiki/Extension:VisualEditor
For information about running tests and contributing code to VisualEditor, see CONTRIBUTING.md. Patch submissions are reviewed and managed with Gerrit. There is also API documentation available for the VisualEditor.