wikimedia/mediawiki-skins-Vector
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/skins/Vector.git synced 2024-12-11 07:26:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-skins-Vector/resources/skins.vector.styles/MenuPortal.less

54 lines
1.2 KiB
Plaintext
Raw Normal View History

Isolate Vector Styles to their Respective Component This will help with the encapsulation/reusability of each component. * Stylesheets were renamed to reflect their respective component name (e.g. search.less became SearchBox.less) * Styles were isolated to each component: * navigation.less now only contains classes that are relevant to Navigation.mustache. * personalNavigation.less, search.less, and tabs.less imports were removed and made first-class styles. * several selectors were moved into common.less * #p-logo was moved into sidebar * tabs.less was renamed to VectorTabs.less and styles specific to VectorMenu.less were put into VectorMenu.less * Storybook was updated to reflect changes Bug: T243281 Change-Id: Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619
2020-02-28 20:06:33 +00:00
@import '../../variables.less';
@import 'mediawiki.mixins.less';
Refactor: Portal is also a Menu To complete the refactor, the Portal is also refactored as a Menu using the getMenu function. An old code path supporting portals outputted by hooks with strings is marked as deprecated to simplify this code in future. array-portals-first -> data-portals-first (the value is not an array) Changes: * $this->getLanguages and $this->getToolbox() always returns an array (see BaseTemplate) but we previously supported portals made using raw HTML. Let's move away from that behaviour and deprecate it. * Hooks are moved into buildSidebarProps and marked as deprecated where possible (SkinTemplateToolboxEnd). SidebarBeforeOutput can be used instead. Bug: T249372 Change-Id: I2549af3e24e5d51c09e9a88ca50a0d9b2e154c3f
2020-04-07 23:21:20 +00:00
// FIXME: For cached HTML
.portal,
.vector-menu-portal {
Add end margin to opt-out link This adds the same end margin as the portal container making the opt-out-link more visually pleasing if it overflows its container. Bug: T243281 Change-Id: I42eb3ec4a18ad9e4f6bcdb451593fec7e6e4992a
2020-03-27 16:15:30 +00:00
margin: 0 @margin-end-portal 0 @margin-start-portal;
Isolate Vector Styles to their Respective Component This will help with the encapsulation/reusability of each component. * Stylesheets were renamed to reflect their respective component name (e.g. search.less became SearchBox.less) * Styles were isolated to each component: * navigation.less now only contains classes that are relevant to Navigation.mustache. * personalNavigation.less, search.less, and tabs.less imports were removed and made first-class styles. * several selectors were moved into common.less * #p-logo was moved into sidebar * tabs.less was renamed to VectorTabs.less and styles specific to VectorMenu.less were put into VectorMenu.less * Storybook was updated to reflect changes Bug: T243281 Change-Id: Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619
2020-02-28 20:06:33 +00:00
padding: 0.25em 0;
direction: ltr;
h3 {
Refactor: Simplify and standardize menu definitions * Standardise the menu markup. This means all menus in Vector will now be wrapped in a div and will have a heading. * All menus now have the vector-menu class. Styles specific to personal tools are moved to layout since these are concerned with placement. * The ul class will always have menu class. * emptyPortal class is generalised into vector-menu-empty for consistency with other classes and moved from common.less into Menu.less * Standardise hooks - BaseTemplateAfterPortlet can now be run on any menu. Changes to HTML: * lang and dir attributes are moved from the h3 up to the div element .vectorTabs, .portal(s) and #p-personal now has hidden span element inside h3 * for non portals ul.menu" is now wrapped in a div.vector-menu-content This change does impact the following CSS selectors which will need to be updated: I see no matches for these selectors in code search. ``` #p-variants > ul #p-namespaces > ul #p-personal > ul #p-views > ul #p-cactions > ul ``` Using global-search.toolforge.org I see one match for p-variants, 26 for p-namespaces, 30 for p-personal, 36 for p-views and 7 for p-cactions. I see this as acceptable breakage provided a user notice is sent out which it has been (T252447) Bug: T249372 Change-Id: Id59234aa6b822a24848386bdc04d8d7ed37ca145
2020-04-16 18:40:39 +00:00
display: block;
refactor: Move up `.portal` underline gradient from `.body` to `h3` Change-Id: I3c057e048ada0601497ee6697c19bf207c3bc821
2020-04-16 05:19:34 +00:00
background-image: url( images/portal-separator.png ); // Support: IE 8 & 9, Fx 3.6-15, Safari 5.1-6, Chrome 10-25
background-image: linear-gradient( to right, transparent 0, #c8ccd1 35%, #c8ccd1 70%, transparent 100% ); // Standard (Firefox 16+, IE 10+, Safari 6.1+, Chrome 26+)
background-position: center bottom;
background-repeat: no-repeat;
background-size: 100% @border-width-base;
Isolate Vector Styles to their Respective Component This will help with the encapsulation/reusability of each component. * Stylesheets were renamed to reflect their respective component name (e.g. search.less became SearchBox.less) * Styles were isolated to each component: * navigation.less now only contains classes that are relevant to Navigation.mustache. * personalNavigation.less, search.less, and tabs.less imports were removed and made first-class styles. * several selectors were moved into common.less * #p-logo was moved into sidebar * tabs.less was renamed to VectorTabs.less and styles specific to VectorMenu.less were put into VectorMenu.less * Storybook was updated to reflect changes Bug: T243281 Change-Id: Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619
2020-02-28 20:06:33 +00:00
color: @color-nav-subtle;
font-weight: normal;
Add opt-out link to Sidebar for Vector/Logged-in Users Without Abstractions This commit is singularly focused on adding a link to the sidebar for Vector, logged-in users. It does the bare minimum to fulfill the requirements of T243281. Additionally, it will help to answer the question "Do we need to use abstractions (other than maybe different templates) to separate Legacy Vector from Vector" by intentionally leaving out any abstractions in order to make it easier to compare with a follow-up patch (Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions. It is a good thing to question whether or not we need addtional abstractions in VectorTemplate and if they will help us as unnecessary abstractions can have the opposite effect and just lead to further frustrations down the road. Therefore, I urge you, the reviewer, to let me know your thoughts! If abstractions are viewed as not making our lives any easier, the follow-up patches may be completely discarded and that's totally okay with me. :) I think it's a good think to talk about now though. Important changes: * The VectorTemplate constructor was changed to allow injecting the config, templateParser, and isLegacy boolean (only the config was allowed before this commit). According to MediaWiki's Stable Interface Policy, "Constructor signatures are generally considered unstable unless explicitly declared stable for calling" [3]. Given that VecorTemplate's constructor is not marked as stable, it is justified to do this without warning according to the policy. * Due to the above, the 'setTemplate' method is no longer needed and was marked as deprecated. * VectorTemplateTest was made to adapt to the new VectorTemplate constructor. Additionally, it now extends from MediaWikiIntegrationTestCase which my intelliphense server can pick up. I *think* MediaWikiTestCase is just an alias to MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed to MediaWikiIntegrationTestCase in [2], but I'm willing to change it back if there is pushback to this. Open questions: * What are VectorTemplate's responsibilities? To me, it acts right now as a controller (because it echos the full HTML string from the template), a model (because SkinTemplate::prepareQuickTemplate sets data on it which it later retrieves through `$this->get()`), a presenter (because it adds data tailored for a web-centric view), and a view (because it renders HTML strings instead of letting the view/template be solely responsible for that). Arguably, some business logic might be mixed in there as well (because it checks to see if a User is logged in/has necessary permissions to show x which my changes here add to). This might not be a problem if we keep VectorTemplate relatively small, but will it remain this way as we progress further in Desktop Improvements? * How do we write tests for VectorTemplate without exposing unnecessary public methods? For example, if I want to test the `getSkinData()` method to see what state will be sent to the template, how should I do this? One option might be to use `TestingAccessWrapper` to expose these private methods which is what `VectorTemplateTest::testbuildViewsProps()` does. Another option is to accept this method as public. Is there a better way? Keep in mind that even with access to this method, there might be many things to mock. [1] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
margin: 0.5em 0 0 ( @margin-start-nav-main-body / @font-size-nav-main-heading );
Isolate Vector Styles to their Respective Component This will help with the encapsulation/reusability of each component. * Stylesheets were renamed to reflect their respective component name (e.g. search.less became SearchBox.less) * Styles were isolated to each component: * navigation.less now only contains classes that are relevant to Navigation.mustache. * personalNavigation.less, search.less, and tabs.less imports were removed and made first-class styles. * several selectors were moved into common.less * #p-logo was moved into sidebar * tabs.less was renamed to VectorTabs.less and styles specific to VectorMenu.less were put into VectorMenu.less * Storybook was updated to reflect changes Bug: T243281 Change-Id: Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619
2020-02-28 20:06:33 +00:00
padding: 0.25em 0;
cursor: default;
border: 0;
font-size: @font-size-nav-main-heading;
}
.body {
Add opt-out link to Sidebar for Vector/Logged-in Users Without Abstractions This commit is singularly focused on adding a link to the sidebar for Vector, logged-in users. It does the bare minimum to fulfill the requirements of T243281. Additionally, it will help to answer the question "Do we need to use abstractions (other than maybe different templates) to separate Legacy Vector from Vector" by intentionally leaving out any abstractions in order to make it easier to compare with a follow-up patch (Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions. It is a good thing to question whether or not we need addtional abstractions in VectorTemplate and if they will help us as unnecessary abstractions can have the opposite effect and just lead to further frustrations down the road. Therefore, I urge you, the reviewer, to let me know your thoughts! If abstractions are viewed as not making our lives any easier, the follow-up patches may be completely discarded and that's totally okay with me. :) I think it's a good think to talk about now though. Important changes: * The VectorTemplate constructor was changed to allow injecting the config, templateParser, and isLegacy boolean (only the config was allowed before this commit). According to MediaWiki's Stable Interface Policy, "Constructor signatures are generally considered unstable unless explicitly declared stable for calling" [3]. Given that VecorTemplate's constructor is not marked as stable, it is justified to do this without warning according to the policy. * Due to the above, the 'setTemplate' method is no longer needed and was marked as deprecated. * VectorTemplateTest was made to adapt to the new VectorTemplate constructor. Additionally, it now extends from MediaWikiIntegrationTestCase which my intelliphense server can pick up. I *think* MediaWikiTestCase is just an alias to MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed to MediaWikiIntegrationTestCase in [2], but I'm willing to change it back if there is pushback to this. Open questions: * What are VectorTemplate's responsibilities? To me, it acts right now as a controller (because it echos the full HTML string from the template), a model (because SkinTemplate::prepareQuickTemplate sets data on it which it later retrieves through `$this->get()`), a presenter (because it adds data tailored for a web-centric view), and a view (because it renders HTML strings instead of letting the view/template be solely responsible for that). Arguably, some business logic might be mixed in there as well (because it checks to see if a User is logged in/has necessary permissions to show x which my changes here add to). This might not be a problem if we keep VectorTemplate relatively small, but will it remain this way as we progress further in Desktop Improvements? * How do we write tests for VectorTemplate without exposing unnecessary public methods? For example, if I want to test the `getSkinData()` method to see what state will be sent to the template, how should I do this? One option might be to use `TestingAccessWrapper` to expose these private methods which is what `VectorTemplateTest::testbuildViewsProps()` does. Another option is to accept this method as public. Is there a better way? Keep in mind that even with access to this method, there might be many things to mock. [1] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
margin-left: @margin-start-portal-body;
Isolate Vector Styles to their Respective Component This will help with the encapsulation/reusability of each component. * Stylesheets were renamed to reflect their respective component name (e.g. search.less became SearchBox.less) * Styles were isolated to each component: * navigation.less now only contains classes that are relevant to Navigation.mustache. * personalNavigation.less, search.less, and tabs.less imports were removed and made first-class styles. * several selectors were moved into common.less * #p-logo was moved into sidebar * tabs.less was renamed to VectorTabs.less and styles specific to VectorMenu.less were put into VectorMenu.less * Storybook was updated to reflect changes Bug: T243281 Change-Id: Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619
2020-02-28 20:06:33 +00:00
padding-top: 0;
ul {
list-style: none none;
margin: 0;
padding-top: 0.3em;
}
li {
margin: 0;
padding: 0.25em 0;
Add opt-out link to Sidebar for Vector/Logged-in Users Without Abstractions This commit is singularly focused on adding a link to the sidebar for Vector, logged-in users. It does the bare minimum to fulfill the requirements of T243281. Additionally, it will help to answer the question "Do we need to use abstractions (other than maybe different templates) to separate Legacy Vector from Vector" by intentionally leaving out any abstractions in order to make it easier to compare with a follow-up patch (Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions. It is a good thing to question whether or not we need addtional abstractions in VectorTemplate and if they will help us as unnecessary abstractions can have the opposite effect and just lead to further frustrations down the road. Therefore, I urge you, the reviewer, to let me know your thoughts! If abstractions are viewed as not making our lives any easier, the follow-up patches may be completely discarded and that's totally okay with me. :) I think it's a good think to talk about now though. Important changes: * The VectorTemplate constructor was changed to allow injecting the config, templateParser, and isLegacy boolean (only the config was allowed before this commit). According to MediaWiki's Stable Interface Policy, "Constructor signatures are generally considered unstable unless explicitly declared stable for calling" [3]. Given that VecorTemplate's constructor is not marked as stable, it is justified to do this without warning according to the policy. * Due to the above, the 'setTemplate' method is no longer needed and was marked as deprecated. * VectorTemplateTest was made to adapt to the new VectorTemplate constructor. Additionally, it now extends from MediaWikiIntegrationTestCase which my intelliphense server can pick up. I *think* MediaWikiTestCase is just an alias to MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed to MediaWikiIntegrationTestCase in [2], but I'm willing to change it back if there is pushback to this. Open questions: * What are VectorTemplate's responsibilities? To me, it acts right now as a controller (because it echos the full HTML string from the template), a model (because SkinTemplate::prepareQuickTemplate sets data on it which it later retrieves through `$this->get()`), a presenter (because it adds data tailored for a web-centric view), and a view (because it renders HTML strings instead of letting the view/template be solely responsible for that). Arguably, some business logic might be mixed in there as well (because it checks to see if a User is logged in/has necessary permissions to show x which my changes here add to). This might not be a problem if we keep VectorTemplate relatively small, but will it remain this way as we progress further in Desktop Improvements? * How do we write tests for VectorTemplate without exposing unnecessary public methods? For example, if I want to test the `getSkinData()` method to see what state will be sent to the template, how should I do this? One option might be to use `TestingAccessWrapper` to expose these private methods which is what `VectorTemplateTest::testbuildViewsProps()` does. Another option is to accept this method as public. Is there a better way? Keep in mind that even with access to this method, there might be many things to mock. [1] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
font-size: @font-size-portal-list-item;
Isolate Vector Styles to their Respective Component This will help with the encapsulation/reusability of each component. * Stylesheets were renamed to reflect their respective component name (e.g. search.less became SearchBox.less) * Styles were isolated to each component: * navigation.less now only contains classes that are relevant to Navigation.mustache. * personalNavigation.less, search.less, and tabs.less imports were removed and made first-class styles. * several selectors were moved into common.less * #p-logo was moved into sidebar * tabs.less was renamed to VectorTabs.less and styles specific to VectorMenu.less were put into VectorMenu.less * Storybook was updated to reflect changes Bug: T243281 Change-Id: Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619
2020-02-28 20:06:33 +00:00
line-height: @line-height-nav;
word-wrap: break-word;
a {
color: @color-link;
&:visited {
color: @color-link--visited;
}
}
}
}
}
Reference in a new issue Copy permalink