Because some people don’t know they can put their own logo on letters:
> The HM Government Logo is at the top of the letter and we can't see
> a way of putting the [organisation] logo on
> We are intending to use the letter template feature for the first time
> and wondered whether the branding is configurable or whether the HM
> Government header is the standard default.
> Can we replace HM Government logo with our own in the letter? IF yes,
> then how?
> I don't seem to be able to set the branding on the letters to be
> [organisation]. it's always HM government. Is there something that
> needs enabling for this account?
No-one actually wants the HM Government logo (no-one is sending real
letters using it). So we should leave the space blank and put a button
there prompting people to add their own logo.
The `release` method is meant to clean up a sticky
element before removal from the store.
The part of this that cleared CSS added due to
being in dialog mode was only run if still in that
mode.
In the template folder JS, we set the mode before
running `recalculate` so elements can be cleaned
in a different mode to that they were last in.
This meant some CSS wasn't being cleaned up.
This sometimes caused an effect where elements
that were added back to the DOM but not stuck
would still have CSS used when they were last
stuck.
This commit also includes the addition of some
missing code that adds back CSS to offset an
element when in a dialog stack.
Moving focus before letting the sticky JS set the
position of sticky elements means focus is shifted
to them when they are still in the page. This
causes the browser to scroll so the focused
elements are visible.
This moves when focus is set to after the sticky
JS has set position therefore avoiding the issue.
Makes sure the tabindex we add for focusing is
removed.
Also removes the outer fieldset from the radios
for new templates. We don't wrap form buttons in
fieldsets anywhere else and it doesn't add any
useful semantics to the form.
Adds some extra styles so <fieldset>'s show as
focused when they are.
Also includes replacement of `overflow: hidden` on
sticky elements with a clearfix. hiding overflow
clips the outline and the clearfix can be used for
containing any floats instead. (I'm assuming that's
why it was set here.)
Bigger hit areas are generally better (cf Fitt’s law[1]), as long as
they’re not ambiguous.
This commit enlarges the hit area of the edit links (using a border) so
they fill the same vertical space as the smallest possible row (going
to the full height might look weird because some of these rows get very
tall).
Bigger hit areas are generally better (cf Fitt’s law[1]), as long as
they’re not ambiguous.
This commit enlarges the hit area of the edit links (using a border) so
they fill the same vertical space as the row they sit in.
We were removing the border to ‘unfold’ the corner of the page. This was
causing the size of the element to shrink.
This meant that it you hovered the bottom 1px of the element it would
cycle in and out of the hover state as fast as the browser could render
it.
This commit fixes that by making the border transparent, rather than
removing it.
Sometimes people print stuff under where we’re folding the letter. It’s
annoying to not be able to see it.
This commit adds a little detail where, once you’ve sent the letter
you can unfolds the corner to see what’s underneath.
It’s better that we do this for all letters for discoverability.
To avoid the problem of having confusing defaults, the postage is now
set explicitly on every template.
Putting the postage ‘inside’ the letter template makes the interaction
for changing it consistent with how other parts of the template are
added.
Plus everyone loves skeumorphism.
The contact block fills from the bottom upwards. So if it only has a few
lines then the ‘Edit’ link button sits quite far away from where the
text appears in the letter. This commit moves the link button to bottom
align with the contact block, so it’s always in close visual proximity.
Duplicates e0ecc95ac6
Copies the code from the normal folder icon, and manually tweaks the
colour, to also get the benefits of minification.
***
IE 10 supports using SVG[1] but has some buggy behaviour when they’re
used as background images.
Without an explicit width/height it stretches the viewBox of the SVG to
fill the containing element. This causes the content of the file to
display centered within the viewBox.
Explicitly setting the width and height seems to be the thing that fixes
this. Out of the suggested fixes on Stackoverflow[2] this one seems to
be the most straightforward.
1. https://caniuse.com/#feat=svg
2. https://stackoverflow.com/questions/17944354/svg-background-image-position-is-always-centered-in-internet-explorer-despite-b
This was failing with a 'Object doesn't have
method' error on IE11. Assume Babel wasn't
polyfilling Array.includes so reverting to jQuery
version for now.
This commit applies a carefully selected blend of `white-space`,
`display` and `background-position` to ensure that:
- you can always see the full name of the current folder in the heading
(which is useful because people might have mutiple folders with the
same name, differentiated by some king of suffix)
- the clickable are of a single folder or template in the list is 100%
width, for the biggest possible hit area
- the name of a folder or template wraps underneath the folder icon (ie
the folder icon is treated like a normal character, not like a bullet
point)
It’s a bit rudimentary to only show the current place in the hierarchy
and the parent. You lose a sense of how deep you are.
But we can’t just show the full path, because it can be arbitrarily
long. So what this commit does is show the full path, but truncates the
display of any items. Further-up than the current folder or its parent.
This also helps disambiguate between folders and templates, because
folders are always shown with the folder icon.
This probably won’t affect many teams, because we don’t anticipate a lot
of deep nesting.
The work done to stack sticky elements closer
together only effected the stack when stuck to the
top/bottom edge:
707c426b9a
It should have included the same for when a stack
of sticky elements is stopped at the end of it's
scroll area. This adds code to deal with that.
The templateFolderForm JS was setting the mode to
'dialog' but not back when the state was changed
back to a normal sticky element. This caused
adjustments and scrolling when no adjustment
needed to be accommodated.
There were also problems with adjustForResize. It
was manipulating the same flag that resizing the
window did and returned a value never used.
The `recalculate` method currently does three
things:
1. sync's the internal store with the DOM
2. updates the saved positional and dimensional
data from the new DOM
3. allows the mode to be set
The problem with using it as the way to set the
mode is that, every call to it is effectively
setting the mode but this isn't always the
intention.
This splits off setting the mode so other modules
have to explicity set it and those that don't
intend to can just call `recalculate` to notify of
DOM changes.
If a sticky element was already in the store, the
code for adding it would return early. This meant
dimensions and positions for it were not being
recalculated.
make sure the class is applied to a child element, so that `$el.find`
will always find something for `js-will-stick-at-bottom-when-scrolling`.
Also, clean up code by treating all stickies on the template folder
form as dialogs - they all are after all all dialogs - modals that
expect your attention on top of the main page content.
When the screen resizes, the dimensions of our
elements may change so we run
`setElementDimensions` again to update our store
of those values.
This caused a bug with the stored position of
stuck elements. When stuck, elements are
'fixed' so their position is relative to the
window position. We need the value stored to be
from the position in the document flow, not the
'fixed' value.
This change means, when an element is stuck, we
check its shim for the position instead. The shim
occupies the space the element would do in the
page so it makes sense to use it for this.
The controls for the template folders are all
present in the page when it loads. The
templateFolderForm JS filters them so you only see
the one you need to for the thing you're trying to
do.
This changes when the controls are made sticky so
it happens after the templateFolderForm JS has
performed its filtering.
This ensures sticky elements don't fade in if
in a sticky position when the page loads.
The fade is there to show when an element is
becoming sticky. This has no use if it was already
sticky the first time you see it.
Because the same situation applies when
recalculate is called, we also want the flag to be
reset before this happens.
When mode === 'dialog', sticky elements are
stacked so we need to apply the box shadow to the
top (when sticking to the bottom edge) and bottom
(when sticking to the top edge) elements in the
stack.
From what I can see, we need the version of
`nth-child` that supports targeting by selector.
As of this date, support for this is only in
Safari:
https://caniuse.com/#feat=css-nth-child-of
Until we can use this version of `nth-child`, we
need to use JS to apply the styles.
Instead of keeping references to nodes detached
from the DOM, remove them from the store.
Likewise, add node appended to the DOM.
This includes code to 'clean' DOM nodes when
removed. This is important because nodes can
retain classes and styles. If they are re-attached
in future this can cause problems with how the
state of the element is determined.
We want a mode for when a single task is shared
between all sticky elements on the page and that
task has the highest priority on the page. In that
case:
- they should stack together into a single block,
attached to the top/bottom of the viewport
- that block should adjust to the vertical space
available
This should also adjust to the height of the
viewport, dropping whatever elements that don't
fit back into the page flow. When this happens, we
scroll the page so all the parts of the dialog are
seen together at the start of the task.
If the screen resizes, sticky elements can end up
moving from one part of the screen to another,
sometimes without passing through their different
states (in-page, stuck, stopped) in the normal
order.
This makes the methods that change their states
better at dealing with those state changes.
