This commit adds the required bootstrap CSS rules for fieldset
elements to the specific selector in portico_signin.css and
removes the CSS from bootstrap.css.
Added a copy-to-clipboard button to the code blocks in the API and
Help Center docs. Previously, copying code from the docs required
manual copying, which was cumbersome.
Used the same copy-to-clipboard svg icon as the one used in
web/src but manually created the button within the js function instead
of using a template. Updated the pre CSS element to have relative
positioning and gave the copy-codeblock element absolute positioning
to ensure the button stayed in the top-right corner.
Fixes#25726.
This commit adds bootstrap CSS rules for number type inputs
in billing and upgrade page to billing.css as we will be
removing them from bootstrap.css in further commits.
This commit adds bootstrap CSS rules for number type inputs
in activity page to activity.css as we will be removing them
from bootstrap.css in further commits.
We use "submit" type inputs in dev login page. Only "cursor"
CSS was applied to those elements from bootstrap and this
commit adds it to those elements in portico_signin.css and
removes the CSS in bootstrap.css and bootstrap-btn.css.
We use "input-xxlarge" class for search box in activity
support page only. This commit adds the width property
in activity.css for the search box and rest of the CSS
applied using this class was redundant and can be removed
safely.
These changes ensure that only headings targeted by URL fragments are
highlighted in full. Div elements will have their immediate first
child element highlighted instead (e.g., the first element of an API
parameter box).
Zulip's select widgets have a 30px height; this comes from Bootstrap
but is also generally nice for visual consistency.
In modals, we use a 15px font-size, instead of the 14px used in the
rest of the app, and in that context, the 4px vertical padding plus
30px fixed height resulted in the text not being vertically aligned.
Fix this by removing that vertical padding; all of our select elements
with these classes appear to position the text in the center of the
dropdown through other CSS mechanisms.
We now allow users to change email address visibility setting
on the "Terms of service" page during first login. This page is
not shown for users creating account using normal registration
process, but is useful for imported users and users created
through API, LDAP, SCIM and management commands.
This commit assigns a `.scroll-target` class to preserve any URL
fragment whose corresponding ID is on the self-same page as the
activating link.
This accommodates a side-effect of the fetch-based page-loading
logic, which seems to lose the `:target` reference once a load
or reload is complete.
One caveat: While the approach here works fine when loading a new
docs page whose URL includes a fragment, there appears to be something
about `simplebar` that clears out the `:target` reference. If you
click a heading link on a help page, for example, you might
momentarily see the highlighted style appear before it disappears.
This PR ensure that all elements targeted by URL fragments will
remain visible below the portico's menu bar at all viewport
sizes and also when a user zooms in, provided the target is on a
page with the menu bar, which will have the `portico-landing`
class.
Whether a quirk or a bug, Chrome appears to ignore the padding on
ancestral containing elements when calculating the offset for
`scroll-margin-top`, which is why padding has been moved to
`.inner-content` for `.why-page` and `.case-studies-page`, which
are the two unique class names for portico pages where the targeted-
element scrolling behavior is used.
This commit ensures that the Attribution, Jobs, and Team pages all
share a uniform structure to match those of other pages. This will
simplify styling and should ensure greater confidence when modifying
portico landing-page styles.
The one CSS modification here, for the jobs page, maintains the space
at the top of the "How we work" section.
The flex-direction property for modal__content should
be set to column as we want to display the elements.
This does not affect most of the modals since they
do not have multiple direct child elements that are
visible at same time and the data-simplebar attribute
already sets the "flex-direction: column" property to
the elements where it is used.
But in the email address visibility modal on user
registration page, there are multiple direct child
elements for the "modal__content" element and we need
to set "flex-direction: column" property for them to
work correctly. We also change the width of select
element in the modal to "fit-content" to avoid it
taking the whole width even when not required.
This commit also fixes the bug in login_to_access
modal, since the `modal__content` for it also
has two direct child elements.
This commit adds width property CSS rule for text inputs in
integrations_dev_panel.css to 206px, as we are going to remove
the bootstrap CSS rule which sets width in further commits.
This commit adds width property CSS rule for text inputs
in billing.css to 206px, as we are going to remove the
bootstrap CSS rule which sets width to 206px in further
commits.
This commit adds width property CSS rule for text
inputs in activity.css to 206px, as we are going to
remove the bootstrap CSS rule which sets width to
206px in further commits.
In previous commits, we updated the realm creation flow to show
the realm name, type and subdomain fields in the first form
when asking for the email of the user. This commit updates the
user registration form to show the already filled realm details
as non-editable text and there is also a button to edit the
realm details before registration.
We also update the sub-heading for user registration form as
mentioned in the issue.
Fixes part of #24307.
We now show inputs for realm details like name, type and URL
in the create_realm.html template opened for "/new" url and
these information will be stored in PreregistrationRealm
objects in further commits.
We add a new class RealmDetailsForm in forms.py for this
such that it is used as a base class for RealmCreationForm
and we define RealmDetailsForm such that we can use it as
a subclass for RegistrationForm as well to avoid duplication.
postcss-preset-env transpiles this back as necessary. (It does a
better job than we did, in fact: we had several four-argument hsl()
calls that should have been hsla().)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Updates `markdown.css` to remove border styling from code
elements, and instead use background-color (as well as
font-family) to visually highlight inline code elements
as distinct from regular text.
Updates code element font-family to be the same as in
`zulip.css`.
Makes padding on the left and right the symmetrical for
inline code elements. Previously there was 4px padding on
the right, but not on the left.
Maintains anchor font-color styling for code elements that
are also links.
Updates `markdown.css` and `rendered_markdown.css` for the rules
in `bootstrap.css` that were being used to style code elements and
removes the now redundant/ignored rules from `bootstrap.css`.
This commit adds bootstrap CSS rules for checkbox element in
emails_log.html as we would remove the bootstrap CSS for checkbox
inputs in furhter commits. We add only required CSS rules.
I am not sure why I added this change in flex-direction
but right now, it doesn't seem to be correct since it force
the footer to overflow mobile width.
Some code blocks in the help center have lines that are too long
to fit, and wrap onto the next line. This can look awkward, and
may cause confusion. An horizontal scroll bar is added to the code
blocks to help fit everything into their own lines and clear up
confusions.
Fixes#24004.
We now allow user to change email_address_visibility during user
signup and it overrides the realm-level default and also overrides
the setting if user import settings from existing account.
We do not show UI to set email_address_visibility during realm
creation.
Fixes#24310.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>