Extend 'sticky' to edittoolbar

[gernert]

In the Google groups Jan showed how to extend the sticky behaviour to the edittoolbar.

As far as I can see, the (minimal) code in $:/themes/tiddlywiki/vanilla/sticky should be:

<$reveal state="$:/themes/tiddlywiki/vanilla/options/stickytitles" type="match" text="yes">
``
.tc-tiddler-title {
    position: -webkit-sticky;
    position: -moz-sticky;
    position: -o-sticky;
    position: -ms-sticky;
    position: sticky;
    top: 0px;
    background: ``<<colour tiddler-background>>``;
    z-index: 500;
}
.tc-editor-toolbar {
    position: -webkit-sticky;
    position: -moz-sticky;
    position: -o-sticky;
    position: -ms-sticky;
    position: sticky;
    top: 35px;
    background: ``<<colour tiddler-background>>``;
    z-index: 500;
}
``
</$reveal>

The top value of 35px in .tc-editor-toolbar is needed to avoid hiding the tiddler control buttons.

[gernert]

I tried to make a pull request but did not succeed, see #2749

[gernert]

To be complete: although this works, it does not work when the preview pane has been activated.

[pmario]

To be complete: although this works, it does not work when the preview pane has been activated.

That's a reason, why a PR couldn't be merged. It would break the existing behavior. ... but ...

It seems we would need to modify the DOM structure, that is created, when the preview pane is activated. .. and .. the preview pane is a float: right which is an incredible difficult beast to tame. .. So my suggestion would be to use display:flex to build a multi column view. ... browser compatibility is great.

@Jermolene what do you think about display:flex here?

[TiddlyTweeter]

@pmario IMO, as a writer, the fact you can't keep the editor controls onscreen sucks. I got so fed up with it that for most serious writing in TW I use a Firefox extension to open a text editor I customised for wikitext compatible code snippets.

Its not an issue for simple tiddler editing. But it is a PITA when you are working on anything complex and long.

My two cents. Josiah

[danielo515]

I'm very recluant to introduce changes that may look prettier but:

1. Are not guaranteed to work on all browsers
2. Are hard to test on all browsers (you have to open the page on all browsers and check that it works)
3. Are focused on browser and may not make sense on mobile

[Jermolene]

@danielo515 I agree; the existing sticky titles support is pretty unsatisfactory, and I'd rather not exacerbate things until browsers sort themselves out.

Hey @TiddlyTweeter

IMO, as a writer, the fact you can't keep the editor controls onscreen sucks.

I assume you know about the setting to force scroll bars when editing long tiddlers; it means that you can indeed keep the editor controls onscreen:

[danielo515]

I assume you know about the setting to force scroll bars when editing long tiddlers; it means that you can indeed keep the editor controls onscreen:

In fact, being able to set that height to automatically fill the screen will be better than making titles sticky. Actually what editors do is exactly this, they allow you to "scroll" the document.

[tobibeer]

But with the current redering process in TW, doesn't that mean that this height will have to dynamically be determined and updated on every keypress in the editor, for both the editor and the preview?

I imagine this might yield some rather jumpy experience, at least at the bottom of the editor.

[nicolnt]

Is there any chance to see this feature coming in the future ? I wonder if browsers have evolved since 2017 to make it easier to implement

[pmario]

Browsers did evolve a bit as the sticky behaviour is more stable now. .. But we still would need to modify the DOM structure as I wrote at https://github.com/Jermolene/TiddlyWiki5/issues/2748#issuecomment-301750938 So nothing happened yet.

The main problem is, that the existing behaviour would need to annoy a developer enough to implement the new behaviour. It seems that isn't the case. Most of the contributions are done in "spare time"

[Jermolene]

Thanks @nicolnt @pmario.

There are a number of improvements under consideration for the edit template. It would be good to tie them together into a new issue.