Styles are missing when JavaScript is disabled #1145
Comments
|
before we start losing hair on this one, could you describe in which context you run the theme with disabled javascript?
|
|
In this specific case, I noticed because the Content Security Policy on the artifacts server prevented JavaScript to run. But in general, we don’t have control on the browser configuration of our users. Degrading gracefully when JavaScript is disabled would be nice. Having two logos in the header made the documentation feel broken (and I’m afraid unmaintained). |
|
ok so let's get rid of the annoying things in this degraded env before trying something in a PR:
|
The search button is there, but clicking on it does nothing. I guess both should only appear when JavaScript is enabled?
Both sidebar works. Toggling sections works just fine.
There is none in our case. |
|
ok so first step recover the search function and remove the items that you cannot use: in your conf.py add back the search TextField in the sidebar or the navbar: html_theme_options = {
"navbar_end": ["search-field","navbar-icon-links"], # add the search field in the navbar and remove theme switch
"navbar_persistent": [], # remove search button as it cannot be used anyway
} |
Support for light/dark themes has been implemented using a `data-theme` attribute set on the `<html/>` tag. As this attribute is set using JavaScript, this meant that it was left unset when visitors had JavaScript disabled. This resulted in several important CSS rules not being matched and a “broken feeling” due to wrong colors, and logo or images shown twice. To better support browsers with JavaScript disabled: 1. Add the same CSS rules as for the light theme when the `data-theme` attribute is not set. This creates a safe fallback in every situation. 2. If `default_mode` is set, write its value to the `data-theme` attribute when writing the HTML files. This enables theme users to present their preferred mode to visitors with JavaScript disabled. 3. Use JavaScript to add the search and theme switcher buttons as they require JavaScript to work. This avoid unusable UI elements to be shown to visitors with JavaScript disabled. 4. Use JavaScript to write the logo for the “other theme”, depending on the value of `default_mode`, defaulting to “light” if unset. While this last change might seem redundant considering the other ones, it does make the resulting pages better for search engines and text browsers. Closes: pydata#1145
|
I am afraid you misunderstood our needs, so I went ahead and implemented some improvements. The issue is not that we want JavaScript to be disabled for all users. It is that some of our visitors might have JavaScript disabled and we are worried the broken aspect of the documentation will turn them away. Ideally the documentation UX should be better when JavaScript is enabled, but perfectly usable without. #1146 should fix the most visible problems. |
Support for light/dark themes has been implemented using a `data-theme` attribute set on the `<html/>` tag. As this attribute is set using JavaScript, this meant that it was left unset when visitors had JavaScript disabled. This resulted in several important CSS rules not being matched and a “broken feeling” due to wrong colors, and logo or images shown twice. To better support browsers with JavaScript disabled: 1. Add the same CSS rules as for the light theme when the `data-theme` attribute is not set. This creates a safe fallback in every situation. 2. If `default_mode` is set, write its value to the `data-theme` attribute when writing the HTML files. This enables theme users to present their preferred mode to visitors with JavaScript disabled. 3. Use JavaScript to add the search and theme switcher buttons as they require JavaScript to work. This avoid unusable UI elements to be shown to visitors with JavaScript disabled. 4. Use JavaScript to write the logo for the “other theme”, depending on the value of `default_mode`, defaulting to “light” if unset. While this last change might seem redundant considering the other ones, it does make the resulting pages better for search engines and text browsers. Closes: pydata#1145
Support for light/dark themes has been implemented using a `data-theme` attribute set on the `<html/>` tag. As this attribute is set using JavaScript, this meant that it was left unset when visitors had JavaScript disabled. This resulted in several important CSS rules not being matched and a “broken feeling” due to wrong colors, and logo or images shown twice. To better support browsers with JavaScript disabled: 1. Add the same CSS rules as for the light theme when the `data-theme` attribute is not set. This creates a safe fallback in every situation. 2. If `default_mode` is set, write its value to the `data-theme` attribute when writing the HTML files. This enables theme users to present their preferred mode to visitors with JavaScript disabled. 3. Use JavaScript to add the search, theme switcher and version switcher interface as they require JavaScript to work. This avoid unusable UI elements to be shown to visitors with JavaScript disabled. 4. Use JavaScript to write the logo for the “other theme”, depending on the value of `default_mode`, defaulting to “light” if unset. 5. Use JavaScript to write the announcement block to the HTML if the announcement is a remote URL. While this last change might seem redundant considering the other ones, it does make the resulting pages better for search engines and text browsers. Closes: pydata#1145
Thanks to everyone who worked on this amazing theme.
When JavaScript is disabled,
data-themeis not set in the<html>tag, resulting in missing styles. #959 exhibited a similar problem but was ultimately solved by tweaking for CloudFlare specific behaviors.An easy way to test this is to use any local JavaScript blocker. uBlock Origin will do nicely. See example video:
Kooha-2023-02-01-12:15:45.webm
One fix would be to modify CSS to better behave when
data-themeis not set. Another would be to write thedata-themewhen writing the HTML files. Possibly this could be done only whendefault_modeis set inhtml_context.The text was updated successfully, but these errors were encountered: