darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-14 23:08:07 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
df313ad3d4c01ac6ece4f7cc4deca91e90b7633d
notifications-admin/app/assets/stylesheets/components/email-message.scss

108 lines
1.8 KiB
SCSS
Raw Normal View History

Don’t lint SCSS files that have come from outside We should (and do) keep exact copies of SCSS files that have come from elsewhere so that we can easily upgrade them. But sometimes they don’t always pass our linting rules, or throw a lot of warnings, which is noisy. This commit: - moves such files into their own subdirectory - tells SCSS Lint to ignore files in this directory
2016-04-13 12:50:13 +01:00
$white-50-opaque: rgba($white, 0.5);
Make the flow of using templates better For users who: - want to send messages from a template - want to edit templates For developers: - who need to get the ID of a template This commit mainly cleans up the choose template page so there are less options, and the options that are there are less wordy. This means: - moving ‘send yourself a test’ onto the send messages page, and making it button - stripping a lot of stuff out of the ‘send from API’ page, so it’s more obvious what the template ID is
2016-04-18 11:10:47 +01:00
$button-bottom-border-colour: rgba(0, 0, 0, 0.17);
Don’t lint SCSS files that have come from outside We should (and do) keep exact copies of SCSS files that have come from elsewhere so that we can easily upgrade them. But sometimes they don’t always pass our linting rules, or throw a lot of warnings, which is noisy. This commit: - moves such files into their own subdirectory - tells SCSS Lint to ignore files in this directory
2016-04-13 12:50:13 +01:00
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
.email-message {
margin-bottom: $gutter;
Make email pattern work in new context The email pattern looked a bit shonky when displayed in a narrower column. This commit fixes it by making the email’s metadata (eg subject, from) into a table, which it sort of is. This means that it is more flexible about the size of container in which it sits.
2016-02-23 14:58:49 +00:00
&-meta {
@include core-19;
margin: 0;
td,
th {
@include core-19;
border-bottom: 0;
border-top: 1px solid $border-colour;
Fix bug which prevented viewing an email job The template for viewing a job was not getting all the variables it needed in order to display an email template. Hadn’t noticed this before, because email templates require more variables than SMS templates. This commit fixes that bug.
2016-03-09 12:18:11 +00:00
vertical-align: top;
Make email pattern work in new context The email pattern looked a bit shonky when displayed in a narrower column. This commit fixes it by making the email’s metadata (eg subject, from) into a table, which it sort of is. This means that it is more flexible about the size of container in which it sits.
2016-02-23 14:58:49 +00:00
}
th {
color: $secondary-text-colour;
}
td {
width: 99%;
}
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
}
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
&-from {
padding-top: 15px;
border-top: 1px solid $border-colour;
}
&-body {
Move parameters out of the `…_message` components This commit refactors the `email_message` and `sms_message` UI components to take fewer parameters. `name`, `edit_link` and anything to do with versions are identical for both text and email messages so I’ve moved them to the pages where you choose a template or see the versions. This commit also tidies up the wording and styling of the template history stuff.
2016-05-26 17:05:16 +01:00
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
width: 100%;
box-sizing: border-box;
padding: $gutter-half 0 0 0;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
margin: 0 0 $gutter * 1.5 0;
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
clear: both;
border-top: 1px solid $border-colour;
border-bottom: 1px solid $border-colour;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
position: relative;
Wrap long words in email template previews If you put, for example, a URL in an email template it can be very long. This can cause it to overflow its container. This commit forces it to wrap instead.
2016-04-13 14:59:19 +01:00
word-wrap: break-word;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
&-wrapper {
Stop page jumping on first load with a long email A long email message needs to be collapsed to only show the first few lines. The problem is that we were doing this by adding a class with Javascript, meaning that the email wasn’t being collapsed until the script in the footer ran. This caused a jump in the page because the browser was painting the whole email message, then repainting it once it was collapsed. This commit takes advantage of the `.js-enabled` class added to the `<body>` by a script in the `<head>` of GOV.UK template. This means that the email message is collapsed with CSS before the first paint of the page, so no jump. This introduces some complexity in how we determine which emails get the expander toggle. Because they’re already collapsed we can’t get their height and work out if they’re long enough to need collapsing. So we need to take a copy of the message, put it off-screen, expand it, get its height, then remove it from the DOM. Bit of a faff. Because of this there’s still a quick flash of the toggle if you see an email message that’s too short to need collapsing. I think this is the lesser of two evils—very short email messages will be few and far between in the real world.
2016-06-14 15:19:31 +01:00
.js-enabled & {
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
max-height: 92px;
overflow: hidden;
}
Stop page jumping on first load with a long email A long email message needs to be collapsed to only show the first few lines. The problem is that we were doing this by adding a class with Javascript, meaning that the email wasn’t being collapsed until the script in the footer ran. This caused a jump in the page because the browser was painting the whole email message, then repainting it once it was collapsed. This commit takes advantage of the `.js-enabled` class added to the `<body>` by a script in the `<head>` of GOV.UK template. This means that the email message is collapsed with CSS before the first paint of the page, so no jump. This introduces some complexity in how we determine which emails get the expander toggle. Because they’re already collapsed we can’t get their height and work out if they’re long enough to need collapsing. So we need to take a copy of the message, put it off-screen, expand it, get its height, then remove it from the DOM. Bit of a faff. Because of this there’s still a quick flash of the toggle if you see an email message that’s too short to need collapsing. I think this is the lesser of two evils—very short email messages will be few and far between in the real world.
2016-06-14 15:19:31 +01:00
.js-enabled .expanded & {
max-height: none;
}
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
}
.toggle {
Stop page jumping on first load with a long email A long email message needs to be collapsed to only show the first few lines. The problem is that we were doing this by adding a class with Javascript, meaning that the email wasn’t being collapsed until the script in the footer ran. This caused a jump in the page because the browser was painting the whole email message, then repainting it once it was collapsed. This commit takes advantage of the `.js-enabled` class added to the `<body>` by a script in the `<head>` of GOV.UK template. This means that the email message is collapsed with CSS before the first paint of the page, so no jump. This introduces some complexity in how we determine which emails get the expander toggle. Because they’re already collapsed we can’t get their height and work out if they’re long enough to need collapsing. So we need to take a copy of the message, put it off-screen, expand it, get its height, then remove it from the DOM. Bit of a faff. Because of this there’s still a quick flash of the toggle if you see an email message that’s too short to need collapsing. I think this is the lesser of two evils—very short email messages will be few and far between in the real world.
2016-06-14 15:19:31 +01:00
display: none;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
position: absolute;
left: 50%;
bottom: -18px;
Make the flow of using templates better For users who: - want to send messages from a template - want to edit templates For developers: - who need to get the ID of a template This commit mainly cleans up the choose template page so there are less options, and the options that are there are less wordy. This means: - moving ‘send yourself a test’ onto the send messages page, and making it button - stripping a lot of stuff out of the ‘send from API’ page, so it’s more obvious what the template ID is
2016-04-18 11:10:47 +01:00
height: 27px;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
padding: 0;
margin: 0 0 0 -30px;
line-height: 12px;
font-size: 30px;
font-weight: bold;
letter-spacing: 2px;
text-align: center;
cursor: pointer;
width: 60px;
text-decoration: none;
Make the flow of using templates better For users who: - want to send messages from a template - want to edit templates For developers: - who need to get the ID of a template This commit mainly cleans up the choose template page so there are less options, and the options that are there are less wordy. This means: - moving ‘send yourself a test’ onto the send messages page, and making it button - stripping a lot of stuff out of the ‘send from API’ page, so it’s more obvious what the template ID is
2016-04-18 11:10:47 +01:00
background: $grey-3;
color: $text-colour;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
border-style: solid;
border-width: 3px;
Don’t lint SCSS files that have come from outside We should (and do) keep exact copies of SCSS files that have come from elsewhere so that we can easily upgrade them. But sometimes they don’t always pass our linting rules, or throw a lot of warnings, which is noisy. This commit: - moves such files into their own subdirectory - tells SCSS Lint to ignore files in this directory
2016-04-13 12:50:13 +01:00
border-color: $white;
Make the flow of using templates better For users who: - want to send messages from a template - want to edit templates For developers: - who need to get the ID of a template This commit mainly cleans up the choose template page so there are less options, and the options that are there are less wordy. This means: - moving ‘send yourself a test’ onto the send messages page, and making it button - stripping a lot of stuff out of the ‘send from API’ page, so it’s more obvious what the template ID is
2016-04-18 11:10:47 +01:00
box-shadow: inset 0 -2px 0 $button-bottom-border-colour, 0 0 0 1px $white-50-opaque;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
&:hover {
Make the flow of using templates better For users who: - want to send messages from a template - want to edit templates For developers: - who need to get the ID of a template This commit mainly cleans up the choose template page so there are less options, and the options that are there are less wordy. This means: - moving ‘send yourself a test’ onto the send messages page, and making it button - stripping a lot of stuff out of the ‘send from API’ page, so it’s more obvious what the template ID is
2016-04-18 11:10:47 +01:00
background: $grey-2;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
}
&:focus,
&:active {
Make the flow of using templates better For users who: - want to send messages from a template - want to edit templates For developers: - who need to get the ID of a template This commit mainly cleans up the choose template page so there are less options, and the options that are there are less wordy. This means: - moving ‘send yourself a test’ onto the send messages page, and making it button - stripping a lot of stuff out of the ‘send from API’ page, so it’s more obvious what the template ID is
2016-04-18 11:10:47 +01:00
border-color: $yellow;
Truncate previews of email messages to ~3 lines Emails can get very long. When you’re trying to do other things on the page this results in a lot of scrolling. This commit truncates email messages to about 3 lines, and adds a JS toggle which reveal the full contents of the email.
2016-04-11 15:16:41 +01:00
outline: none;
}
}
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
}
}
Stop page jumping on first load with a long email A long email message needs to be collapsed to only show the first few lines. The problem is that we were doing this by adding a class with Javascript, meaning that the email wasn’t being collapsed until the script in the footer ran. This caused a jump in the page because the browser was painting the whole email message, then repainting it once it was collapsed. This commit takes advantage of the `.js-enabled` class added to the `<body>` by a script in the `<head>` of GOV.UK template. This means that the email message is collapsed with CSS before the first paint of the page, so no jump. This introduces some complexity in how we determine which emails get the expander toggle. Because they’re already collapsed we can’t get their height and work out if they’re long enough to need collapsing. So we need to take a copy of the message, put it off-screen, expand it, get its height, then remove it from the DOM. Bit of a faff. Because of this there’s still a quick flash of the toggle if you see an email message that’s too short to need collapsing. I think this is the lesser of two evils—very short email messages will be few and far between in the real world.
2016-06-14 15:19:31 +01:00
.js-enabled .toggle {
display: inline-block;
}
.js-enabled .expanded .toggle {
display: none;
}
Reference in New Issue Copy Permalink