chirun-ncl / chirun

A Python package providing the command line interface for building flexible and accessible content with Chirun.
https://chirun.org.uk/
Other
29 stars 4 forks source link

Proposed changes to stylesheet #169

Closed prowlett closed 1 year ago

prowlett commented 1 year ago

Is this (left) what chirun output is supposed to look like now? It looks like browser defaults, I'm wondering if the stylesheet hasn't loaded. On the right is what it looked like last year, which to me looks more modern/appealing.

Screenshot from 2023-09-15 09-35-30

christianp commented 1 year ago

Sorry, that's how it's meant to look - the stylesheet is a lot more basic than it used to be!

I started from scratch, and tried to go for as much contrast and simplicity as possible, to help accessibility. It could definitely be expanded on, but I'd rather start from a design that satisfies all the criteria than whittle away at the old design.

prowlett commented 1 year ago

Okay, thanks. I'm aware that I'm devolving accessibility to chirun and I'm totally on board with the idea of building accessibility from the ground up, but it needs to look sufficiently styled that it looks modern and appealing, which will impact take-up. I would prefer this doesn't go overboard, but I think the old version did a good job of looking subtly different from defaults. Also some people do get information from colour, so as long as it isn't the only way of conveying information I think a little subtle shading doesn't hurt. I'm not the most visual of people, but I've had a go. I've only edited the CSS in styles.css, so people with really specific needs can override anyway.

Here's what my edited version looks like:

Screenshot from 2023-09-15 11-54-21

Here's what I changed in styles.css. I've listed the changes below, then included the same changes as a diff on the old and new files. Below that, I included a few comments on things I didn't change but I think should be changed.

Under :root:

Changed

--font-family: "Segoe UI", Roboto, "Helvetica Neue", Arial,sans-serif;

Changed

--link-colour: #007bff;

Looking at article.item, I added:

article.item {
    border: 1px solid var(--bg-colour-accent-1);
}
article.item header {
    border-bottom: 1px solid var(--bg-colour-accent-1);
    background-color: var(--bg-colour-off);
    padding: 0.5em 0.5em 0ex 0.5em;
}
article.item header h2 {
    font-size: 130%;
}

Under body > :is(main, header, footer), changed:

padding: 0 3rem;

Under body > footer > hr, added:

margin-left: 0;
margin-right: 0;
border-color: var(--bg-colour-off);

Under body > main > #sidebar, added:

background-color: var(--bg-colour-accent-2);
padding: 1em;

Added:

body > header > nav {
    background-color: var(--bg-colour-off);
}

Under p, h1, h2, h3, h4, h5, h6, added:

font-weight: normal;

Here are all those changes as a diff:

