Smart columns to make use of wide screens

#1

Folks and especially CSS gurus

I use large wide screens all the time for tiddlywiki. Often as a result long paragraphs are stretched out onto single lines and reading the tiddler is like watching tennis. Left right left right for each sentence. I had the idea to use multiple columns when the space is available.

This stylesheet modifies only the display of body text and if it has more than 600px width displays a new column. Try it on tiddlywiki.com.
Use the zoom to see this effect come and go. Its cool I think.

But I have a few questions below to make it better.

I created the attached stylesheet tiddler
smart-columns stylesheet.json (345 Bytes)

Containing the following;

.tc-tiddler-body {
  -webkit-column-width: 600px;
     -moz-column-width: 600px;
          column-width: 600px;
    column-rule: 4px double #ff00ff;
}
div, ol, ul, img, table, { break-inside: avoid; }

I raise this because I am sure people asked about this in the past but if you open the tiddler “About” which is very short it is still breaking the columns.

  • How could I stop this occurring until a tiddler is big enough, such that we are forced to scroll to see the rest, and only then use more columns?
  • See the css div, ol, ul, img, table, { break-inside: avoid; } would this have any unwanted effects?
  • Should other html elements also have the break-inside: avoid; set for them?
  • Should this setting 600px be a different value and what are the practical values? Try 400px as an example.

[Edited]
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.

Finally any thoughts?

1 Like
Table with several outputs in one row
Something I miss here that Google Groups does
#2

I think that I you “say” “use columns” the browser will always use them. With CSS you can’t change the use of properties dynamically, except wih use of some function like calc. But you don’t know the lenght of your text and it’s height in the browser. For this you need a programming language like javascript.

About the property break-side, I don’t know anything.

The value is dependent on readability, because with bad values can generate lines that are too short or too long. But there isn’t a perfect value, there are some “popular” intervals that are around 40-60 (-/+ 5-10 up/down) chars for line.

#3

Here’s another interesting bit of column-related CSS:

.tc-tiddler-body { max-height:50vh; column-count:2; overflow:auto; }

It limits the height of a tiddler body to half the window height (50vh), and then shows 2 visible columns, with sideways scrolling for more columns if there isn’t enough room to fit all the tiddler content.

-e

4 Likes
#4

Me too, four of them - but it has to be said, @TiddlyTweeter 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.