mediawiki-extensions-Visual.../modules/ve-mw/init/styles/ve.init.mw.DesktopArticleTarget.noscript.css

39 lines
1.1 KiB
CSS
Raw Normal View History

Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
/*!
* VisualEditor MediaWiki DesktopArticleTarget noscript styles
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
*
* @copyright 2011-2016 VisualEditor Team and others; see AUTHORS.txt
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
* @license The MIT License (MIT); see LICENSE.txt
*/
/* stylelint-disable selector-no-id */
mw.ViewPageTarget: Get rid of FOUC on edit section brackets 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
2014-05-07 00:08:53 +00:00
/* Hide VE edit tab and section edit things for noscript users.
* For script users they're always visible unless and until ve-not-available is added.
*/
.client-nojs #ca-ve-edit,
.client-nojs .mw-editsection-divider,
.client-nojs .mw-editsection-visualeditor,
.ve-not-available #ca-ve-edit,
.ve-not-available .mw-editsection-divider,
.ve-not-available .mw-editsection-visualeditor {
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
display: none;
}
mw.ViewPageTarget: Get rid of FOUC on edit section brackets 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
2014-05-07 00:08:53 +00:00
/* stylelint-enable selector-no-id */
mw.ViewPageTarget: Get rid of FOUC on edit section brackets 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
2014-05-07 00:08:53 +00:00
/* For script users, expand brackets by default, unless and until ve-not-available is added */
/* @noflip */
.client-js .mw-content-ltr .mw-editsection-bracket:first-of-type,
.client-js .mw-content-rtl .mw-editsection-bracket:not( :first-of-type ) {
mw.ViewPageTarget: Get rid of FOUC on edit section brackets 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
2014-05-07 00:08:53 +00:00
margin-right: 0.25em;
color: #555;
}
/* @noflip */
.client-js .mw-content-rtl .mw-editsection-bracket:first-of-type,
.client-js .mw-content-ltr .mw-editsection-bracket:not( :first-of-type ) {
mw.ViewPageTarget: Get rid of FOUC on edit section brackets 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
2014-05-07 00:08:53 +00:00
margin-left: 0.25em;
color: #555;
}