7c7
<     --font-family: sans-serif;
---
>     --font-family: "Segoe UI", Roboto, "Helvetica Neue", Arial,sans-serif;
13c13
<     --link-colour: #0000ee;
---
>     --link-colour: #007bff;
149c149
<     padding: 0 1rem;
---
>     padding: 0 3rem;
166a167
>     font-weight: normal;
256a258,260
> body > header > nav {
>     background-color: var(--bg-colour-off);
> }
290a295,296
>     background-color: var(--bg-colour-accent-2);
>     padding: 1em;
333a340,341
>     margin-top: var(--spacing);
>     margin-bottom: var(--spacing);
372a381,383
>     margin-left: 0;
>     margin-right: 0;
>     border-color: var(--bg-colour-off);
392a404,415
> }
> 
> article.item {
>     border: 1px solid var(--bg-colour-accent-1);
> }
> article.item header {
>     border-bottom: 1px solid var(--bg-colour-accent-1);
>     background-color: var(--bg-colour-off);
>     padding: 0.5em 0.5em 0ex 0.5em;
> }
> article.item header h2 {
>     font-size: 130%;

Some other notes:

What do you think? Is it possible to implement these (or similar) changes?

christianp commented 1 year ago

Working through these suggestions:

--font-family: I prefer to stick with the browser's default. I've added --sans-serif-font and --serif-font CSS properties, to make it easier to change what the corresponding options in the menu mean.

--link-colour: #007bff doesn't satisfy even level A of the WCAG colour contrast criterion, against a white background. Again, I prefer to go with the browser's default, which as well as satisfying level AAA, is a conventional colour so it's less ambiguous what is or isn't a link.

Styling on the part boxes: yep, that's good.

Footer <hr>: I've been meaning to fix the width of it! I prefer it black to the bg-colour-off, though.

image

Sidebar and breadcrumbs: I agree you need something to differentiate them from the main text, but I'm not keen on a block of background colour. I've had a go with a linear gradient fading in from the background, and I might be 20 years late to the party but I think I like it.

image

I like bold headings!

prowlett commented 1 year ago

I don't enough about colour contrasts, I just got #007bff from the old chirun stylesheet. I do think though that the more you choose browser defaults, the more it looks plain and old-fashioned. I think good, accessible choices can be made that still look a bit different to be distinctive and 'modern'. I don't know how this was handled with Numbas, but that has a clean, modern look, I'd say.

I actually quite like Atkinson Hyperlegible, which since you've bothered to import it could be an option for the default?

I think the gradient sidebar looks good fading away from the content. It's sensible to have the top bar fade out before the button, but I'm not sure about the green because it seems to draw my eye. Does it look odd to have the same blue colour for both? Or something that stands out less like a grey at the top? Probably it's just that I'm not used to it. Overall, I think the use of gradients to separate backgrounds looks good.

The headings just seem to leap out of the page in an overpowering way. If they must be bold, could they be less bold? Or smaller?

What about the width of the sidebar? To me, this seems too large, and it wraps too soon. For example, on my 2560x1440 screen half the screen isn't enough to display the content next to the sidebar. Here by comparison with the old chirun. The old one doesn't use the full width for some reason (which seems odd) but still has the content displayed fine in 510px width.

Screenshot from 2023-09-20 09-37-10

The new theme (though I'm not using your branched one so not sure if it's different?) doesn't snap to the side until I make the window slightly wider, at which point it crams the content into only 500px and the sidebar is 400px - 45% of the window for a navigation sidebar seems too high to me.

Screenshot from 2023-09-20 09-42-17

Firefox's responsive design thing indicates that the old chirun would give a sidebar on an iPad or Kindle Fire, or on a phone in landscape mode, but have the content wrapped below the navigation on phones in portrait mode. This seems like a good setup to aim for.

christianp commented 1 year ago

I suppose a reasonable principle is that the breakpoint should happen at or before the point where the text would be narrower than the optimal readable width, which is 50em. I've made a change to the issue-169 branch to do that.

I've also changed the breadcrumbs nav at the top to be the same colour as the sidebar, and made the headings a little bit smaller.

prowlett commented 1 year ago

Sounds good. I don't know how (or even if it is a good idea) I can update my chirun to the issue-169 branch (I followed 'Quick Installation'). Is there a way I can try this, or can you post a screenshot, or are you happy to merge this into the main branch?

christianp commented 1 year ago

@prowlett I think if you do pip install git+https://github.com/chirun-ncl/chirun.git@issue-169 you'll get this branch.

christianp commented 1 year ago

But in fact, I'm now happy with those changes so I've merged in to the master branch and deleted the issue-169 branch.

prowlett commented 1 year ago

I've updated and got the new version, which has the sidebar on the right and some icons etc. which I support. However, the width issue seems even worse. On my screen, the sidebar takes up the whole width until the window gets to 1249px wide, at which point it snaps to the side and the content is 800px wide. Here the left side is 1248px wide and the right is 1249px wide. Once it snaps to the side, the ratio between content and sidebar is two thirds:one third which seems reasonable, just it seems to me that it's happening too late.

image

I understand that on a phone in portrait mode it's going to have to put the navigation above the content (although does it need to take up so much vertical space? I seem to be scrolling a while to get to the content.)

image

I don't know what standards you are working to, but I don't usually have to have my browser window as wide as is needed to get the sidebar to snap to the side on other websites.

Looking again at the Firefox responsive design simulator, it suggests that an iPad in landscape mode wouldn't have a sidebar. Isn't there enough room for the content to sit at the side of the sidebar within the 1080 pixels here?

image

prowlett commented 1 year ago

Above you say

I suppose a reasonable principle is that the breakpoint should happen at or before the point where the text would be narrower than the optimal readable width, which is 50em.

Looking at style.css as generated, line 330 is

@media (max-width: 78em), print {

78em is the 1248px I'm seeing. Changing this line to

@media (max-width: 50em), print {

produces more what I'd expect to see - the sidebar takes over when the window drops to 800px wide. Screenshot here on a simulated iPad screen at 1080px.

image