Presenting: Boosters - a suite of functional stylesheets

Plugins
#1

Boosters is a suite of functional and independent stylesheets.

    functional = affects how targeted items behave
    independent = pick and choose which boosters you like
    stylesheets = it's just looks; no tiddlers are overwritten.

They also (admittedly to my surprise) work very well on mobile, at least on my android.

Some examples...

Edit view the way the Allmighty originally intended:
This shows the result from several active boosters. (Yes, you can still easily access the editor tools and the custom fields, by hovering).

image
image1288Ă—565 18.8 KB

Controlpanel - the settings display:

image
image1288Ă—847 51.3 KB

Sidebar - sticky sidebar head when scrolled, bulleted Recent list (tiddler HelloThere is indicated as open):
image


...and much more.

Boosters

7 Likes
#2

Hi Mat,
I do like your stuff. You have a very good sense of visual style. I do love the subtle bottom shadow of the “sticky” sidebar tabs. It’s a brilliant solution to create a visual separation.

That said: What I do not like is your CSS code.

IMO .tc-reveal should be avoided for styling. There are enough .tc-* named definitions that can be used to reliably style UI elements. The reveal-widget may be removed in future UI elements by using the much more versatile Conditional Shortcut Syntax, introduced with v5.3.x.

<% if %> works similar to the <$list-widget and does not force the construction of DOM elements. So there should be no tc-reveals in the future.

I also think your CSS code is way too specific. It does contain stuff like .tc-xx > p > tc-page-controls, which targets specific HTML tags like P. So if the TW UI changes in the slightest bit, your CSS will break.

See: Child combinator - CSS: Cascading Style Sheets | MDN –

The child combinator (>) is placed between two CSS selectors. It matches only those elements matched by the second selector that are the direct children of elements matched by the first.

IMO .tc-xx .tc-page-controls will do the same thing and gives UI devs the freedom to change the UI DOM structure in the future. eg: The TW UI creates a lot of redundant P tags, that should be gone in future UIs.

I think you will not need any tc-reveal:has() pseudo-classes to meet your goals.

And last but not least. Avoid !important at all cost. It only causes problems for your users in the future, if they need to apply their own modifications, they will be forced to use !important !important. :confused:

-mario

#3

If I import the boosters-plugin to tiddlywiki.com, it does not work in the More: Boosters sidebar.
-m

#4

@pmario - thanks for your (as always) valuable input.

I didn’t realize that using, specifically, .tc-reveal was an issue - good to know and I’ll see what I can do (…but not today). That said, one reason for the high specificity is to not accidentally target anything else. And, as I report here, not all TW elements have a proper class to target so I was forced to “back up” in the tree to target it (for the Controlpanel “compact-settings” booster). Better ideas are welcome.

#5

You sure? It works when I try. Did you import the plugin AND all/any of the booster stylesheets as explained ? (If you didn’t, I have to ask why because I don’t understand how the instructions could be missed.)

Note that it is a subtab under “More”, not a top level tab.

#6

I did start to explore the functions and then the About page has long been gone as I did import the plugin to tw-com.

Sorry I did not read anything :innocent:. I did import the plugin and expected it to work. I should have read the instructions.

May be you can add the About tiddler as the default if all tiddlers are closed.
Set the tiddler $:/config/EmptyStoryMessage to

title: $:/config/EmptyStoryMessage

{{About||$:/core/ui/ViewTemplate}}
#7

These are fantastic.

You’re right: this is absolutely how the Almighty intended us to edit! For me, even though I very rarely use the edit toolbar, I haven’t removed it, because every now and then… This is the perfect compromise (although the target hover zone is a little small vertically for me.) I have two other tweaks that I would do to it for myself. I would use visibility:hide rather than display:none for the new field label; I simply prefer that look, and might even move fields over to line up better with the existing fields. And I would do something similar to the new field block as a whole when there are no custom fields; I don’t like the jumpiness of the tiddler bottom on hover.

But that leads me to my only critique. If I want to make changes to many of these, I need to edit your CSS tiddlers, because there are a number of !important declarations. I can’t simply add a new one of my own with the changes, which would allow for easier upgrades if you make changes. Are all those !importants critical? (I was looking specifically at `recent-bullets)

A question, regarding this:

The plugin is just an interface, to which you add the individual booster stylesheets.

Is there any more to this interface than tagging the tiddlers as boosters and as their subcategories, which allows them to show up in the sidebar? I dragged one tiddler to another wiki without the plugin, and it worked just fine. Am I missing anything else by doing that?

#8

@Scott_Sauyet - thanks for your kind words and suggestions. I’ll look into it but it will take some time.

Regarding the many !important declarations; just test to see what works. I just tested to remove the !important in recent-bullets and, to my surprise, it seems to work perfectly fine. Maybe they were leftovers from the dev of this (which has been a long process). But the “boosters” are just plain stylesheets, not even shadows, so it is super simple to just remove them and see if it works

That should be perfectly fine. They’re just stylesheets and the plugin is just a UI for convenience.

1 Like
#9

These look great. I am working through them now. Many are very useful,

I will add to this reply as I go.

  • I find the check boxes ON when hidden not intuitive. I would prefer them as on when displaying the element, off when hidden. There is also the newish indeterminate icon.

Futures;

  • I wonder if one day this could be set on a per-tiddler basis, perhaps from the Info panel?
#10

What do you mean is “hidden”? A checked checkbox signifies that the booster stylesheet is tagged with $:/tags/Stylesheet, thus active, that’s all.

Well, if any software could actualize this it would be TW with its transclusions and templates. Perhaps a tiddler viewtemplate that, if the current tid fulfills some condition, runs the stylesheet and transcludes the current title into the style definitions.

#11
  • I understand that however a number of your style sheets hide something. Checked means something will be hidden, I suppose I prefer it refer to the visibility so if a stylesheet hides something I would prefer it to be unchecked, if it is not displayed it is checked, whatever the that fact is about the stylesheet being active or inactive. Otherwise when I read it I have to think if it is checked the stylesheet is active and it gets hidden.
    • Normally it is the result we care about not how its achieved.

Just my perspective, but I like your toolset. :nerd_face:

#12

I do see the rationale for @twMat to keep checkbox-yes state lined up with the activation of this or that optional stylesheet in the package.

But Tones’ concern is also right: It’s important that each checkbox be clearly labeled.

Some of them are already well-labeled. But, most notably, the checkbox for “editor-toolbar” activates your stylesheet tweak which HIDES the editor-toolbar until hover. So, a label like “suppress edit-bar” or “edit-bar only on hover” would communicate more clearly. :slight_smile:

#13

@TW_Tones and @Springer , now I understand better.

Yeah, maybe I should reconsider their labels. But note that it is super simple to relable them: The label of the booster is simply the suffix in its tiddler title, $:/Boosters/THIS-BIT, and they’re not part of any plugin so just name it however you want. (I didn’t test names with space characters in it, tho.)

1 Like