New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why deprecate the html_codeblock_linenos_style
option?
#10265
Comments
The reason for the deprecation is (as mentioned in #7879) accessibility: #7849.
It's not. This is not the reason.
The reason for not providing a choice is to help blind people. |
I'm having trouble imagining any literal code blocks being comprehend-able via screen readers because of syntactical convention (snake casing vs camel casing vs improper casing). Nonetheless, having the line numbers be statically positioned (& separate from the rest of literal code blocks) is obviously a visual preference. I still think deprecating the option all together is too utilitarian. I'm ok with the default ( ps - I'm not as familiar with accessibility standards as I should be for web development. Upon first glance, I don't see an easy workaround using |
I removed this in #10471 along with the other deprecated items. Our options seem to be
(2) would obviously be my preference. What would be required, and is it even possible? A |
Our theme is rather rigid. We can't make a lot of changes to CSS or JS because that would cause annoying merge conflict with mkdocs-material theme (our sphinx-immaterial theme's upstream). Our theme needs the line numbers in a separate column of a 1-row table. It may not be pleasing to accessibility standards, but that doesn't seem to be a high priority for our upstream mkdocs sources. If option 1 is completely off the table, then we'll have to patch it back in ourselves. The current default behavior does not behave well with sphinx-immaterial theme, so we've hard-coded the config's old table behavior. The mkdocs upstream theme relies on |
Just mentioning that clipboard.js will copy the line numbers of a code block that are inlined with the code. Seems like this deprecation will gain accessibility, but lose convenience (visually and functionally). |
@AA-Turner As far as option 2, I think we can get away with wrapping the inline line numbers with special attributes. The following is one way in which <code>
<span class="linenos" data-linenos="1 ">
::before
</span>import foo.bar
</code> I think there's some fancy JS taking the I've opened an issue with our upstream mkdocs src to support inline behavior: squidfunk/mkdocs-material#4061 |
Is clipboard.js a hard requirement? Can something be done to teach it about the inline approach? A |
As far as I can tell, the In fact, the popular sphinx-copybutton extension from executablebooks uses clipboard.js, and the inline behavior is still being addressed: executablebooks/sphinx-copybutton#138. |
This is a blocker issue for 6.0. A |
Agreed. The only solution I can think of is to monkeypatch literal blocks in sphinx v6+. |
For 6.0.0, we will revert the removal and delay the deprecation, unless things have moved on in the JS side. A |
Is your feature request related to a problem? Please describe.
We've been porting the mkdocs-material theme to sphinx-immaterial, and found the the mkdocs-material theme uses tables to represent literal code blocks with line numbers. With Sphinx's default setting
We found a few problems:
Describe the solution you'd like
Please don't deprecate the
html_codeblock_linenos_style
config option in Sphinx v6.0.Describe alternatives you've considered
For now, we're thinking of having the sphinx-immaterial theme assert the option to use
When/If Sphinx v6.0 removes the option, we're going to have to overwrite the
visit_literal_block()
to restore this functionality.Additional context
I've read #7879 (comment), but I don't see any good rationality to deem the option deprecated. The sphinx builtin themes aren't the only themes that supply their own CSS (we don't inherit any CSS from sphinx builtin themes). If writing CSS for code blocks with line numbers (using
"table"
) is too complex, then leave it to the theme designers to choose how to set the option - don't deprive them of the option all together.We're not as flexible as we'd like to be concerning CSS changes. This is because we need to minimize the possible merge conflicts when merging in updates from the mkdocs-material theme. Same reason goes for using clipboard.js instead of executablebooks/sphinx-copy-button extension (though this isn't as strict a requirement as keeping the CSS unaltered).
Original issue for the sphinx-immaterial theme is jbms/sphinx-immaterial#26
The text was updated successfully, but these errors were encountered: