mediawiki-skins-Vector/includes/templates/skin.mustache

86 lines
3 KiB
Plaintext
Raw Normal View History

{{!
string|null html-site-notice the contents of a banner defined in MediaWiki:Sitenotice.
Also used by CentralNotice to inject banners into Vector.
Indicator[] array-indicators wiki-defined badges such as "good article",
"featured article". An empty array if none are defined.
string html-title
bool is-article
string msg-tagline
string html-subtitle
string html-undelete-link
string html-newtalk
string msg-vector-jumptonavigation
string msg-vector-jumptosearch
Switch to navigation-first DOM order under `$wgVectorIsSearchInHeader` feature flag This moves the header, navigation, sidebar, and article toolbar to be before the content in the DOM. As a result, a lot of absolute positioning logic can be removed and styles can be simplified. Note that although the sidebar was moved from the header into the workspace container allowing it to de-absolutely positioned, its absolute positioning was kept intact as it has a fair amount of complexity that should be handled in a separate task. To activate, set `$wgVectorIsSearchInHeader = true;` Changes that could cause concern: * The "jump to search" link was removed as the search is now much earlier in the DOM and I questioned the value of keeping this. However, it can be added back in if this change is contentious. * A "jump to content" link was added to account for the new DOM order. * Because the sidebar was taken out of the header, users will not be able to tab from the sidebar button into the sidebar without additional tweaking (e.g. should we add JS to enable this?). It was deemed that this work can be saved as a follow-up task. * I applied `overflow-y: auto` to the `mw-page-container` because the header's top margin was collapsing and caused whitespace to appear between the viewport and the header. Alternatively, we could apply a top padding to the page container and remove the header's top margin. I went for the simplest solution but am open to alternatives. * I left the footer as-is in this patch to minimize risk. It might be cleaner later on to move the footer inside the workspace container which would leave only one workspace container. Bug: T261802 Change-Id: Ic553fab3bde25769b103d899b92b3b694c00c384
2020-09-08 23:20:58 +00:00
string msg-vector-jumptocontent
string html-body-content
string html-categories
string html-after-content
LogoOptions data-logos
object data-portlets
MenuDefinition data-portlets.data-personal
MenuDefinition data-portlets.data-namespaces
MenuDefinition data-portlets.data-variants
MenuDefinition data-portlets.data-views
MenuDefinition data-portlets.data-actions
object data-search-box. See SearchBox.mustache for documentation.
boolean sidebar-visible For users that want to see the sidebar on initial render, this should be
true.
string msg-vector-action-toggle-sidebar The label used by the sidebar button.
string msg-vector-main-menu-tooltip The title attribute for the main menu icon.
object data-portlets-sidebar. See Sidebar.mustache for documentation.
object data-footer for footer template partial. see Footer.mustache for documentation.
}}
<div class="mw-page-container vector-layout-legacy">
<span id="top-page"></span>
Switch to navigation-first DOM order under `$wgVectorIsSearchInHeader` feature flag This moves the header, navigation, sidebar, and article toolbar to be before the content in the DOM. As a result, a lot of absolute positioning logic can be removed and styles can be simplified. Note that although the sidebar was moved from the header into the workspace container allowing it to de-absolutely positioned, its absolute positioning was kept intact as it has a fair amount of complexity that should be handled in a separate task. To activate, set `$wgVectorIsSearchInHeader = true;` Changes that could cause concern: * The "jump to search" link was removed as the search is now much earlier in the DOM and I questioned the value of keeping this. However, it can be added back in if this change is contentious. * A "jump to content" link was added to account for the new DOM order. * Because the sidebar was taken out of the header, users will not be able to tab from the sidebar button into the sidebar without additional tweaking (e.g. should we add JS to enable this?). It was deemed that this work can be saved as a follow-up task. * I applied `overflow-y: auto` to the `mw-page-container` because the header's top margin was collapsing and caused whitespace to appear between the viewport and the header. Alternatively, we could apply a top padding to the page container and remove the header's top margin. I went for the simplest solution but am open to alternatives. * I left the footer as-is in this patch to minimize risk. It might be cleaner later on to move the footer inside the workspace container which would leave only one workspace container. Bug: T261802 Change-Id: Ic553fab3bde25769b103d899b92b3b694c00c384
2020-09-08 23:20:58 +00:00
<a class="mw-jump-link" href="#content">{{msg-vector-jumptocontent}}</a>
<div class="mw-page-container-inner {{#data-toc}} vector-toc-visible{{/data-toc}}">
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
<input
type="checkbox"
id="mw-sidebar-checkbox"
class="mw-checkbox-hack-checkbox"
{{#sidebar-visible}}checked{{/sidebar-visible}}>
Switch to navigation-first DOM order under `$wgVectorIsSearchInHeader` feature flag This moves the header, navigation, sidebar, and article toolbar to be before the content in the DOM. As a result, a lot of absolute positioning logic can be removed and styles can be simplified. Note that although the sidebar was moved from the header into the workspace container allowing it to de-absolutely positioned, its absolute positioning was kept intact as it has a fair amount of complexity that should be handled in a separate task. To activate, set `$wgVectorIsSearchInHeader = true;` Changes that could cause concern: * The "jump to search" link was removed as the search is now much earlier in the DOM and I questioned the value of keeping this. However, it can be added back in if this change is contentious. * A "jump to content" link was added to account for the new DOM order. * Because the sidebar was taken out of the header, users will not be able to tab from the sidebar button into the sidebar without additional tweaking (e.g. should we add JS to enable this?). It was deemed that this work can be saved as a follow-up task. * I applied `overflow-y: auto` to the `mw-page-container` because the header's top margin was collapsing and caused whitespace to appear between the viewport and the header. Alternatively, we could apply a top padding to the page container and remove the header's top margin. I went for the simplest solution but am open to alternatives. * I left the footer as-is in this patch to minimize risk. It might be cleaner later on to move the footer inside the workspace container which would leave only one workspace container. Bug: T261802 Change-Id: Ic553fab3bde25769b103d899b92b3b694c00c384
2020-09-08 23:20:58 +00:00
{{>Header}}
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
<div class="mw-workspace-container">
Switch to navigation-first DOM order under `$wgVectorIsSearchInHeader` feature flag This moves the header, navigation, sidebar, and article toolbar to be before the content in the DOM. As a result, a lot of absolute positioning logic can be removed and styles can be simplified. Note that although the sidebar was moved from the header into the workspace container allowing it to de-absolutely positioned, its absolute positioning was kept intact as it has a fair amount of complexity that should be handled in a separate task. To activate, set `$wgVectorIsSearchInHeader = true;` Changes that could cause concern: * The "jump to search" link was removed as the search is now much earlier in the DOM and I questioned the value of keeping this. However, it can be added back in if this change is contentious. * A "jump to content" link was added to account for the new DOM order. * Because the sidebar was taken out of the header, users will not be able to tab from the sidebar button into the sidebar without additional tweaking (e.g. should we add JS to enable this?). It was deemed that this work can be saved as a follow-up task. * I applied `overflow-y: auto` to the `mw-page-container` because the header's top margin was collapsing and caused whitespace to appear between the viewport and the header. Alternatively, we could apply a top padding to the page container and remove the header's top margin. I went for the simplest solution but am open to alternatives. * I left the footer as-is in this patch to minimize risk. It might be cleaner later on to move the footer inside the workspace container which would leave only one workspace container. Bug: T261802 Change-Id: Ic553fab3bde25769b103d899b92b3b694c00c384
2020-09-08 23:20:58 +00:00
{{>Navigation}}
<div class="mw-table-of-contents-container mw-sticky-header-element">
{{#data-toc}}{{>TableOfContents}}{{/data-toc}}
</div>
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
<div class="mw-content-container">
{{! `role` is unnecessary but kept to support selectors in any gadgets or user styles. }}
<main id="content" class="mw-body" role="main">
<a id="top"></a>
<div id="siteNotice">{{{html-site-notice}}}</div>
{{>ContentHeader}}
{{>ContentSubheader}}
<div id="bodyContent" class="vector-body">
<div id="contentSub"{{{html-user-language-attributes}}}>{{{html-subtitle}}}</div>
<div id="contentSub2">{{{html-undelete-link}}}</div>
{{{html-user-message}}}
{{{html-body-content}}}
{{{html-categories}}}
</div>
{{#is-language-in-content-bottom}}
{{#data-portlets.data-languages}}{{>Menu}}{{/data-portlets.data-languages}}
{{/is-language-in-content-bottom}}
</main>
{{{html-after-content}}}
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
</div> {{! END mw-content-container }}
</div> {{! END mw-workspace-container }}
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
<div class="mw-workspace-container mw-footer-container">
<div class="mw-content-container">
{{#data-footer}}{{>Footer}}{{/data-footer}}
</div>
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
</div>
</div> {{! END mw-page-container-inner }}
</div> {{! END mw-page-container }}
{{#data-vector-sticky-header}}{{>StickyHeader}}{{/data-vector-sticky-header}}