Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wider view for view-only mode #25

Closed
popindavibe opened this issue Apr 3, 2019 · 11 comments
Closed

Wider view for view-only mode #25

popindavibe opened this issue Apr 3, 2019 · 11 comments
Labels
scope: frontend Only relevant for the frontend type: feature Adds or requests new functionality
Milestone

Comments

@popindavibe
Copy link

Hello,

I have been asking @SISheogorath about this. My current issue is that even in plain view, I am getting a fairly reduced window when my browser is full screen on 1080p widescreen.

This was already raised in the former repository in issue hackmdio/codimd#1119

So far I managed to get a "satisfying" result by changing values in the build files (so, temporary) ./public/build/index.css and ./public/build/index-styles.css .
All I did was to change:
In ./public/build/index.css

.ui-infobar {               
    position: relative;     
    z-index: 2;             
    max-width: 1100px;      
    /* max-width: 758px; */ 
    margin-top: 25px;       
    margin-bottom: -25px;   
    color: #777;            
}                           

In ./public/build/index-styles.css :

    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Helvetica, Arial, sans-serif,  "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
    padding-top: 40px;
    padding-bottom: 40px;
    max-width: 1100px;
        overflow: visible !important;
}

To give a better idea, this is what I get:

  • tablet size (Ipad)

  • HD / 1280 px wide

  • Full HD resolution

  • Current, from demo instance:

@popindavibe
Copy link
Author

popindavibe commented Apr 3, 2019

I see a lot of references to 758px value in the css files, so I don't know how well this is gonna work when only modifying those 2 files. I'll keep it in observation for some time though, if I notice something very wrong I'll report here.

@ccoenen
Copy link
Contributor

ccoenen commented Apr 3, 2019

I think we can use horizontal space better for tables, images and diagrams. I'm a little reluctant to put everything at wider width, though. In my opinion, readability suffers too much at these line lengths.

@SISheogorath SISheogorath added the type: feature Adds or requests new functionality label Apr 4, 2019
@popindavibe
Copy link
Author

Well, I guess it boils down to personal preference and what we feel is confortable. For me this makes it more readable, and allows html image positioning left and right while keeping a comfortable area for text.

I am currently using CodiMD for real-time article drafting for static website. This gives me a better result on what it's going to look like on the jekyll website eventually.

But even then, I would argue that such a small window of text makes the plain view kind of pointless on anything full HD.

@ccoenen
Copy link
Contributor

ccoenen commented Apr 4, 2019

It's not a matter of opinion or personal preference that excessive line length hinders readability. There's probably a sweet spot that is up for debate, but lines much longer than 80 characters hinder readability objectively.

Websites designed for readability face the same dilemma, and pretty much everyone chooses to limit line length. In the following (2300px) screenshot, github opts for ~100 characters, smashing magazine is closer to the recommended range at ~75 characters per line. I chose the nearly full-screen examples to show their choice of limiting overall width. They did not "forget" that wider monitors are a common thing. They chose not to display content wider than this for a different reason: readability.

grafik

@popindavibe
Copy link
Author

popindavibe commented Apr 4, 2019

Well, to follow a thread of short comments is something, and it makes complete sense to me to keep it tight. But if you look at how large is a README.md displays on Github (to follow on the example), it's much larger (ok, not as large as 1100px, but that wasn't the point).

I mean, yeah, Medium for example has a very slim column of text. And as a pretty much text-only website it works. But well, if I just want to write pure text and paragraph, I won't be using CodiMD. I like CodiMD because I can leverage the power of Mardown and HTML render swiftly to render tables, quotes, images, diagrams and raw output! And for that, current width is a bit tight to my liking.

So well, to me it would be an improvement to get a wider plain view (it would actually be best to be able to let viewers dynamically set how much of the available space they want the output to fit in), but if the general feeling is that it's a regression then I am happy with closing the issue. So far it's a 2-sed step that I'll be able to re-play on updates, so not a big concern anyway.

@dampfklon
Copy link

How about making the general view wider but restricting text lines to about 100 chars?

So paragraphs keep their readability but pictures, tables etc. have more space to render.

@indrayam
Copy link

Is there any chance this issue will get addressed?

@indrayam
Copy link

@popindavibe The changes you mentioned above. Does it work well across CodiMD site>

@popindavibe
Copy link
Author

@indrayam I didn't observe any issues really. Though I just upgraded CodiMD to 1.6.0 and haven't re-applied the CSS change yet.

@zeigerpuppy
Copy link

changing max-width to a relative size also works:

max-width: 80%

The width limitation is really annoying for mermaid diagrams especially.
Perhaps there could be a toggle in the document header for document width, it seems that there are quite a few cases where increased width may improve overall readability.

@InnayTool InnayTool added the scope: frontend Only relevant for the frontend label Jul 8, 2020
@InnayTool InnayTool added this to the Release 2.0 milestone Jul 8, 2020
@ErikMichelson
Copy link
Member

For reference: This is already implemented in the new frontend: hedgedoc/react-client#271

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: frontend Only relevant for the frontend type: feature Adds or requests new functionality
Projects
None yet
Development

No branches or pull requests

8 participants