build site with Eleventy

[alifeee]

closes #160

As described in #160, the repository structure is now multiple "year folders", each containing many html fragment files. These can be any name and format, and the content is placed within the <li> items in the main <ol> list on the page. For example, a file 2024/alifeee.html, with content

<a href="https://alifeee.co.uk">alifeee</a>

is rendered into the 2024 HTML file as

  <ol>
    <!-- ... -->
    <li><a href="https://alifeee.co.uk">alifeee</a></li>
    <!-- ... -->
  <ol>

This is done with the Handlebars templating language, but Eleventy allows any templating language.

All historical files are converted to the new format, and the new format allows a pre-filled link to be provided, i.e.,

https://github.com/css-naked-day/css-naked-day.github.io/new/master/2023?filename=yourname.html&value=%3Ca%20href=%22https://yoursite.com/%22%3EYour%20site%20name%3C/a%3E

I have also added a GitHub Actions workflow to publish the site to GitHub pages. To allow this to work, the publishing source for GitHub pages will have to be changed in the settings from "branch" to "action".

Please see a preview of the site on https://cssnaked.alifeee.co.uk/, and I encourage you to download and tinker with the branch on my repository yourself.

The resulting site is almost identical to the existing. The differences are:

• the names are sorted alphabetically (by the sorting of the file-system)
• there is a Yours? link at the bottom of each <ol>. This uses the pre-filling style of link mentioned above.

Thanks. Hope all is well.

[arkhi]

@alifeee: Thanks for this, it’s a lot of work!

I would be more in favour of one file with structured data, processing it and ordering the content of each file from it automatically. Say, one per owner. Maybe something like this with your 2024’s data:

author = "alifeee"

[[2024]]
name = "website"
url = "https://alifeee.co.uk/"

[[2024]]
name = "blog"
url = "https://blog.alifeee.co.uk/"

[[2024]]
name = "weeknotes"
url = "https://weeknotes.alifeee.co.uk/"

It could also go the other way around, with the URL being the root, with years as an array. This has the benefit to be less verbose, and more convoluted to identify which website to show for which years:

author = "alifeee"

["https://alifeee.co.uk/"]
name = "website"
years = [2024, 2023]

["https://blog.alifeee.co.uk/"]
name = "blog"
years = [2024, 2022]

["https://weeknotes.alifeee.co.uk/"]
name = "weeknotes"
years = [2024, 2023, 2022, 2007]

What do you say?

I’ll look deeper into it in March.

[alifeee]

@alifeee: Thanks for this, it’s a lot of work!

no worries ;], it seems a bit easier to accept pull requests for files than for a bunch of line-edits in one file !

I'd be happy to help further with the project in the coming months if you desire it :]

I would be more in favour of one file with structured data, processing it and ordering the content of each file from it automatically. Say, one per owner. Maybe something like this with your 2024’s data:

What do you say?

personally I think any version of trying to be prescriptive (i.e., decide what formats are allowed, and therefore what they transform into) is a bit limiting. I think letting people provide their own HTML (as they should be able to write a small HTML snippet if they can remove the CSS from their website) is good.

[arkhi]

no worries ;], it seems a bit easier to accept pull requests for files than for a bunch of line-edits in one file !

Well, what I had in mind is that one maintainer would maintain one file. That way, we keep consolidated data and avoid multiple people changing the same file. The example file I gave would be called alifeee.toml (or whatever, really…).

We can then proceed with sorting based on the property we want (maybe add a sortBy property), which is harder if it’s hard-coded into HTML. That is if we want the order to matter, of course.

[alifeee]

We can then proceed with sorting based on the property we want (maybe add a sortBy property), which is harder if it’s hard-coded into HTML. That is if we want the order to matter, of course.

Sure. To me, looking at a lot of the pages, I see some annoyance and edge cases by trying to describe the format of people's bullet points (e.g., multiple sites), over just allowing freedom by letting people use HTML snippets

[alifeee]

@j9t @arkhi what do you think of this?

considering CSS naked day is in 11 days, perhaps it waits?

Perhaps it'd be a good learning experience to turn the 2025 list into this format, if you wanted to continue with it?

[arkhi]

@j9t: Do you have thoughts on how to structure this data?

I’m extremely sceptical on individual files with freeform HTML and prefer structured data that we can then transform into HTML, so any opinion of yours can really help as I don’t want to straight out put @alifeee’s work aside.

My take is that it should be easy for anyone to edit their one file, and understand the basic concepts of a toml file. Scattering the data across a multitude of files means editing each one of them. I feel maintenance could suffer.

[alifeee]

I'll let you discuss this as you have the experience.

My only take is that HTML is a lot less forgiving to a build stage than structured markup (i.e., bad TOML is more likely to break a build)

also, don't worry about putting my work aside. I did this a year ago. :]

[j9t]

@arkhi, @alifeee, how can I best help? Do you like me to focus on the participant-related data, or on the whole PR?

For the data, I’d leave HTML out of there, too.

What I could imagine to work are YAML or Markdown files using a flat front matter:

---
participant: "NAME"
url: https://example.com/
---

This could be extended to both enforce a naming structure (à la participant_firstname, participant_lastname, participant_organization) as well as be modified to add several URLs (though I think that’s not needed—adding another Markdown file should do).

Happy to elaborate, also there to play more ideas!

[alifeee]

I hope you had a good CSS naked day 2025 ! I was away so I couldn't participate :]

as you see, the 2025 edition has a couple of entries that would not have fit into a nice schema of "name and URL" (namely items 24 and 27).

This is why I suggested freeform HTML, otherwise there is excessive thinking and maintenance of these edge-cases.

thanks,
alifeee