2023 redesign css updates #855
Conversation
Based on feedback from Kyra, which I agree to
Adding and changing some URLs
Fix some broken links, ref solid#845
This reverts commit 6f1667e.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Added .container, .tiles, and .button (and developed .legend a bit more). Have tried to clean up "old" CSS, i.e. the ones not necessary since I've created some CSS classes, but there is probably more. Need more work, but wanted to share my progress.
|
@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. |
|
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: 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. |
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. |
|
Ok, then disregard my suggestions. But I really don't understand how you think this will be maintainable. |
As per feedback from Sarven and Virginia
…oject.org into 2023-redesign-css-updates
|
@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. |
There was a problem hiding this comment.
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.
| </li> | ||
| <li> | ||
| <p><strong>Example applications</strong></p> | ||
| <p>Find examples of applications built with Solid.</p> | ||
| <a href="" rel="rdfs:seeAlso">See example applications</a> | ||
| <a href="https://forum.solidproject.org/c/applications/" rel="rdfs:seeAlso">See example applications</a> |
There was a problem hiding this comment.
| <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?
There was a problem hiding this comment.
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?
| <dt>Organization</dt> | ||
| <dd><a href="https://mydata.org/" rel="schema:organizer">MyData</a></dd> | ||
| <dt>Date</dt> | ||
| <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> |
There was a problem hiding this comment.
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.
| <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.
There was a problem hiding this comment.
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?
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Sarven Capadisli <[email protected]>
Where should it be documented? |
|
Admittedly, I've skipped terms.html - It currently isn't linked to anywhere, I reckon that should be done? |
|
Is this still incomplete? |
I've rebased the branch on
2023-redesignand 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.