Closed bashtage closed 1 year ago
These aren't really admonitions. Rather, they are just directives that generate simple div elements:
<div class="versionadded">
<p><span class="versionmodified added">New in version 1.0: </span>This was added in 1.0</p>
</div>
<div class="versionchanged">
<p><span class="versionmodified changed">Changed in version 2.0: </span>This was changed in 2.0</p>
</div>
<div class="deprecated">
<p><span class="versionmodified deprecated">Deprecated since version 3.0: </span>This is deprecated since 3.0</p>
</div>
This is actually not unlike what the RTD theme does for these directives.
The reason these stand apart from admonitions is because the first argument (delimited by a whitespace) is concatenated with the "title". So, while you can use the theme's custom admonition feature to override the sphinx directives, the argument will appear as a custom title (not concatenated with the default title and only delimited by a blank line).
~I would only consider adding theme-equivalent overridden directives if you can show that they are used like admonitions in the mkdocs-material theme without any user-defined customization (mkdocs plugins included as "customization").~
Yes it appears that other themes just italicize the title. Is that what you would like to happen @bashtage ?
Something more along the lines of the bottom one in the link below is what I was hoping for. I can fix these using custom CSS of course. These directives are fairly common in project documentation, and so it would be great if they could be auto styled to be similar to propper admonitions.
https://pydata-sphinx-theme.readthedocs.io/en/stable/examples/kitchen-sink/admonitions.html
I would consider that theme's specfic style controversial because they aren't actual admonitions.
Consider
.. versionadded:: 1.0 Some content
- a list element
.. note::
Some content.
which renders like so:
I'm more inclined to add the CSS that seems inherited by other themes (from sphinx' basic theme CSS) to italicize the title. As you noted, the custom CSS to treat the generated div
s as an admonition can be added by docs author(s).
Reminder, we explicitly don't inherit CSS from Sphinx' basic theme for various reasons.
There's also nothing stopping users from using our custom admonitions feature:
sphinx_immaterial_custom_admonitions = [
{
"name": "versionadded",
"color": (72, 138, 87),
"classes": ["info"],
"override": True,
},
]
This abstracts the custom CSS needed, but you'd have to repeat the default title to get it to show:
.. versionadded:: New in version 1.0
- a list element.
renders as
Remember that admonitions require content. So you'd have to separate the description of the version changes in a separate paragraph nested in the directive content. There's currently no way to create an admonition that only shows a title section as the pydata theme does for these directives.
To me it does seem that the pydata styling fits well with this theme, better than just italicizing, and is probably similar to what mkdocs-material would do if mkdocs had similar directives.
It seems that we could style it as an admonition even without it actually being an admonition, but I suppose it would be better if it can be done in a more generic way, similar to our other custom admonition support.
As for admonitions needing a body (may be independent of this issue) that seems like an unnecessary restriction given that we allow custom admonition titles. Not clear how easily we can relax that restriction though.
As for pydata theme reference: the styling of these directives was requested in this issue
As for admonitions needing a body (may be independent of this issue) that seems like an unnecessary restriction given that we allow custom admonition titles. Not clear how easily we can relax that restriction though.
I had a thought that might help with this. We could add a custom admonition option to not require content when the directives are created. I only had has_content = True
because that's how every other admonition in Sphinx/docutils is configured.
sphinx_immaterial_custom_admonitions = [
{
"name": "versionadded",
"color": (72, 138, 87),
"classes": ["info"],
"override": True,
"has_content": False,
},
]
From there we can auto-override the version directives to behave like admonitions with only a title section. Users would still be able to override the auto-overridden directives if they so choose. I'd probably also add a conf.py option to disable auto-overriding the version directives as well (just like we did for all other overridden admonitions).
The concatenation of version spec with default title is still an obstacle though. I'm not sure how we'd do that without the code getting hairy (may need a few new if conditions to check for these specific directives).
The :no-title:
option would have to be ignored if has_content == False
.
I toyed around with this...
Which will now produce Notice, I haven't added the CSS to italicize the prefixed title + version spec.
One caveat that might be a deal-breaker (as for using the custom admonitions feature) is the generated directive class has no way of knowing what the corresponding directive name is. So, concatenating the first argument with the default title isn't exclusive to the version directives (see WIP patch above).
There might be other unintended behavior that could be triggered but I haven't fully vetted the patch yet.
Those look great.
I think I can work around the unintuitive directive class by using a special CSS class for the version directives...
I'll keep toiling and submit a PR for review.
Thanks for your work on this!
The way the combined title is generated seems rather hacky --- it might be cleaner to specify either a jinja2 template or str.format
template in the custom admonition config.
Also your current patch does not seem to actually check the config's has_content
option --- which should probably be renamed to require_content
and can probably default to False
.
I thought the pydantic class would type check the added user option. I'll look into that.
probably be renamed to require_content and can probably default to False.
I'm open to renaming the option as I just found out that setting the directive class' has_content=False
will prevent any content from being added. I'm still playing around with this problem... I also explored the required_arguments
class attr for directive classes, but it doesn't seem to fit well within the generalized custom admonitions.
The way the combined title is generated seems rather hacky --- it might be cleaner to specify either a jinja2 template or str.format template in the custom admonition config.
I'll probably go with str.format
since adding a jinja template seem like overkill for this.
The way the combined title is generated seems rather hacky --- it might be cleaner to specify either a jinja2 template or str.format template in the custom admonition config.
I'll probably go with
str.format
since adding a jinja template seem like overkill for this.
Either way seems fine --- to be clear I was not proposing a jinja template in a separate file, rather just a jinja template specified as a string literal, e.g.: "Deprecated since version {{ arg }}"
Clearly its been a while since I did anything with docutils. I'll look into the jinja template as well.
I'm resorting to the same approach used to generate the titles in Sphinx. Labels (aka titles) are translateable. And italics rely solely on CSS applied to the rendered docutils node (not inline italic rST syntax).
Please note that the admonition approach will break the Sphinx builder named ChangesBuilder
as we will not be using the original directive class VersionChange
. I'm ok with this because the builder seems kinda useless (last time I tried it), and users can always set the new conf.py option sphinx_immaterial_override_version_directives=False
to revert back to original Sphinx implementation.
I just made a fresh attempt to style these directives using original code in sphinx but with the visit_versionmodified()
monkey-patched and custom admonition templates (no directives overridden). This resulted in:
This was surprisingly easier than overriding the directives themselves! Now I'm going to do my thing to see if I can extend the icon & color customization to user-defined conf.py options. Stay tuned for a new PR proposal.
Note, that the directives take 1 required argument and 1 optional argument. Meaning that any body content for the pseudo admonitions has to be given after the optional argument (see versionadded example in screenshot).
@bashtage Looks like these directives use a node that inherits from admonitions but isn't implemented like admonitions (more like a todo
admonition without the admonition style). So, this adds to the confusion. 😞
Solution available in the nightly at https://test.pypi.org/project/sphinx-immaterial/0.11.3.post1.dev17/
Its been slow, but we're getting close to a new release (just a few more simple issues to squash).
They work really well. The main style looks good and is consistent with the rest of the theme.
In the end I applied a tiny bit of personal preference to them:
font-weight:normal
In a glimpse of foresight, I anticipated that users might want to make the admonitions :collapsible:
or use custom CSS :class:
and/or :name:
(element id
). Styling from other builtin admonition styles can also be inherited with sphinx_immaterial_custom_admonitions
's classes
option.
solution updated in nightly https://test.pypi.org/project/sphinx-immaterial/0.11.3.post1.dev21
Sphinx admonitions such as
have no style applied.
If you search for deprecated in the specimen page you will see unstyled markup of