status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
consul/ui/packages/consul-ui/app/styles/routes/dc/services/index.scss

36 lines
1.1 KiB
SCSS
Raw Normal View History

ui: Alter position of dashboard button in the service instance header (#11988)
2022-01-12 09:31:54 +00:00
/* drop the external dashboard button down if it exists */
/* so it doesn't sit next to the Intentions create button */
/* awkwardly */
html[data-route^='dc.services.show'] .app-view .actions .external-dashboard {
position: absolute;
top: 50px;
right: 0;
}
ui: Various CSS amends (#8708) * ui: Various CSS amends 1. Split out %icon-definition from %composite-row 2. Add hover effect to node listing 3. Fix up proxy level list components 4. Rename our various pills to use a 100-900 scale 5. Reogranize other icon related things (consul-kind and consul-external-source) * Fix up upstream test
2020-09-22 17:20:44 +00:00
/* instance detail dl text*/
ui: Outlet Loading (#8779) Moves all Route/model hook loading to use Outlet components which listen on route change.
2020-10-01 08:33:22 +00:00
html[data-route^='dc.services.instance'] .app-view > header dl {
ui: Various CSS amends (#8708) * ui: Various CSS amends 1. Split out %icon-definition from %composite-row 2. Add hover effect to node listing 3. Fix up proxy level list components 4. Rename our various pills to use a 100-900 scale 5. Reogranize other icon related things (consul-kind and consul-external-source) * Fix up upstream test
2020-09-22 17:20:44 +00:00
float: left;
margin-top: 19px;
margin-bottom: 23px;
margin-right: 50px;
}
ui: Outlet Loading (#8779) Moves all Route/model hook loading to use Outlet components which listen on route change.
2020-10-01 08:33:22 +00:00
html[data-route^='dc.services.instance'] .app-view > header dt {
ui: Replaces almost all remaining instances of SASS variables with CSS (#11200) From an engineers perspective, whenever specifying colors from now on we should use the form: ``` color: rgb(var(--tone-red-500)); ``` Please note: - Use rgb. This lets us do this like rgb(var(--tone-red-500) / 10%) so we can use a 10% opacity red-500 if we ever need to whilst still making use of our color tokens. - Use --tone-colorName-000 (so the prefix tone). Previously we could use a mix of --gray-500: $gray-500 (note the left hand CSS prop and right hand SASS var) for the things we need to theme currently. As we no longer use SASS we can't do --gray-500: --gray-500, so we now do --tone-gray-500: --gray-500. Just for clarity after that, whenever specifying a color anywhere, use rgb and --tone. There is only one reason where you might not use tone, and that is if you never want a color to be affected by a theme (for example a background shadow probably always should use --black) There are a 2 or 3 left for the code editor, plus our custom-query values
2021-10-07 18:21:11 +00:00
font-weight: var(--typo-weight-bold);
ui: New Intention Form/List components (#8172)
2020-07-09 09:08:47 +00:00
}
ui: Minor CSS tweaks (#10295)
2021-05-26 13:35:19 +00:00
html[data-route^='dc.services.instance'] .tab-nav {
ui: Replaces almost all remaining instances of SASS variables with CSS (#11200) From an engineers perspective, whenever specifying colors from now on we should use the form: ``` color: rgb(var(--tone-red-500)); ``` Please note: - Use rgb. This lets us do this like rgb(var(--tone-red-500) / 10%) so we can use a 10% opacity red-500 if we ever need to whilst still making use of our color tokens. - Use --tone-colorName-000 (so the prefix tone). Previously we could use a mix of --gray-500: $gray-500 (note the left hand CSS prop and right hand SASS var) for the things we need to theme currently. As we no longer use SASS we can't do --gray-500: --gray-500, so we now do --tone-gray-500: --gray-500. Just for clarity after that, whenever specifying a color anywhere, use rgb and --tone. There is only one reason where you might not use tone, and that is if you never want a color to be affected by a theme (for example a background shadow probably always should use --black) There are a 2 or 3 left for the code editor, plus our custom-query values
2021-10-07 18:21:11 +00:00
border-top: var(--decor-border-100);
ui: Minor CSS tweaks (#10295)
2021-05-26 13:35:19 +00:00
}
html[data-route^='dc.services.instance'] .tab-section section:not(:last-child) {
ui: Replaces almost all remaining instances of SASS variables with CSS (#11200) From an engineers perspective, whenever specifying colors from now on we should use the form: ``` color: rgb(var(--tone-red-500)); ``` Please note: - Use rgb. This lets us do this like rgb(var(--tone-red-500) / 10%) so we can use a 10% opacity red-500 if we ever need to whilst still making use of our color tokens. - Use --tone-colorName-000 (so the prefix tone). Previously we could use a mix of --gray-500: $gray-500 (note the left hand CSS prop and right hand SASS var) for the things we need to theme currently. As we no longer use SASS we can't do --gray-500: --gray-500, so we now do --tone-gray-500: --gray-500. Just for clarity after that, whenever specifying a color anywhere, use rgb and --tone. There is only one reason where you might not use tone, and that is if you never want a color to be affected by a theme (for example a background shadow probably always should use --black) There are a 2 or 3 left for the code editor, plus our custom-query values
2021-10-07 18:21:11 +00:00
border-bottom: var(--decor-border-100);
ui: Minor CSS tweaks (#10295)
2021-05-26 13:35:19 +00:00
}
html[data-route^='dc.services.instance'] .tab-nav,
html[data-route^='dc.services.instance'] .tab-section section:not(:last-child) {
ui: Replaces almost all remaining instances of SASS variables with CSS (#11200) From an engineers perspective, whenever specifying colors from now on we should use the form: ``` color: rgb(var(--tone-red-500)); ``` Please note: - Use rgb. This lets us do this like rgb(var(--tone-red-500) / 10%) so we can use a 10% opacity red-500 if we ever need to whilst still making use of our color tokens. - Use --tone-colorName-000 (so the prefix tone). Previously we could use a mix of --gray-500: $gray-500 (note the left hand CSS prop and right hand SASS var) for the things we need to theme currently. As we no longer use SASS we can't do --gray-500: --gray-500, so we now do --tone-gray-500: --gray-500. Just for clarity after that, whenever specifying a color anywhere, use rgb and --tone. There is only one reason where you might not use tone, and that is if you never want a color to be affected by a theme (for example a background shadow probably always should use --black) There are a 2 or 3 left for the code editor, plus our custom-query values
2021-10-07 18:21:11 +00:00
border-color: rgb(var(--tone-gray-200));
ui: Minor CSS tweaks (#10295)
2021-05-26 13:35:19 +00:00
}
ui: Accessibility scan improvements (#9485) * ui: Remove all vestiges of role=tabpanel * Switch out tablist role for a label, default to Secondary * Move healthcheckout-output headers to h2, ideally these would be outside the component * Add aria-label for empty button * Fix up non-unique ids in topology component * Temporarily fixup h2 in KV > LockSession * Fixup dl with no dt * h3 > h2 * Fix up page objects that were reliant on ids
2021-01-05 10:05:59 +00:00
html[data-route^='dc.services.instance'] .tab-section section:not(:last-child) {
ui: Fix up tab separator CSS to not apply to all tabs (#8792)
2020-10-01 13:33:48 +00:00
padding-bottom: 24px;
}
ui: Re-organize our %h* placeholders (#9584) We've always had this idea of being able to markup up information semantically without thinking about what it should look like, then applying our %h* placeholder styles to control what the information should look like. Back when we originally made our set of %h* placeholders, we tried to follow Structure as much as possible, which defined the largest header (which we thought would have been the h1 style) as a super large 3.5rem. Therefore we made our set of %h* placeholders the same as Structure beginning at a huge 3.5 size. We then re-overwrote those sizes only in Consul specific CSS files thinking that this was due to us existing before Structure did. Lately we saw an extra clue in Structure - the extra large 3.5 header was called 'h0'. This commit moves all our headers to use a zero based scale, and additionally uses our 3 digit scale as opposed to 1 digit (h1 vs h100), similar to our color scales (note we don't use a hypen, which we can alter later if need be), which means we can insert additional h150 etc if need be. Additional we stop styling our headers globally (h1 { @extend %h100; } ). This means there is no reason not to use headers for marking up content depending on what it is rather than what it should look like, and as a consequence means we can be more purposeful in ordering h* tags. Lastly, we use the new scale over the entire codebase and update a couple of places where we were using using header tags due to what the styleing for them looked like rather than what the meaning/order was.
2021-01-26 17:53:45 +00:00
html[data-route^='dc.services.instance.metadata'] .tab-section section h2 {
@extend %h300;
ui: Fix up tab separator CSS to not apply to all tabs (#8792)
2020-10-01 13:33:48 +00:00
margin: 24px 0 12px 0;
}