Skip to content

Conversation

@adamzap
Copy link
Member

@adamzap adamzap commented Dec 19, 2025

This PR fixes #1988 and is a second attempt at #1799. This comment by @thibaudcolas was especially helpful in arriving at this implementation.


Some of the functionality of the floating warning on unsupported and in-development documentation versions was implemented using JavaScript. This is longer necessary if we use the following approach with modern CSS:

Attach the warning element the top of the page with position: sticky. This almost solves the problem, but we still have to scroll past header elements when an internal page link is clicked. This is achieved with a combination of the :has pseudo-class and the scroll-margin-top property.

We apply scroll-margin-top to elements that can be scrolled to by their id attribute. This is done with responsive breakpoints to get appropriate spacing when the floating warning has one, two, or three lines of text. Thanks to :has, this only happens when a warning element is on the page.

The modern CSS features used are widely-supported:

Other than making the primary CSS changes and removing the related JavaScript, this patch does the following:

  • Simplify the CSS so that the class on all floating warning elements implements the common rules and the CSS for the IDs on the elements implements the colors
  • Add a z-index to warning elements so that they always display in front of the header element
  • Move the floating warning element to the top of the page in the HTML
    • Remove the body_extra block that was only being used by the floating warning element
    • Add a new before_header block for the floating warning element

Thank you to @bmispelon and @thibaudcolas for helping me arrive at this solution.


image

To test this PR:

  1. Check that the floating warning element behaves as expected on the documentation part of the site. You can see it by navigating to the development version of the documentation or an unsupported version like 3.2.
  2. Check that both clicking on and navigating to internal page links keeps the desired header in view.
  3. Check that the responsive breakpoints I chose work well for window sizes where the warning text is one, two, or three lines.

Some of the functionality of the floating warning on unsupported and
in-development documentation versions was implemented using JavaScript.
This is longer necessary if we use the following approach with modern
CSS:

Attach the warning element the top of the page with `position: sticky`.
This almost solves the problem, but we still have to scroll past header
elements when an internal page link is clicked. This is achieved with a
combination of the `:has` pseudo-class and the `scroll-margin-top`
property.

We apply `scroll-margin-top` to elements that can be scrolled to by
their `id` attribute. This is done with responsive breakpoints to get
appropriate spacing when the floating warning has one, two, or three
lines of text. Thanks to `:has`, this only happens when a warning
element is on the page.

The modern CSS features used are widely-supported:

- https://caniuse.com/css-has
- https://caniuse.com/css-sticky
- https://caniuse.com/mdn-css_properties_scroll-margin-top

Other than making the primary CSS changes and removing the related
JavaScript, this patch does the following:

- Simplify the CSS so that the class on all floating warning elements
  implements the common rules and the CSS for the IDs on the elements
  implements the colors
- Add a `z-index` to warning elements so that they always display in
  front of the header element
- Move the floating warning element to the top of the page in the HTML
  - Remove the `body_extra` block that was only being used by the
    floating warning element
  - Add a new `before_header` block for the floating warning element

Thank you to Baptiste Mispelon and Thibaud Colas for helping me arrive
at this solution.
#outdated-warning {
position: absolute;
@include respond-max(674px) {
body:has(.doc-floating-warning) [id] {
Copy link
Member Author

@adamzap adamzap Dec 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[id] feels too generic here, but I can't think of a downside. I think we'd want any element that can be scrolled to to be affected.

Copy link
Member

@pauloxnet pauloxnet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sarahboyce
Copy link
Contributor

Thank you for this! Always love removing JavaScript ❤️

Links with a header anchor on mobile loose the headers for me

Screenshot from 2025-12-19 21-10-09

Currently on mobile for docs.djangoproject.com, the warning is not sticky. Do you think this should do the same to simplify the scroll-margin-top calculation?

This change restores the previous behavior.
@adamzap
Copy link
Member Author

adamzap commented Dec 21, 2025

@sarahboyce Thank you! I overlooked the behavior change at mobile width. It should be addressed in 33ba68d.

Copy link
Contributor

@sarahboyce sarahboyce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! This looks great ⭐

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use CSS instead of JS for floating docs banner

3 participants