This commit adds the redesigned banner component to the codebase along
with a storybook-style page in /devtools/banners to view and test the
redesigned banner component.
Any banner using the new redesigned styles, requires two classes,
- First, the base `banner` class which defines the structure and
behavior of the banner.
- Second, a modifier class like `banner-info` which defines the styles
for the particular banner type.
The navbar alert banners also have a custom class `navbar-alert-banner`
which is used to define the specific style and structure for these
banner types.
This commit also makes the `banner`, `action-button` and `icon-button`
components into handlebar templates to maintain consistency in their
usage in the codebase.
This commit adds the redesigned button styles to the codebase along with
with a storybook-style page in `/devtools/buttons` to view and test the
redesigned button component.
The redesigned button component, uses the `action-button` class to
follow Zulip's no-abbreviation policy, and to avoid conflicts with the
pre-existing `button` and bootstrap `btn` classes.
A button using the new redesigned styles, required two classes,
- First, the base `action-button` class which defines the structure
and behavior of the button.
- Second, a modifier class like `action-button-primary-neutral` which
defines the styles for the particular action button type.
We also add the `run-dev` commands to `/devtools` page. The GitHub
issue link is duplicated between both, but it's a useful duplication
and the link is unlikely to change.
Previously, we had an architecture where CSS inlining for emails was
done at provision time in inline_email_css.py. This was necessary
because the library we were using for this, Premailer, was extremely
slow, and doing the inlining for every outgoing email would have been
prohibitively expensive.
Now that we've migrated to a more modern library that inlines the
small amount of CSS we have into emails nearly instantly, we are able
to remove the complex architecture built to work around Premailer
being slow and just do the CSS inlining as the final step in sending
each individual email.
This has several significant benefits:
* Removes a fiddly provisioning step that made the edit/refresh cycle
for modifying email templates confusing; there's no longer a CSS
inlining step that, if you forget to do it, results in your testing a
stale variant of the email templates.
* Fixes internationalization problems related to translators working
with pre-CSS-inlined emails, and then Django trying to apply the
translators to the post-CSS-inlined version.
* Makes the send_custom_email pipeline simpler and easier to improve.
Signed-off-by: Daniil Fadeev <fadeevd@zulip.com>
Adds links to the documentation about management commands in the
API documentation for creating users, as well as the `/devtools`
documentation, the GDPR compliance article and the incoming
webhooks tutorial.
Adds HTML title elements to templates that extend either `base.html`,
`portico.html` or `portico_signup.html`, and that are not website
portico landing pages that will use the `PAGE_TITLE` variable to set
the HTML title element (see following commit in series).
Also, updates some templates for missing translation tags.
As a general rule, we want the title element (and page content)
translated. Exceptions that are updated in this commit are templates
used in the development environment, analytics templates that are used
by staff and templates related to Zephyr.
I rewrote most of tools/lib/pretty-printer.py, which
was fairly easy due to being able to crib some
important details from the previous implementation.
The main motivation for the rewrite was that we weren't
handling else/elif blocks correctly, and it was difficult
to modify the previous code. The else/elif shortcomings
were somewhat historical in nature--the original parser
didn't recognize them (since they weren't in any Zulip
templates at the time), and then the pretty printer was
mostly able to hack around that due to the "nudge"
strategy. Eventually the nudge strategy became too
brittle.
The "nudge" strategy was that we would mostly trust
the existing templates, and we would just nudge over
some lines in cases of obviously faulty indentation.
Now we are bit more opinionated and rigorous, and
we basically set the indentation explicitly for any
line that is not in a code/script block. This leads
to this diff touching several templates for mostly
minor fix-ups.
We aren't completely opinionated, as we respect the
author's line wrapping decisions in many cases, and
we also allow authors not to indent blocks within
the template language's block constructs.
This reverses the policy that was set, but incompletely enforced, by
commit 951514dd7d. The self-closing tag
syntax is clearer, more consistent, simpler to parse, compatible with
XML, preferred by Prettier, and (most importantly now) required by
FormatJS.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
