Codimd: Wide-mode for viewing panel

[csuwildcat]

I find that when using HackMD for sequence diagrams, and other visual artifacts, the max-width in the viewing panel can make reading horizontally packed diagrams very difficult. In looking at the CSS, I found that simply removing the max-width set on the #doc element expands the readable area and allows diagrams to scale up to sizes that are easier to read. Would you consider adding a UI toggle switch that allowed users to toggle to a wide-mode view setting?

[ccoenen]

We were discussing something very similar in #915, I'll close this in favor of the other ticket. If you feel this is very different, feel free to comment here and I'll reopen it!

[csuwildcat]

The major difference between this and the other ticket is that the other one seems to be about someone who wanted the ability to see more in dual edit/view mode, and what I'm saying is that even in view only mode, the content being locked to a max-width means that many diagrams render so small they're hard to read.

The notion here, independent of anything, is that it'd be great to have a 100% width toggle for the the content panel itself, so diagrams are allowed to expand horizontally enough to be legible. To test this, just create a sequence diagram with 6 or 7 actors + lines of text. The page width is locked so small that many diagrams render at a minuscule, unreadable font size.

[SISheogorath]

Would you consider a meta-yaml option as sufficient? Since it's related to the document, I think it would make sense to provide it there.

https://demo.codimd.org/yaml-metadata#

[ccoenen]

I agree, 100% would indeed be helpful sometimes.

I wonder if this more like "night mode" toggle (i.e. something every user decides for themselves and semi-permanent) or if this is indeed tied to a single document (and therefore applies to all visitors/users).

[ccoenen]

another way would be, to exempt diagrams from the max-width. This is regularly done in layouting (think: infographics in magazines), where text needs to have a narrow column for better legibility, but a graphical element (such as a diagram) would be allowed to take up more space.

[csuwildcat]

Yeah, it's really all about visual elements, like diagrams and graphics.
The most interesting, but potentially more complex feature would be to
allow a per-image setting - could do that two ways:

1. In edit source, create some recognized, textual expression that tells
   the parser to render a block of any kind at a given width/max, like 100vw.

2. Add an on-hover range/counter input to graphics in the view panel that
   goes from the default (current max-width) to 100vw

On Fri, Jan 18, 2019, 5:41 AM Claudius Coenen <[email protected]
wrote:

another way would be, to exempt diagrams from the max-width. This is
regularly done in layouting (think: ingographics in magazines), where text
needs to have a narrow column for better legibility, but a graphical
element (such as a diagram) would be allowed to take up more space.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hackmdio/codimd/issues/1119#issuecomment-455549552,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAICygy-EPIiK7DIUalPDzW-9_PHUhrvks5vEc7ugaJpZM4aGYGD
.

[belzebub40k]

Maybe something like Doodle does would be a solution. They have a button that expands just this one element. For me the 758px are fine most of the time but for example wide tables are getting hard to read when you have to scroll horizontally.

[csuwildcat]

Yeah, that would work, and it's easy: just set images and diagrams to 100vw
to break them out of the fixed width constraint of their containing
ancestors and max to the viewport size.

On Fri, Mar 1, 2019, 5:29 AM Julian [e-mail] wrote:

Maybe something like Doodle does would be a solution. They have a button
that expands just this one element. For me the 758px are fine most of the
time but for example wide tables are getting hard to read when you have to
scroll horizontally.

[image: screenshot_20190301_142108]
https://user-images.githubusercontent.com/915117/53640915-baff5000-3c2d-11e9-82db-93a67291ad95.png
[image: screenshot_20190301_142154]
https://user-images.githubusercontent.com/915117/53640922-bdfa4080-3c2d-11e9-9c6f-5e0af8b0288c.png

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hackmdio/codimd/issues/1119#issuecomment-468664924,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAICynabEJyTtLUDaQmkkTWKdcaOg-l0ks5vSStEgaJpZM4aGYGD
.

[tholok97]

IMO this feature would be nice for code blocks as well. I often post code/logs that go beyond the max width, meaning I have to navigate with the horizontal scroller to see it all. I find myself manually editing the CSS to increase the max-width quite often.

[csuwildcat]

LOL, I find myself killing the max-width in dev tools too. If they don't
fix it soon, I might write a quick web extension.

On Wed, Jul 3, 2019, 2:25 AM Thomas Løkkeborg [e-mail]
wrote:

IMO this feature would be nice for code blocks as well. I often post
code/logs that go beyond the max width, meaning I have to navigate with the
horizontal scroller to see it all. I find myself manually editing the CSS
to increase the max-width quite often.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hackmdio/codimd/issues/1119?email_source=notifications&email_token=AABAFSVIA3JTV223FBD6UITP5RWAFA5CNFSM4GQZQGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZD3IMQ#issuecomment-508015666,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABAFSQO4MCMJ7YX6TULUM3P5RWAFANCNFSM4GQZQGBQ
.