Update release notes

2026-09-24 10:18:43 +00:00 · 2026-07-18 15:00:22 +01:00
parent 35ede09e0f
commit 6a2670592f
8 changed files with 77 additions and 17 deletions
@@ -1,11 +0,0 @@
-title: $:/changenotes/5.4.0/#8702/impacts/wikitext-palette-entries
-changenote: $:/changenotes/5.4.0/#8702
-created: 20250901000000000
-modified: 20250901000000000
-tags: $:/tags/ImpactNote
-description: Palette entries using wikification will no longer work
-impact-type: deprecation
-
-Before v5.4.0, TiddlyWiki palette entries were interpreted as WikiText, allowing the familiar `<<colour ...>>` macro to be used within them. In fact, these entries can use any valid wikitext, including widgets and conditionals.
-
-From v5.4.0 onwards, palette entries are treated as filter expressions. To improve backwards compatibility there is special handling to transform the `<<colour ...>>` macro into the equivalent filter expression `[tf.colour[...]]`. However, other wikitext constructs are not supported and will not function correctly.
@@ -0,0 +1,11 @@
+title: $:/changenotes/5.5.0/#8702/impacts/wikitext-palette-entries
+changenote: $:/changenotes/5.5.0/#8702
+created: 20250901000000000
+modified: 20260718000000000
+tags: $:/tags/ImpactNote
+description: Palette entries using wikitext other than the `<<colour ...>>` macro will no longer work
+impact-type: deprecation
+
+Before v5.5.0, TiddlyWiki palette entries were interpreted as WikiText. In practice this was almost always used for the familiar `<<colour ...>>` macro, but any valid wikitext could be used, including widgets and conditionals.
+
+From v5.5.0 onwards, palette entries are treated as filter expressions. Entries using the `<<colour ...>>` macro continue to work unchanged: they are automatically transformed into the equivalent filter expression `[tf.colour[...]]`. However, any other wikitext constructs are not supported and will not function correctly.
@@ -0,0 +1,12 @@
+title: $:/changenotes/5.5.0/#8702-changecount
+description: New `changecount` filter operator
+release: 5.5.0
+tags: $:/tags/ChangeNote
+created: 20260718000000000
+modified: 20260718000000000
+change-type: feature
+change-category: filters
+github-links: https://github.com/TiddlyWiki/TiddlyWiki5/pull/8702
+github-contributors: Jermolene
+
+New <<.olink changecount>> filter operator that returns the change count for each tiddler title in the input list. The change count is a counter maintained by the core that is incremented each time a tiddler is modified, making the operator useful for detecting and reacting to changes.
@@ -0,0 +1,21 @@
+title: $:/changenotes/5.5.0/#8702-colour-operators
+description: New filter operators for manipulating colour values
+release: 5.5.0
+tags: $:/tags/ChangeNote
+created: 20260718000000000
+modified: 20260718000000000
+change-type: feature
+change-category: filters
+github-links: https://github.com/TiddlyWiki/TiddlyWiki5/pull/8702
+github-contributors: Jermolene
+
+A suite of new filter operators for manipulating colour values, backed by the [[color.js|https://colorjs.io/]] library, with full support for wide gamut colours (such as Display P3) and the OKLCH colour space:
+
+* <<.olink colour-lighten>> and <<.olink colour-darken>> for lightening and darkening colours
+* <<.olink colour-set-alpha>> for setting the opacity of a colour
+* <<.olink colour-get-oklch>> and <<.olink colour-set-oklch>> for reading and writing the lightness, chroma and hue components of a colour
+* <<.olink colour-contrast>> for measuring the contrast between colours
+* <<.olink colour-best-contrast>> for choosing the colour from a list that gives the best contrast with a target colour
+* <<.olink colour-interpolate>> for blending between two colours
+
+The internal CSS colour parser is now also backed by color.js, allowing modern CSS colour syntax to be used anywhere TiddlyWiki accepts a colour. The legacy `$tw.utils.parseCSSColor` function is retained for backwards compatibility, and continues to return RGB components in the 0-255 range.
@@ -0,0 +1,11 @@
+title: $:/changenotes/5.5.0/#8702-defaultprefix/impacts/multi-value-widgets
+changenote: $:/changenotes/5.5.0/#8702-defaultprefix
+created: 20260718000000000
+modified: 20260718000000000
+tags: $:/tags/ImpactNote
+description: The names and values filters of the multi-value widgets no longer deduplicate their results
+impact-type: compatibility-break
+
+Before v5.5.0, the names and values filters of the multi-value widgets ([[genesis|GenesisWidget]], [[setmultiplevariables|SetMultipleVariablesWidget]], [[action-setmultiplefields|ActionSetMultipleFieldsWidget]] and [[action-sendmessage|ActionSendMessageWidget]]) were evaluated with the usual default filter run prefix, which deduplicates results. A duplicate value would therefore be silently dropped, misaligning the pairing between names and values.
+
+From v5.5.0 onwards, these filters are evaluated with the `all` filter run prefix, so duplicates are preserved and each name is reliably paired with the value at the same position. Filters that relied on the previous deduplication behaviour may now return additional results.
@@ -0,0 +1,14 @@
+title: $:/changenotes/5.5.0/#8702-defaultprefix
+description: New `::defaultprefix` filter pragma
+release: 5.5.0
+tags: $:/tags/ChangeNote
+created: 20260718000000000
+modified: 20260718000000000
+change-type: feature
+change-category: filters
+github-links: https://github.com/TiddlyWiki/TiddlyWiki5/pull/8702
+github-contributors: Jermolene
+
+New `::defaultprefix:<prefixname>` filter pragma that sets the default filter run prefix applied to subsequent runs in the filter that do not specify their own prefix. For example, `::defaultprefix:all` makes unprefixed runs accumulate their results without deduplication, instead of the usual `or` behaviour.
+
+The core uses this mechanism internally so that the multi-value widgets ([[genesis|GenesisWidget]], [[setmultiplevariables|SetMultipleVariablesWidget]], [[action-setmultiplefields|ActionSetMultipleFieldsWidget]] and [[action-sendmessage|ActionSendMessageWidget]]) preserve the positional alignment between the results of their names and values filters.
@@ -1,6 +1,6 @@
-title: $:/changenotes/5.4.0/#8702
-description: Colour handling improvements
-release: 5.4.0
+title: $:/changenotes/5.5.0/#8702
+description: Colour palette improvements
+release: 5.5.0
 tags: $:/tags/ChangeNote
 change-type: enhancement
 change-category: hackability
@@ -17,8 +17,8 @@ There are also new capabilities for palette authors:

 * Inheritance for palettes, making it easy to create chains of variants of a base palette
 * Self contained palettes that can contain both dark and light variants (or variants for any other custom scheme)
+* Automatic readability tests that palettes can use to check colour contrast, with the results shown in the palette chooser

-To make all of these new features possible, this PR also includes some useful new general purpose mechanisms and features:
+Palette entries are now defined as filters that are evaluated, rather than wikitext that is wikified. When switching to a new palette, its colours are compiled to raw CSS colour values in the system tiddler `$:/temp/palette-colours`, which also allows the `<<colour>>` macro to become a function that can be used as the value of a style attribute.

-* Several new filter operators for manipulating colour values. The underlying functionality comes from the [[color.js|https://colorjs.io/]] library
-* New `changecount` filter operator
+The general purpose mechanisms underpinning these features are described in their own change notes: the new colour manipulation filter operators, the new `changecount` filter operator, and the new `::defaultprefix` filter pragma.
@@ -44,6 +44,8 @@ Valid change categories are as follows:
 * ''performance''
 * ''developer''

+Note that it is possible for a single PR to have more than one change note if the PR contains multiple discrete changes. In this case, the PR will be listed in each change note.
+
 ! Impact Notes

 Impact notes describe the impact of a particular change. There can be multiple impact notes for a given change. They comprise the following information: