Button style inconsistent, palette dependent

Developers
, , ,
#1

Expected behavior:

Changing the current palette influences only colors, not other properties of elements, e.g. buttons.

Actual behavior:

If the current palette doesn’t define any of the button colors (button-foreground, button-background, button-border), e.g. Vanilla, the buttons take the default style, browser dependent, including reactions to hover and click. Screenshots with Vanilla palette:

Firefox or Chrome/Desktop or Android: firefox-vanilla
Safari/MacOS: safari-vanilla Safari/iOS: safari-ios-vanilla-cropped

If the palette does define (some of?) those colors, e.g. Spartan Day, the default style is overridden, the button has a rectangular border, and does not react to hover. This altered style is also, to some degree, browser dependent (“3D” border on on Firefox and Chrome, solid border on Safari). Screenshots with Spartan Day palette, same order:

Firefox or Chrome/Desktop or Android: firefox-spartan
Safari/MacOS: safari-spartan Safari/iOS: safari-ios-spartan-cropped

Is this situation considered a bug, or is it intended? I see it as a bug, because:

  • Functionality of palettes is inconsistent, if they influence things other than colors.
  • The “custom” button style differs a lot from other similar UI elements (e.g. editor toolbar buttons, tabs), and looks quite outdated (kinda like Windows 98 buttons).
  • The “browser default” button style is, obviously, not consistent across browsers, and not easy to modify thought palette only (e.g. if one wanted to change only its color, not other properties).

The only similar discussion I was able to find on here or GitHub is this one: [IDEA] Define button colours in every palette · Issue #5153 · Jermolene/TiddlyWiki5 · GitHub
An argument made there in favor of the default button is, that it looks much more like a clickable element and that users are familiar with the button style of their browser.

I think the custom button style should be improved, in order to better match other UI elements (like editor toolbar buttons), react to hover, and make it consistent across browsers.

Another question is, whether the browser default buttons style should be used at all.
I think it is worth considering to always use a custom style that matches other TW elements. TW has many custom buttons/ clickable elements already anyway: editor toolbar (including dropdown menu), site and view toolbar, plugin library buttons, dropdowns for content type and field name.
Even if the default button style stays as an option, I’m not sure that choosing it through palette is the most intuitive way. Although it is easier to manage (requires less code changes) than a theme or plugin specifically for this single detail.

What do you think?

1 Like
#2

Thanks @vilc there are some vexed questions here.

My preference is for TiddlyWiki to use browser default styling for UI elements so that they are familiar to users. I think this is particularly important now that we’re seeing more and more novel implementations of the web platform. For example, Apple’s Vision Pro has distinctive styling for system components that incorporates ambient lighting and reflections.

To accommodate users with different preferences we extended palette handling to allow the button colours to be specified. Hence the current situation where the default palette uses default button styling and some other palettes use custom button styling.

I agree that the way that button styling is controlled by palettes is a little unexpected. However, the only customisation we support for buttons is to set the various colours, so the palette is the logical place to specify those colours.

I’d be happy to see improvements to custom button styling, what do you have in mind?

#3

Thanks @jeremyruston for the explanation.

I was thinking of solid border and rounded edges, to make it more similar to other elements (e.g. editor toolbar buttons and “get more plugins” button are all rounded, the default buttons in all major browsers are also rounded), afaik there are no clickable elements with sharp corners. This is easily achievable by adding

border: 1px solid;
border-radius: 2px;

To the button definition in Vanilla theme $:/themes/tiddlywiki/vanilla/base:

html button {
	line-height: 1.2;
	color: <<colour button-foreground>>;
	fill: <<colour button-foreground>>;
	background: <<colour button-background>>;
	border-color: <<colour button-border>>;
}

This should also fix the custom button having a different border in Safari/iOS compared to all other browsers, but I haven’t tested it yet. Perhaps some additional padding adjustments would be necessary for more consistency between Safari/iOS and other browsers (but this is of lower priority, if at all necessary).

The next thing would be making it responsive to hover and click, but I have not yet found a way to do it without influencing other buttons like page controls or view toolbar.
This would also require either conditional styling based on whether the palette is dark or light (to darken the hovered on button in a light palette and lighten in a dark palette), or defining button-background in all palettes that have only button-foreground (and flip them on hover, like in editor toolbar).