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

36 lines
1.2 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: Update Consul UI colors to use HDS colors (#16111) * update red color variables to hds * change background red to be one step lighter * map oranges * map greens * map blues * map greys * delete themes, colours: lemon, magenta, strawberry, and vault color aliases * add unmapped rainbow colours * replace white and transparent vars, remove unused semantic vars and frame placeholders * small tweaks to improve contrast, change node health status x/check colours for non-voters to match design doc, replace semantic colour action w hds colour * add unmapped grays, remove dark theme, manually set nav bar to use dark colours * map consul pink colour * map yellows * add unmapped oranges, delete light theme * remove readme, base variables, clean up dangling colours * Start working on the nav disclosure menus * Update main-nav-horizontal dropdowns * Format template * Update box-shadow tokens * Replace --tone- usage with tokens * Update nav disabled state and panel border colour * Replace rgb usage on tile * Fix permissions modal overlay * More fixes * Replace orange-500 with amber-200 * Update badge colors * Update vertical sidebar colors * Remove top border on consul peer list ul --------- Co-authored-by: wenincode <tyler.wendlandt@hashicorp.com>
2023-02-27 16:30:12 +00:00
border-color: var(--token-color-surface-interactive-active);
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;
}