Files
notifications-admin/app/assets/stylesheets/views/template.scss

68 lines
1.3 KiB
SCSS
Raw Normal View History

.template-container {
position: relative;
}
%edit-template-link,
.edit-template-link {
@include core-19;
position: absolute;
background: $link-colour;
color: $white;
padding: 10px govuk-spacing(3);
z-index: 10000;
&:link, &:visited {
color: $white;
}
&:hover {
color: $light-blue-25;
}
&:focus {
color: $govuk-text-colour;
}
}
.edit-template-link-letter-contact {
@extend %edit-template-link;
right: -25px;
top: 232px; // align to bottom of contact block
}
.edit-template-link-letter-address {
@extend %edit-template-link;
top: 14.65%; // align bottom edge to bottom of address
left: -5px;
}
.edit-template-link-letter-body {
@extend %edit-template-link;
top: 400px; // aligns to top of subject
left: -5px;
}
.edit-template-link-letter-postage {
@extend %edit-template-link;
top: 51px; // aligns bottom edge to bottom of postmark
right: 145px; // Aligns right edge to midpoint of postmark and fold
}
.edit-template-link-letter-branding {
@extend %edit-template-link;
top: 51px; // aligns with change postage link
left: 66px; // Aligns to left of logo area
}
.template-content-count {
@include core-19($tabular-numbers: true);
color: $secondary-text-colour;
Stop content length message from making page jumpy The content length message was making the page jumpy and causing reflows in three ways. This commit addresses each of those ways: As the user scrolled --- The footer went from fixed to sticky and the spacing around the message changed. This change in spacing was needed so that the message looked right in both contexts. I think the best way to resolve this is to not use the sticky footer when editing text message or broadcast templates. On my 1440×900 screen I can fit a 5 fragment text message, plus the ‘will be charged as 5 text messages’ message, plus the save button. Our top 10 screen resolutions according to our analytics are: Position | Resolution | Percentage of users ---------|------------|-------------------- 1 | 1920x1080 | 27.37% 2 | 1280×720 | 11.07% 3 | 1366×768 | 8.88% 4 | 1536×864 | 5.79% 5 | 1440×900 | 4.52% 6 | 1600×900 | 3.71% 7 | 1280×1024 | 3.10% 8 | 1680×1050 | 2.42% 9 | 1920×1200 | 2.33% 10 | 2560×1440 | 1.99% When the page first loaded --- The message is empty so takes up no space, then the javascript fires and inserts the message, taking up a line of space. This is resolved by making the empty message take up space with a non-breaking space character. When the user first typed --- We previously didn’t show any message until the user started typing. This meant that, with the above fix, there was a larger than normal empty space between the textarea and the save button. This is resolved by always showing the message, even when the user hasn’t typed anything yet. *** These are design decisions which made sense when the message was displayed along side the button, but we’ve had to change now that the message is above the button.
2021-01-08 15:23:54 +00:00
padding: 0 0 govuk-spacing(6) 0;
& .govuk-error-message {
Stop content length message from making page jumpy The content length message was making the page jumpy and causing reflows in three ways. This commit addresses each of those ways: As the user scrolled --- The footer went from fixed to sticky and the spacing around the message changed. This change in spacing was needed so that the message looked right in both contexts. I think the best way to resolve this is to not use the sticky footer when editing text message or broadcast templates. On my 1440×900 screen I can fit a 5 fragment text message, plus the ‘will be charged as 5 text messages’ message, plus the save button. Our top 10 screen resolutions according to our analytics are: Position | Resolution | Percentage of users ---------|------------|-------------------- 1 | 1920x1080 | 27.37% 2 | 1280×720 | 11.07% 3 | 1366×768 | 8.88% 4 | 1536×864 | 5.79% 5 | 1440×900 | 4.52% 6 | 1600×900 | 3.71% 7 | 1280×1024 | 3.10% 8 | 1680×1050 | 2.42% 9 | 1920×1200 | 2.33% 10 | 2560×1440 | 1.99% When the page first loaded --- The message is empty so takes up no space, then the javascript fires and inserts the message, taking up a line of space. This is resolved by making the empty message take up space with a non-breaking space character. When the user first typed --- We previously didn’t show any message until the user started typing. This meant that, with the above fix, there was a larger than normal empty space between the textarea and the save button. This is resolved by always showing the message, even when the user hasn’t typed anything yet. *** These are design decisions which made sense when the message was displayed along side the button, but we’ve had to change now that the message is above the button.
2021-01-08 15:23:54 +00:00
margin: 0;
}
}