Smart columns to make use of wide screens

#4

Me too, four of them - but it has to be said, @TiddlyTitch is the screen-size king :upside_down_face:

Yep. Most of my tiddlers are presented in views with fixed positioning. I use columns for display and editing – 3 columns for display in viewing mode, 2 columns for display +1 for editing in editing mode. It’s a very efficient way of working – I’d never go back.

I don’t use break-inside. My system is much like @EricShulman described – height limited (85vh) and the columns “flow” to the right naturally. For printing purposes (rarely needed), I have a view (template) that does not have columns – so I don’t need break control.

Here’s CSS (macro)

\define chapsec-div(columns)
 columns:$columns$; 
    -moz-columns:$columns$; -webkit-columns:$columns$;
 column-gap:0; 
    -moz-column-gap:0; -webkit-column-gap:0;
 column-rule: 2px dotted #ddd; 
    -moz-column-rule: 2px dotted #ddd; -webkit-column-rule: 2px dotted #ddd;
 column-fill:auto; 
    -moz-column-fill:auto; -webkit-column-fill:auto;
 max-height: 85vh;
 padding: 4px 2px;
\end

I suspect the brand prefixes can be taken out…

2 Likes
#5

LOL! Right. I guess that is true, though I never advertised that I have very large super-resolution screens with auto color calibration. You need that if you want to force a computer system to actually display on screen something that actually resembles reality. I need that for work in real life on movies and presenting static images of real artworks. Color matching is a whole art in itself. One that is still over-complicated because there are really still no proper standards on hardware colour generation on most monitors.

Enough about me.

It is an interesting OP and thread.

I thought @CodaCoder’s note particularly interesting.

TBH I would say the final solution will depend somewhat on screen estate available. Meaning, I doubt there is one solution to the OP. Screens are physical media. So a flexi solution is more about somehow understanding what are the appropriate “slices” for the aim ON the particular hardware available.

Just thoughts (the code solutions look fit enough :slight_smile: )

TT

2 Likes
#6

Alvaro and developers here,

There is much that can be done without introducing Javascript than you think. In fact Tiddlywiki is based on Javascript and much of what we need is accessible through widgets in tiddlywiki. It is increasingly rare we need additional Javascript modules in tiddlywiki.

I am not saying this about you, specifically but with my decade of experience with tiddlywiki often when we get a new user with javascript skills that are often trying to solve issues in tiddlywiki by introducing javascript. As a super user (not using Javascript) I often know another way. I think it fair to say unless they are pulling in a new solution based on a library of features, this is more often than not, unnecessary to introduce new Javascript because there is a way to achieve what they want already in tiddlywiki.

Of course there are plenty of edge cases or minor improvements where new core or plugins make sense for tiddlywiki, and this is where we really need our javascript developers to help, but the problem is when too many solutions are designed to solve problems for which there are already tiddlywiki solutions.

  • You can use calc in tiddlywiki css
  • You can change properties / attributes in html and css dynamically in tiddlywiki
  • See $:/info/browser/screen/width and $:/info/browser/screen/height

I am not so interested in a perfect value, but a good enough default, that can be configured to taste.

This highlight a little dilemma I find myself in, I often see the limitations because I rub up hard against them as a superuser, who can not easily revert to Javascript and core changes. On one hand, I find it hard to get developers to understand my argument because the see javascript and core changes as the solutions, but on the other hand few ask me if there is a way to already do it.

To me the majority of our development should be based on identifying and satisfying fundamental gaps in what tiddlywiki can do (without plugins) and make the core changes only to facilitate design freedom, using tiddlywiki native functionality.

As others have pointed out there is a lot of functions already in the core, some of which are not yet exposed to users/designers. We do not need more functions necessarily, but more access to existing functions, more hackability, and the documentation to empower users of different skill levels.

#7

Thanks for the alternative methods.

If I could ask

  • Is there an easy way for me to enhance my original example to not move to columns unless the content is goes beyond a maximum height (the screen height?)
  • Is there a way to remove the unwanted space at the top of the first column?

I did have questions in my original post I hope you can answer.

#8

Yes, I know it. But the problem is in how we obtain the height of tiddler and then apply a style or other. And I don’t know if we have a tw function for view the height of a tiddler.

I always talk about short solutions. Yes, it is possible find others long ways to do it.

Yes, we can play wiht styles but we can’t do it if we don’t have a necessary value.

One possible workaround would be calc the height with (variables of) the number of chars and “parragraps”, which would be obtained using filters, vs a width (width of tiddler or width of the column). Then we apply, for example, a right padding if it is smaller than a minimal value, or columns are applied if it is longer. And So with filtered transclusion the styles are applied. (short and messy explanation)

2 Likes
#9

I just edited the lead post in this topic to include;

It makes sense for this solution that increases density of content on wide screens (using columns) to also allow the opposite - scale up the content size to make use of the extra wide screen ie reduced density as well.

Somewhat related Perhaps there could even be a color blind option, and the screen read option although I expect such users may bring their own colours and tools to the browser.

Suggestions welcome.

#10

I think this thread should be in the HowTo category. You should consider to move it.

#11

@pmario I am all for that when we know how to :grinning:

#12

It’s easy when you have the editing powers :frowning:

#13

I will try to explain better the workaround. (Maybe I won’t do it)

  • We know: font-size (in paragraphs) and line-height (they are in theme tweaks)
  • With their multiplication we have the real height of one line, but in a paragraph we can have several lines.
  • The number of lines in one paragraph i (NLPi) will be determinated by how many chars enter in X width of paragraph. We could use the division of width by font-size, the result is multiplied by :arrow_right: the number of characters of the paragrah :arrow_left:. and then we have this NLPi
  • There is a extra point each paragraph have a top and bottom margin of 1em (=font-size of paragraph). But the most times, If we count only one of them it would be enought. Then we have the font-size multiplied by :arrow_right: the number of paragraphs :arrow_left:
  • We can calculate the height of our text in fixed width.
  • The las step is the evaluation of the height of text vs our ¿key? height and then apply one or other style.

I think that the heaviest task is to obtain (and the most important):

  • :arrow_right: number of paragraphs
  • :arrow_right: number of characters of each paragrah
#14

@Alvaro I think what you are trying to do here is very important, I am not sure it is essential for the Original Post, but that is debatable.

As Eric suggested there are some Hight related CSS.

limits the height of a tiddler body to half the window height (50vh),

One problem area where estimating content height.

  • When printing, being able to determine when a page break is needed before having the break forced on us.
  • With effective use of your workaround it may help us choose when to introduce column breaks.

Progress

  • I think I can get the number of paragraphs and number of characters there in.
    • I think we need to count white spaces and punctuation as well?
  • How dose this relate to the Zoom effect eg ctrl-minus or ctrl-mouse roller?

Thoughts
It is programaticaly possible to render a tiddler fully in a variable, such that all lists and widgets, transclusions and macros are resolved and stored in that variable, normally this would simply be displayed, however we can use this to determine total length and content (paragraphs, lines etc…) of the result (not just the wikitext).

#15

Also,

It makes sense to use css to stop various elements being broken by a column break such as paragraphs, images, tables etc…

div, ol, ul, img, table, { break-inside: avoid; }

How could these effect our attempt to quantify the text?

#16

Are you assuming that a paragraph is composed of only text of a constant font-size and line-height? Within the bounds of a single paragraph (i.e, between <p> and </p>), there can be any number of changes in font-size and line-height, as well as transcluded content and embedded images, tables, input fields, buttons, etc. This makes it unlikely that your suggested calculation will produce a reliable measure of the overall paragraph height.

-e

#17

Eric, I agree that

any number of changes in font-size and line-height, as well as transcluded content and embedded images, tables, input fields, buttons, etc.

However this is when we look at the original wikitext and widget before rendering.

But then we can wikify the whole text field with the wikify widget and generate an expanded html representation.

  • I wonder if we could use this this to get more information?

Not withstanding this interesting possibility above, if we can specify 50vw for 50% of the view window then surely we “know” what “100% of the view window is”. I

To me the key here is can we determine if a tiddlers rendered size is greater than the view window? Even better if we knew how many times the view window, Once known we can choose to introduce multiple columns, overflow or other alternate view be it for wide screens or narrow.

I do not recall how but I believe it is possible to extract the screen dimension’s, because we know this is used to trigger mobile view.

A key technical hurdle is to identify what size rendered content in a tiddler is, at least relative to the view window.

#18

It could be this 50vh or other value.

vs

In printing we have a fixed format, you can play to adjust the elements there. But you don’t have this zoom (internally in the format). The web and the browsers are new, they are continously improved.

@TW_Tones and @EricShulman , I agree. There a lot of uncounted variables. For example, big images broke all if we don’t use a max-width: 100%. It was a possible (basic) workaround to direct use of js.

#19

Sorry, but without using JavaScript to figure this out in detail is probably a waste of your time. Even if you use JS, you’re likely to be chasing what the layout engines in browsers already do but with far less accuracy – I fancy @EricShulman already knows this but is far too polite to say it.

There maybe some mileage to be gained by counting the outer heights/widths of all block level elements on the page (briefly, div, p, etc) but even then, you may miss something which will shorten your journey and leave you a mile or two short of your target.

Lastly, the CSS break* stuff is still “flaky” across browsers (perhaps I should say “agents”). And when it comes to multicolumn layout, well, don’t take my word for it…

https://caniuse.com/multicolumn

My advice, FWIW, use the browser and tools as they are, go with the flow, and don’t keep dogs and start trying to bark yourself.

#20

Today I found again the possible future solution with CSS, but at this moment it is in an early stage of development.

#21

Hey all, for folks attracted by this thread’s title – but who would love a ready-made solution – please check out the Shiraz multicolumn feature. With Shiraz plugin installed, setting the tiddler’s class field to multicol results in a flexible layout that uses available story-river width for columns, taking into account text display size as well.

2 Likes
#22

@Springer yes Shiraz is a great collection, I just revisited it but unfortunately it needs specific application to a tiddler, I was looking at having it respond only when needed, unfortunately it also has the problem with my own method of columnizing even very short tiddlers which looks terrible.

The key is to find a way to get the columns to occur depending on the width (we have that) it will create a columns for every 600px of width, and only if the content goes beyond the current Hight of the View Windows 100vw (100% of View Window), the problem is so far that it will always display on 100vw even with almost no content in a short tiddler when no columns needed. And across 2-3 columns even with only a few sentences.

This is why I and @Alvaro can we do the impossible and estimate the rendered size, or use CSS in a different way.

Try my css in the original post on tiddlywiki.com and zoom in and out on wide screen, open large and small tiddler to see the problem.

#23

Tony, as a “shorthand” mnemonic, you might call vw viewport-width. Similarly for vh – viewport-height.

vw

Equal to 1% of the width of the viewport’s initial containing block.

<length> - CSS: Cascading Style Sheets | MDN

So the number you supply, say 50, in 50vw amounts to 50 x 1% or 50% of the viewport width.

HTH.