Skip to content
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.

Use a wider default style #250

Open
karwa opened this issue Apr 21, 2021 · 3 comments
Open

Use a wider default style #250

karwa opened this issue Apr 21, 2021 · 3 comments
Labels
design Functionality with a design component

Comments

@karwa
Copy link

karwa commented Apr 21, 2021

Swift-doc really doesn't do a good job of using all of the available space.

image

As a result, it tends to be very uncomfortable to read (at least for me). There's a lot of wrapping, so things like code samples look especially poor:

image

Removing the max-width: 1280px constraint from body, things look just as clean, but become a lot more comfortable to read, and code samples suffer from much less wrapping:

image

Obviously, everybody has their own opinions on style and design, but this does seem to be quite wasteful of the available space. Developers will likely spend a long time reading and studying these documents, so comfort and readability should be top priorities IMHO.

@compnerd
Copy link
Contributor

I think that rather than using a wider default style, it may be better to actually use a flex-width container to get scaling based on the current window size. This would be particularly helpful for scaling the documentation from desktop to mobile.

@mattt
Copy link
Contributor

mattt commented Jun 1, 2021

@karwa Thanks for sharing your feedback about the design. I agree that matters of style can be difficult to discuss because of their subjective nature.

There's a consensus among designers that the optimal line length for typography on websites is somewhere between 45 – 90 characters. The current stylesheet follows this guidance.

I think there's a consensus, albeit weaker, among developers that line length for code should be around 80 – 100. I believe the current stylesheet should also follow these guidelines. If they don't, that's something we should address.

swift-doc takes any code formatting as-is. So if your code is formatted to look nice at an 80 character width,
it'll look great in the generated HTML.

@compnerd The current stylesheet is mobile responsive. On desktop, increasing the zoom level (+) should magnify text and container widths to use the available screen real estate.

@mattt mattt added the design Functionality with a design component label Jun 1, 2021
@karwa
Copy link
Author

karwa commented Jun 1, 2021

Sure; I just find it very difficult to read, especially for longer bodies of text. It's so bad that it actually gives me headaches.

The reasoning for the 45-90 character length is given as:

Shorter lines are more comfortable to read than longer lines. As line length increases, your eye has to travel farther from the end of one line to the beginning of the next, making it harder to track your progress vertically.

But, at least for my eyes, I'd rather have longer lines so my eyes don't need to reset to the beginning quite so often. There is a balance to be struck, and I can't make generalisations over what all human beings find comfortable -- but then again, that website is making a broad generalisation, so...

It's one of the main reasons I decided to fork this project for documenting WebURL. You can see an example of the results here. I didn't make that change because I think it looks "better" or "nicer" in an aesthetic sense; I did it because I found it more functional - it's easier to consume the information and doesn't give me headaches. I'd rather not use a fork, but as long as the default output makes me physically uncomfortable, I don't see that I have a choice.

I think it would be worth making it an option, at any rate.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
design Functionality with a design component
Projects
None yet
Development

No branches or pull requests

3 participants