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.

[csarven]

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.

[csarven]

Suggested change

	<a href="https://forum.solidproject.org/c/applications/" rel="rdfs:seeAlso">See example applications</a>
	<a href="https://solidproject.org/apps" rel="rdfs:seeAlso">See example applications</a>

What's currently on the website is most comprehensive and up to date. Any particular reason to direct people to the forum?

[megoth]

This was not part of my update (I only removed the class button).

I agree that https://solidproject.org/apps is (probably) better, but then we should add that page to the new redesign as well.

Maybe @KyraAssaad have some thoughts on this?

[csarven]

I know I included content in the original but it is not necessary if the date is always going to be yyyy-mm-dd without time. The precision is the same. Value from the text content will be used. If the precision for the machine-readable is desired, and the human gets less precise in text content, then content can be handy.

Suggested change

	<dd><time property="schema:startDate" datatype="xsd:date" content="2023-05-31" datetime="2023-05-31">2023-05-31</time>–<time property="schema:endDate" datatype="xsd:date" content="2023-06-02" datetime="2023-06-02">2023-06-02</time></dd>
	<dd><time property="schema:startDate" datatype="xsd:date" datetime="2023-05-31">2023-05-31</time>–<time property="schema:endDate" datatype="xsd:date" datetime="2023-06-02">2023-06-02</time></dd>

Not sure if you want to follow this pattern for the rest.

[megoth]

I have no strong opinions on this, but in general I think less is better. Do you want me to remove all uses of content="[date]" in the HTML?

[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?