2023 redesign css updates

[megoth]

I've rebased the branch on 2023-redesign and added some CSS classes (.container, .tiles, .button, and added a bit to .legend).

There's more work to do, but I wanted to share my progress.

[megoth]

@KyraAssaad you probably want to review this. The work is not done, but I hope the CSS is a bit easier to maintain with my proposed changes.

[csarven]

Pardon me but I don't understand the fascination with adding random classes to HTML that are essentially corresponding to a particular design in mind. As mentioned elsewhere, HTML really needs to stand on its own so that different CSS can be applied and maintained over time without having to resort to HTML changes (CSS Zen Garden made this case long ago). I can't stress how important this is considering our limited resource even if it seems like no biggie right now.

All of the classes introduced in this PR: container, container--full, container--open-end, tiles, tiles--very-distinct, button, are 100% about the specific proposed design. They add no structural or semantic "information" to the underlying content such that they'd be meaningful for a different design.

If classes need be, it is because there is a higher level categorisation of the recurring components that's not particularly expressible. Taking notions such as "features" or "see also" included on some of the pages, once we have a "name" for all those components, then we can use more accurate or precise HTML(+RDFa) towards them. If at that point there are no unique ways to style those components, we can introduce things to be able to target them in CSS.

[VirginiaBalseiro]

Pardon me but I don't understand the fascination with adding random classes to HTML that are essentially corresponding to a particular design in mind. As mentioned elsewhere, HTML really needs to stand on its own so that different CSS can be applied and maintained over time without having to resort to HTML changes

All of the classes introduced in this PR: container, container--full, container--open-end, tiles, tiles--very-distinct, button, are 100% about the specific proposed design. They add no structural or semantic "information" to the underlying content such that they'd be meaningful for a different design.

If classes need be, it is because there is a higher level categorisation of the recurring components that's not particularly expressible.

Agree 100% and we were deliberately trying to avoid this with the initial CSS, albeit with its many issues that we were looking into solving later, and made note of that on the PR.

[megoth]

Ok, then disregard my suggestions. But I really don't understand how you think this will be maintainable.

[megoth]

@csarven @VirginiaBalseiro I've now removed the CSS classes that didn't contribute any semantics to the HTML. I still think it's a bit painful to maintain, especially for people who scan through the CSS and want to reuse design. I've tried to mitigate this by adding some documentation to those parts in the CSS. I've changed very little in the HTML apart from that, so I hope this looks better.

[megoth]

Using the header pattern to isolate some heading and short description makes sense. I wasn't sure to implement this in the original because it wasn't particularly necessary to wrap it. If that idea is what's intended - which should be documented - then lets keep it consistent with header.

Where should it be documented?

[megoth]

Admittedly, I've skipped terms.html - It currently isn't linked to anywhere, I reckon that should be done?

[michielbdejong]

Is this still incomplete?