Preview of input styles for 2.10.3

[Yakov]

Hello everyone,

recently I've made some experiments regarding styles of inputs in TW and come with a prototype that I'm considering to include into 2.10.3. I'd like to know what you think about it and I've prepared a snippet that you can add into your StyleSheet and provide some feedback (see below).

Here are some previews (note the borders → shadows, in-focus state, selection – they use colors from ColorPalette):

editors:

other inputs:

selection fallback style for rare input types (like file, password, etc):

similar for checkboxes (as they don't have the box with shadows):

the next input in focus, for contrast:

In the sidebar, there will be extra borders (in search and username inputs), that will be removed with other changes, but if you'd like to remove them, add

 , #sidebarOptions input 

after the first  select in the snippet below.

The selection styles are not that simple as they should be different from the background color in all the cases, which is not fully implemented in this snippet, although I've took into account the major bits – code and messages styles:

As there was no feedback to the options-in-templates thread while it poses some backward compatibility risks, I think it would be sane to introduce border-radius in inputs first, and do the hard part later.

Feedback about compatibility with your custom styles will be particularly valuable. Also, let me know if this hurts contrast for you in some cases.

Best regards,

Yakov.

PS I'm also thinking about using only secondary (yellow-ish in the standard ColorPalette) colors for all the hovers (like tiddly links, tabs, etc), but this is not included into this preview (yet).

Styles:

/*{{{*/
/* == nice inputs and in focus == */
textarea, input[type="text"], input:not([type]), input[type="file"], input[type="search"], select,
 .editor textarea {
    padding: 0.3em 0.5em 0.2em;
    border: none;
    box-shadow: 0.1em 0.1em 0.3em [[ColorPalette::TertiaryMid]] inset;
    border-radius: 4px;
    box-sizing: border-box;
}
/* checkboxes and some others */
input:focus {
    outline-color: [[ColorPalette::SecondaryMid]];
}
textarea:focus, input[type="text"]:focus, input:not([type]):focus, input[type="search"]:focus, select:focus {
    outline: none;
    box-shadow: 0.1em 0.1em 0.3em [[ColorPalette::SecondaryMid]] inset;
}

/* == nice selection == */
::selection {
    background: [[ColorPalette::SecondaryLight]];
}
/* TODO: others with SecondaryLight background (see StyleSheetColors: .button:hover, .wizard .button, .popup li a:hover, .highlight, .marked, #backstageArea a:hover) */
.annotation::selection, #messageArea ::selection {
    background: [[ColorPalette::SecondaryMid]];
}
/*}}}*/

[Roma]

Just a quick and general answer: I usually prefer flat design and sobriety. 
Style as aesthetics is part of interfacing man & machine, so yes, it matters.

Research on this subject is good but difficult for it this working condition criteria can hardly be shared  (...)

I appreciate your documentation. Will have a look as soon as I have some time...

[Wolfgang]

Hi Yakov,

besides "De gustibus (non) est disputandum" ;-)

• highlighted text (@@...@@) is also yellow, so marking such text can't be seen

I had to remove the snipped because I quite often come into this situation...

Thanks,

Wolfgang

[Jon]

Hi, Yakov,

Thanks for your work on the interface. I like the rounded input boxes and in fact have used a similar style in some of my own customized TWs to dress up input forms. 

Since you asked, though, I would have to say that I am not overly fond of the "shadowed" style. I find a simple rounded box with a gray border to have a cleaner, less distracting look. I feel like the shadows call too much attention to the design instead of letting the user's eye focus on the function.

Where the input is in a table, like your "Options" dialog example, there's sort of a "box-in-a-box" feel. Maybe the cleaner style in that case is to make the input the exact size of the table cell and use inset borders or background color to show it's active?

--Jon

[Okido]

Hello Yakov,

I added your proposal to my main TWC.

I am not happy with the boxes looking smudged by a shadow, I prefer simple rounded boxes with a gray border and a minimalist shadow.

Have a nice day, Okido

Op zaterdag 11 januari 2025 om 17:45:52 UTC+1 schreef Jon:

[Yakov]

Thanks everyone for testing and providing your feedback!

As far as I can see, it's better to put the borderless inputs (shadows instead of borders) into a separate theme instead of the core. I suspected that due to potential backward compatibility issues, so let it be.

> Where the input is in a table, like your "Options" dialog example, there's sort of a "box-in-a-box" feel. Maybe the cleaner style in that case is to make the input the exact size of the table cell and use inset borders or background color to show it's active?

Absolutely, Jon, I also don't like the "box-in-a-box" UI. That's actually one of the reasons I considered the inputs with shadows: if a normal input is put into a cell without extra borders, how one will understand that it's an input and not a text/empty cell? I haven't stretched the inputs in this iteration, but since using shadows is not to the community liking, I'm not sure how else we can address this issue. I don't think using background color would be a good option; using a special style for bottom border could be a solution, but it doesn't interact well with the rounded borders (I haven't experimented on this yet, though).

> highlighted text (@@...@@) is also yellow, so marking such text can't be seen

Yeah, that's why the snippet contains a TODO for this. See the new version that handles this case and most of the others, below.

So, the new version below

• Increases paddings in inputs the same way as the previous one;
• Changes default outline color for focused elements (black in my case) to that from ColorPalette;
• Sets selection color from ColorPalette in a more nuanced way (uses colors contrast from specific backgrounds).
  

Let me know how it works for you; I'll probably add some more experiments for more consistent hover/active states of different elements (links, buttons, tabs, etc) later.

Best regards,

Yakov.

/***
v2
***/
/*{{{*/

/* == nice inputs and in focus == */
textarea, input[type="text"], input:not([type]), input[type="file"], input[type="search"], select,
 .editor textarea {
    padding: 0.3em 0.5em 0.2em;

    border-radius: 4px;
    border-width: 1px;
    box-sizing: border-box;
}
:focus {
    outline-color: [[ColorPalette::SecondaryMid]];

}

/* == nice selection == */
::selection {
    background: [[ColorPalette::SecondaryLight]];
}

/* TODO: others with SecondaryLight background (see StyleSheetColors: .button:hover, #backstageArea a:hover) ..note: .button:active is different from .popup li a:active */
.annotation::selection, #messageArea ::selection, .highlight::selection, .marked::selection, .wizard .button::selection, .popup li a:hover::selection {

    background: [[ColorPalette::SecondaryMid]];
}
/*}}}*/

воскресенье, 12 января 2025 г. в 18:54:04 UTC+3, Okido:

[Jon]

I also don't like the "box-in-a-box" UI. That's actually one of the reasons I considered the inputs with shadows: if a normal input is put into a cell without extra borders, how one will understand that it's an input and not a text/empty cell?

I played around with this a little bit. Here's a possible starting point, a way to get the table cell itself to have inset borders if it contains a borderless input. I also added a light background because I thought the borders were a little subtle, but by playing with the borders (color, maybe?) the background might not be needed:

table.twtable {
  border-collapse: separate;
  border-spacing: 0;
}

td:has(> .txtOptionInput) {
  border-style: inset;
  background-color: #eee;
  padding: 0;
  }

.txtOptionInput {
  background: #eee;
  color: #000;
  box-sizing: border-box;
  width: 100%;
  height: 100%;
  border: none;

  }

[Yakov]

Well, I'd definitely avoid using gray background as it is usually used to mark disabled fields. Another issue with this approach is it either differentiates inputs (some now have background, some don't) or we have to add it to editors, and in fact my general idea is to reduce the number of colored background (like in tags and popups already and in sidebar options in the future releases, I'm experimenting with it already for 2.10.3) instead of adding new ones. While differentiating option inputs visually may be a proper thing to do, I think a more proper thing to do is to deal with the other borders: with those in the "ListView" tables (options, plugins, import).

If you take a look at some UI examples, you can see that for options, they usually use borderless tables:

We can consider modifying ListView towards this direction. As is:

Applying borderless partially:

Fully borderless:

Both look fine to me, but I'd probably stick to the partially borderless for now, because ListView is used in several places, and in big tables it can be difficult to follow a table line (although I don't have an example screenshot at the moment) and also sometimes long texts are not well-readable without a separator:

You can try both versions by adding

.listView th, .listView td, .listView tr {
    border: none;
    border-bottom: 1px solid #ccc; /* comment this out/remove line to get fully borderless */
}

to StyleSheet. In fact, we can try a more radical version by extending partially borderless style to all the tables with something like this:

.twtable td, .twtable tr {
    border: none;
    border-bottom: 1px solid #ccc;
}

.twtable tr:last-child, .twtable tr:last-child > td {
    border: none;
}

which seem to look fine to me:

(not only to me: see, for instance, Bootstrap tables)

So yeah, I think we should consider partially borderless tables as a first iteration, and if it works fine, consider fully borderless ListView. What do you think?

понедельник, 13 января 2025 г. в 20:35:08 UTC+3, Jon:

[Wolfgang]

Hi Yakov,

selecting highlighted text is visible now (orange). 

However, selecting regular text is (light) yellow (hardly readable).

Selecting links is also (light) yellow but with white text (even worse readable).

For me, the present blue selection color is more consistent and better readable by far.

Thanks,

Wolfgang

[Yakov]

Thanks everyone for the feedback,

here's the last iteration (the last portion of new suggestions) before I start updating these bits in the core:

• Based on the feedback, both shadows in inputs and colored text selection won't get into 2.10.3 (will either work more on them and propose in the next versions or will put them into a separate theme for those who are interested);
• This time, I'm proposing to try not only styles, but also CssOptionsPlugin, which will most likely be a part of 2.10.3 core and which:
  • Introduces css- options that are instantly applied as css variables on change (without any refreshing);
  • Allows to introduce new features with forward compatibility (unlike shadow tiddlers) – this time, border rounding;
• What's included in this iteration:
  • (as previously) outline of focused elements, colored in accord with ColorPalette;
  • border-radius for various elements (block and inline);
  • sidebar options: no background color, instead size and border consistent with tabs below;
  • system-ui font (i.e. default font-family native to your OS);
  • hover colors of links and tabs – now consistent with hover of buttons;
  • semi-borderless tables (let me know how they work in content: maybe it's better to only apply them to backstage tables in this iteration);
• Also, below is a proposed version of default OptionsPanel content, more brief and clean.

Let me know if you have objections, suggestions, or appreciations. I hope to accumulate at least 3 reactions before proceeding to the core update.

Best regards,

Yakov.

New OptionsPanel content:

These options are saved in your browser, unless are written in SystemSettings

<<option chkAutoSave>> Automatically save changes
<<option chkSaveBackups>> Save backups
<<option chkCaseSensitiveSearch>> Case-sensitive searching
<<option chkRegExpSearch>> Search with ~RegExp-s
<<option chkAnimate>> Enable animations

[[AdvancedOptions]]

Add this to SystemSettings to define the border radius variables (for the stylesheet below):

cssBlockBorderRadius: 4px
cssInlineBorderRadius: 0.4em

If you'd like to see how changing them is instantly applied to styles, try <<option cssBlockBorderRadius>> (it is applied to the input itself, beside other elements). If you'd like to see it in AdvancedOptions, add this to the end of CssOptionsPlugin:

tw.options.define("cssBlockBorderRadius", "4px", "experimental, sets border radius of several components")

StyleSheet snippet:

/*{{{*/
/* == nice inputs and in focus == */
textarea, input[type="text"], input:not([type]), input[type="file"], input[type="search"], select,
 .editor textarea {
    padding: 0.3em 0.5em 0.2em;

    border-radius: var(--blockBorderRadius);

    border-width: 1px;
    box-sizing: border-box;
}
:focus {
    outline-color: [[ColorPalette::SecondaryMid]];
}

/* == consistent hover/active states (a minimal iteration) == */
a:hover {
    background-color: [[ColorPalette::SecondaryLight]];
    color: [[ColorPalette::PrimaryMid]];
}

/* == sidebar options, consistent with tabs == */
#sidebarOptions .sliderPanel {
    background: inherit;
    margin-left: 0;
    font-size: 1em;

    border: 1px solid #ccc;
}
#sidebarTabs .tabContents {
    width: unset;
}

