Skip to content

[discussion] Consider modularity of different page components #330

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

Closed
3 tasks
bollwyvl opened this issue Mar 7, 2021 · 0 comments · Fixed by #1215
Closed
3 tasks

[discussion] Consider modularity of different page components #330

bollwyvl opened this issue Mar 7, 2021 · 0 comments · Fixed by #1215

Comments

@bollwyvl
Copy link
Collaborator

bollwyvl commented Mar 7, 2021

... Do you think that the _templates folder is a better place for these links? https://github.com/pydata/pydata-sphinx-theme/tree/master/pydata_sphinx_theme/_templates

I think of _templates as being more like "components", little snippets of HTML that could be put in other parts of the page as well for themes that are sub-theming this one. The .html in folder above _templates I think of more as defining the major structure of the theme (sidebars, top bar, etc). What do folks think?

from #293 (comment), regarding

Goal

Make the overall template/file architecture more modular, minimizing downstream breakage of sites using existing template identifiers.

Motivation

A number of components, such as the "icon links" section proposed in #293, are potentially block-level constructs, which could be re-combined more flexibly in the _templates folder. These could be overridden at a more modular level, but currently have id-level constructs in the DOM/CSS.

Design ideas

The following components are candidates for being moved into _templates.

  • icon-links.html
  • search-related things
  • ...

Criteria

For a successful migration, the default theme should maintain an existing id that meets existing styling need, but allow for a new class-ful variant.

Accessibility

As a component is migrated, it would be worth strongly-considering whether the tags chosen (an abundance of div, span and i) could be replaced with more readily screen-reader interpretable DOM (e.g. article, section). The existing tag names be maintained, and tested, with a transition plan to replace them.

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 a pull request may close this issue.

1 participant