Idea: auto-generate breadcrumbs based on directory tree #1410

Open
opened 2020-05-27 21:41:48 +00:00 by reinhard · 4 comments
Member

Currently, each page has to contain an explicit line to display the breadcrumb like this:

<p id="category"><a href="/work.html">Campaigns</a></p>

An exception are news (and newsletters and podcasts) where the breadcrumbs are automtically generated by some hardwired XSL magic.

My idea now is whether we couldn't replace both the literal line in each file as well as the XSL magic by some smarter XSL magic which determines the breadcrumbs with this algorithm:

  • If the filename is not index.html, the breadcrumb links to the index.html in the same directory. If there is no index.html in the same directory or if the filename is index.html, the breadcrumb links to the index.html in the parent directory.
  • The label for the link is distilled from the <h1> header of the page to where the breadcrumb links.
  • If the body class is "toplevel", no breadcrumb is generated.

Advantages:

  • The breadcrumb <p> does not have to be explicitly written in the file.
  • The hardwired XSL magic for all kinds of news items can be removed.
  • The breadcrumbs can't be forgotten (currently there are a number of pages where they are missing).
  • The breadcrumbs can change automatically. For example, for any news item in 2019, the breadcrumbs would now point to /news/index.html, but in 2021, when there is a separate news archive page for 2019, the breadcrumbs would automatically change.
  • The breadcrumbs will always be uniform, it will not happen that breadcrumbs pointing to the same overview page are, for example, translated differently.

Disadvantages:

  • The breadcrumbs must match the directory structure.
  • The algorithm to generate the breadcrumb might become somewhat complicated.
  • Some structural hickups (for example /news/newsletter.html instead of /news/nl/index.html, or /news/podcast.html instead of /news/podcast/index.html) must be fixed first.

Please let me know what you think.

Currently, each page has to contain an explicit line to display the breadcrumb like this: ```xml <p id="category"><a href="/work.html">Campaigns</a></p> ``` An exception are news (and newsletters and podcasts) where the breadcrumbs are automtically generated by some hardwired XSL magic. My idea now is whether we couldn't replace both the literal line in each file as well as the XSL magic by some smarter XSL magic which determines the breadcrumbs with this algorithm: * If the filename is not index.html, the breadcrumb links to the index.html in the same directory. If there is no index.html in the same directory or if the filename is index.html, the breadcrumb links to the index.html in the parent directory. * The label for the link is distilled from the `<h1>` header of the page to where the breadcrumb links. * If the body class is "toplevel", no breadcrumb is generated. Advantages: * The breadcrumb `<p>` does not have to be explicitly written in the file. * The hardwired XSL magic for all kinds of news items can be removed. * The breadcrumbs can't be forgotten (currently there are a number of pages where they are missing). * The breadcrumbs can change automatically. For example, for any news item in 2019, the breadcrumbs would now point to /news/index.html, but in 2021, when there is a separate news archive page for 2019, the breadcrumbs would automatically change. * The breadcrumbs will always be uniform, it will not happen that breadcrumbs pointing to the same overview page are, for example, translated differently. Disadvantages: * The breadcrumbs *must* match the directory structure. * The algorithm to generate the breadcrumb might become somewhat complicated. * Some structural hickups (for example /news/newsletter.html instead of /news/nl/index.html, or /news/podcast.html instead of /news/podcast/index.html) must be fixed first. Please let me know what you think.
reinhard added the
build
xsl
labels 2020-05-28 13:16:31 +00:00
Owner

Phew, nice idea, and I agree that this might become tricky. However, if you think you can manage it, I would celebrate :)

Also, it becomes obvious that we have to tackle what you call "structural hickups". Are you aware of more of them?

And just one side-note: a file that has the same name as its directory should have the same role as an index.en.xhtml (e.g. /activities/routers/routers.en.xhtml)

Phew, nice idea, and I agree that this might become tricky. However, if you think you can manage it, I would celebrate :) Also, it becomes obvious that we have to tackle what you call "structural hickups". Are you aware of more of them? And just one side-note: a file that has the same name as its directory should have the same role as an index.en.xhtml (e.g. `/activities/routers/routers.en.xhtml`)
Author
Member

Phew, nice idea, and I agree that this might become tricky. However, if you think you can manage it, I would celebrate :)

I think I'll guive it a try.

Also, it becomes obvious that we have to tackle what you call "structural hickups". Are you aware of more of them?

Probably there are quite some which will be solved with the activities/campaings cleanup (there is no activities/index.html yet), and I guess some of the directories now in git root should go below "about" (for example, "associates" and "timeline").

It's probably better to fix these first. Should we discuss these things here or should I open a separate issue for each "hickup"?

And just one side-note: a file that has the same name as its directory should have the same role as an index.en.xhtml (e.g. /activities/routers/routers.en.xhtml)

Yes. Absolutely.

> Phew, nice idea, and I agree that this might become tricky. However, if you think you can manage it, I would celebrate :) I think I'll guive it a try. > Also, it becomes obvious that we have to tackle what you call "structural hickups". Are you aware of more of them? Probably there are quite some which will be solved with the activities/campaings cleanup (there is no `activities/index.html` yet), and I guess some of the directories now in git root should go below "about" (for example, "associates" and "timeline"). It's probably better to fix these first. Should we discuss these things here or should I open a separate issue for each "hickup"? > And just one side-note: a file that has the same name as its directory should have the same role as an index.en.xhtml (e.g. `/activities/routers/routers.en.xhtml`) Yes. Absolutely.
reinhard added a new dependency 2020-05-28 18:33:26 +00:00
Owner

It's probably better to fix these first. Should we discuss these things here or should I open a separate issue for each “hickup”?

I would suggest to open one separate issue for all problematic cases taken together

> It's probably better to fix these first. Should we discuss these things here or should I open a separate issue for each “hickup”? I would suggest to open one separate issue for all problematic cases taken together
reinhard added a new dependency 2020-05-29 14:23:07 +00:00
Author
Member

Done: #1419

Done: #1419
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: FSFE/fsfe-website#1410
No description provided.