/* == semi-borderless tables == */

.twtable td, .twtable tr {
    border: none;
    border-bottom: 1px solid #ccc;
}
.twtable tr:last-child, .twtable tr:last-child > td {
    border: none;
}

/* if you'd like to apply this to backstage only, use this instead (remove the border-bottom bit to get fully borderless):

.listView th, .listView td, .listView tr {
    border: none;
    border-bottom: 1px solid #ccc;
}

*/

/* == border-radius for other elements (testing option-variables) == */
.tagging, .tagged, pre, #messageArea, .annotation, .popup, .wizardStep, .tabContents, #sidebarOptions .sliderPanel {
border-radius: var(--blockBorderRadius);
}
/* inputs+: above */
/* non-block elements should be handled differently: value in em */
.tab {
    border-radius: var(--inlineBorderRadius) var(--inlineBorderRadius) 0 0;
}
.button {
border-radius: var(--inlineBorderRadius);
}
.popup .button {
    border-radius: 0;
}
.tiddlyLink {
    border-radius: var(--inlineBorderRadius);
    padding: 0.1em 0.2em 0.25em;
    margin: 0 -0.2em;
}
.popup .tiddlyLink {
    border-radius: 0;
    margin: 0;
}

/* == font family consistent with OS == */
body {
font-family: system-ui, arial, helvetica, sans-serif;
}

/*}}}*/

суббота, 25 января 2025 г. в 08:53:42 UTC+3, Wolfgang:

[Yakov]

Have anybody tried the last edition yet?

I'm really reluctant about pushing these changes without feedback from community, so I'll be glad if you check them and let me know how they work for you.

Best regards,
Yakov

вторник, 25 февраля 2025 г. в 19:45:07 UTC+3, Yakov:

[Okido]

Hello Yakov,

The thing that I am not going to use is the system-ui font, I prefer the old style arial etc.

The CssOptionsPlugin.js is nice but I prefer the pure CSS instead, I do not see what advantage this would bring if it is the core.

Have a nice day, Okido

Op zaterdag 15 maart 2025 om 12:56:08 UTC+1 schreef Yakov:

[Yakov]

Hello Okido,

the usage of CSS variables (which is, by the way, purer CSS then using the TW-specific [[Tiddler::Slice]] syntax) has 2 main advantages:

1. Instant customization: when such a variable is updated, everything is updated natively by the browser, no refreshing is needed, which is nice for any settings changing UI (see the gif below);
2. Forward compatibility: if I add a new color to ColorPalette and use it in core styles, anyone who has a customized ColorPalette will have the styles broken since they don't have the new "variable" in it, so using shadows for new things like border-radius won't work in a forward-compatible way (unless we add a new shadow per option). With CSS variables/css- options, there's no such issue as they are granular by design: adding a new variable works fine regardless how users customized the previous ones.

Initial application for them is border radius(es), but I'm sure they will help with various other features (I saw the forward compatibility limitation in several scenarios).

Best regards,

Yakov

понедельник, 17 марта 2025 г. в 21:56:34 UTC+3, Okido:

[Yakov]

PS oops, I forgot to attach the gif:

вторник, 18 марта 2025 г. в 10:09:55 UTC+3, Yakov: