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/components/modal-dialog/skin.scss

59 lines
1.4 KiB
SCSS
Raw Normal View History

ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
%modal-dialog.warning header {
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
background-color: rgb(var(--tone-yellow-050));
border-color: rgb(var(--tone-yellow-500));
color: rgb(var(--tone-yellow-800));
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
%modal-dialog.warning header > *:not(label) {
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-size: var(--typo-size-500);
font-weight: var(--typo-weight-semibold);
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
%modal-dialog.warning header::before {
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
@extend %with-alert-triangle-mask, %as-pseudo;
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
color: rgb(var(--tone-yellow-500));
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
float: left;
margin-top: 2px;
margin-right: 3px;
}
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
%modal-dialog-overlay {
ui: Fix brand coloring for inline-code plus docs (#11578) * ui: Fix brand coloring for inline-code plus docs Also use --tones instead of --black/--white (#11601) Co-authored-by: Evan Rowe <ev.rowe@gmail.com>
2021-11-23 18:32:11 +00:00
background-color: rgb(var(--tone-gray-000) / 90%);
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}
%modal-window {
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
box-shadow: var(--decor-elevation-800);
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}
%modal-window {
/*%frame-gray-000*/
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
background-color: rgb(var(--tone-gray-000));
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}
%modal-window > footer,
%modal-window > header {
@extend %frame-gray-800;
}
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
%modal-window > header > * {
@extend %h200;
}
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
.modal-dialog-body,
%modal-window > footer,
%modal-window > header {
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-300));
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}
.modal-dialog-body {
border-style: solid;
border-left-width: 1px;
border-right-width: 1px;
}
%modal-window > footer,
%modal-window > header {
border-width: 1px;
}
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
%modal-window > header [data-a11y-dialog-hide] {
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
@extend %with-cancel-plain-icon;
cursor: pointer;
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: var(--decor-border-100);
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
/*%frame-gray-050??*/
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
background-color: rgb(var(--tone-gray-050));
border-color: rgb(var(--tone-gray-300));
border-radius: var(--decor-radius-100);
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
}