Contributing to tiddlywiki: What are the current requirements for backward compatibities?

Developers
#1

CSS has evolved significantly lately, introducing features such as :is, :where, @layer, :has, color-mix, and others that could enhance the base theme of TiddlyWiki, making it cleaner and more streamlined. These improvements could also enhance accessibility, for example, by utilizing color-mix with OKLCH as demonstrated here to improve color palette and ensure WCAG 3.0 APCA compliance: Thinking on ways to solve color palettes.

Furthermore, media queries like prefers-reduced-motion, which are not supported by Internet Explorer as shown here, offer additional opportunities for improvement for users with motion sickness.

Features such as @layer could enable users without in-depth knowledge of TiddlyWiki’s core to easily adapt TiddlyWiki for their own purposes, as illustrated in my work in progress at minimal-css.tiddlyhost.com. This is achieved by eliminating the need for lengthy and complex CSS selectors that are tiddlywiki specific. This css specificity issue happens often, here’s a recent example: How do I standardize font size in my table of contents? : r/TiddlyWiki5 (reddit.com)

The solution that was given was to use this:

.tc-table-of-contents li li li li, .tc-table-of-contents li li li, .tc-table-of-contents li li , .tc-table-of-contents li 
{font-size: 1em;
font-weight: normal;
}

In my opinion, this is not a solution that is easy to find for someone without a very good understanding of CSS AND tiddlywiki. :where() and @layer would improve the user experience by a lot (see: Specificity - CSS: Cascading Style Sheets | MDN (mozilla.org)).

There are also some css features that could be used as progressive enhancement, improving the experience of compatible browsers without compromising the experience of users on older browser, such as text-wrap: balance ( CSS text-wrap: balance | CSS and UI | Chrome for Developers).

As we can see, maintaining backward compatibility for obsolete browsers, such as Internet Explorer, ultimately compromises user experience if careful compromises are not made. I am eager to contribute more to TiddlyWiki’s development, especially in the area of CSS, so I need to know exactly where the line is (currently) drawn.

I searched for explicit guidelines on tiddlywiki.com but was not able to find any (my apologies if they exist!). Same goes for javascript features, I’ve recently learned that there are discussions on to use ECMAscript standard 2018 or 2019 for the TW core, but as far as I know, nothing official yet.

The Mozilla documentation now includes a concept called “baseline,” as discussed in Introducing Baseline | Blog | web.dev. Baseline features should be safe to use in all up-to-date browsers. Are we allowed to use baseline features ? @jermolene ?

1 Like
Organizing ideas for future TW releases
#2

I did see https://tiddlywiki.com/dev/#Using%20ES2016%20for%20Writing%20Plugins for the js version to use (ES2015), but what about css …?

#3

Apart from browser compatibility, the other backwards compatibility constraint is that user defined CSS should continue to function as it does today after any core CSS changes are made.

An interesting approach might be a new core theme that leverages modern CSS and also provides a visual refresh. As long as that is accomplished without altering the templates - apart from perhaps adding additional classes if/where necessary - that would entirely sidestep the issue of backwards compatibility. Such a core theme could then one day potentially be adopted as the default.

3 Likes
#4

I understand. My theme might prove useful after all, if I can complete it.

However, I still have questions. Currently, there’s a minor bug affecting the ribbon on the cards displayed on TiddlyWiki’s homepage. Specifically, when the titles become “sticky,” the ribbon obscures the title bar, potentially hiding its controls.

image

Using :has and isolation: isolate could easily rectify this issue, but @pmario advised that we should adhere to CSS features contemporary with the ECMAScript standards of 2018/2019.

Although this issue is specific to the documentation, similar problems might arise in the empty edition. I would appreciate clarity on the oldest browser versions we aim to support—if the “baseline” is insufficient—to determine what solutions can be used.

#5

Hi @telumire as you note, TiddlyWiki’s dialect of CSS is now fairly old fashioned: we avoid using anything newer than Flexbox. We miss out on a lot of modern CSS features, perhaps particularly variables.

TiddlyWiki’s position on backwards compatibility is subtly different between JavaScript and CSS. In the case of CSS, if a particular property or syntax variant isn’t supported then that line is ignored. With care, it is often possible to provide fallbacks when using newer CSS features. So, in the context of the core Vanilla theme I am happy to see modern CSS introduced within those backwards compatibility constraints.

However, where I’d like to get to is to introduce a new, modern default theme for the core, and make the Vanilla theme available for backwards compatibility.

As @saqimtiaz mentions, the least disruptive approach would be to carefully maintain the existing DOM structure and classes, only adding new classes if needed.

There is also a case to be made for a completely new theme that doesn’t try to retain compatibility with existing CSS. Such a thing would probably be a great deal easier to create. So, I think this is a great point for developers to think about creating new themes.

1 Like
#6

Will there be a new default theme? Or just update the CSS level, and mark old vanilla theme as vanilla-legacy?

If there comes a new default theme, hope we have a professional designer to bring Notion grade design this time. Some users said vanilla theme of tw is too “industrial style”.

2 Likes
#7

I’d be willing to throw in some cash on it, if it helps us find someone skilled to get a professional theme.
A list of wishes and nice-to-haves in a new modern theme, roughly in decreasing priority order:

  • comfortable interface on mobile devices
  • compatibility with or incorporation of something similar to @BurningTreeC’s Flex Layout
  • improve the way palettes are handled (see my post here)

There are surely many others and this would have to be discussed, just a quick take before I forget it.

2 Likes