A large portion of the diff for landing-page.js is due to refactoring the
contents of integrations_search into top level UI update functions.
State flows as follows: dispatch(action) -> render(state) -> update UI
Routes now use pushState instead of hashes.
On transition between categories scrolling position is fixed,
and on transition between catalog and integration sub-pages the page
scrolls to the top.
On some monitors it appears as though there's a slight gap between
the bottom of the wave and the top of the section below. This moves
the wave down a pixel to ensure the gap disappears.
Fixes: #6064.
This is a redesign of the features landing page from the current style
that includes the new sections in a grid format as well as some new
high-quality sections.
Can be added to the landing pages via:
+ {% include 'zerver/compare.html' %}
+
I'm avoiding adding that include into the landing pages until we have
time to do a bit of tweaking of the styling to integrate better into
/hello/ (primarily color-wise).
Most of the work for this was done by Brock, huge thanks to him!
There appears to be an issue in which on production the
./landing-page/assets folder is excluded from the build process,
so move it to the parent folder to fix the assets to appear in
production.
While it's sometimes nice to put a few selectors on the same line,
it is generally better to have a consistent way of formatting our
selectors, and most of our code up until now lists them vertically.
This change fixes the linter to enforce one selector per line, and
it cleans up the places in the CSS where we had multiple selectors
on the same line.
The advantages of one-per-line are as followers:
* cleaner diffs
* easier to see when multiple areas of the app may have the
same format
* less likely to go over 80 cols
* makes it more clear where we have deep nesting in the
individual selectors
* makes it easier for our linting tools to enforce
whitespace violations
This also fixed an old bug where we had ".landing_page h2, h4", which
sets "h4" styles outside of the landing page.
The issue is that stacking the two transitions appears to make the
::after pseudo-element slower for some reason than its parent. This
visually appears to fix it.