How to use the colour macro as an attribute value

[jeremyruston]

@jeremyruston

Perhaps triple single quotes are a bit hard to read, but they would be unlikely to appear in existing wikis.

I just realised that we should be able to apply wikification to attributes that are specified as transclusions of variables or tiddlers (ie attr=<<mything>> or attr={{anotherthing}}.

So, rather then being triggered by a new type of quotation, it occurs to me that we might use a double equals sign to indicate wikification. For example:

<$let
   a=="The time is <<now>>"
   b==<<colour foreground>>
   c=={{MyToolTip}}

This approach would allow us to apply separate optimisations to each type of wikification, in particular we would be able to take advantage of the cached parse tree when transcoding variables or tiddlers.

[Springer]

@jeremyruston

we might use a double equals sign to indicate wikification

This strikes me as brilliant!

Just yesterday I was running into trouble getting the action-confirm widget to display the intended message, and wished for a simpler way to pass along the same string that had been working perfectly well when it was simply displaying in its own div.

Would this == solution be broadly available to widget attributes, etc.? If so, this would be revolutionary! (And would deserve not to be tucked into a thread about the colour macro!)

[CodaCoder]

Are we truly happy about == ?

There is a ton of prior art (baggage) where that means “equivalency”.

I just wonder how much of a stumbling point (reading code, I mean) this might be.

We have = for assignment.
We have : for assignment of defaults.
Do we need another type?

Might we consider a boolean attribute? (Although, in a multi-assignment <$let> that would not work.)

<$let wikify a="The time is <<now>>"/>
<$let wikify b=<<colour foreground>> />
<$let wikify c={{MyToolTip}} />

Or  :=  (“becomes”)

<$let
   a:="The time is <<now>>"
   b:=<<colour foreground>>
   c:={{MyToolTip}}

[buggyj]

“==” is used as comparison in many programming languages, and therefore may confuse people (or bots)

I like ‘:=’ as this is used as assignment in some languages (eg pascal) as suggest by CodaCoder Talk TW - Community discussion forum about TiddlyWiki

[Mohammad]

More grammar makes things more complicated. Should we concatenate strings and variables like "Time is <<now>>"?
I think we have a lot of rules and grammar now!

[CodaCoder]

@Mohammad

More grammar makes things more complicated.

How so? Adding more doesn’t mean complicated. The growth/improvement of the grammar is a necessity assuming we want the language to become more expressive.

It may not be pretty, but I really like @bluepenguindeveloper’s idea: x=w"to-be-wikified-stuff". But I think  :=  is less of a shift in semantics (and bit more natural).

[bluepenguindeveloper]

Earlier I was going to say that one advantage := has over a w prefix is that the former can be used on non-literal attributes (attr:={{somethingTranscluded}}). But then I realized that that’s not strictly true; <<>> or {{}} with w is just as much of a possibility as prefixing quotes with w. (attr=w{{somethingTranscluded}}).

But you’re right, it sure isn’t pretty.

Semantically, I think what we’re doing isn’t a different kind of assignment; it is assigning a different value, namely, the result of wikification; thus, I could see an argument from semantics for doing something to the attribute value (a prefix or surrounding it with something) rather than doing something to the = sign (a double == or := etc.). Ideas would include parentheses, slashes or backslashes, or some symbol for a prefix other than w (maybe $ or ! or \).

But personally, I think changing the equals sign to := or == to indicate wikification simply makes for cleaner code, and even == (despite its meaning in other languages) would be far from the worst abuse of notation in my opinion.

[jeremyruston]

I think the “w” prefix is ugly and not consistent with TiddlyWiki’s use of symbols vs. letters elsewhere.

I like that == feels like a more intense version of =. I can see the argument for :=but I think the resemblance to other programming languages is unhelpful.

I don’t think we should shape the wikitext syntax to meet the expectations of experienced software developers. In any case, arguably using := does them a disservice because any prior understanding of the distinction between := and = will not apply here.

If we are going to consider the needs of experienced software developers, it makes sense to work on the assumption that they are smart. Such a developer encountering == in an assignment context can be assumed to realise fairly swiftly that this cannot be a comparison.

[Springer]

@jeremyruston

I like that == feels like a more intense version of =.

As someone who has often struggled with having pasted some value in as an attribute or parameter, not noticing the presence of internal wiki-dependent stuff (and then being flummoxed about how to get things to appear as intended), I suspect that the == notation would feel very friendly to exactly the people who can be thrown off by the current behavior.

It reads to me like “Please make this attribute/parameter equal what this upcoming thing equals (i.e., how the following string would get parsed if it were encountered in a tiddler).” This feels quite elegant to me!

[jeremyruston]

I’ve been working on a PR that fixes usage of the colour macro as a style attribute, amongst other things:

Colour handling improvements

The PR does not implement the triple equals sign for wikification idea suggested above. Instead, it uses a simple “wikify” operator.

One of the other things that the PR does is implement full previews in the palette picker:

[Scott_Sauyet]

@jeremyruston

I’ve been working on a PR that fixes usage of the colour macro as a style attribute,

This is very exciting. Is there any chance this could help move us toward including something like the Captivate theme in the core, or even tools like ColorAction?

@jeremyruston

One of the other things that the PR does is implement full previews in the palette picker:

That means I can stop worrying about trying to accomplish an SVG preview!

[jeremyruston]

@Scott_Sauyet

This is very exciting. Is there any chance this could help move us toward including something like the Captivate theme in the core, or even tools like ColorAction ?

Yes. It will be possible to construct palettes that have a small number of base colours defined as RGB, with all the other colours derived from those base colours using colour operations like lighten, darken, saturate, etc. The underlying color.js library offers a wide range of features, including support for P3 colours and OKLCH.

@Scott_Sauyet

That means I can stop worrying about trying to accomplish an SVG preview!

Thank you for reminding me, that was an interesting experiment, and a great thread. I added the thread to the references in the PR. I had originally expected to use SVG for the previews, and then even when I started experimenting with HTML I was expecting to have to use CSS transforms to scale the previews.

[Euthymious]

@jeremyruston

implement full previews in the palette picker:

The preview would be even more useful if it included more elements: links, quotes, tabs (in tiddlers and in sidebar), alerts etc.

[Springer]

@jeremyruston

One of the other things that the PR does is implement full previews in the palette picker:

@Euthymious

The preview would be even more useful if it included more elements: links, quotes, tabs (in tiddlers and in sidebar), alerts etc.

It’s an interesting question what to include!

Different users make serious use of different aspects of the interface: alerts, blockquotes, tabs, pre- [code] formatting, message boxes, modals, tooltips, diff comparisons, dropdowns, tags, tables… For any user who really leverages these, there are others for whom a preview of these would be clutter and cruft.

It would be awesome if the preview were itself somewhat configurable. (Maybe it is — I haven’t peeked under the hood.)

[pmario]

@Euthymious

The preview would be even more useful if it included more elements: links, quotes, tabs (in tiddlers and in sidebar), alerts etc.

You should have a closer look at my Palette Manager edition and plugin: Palette Manager — Preview

[Scott_Sauyet]

@pmario

You should have a closer look at my Palette Manager edition and plugin

I think think these comments were about the screenshots of different themes in Jeremy’s message above. Does your palette manager give those? I didn’t see them. No critique here; it’s a wonderful tool, but I would love to have these quick screenshots available when selecting palettes. Also when creating them.

@Springer

@Euthymious

The preview would be even more useful if it included more elements: links, quotes, tabs (in tiddlers and in sidebar), alerts etc.

It’s an interesting question what to include!

Different users make serious use of different aspects of the interface: alerts, blockquotes, tabs, pre- [code] formatting, message boxes, modals, tooltips, diff comparisons, dropdowns, tags, tables… For any user who really leverages these, there are others for whom a preview of these would be clutter and cruft.

I’d be happy if there was a significantly more complex document previewed. But it’s unquestionable that there are far too many features that could be demoed for any static preview document to capture everything a user might care about. I don’t think that’s the point, though. It’s easy enough to test switching palettes when they’re all included in your current document. And it’s simple enough to import one for testing.

When I tried working on a similar idea earlier, I was aiming at this screenshot as my goal; it captures much, and can easily have alerts and notifications added.

But when I scale it down to something like preview size, it no longer seems very useful. I’d have to see it alongside other previews to be sure; as the differences between them are probably most relevant, but at a first impression, this is not great:

Still, I still would like to see at least some additional sophistication. I just down know what the appropriate balance would be…

[Springer]

@Scott_Sauyet

there are far too many features that could be demoed for any static preview document to capture everything a user might care about.

Too many important features exist, such that no single static preview can capture what “any user” cares about — but that doesn’t mean the code couldn’t help each of us capture, in a thumbnail, the central bits that matter to us… This is why I’d love for user herself to be able to choose a preferred preview… I might prefer to glance over a set of mockups that foregrounds tables, alerts, and tabs; someone else might want to glance at a set of a mock-ups that foregrounds edit view background, tags, link colors, and buttons (etc.).

In the preview above it seems at least one tiddler-worth of space is wasted; there are two mock tiddlers with titles and viewbar buttons, but no glimpse of sidebar tabs, tables in story river, or link coloration. It’s definitely a good start, much better than choosing only a name with a row of colored boxes!..

Still, whatever the tools are that yield the set of thumbnails above, I’d love to see end-users able to choose among a few templates for the thumbnails…

More boldly — leveraging something like the demo of custom story view mini-tiddlers here — shouldn’t it be possible, in theory, to specify, dynamically, a particular actual tiddler or two to be rendered across an array of palette thumbnails?

[pmario]

@Springer

More boldly — leveraging something like the demo of custom story view mini-tiddlers here — shouldn’t it be possible, in theory, to specify, dynamically, a particular actual tiddler or two to be rendered across an array of palette thumbnails?

I think it should be possible to create “real working tiddler” thumbnail, using a new template for the testcase-widget. Those thumbnails could even be interactive if we want to.

[CodaCoder]

@pmario

I think it should be possible to create “real working tiddler” thumbnail,

What you really need is this. But it’s not ready for prime-time yet. Check the browser support.

[jeremyruston]

There are two approaches to gaining more detailed/accurate previews:

• Continue to extend the simplified plain HTML representation of the page. As @Springer suggests, the implementation could be extensible so that plugins could add their own preview elements, and there’s no reason in principle why we couldn’t get as close to a live preview as we wanted. This approach essentially duplicates simplified versions of the templates used for TW’s normal rendering, giving us a high degree of control over how the previews are generated
• Somehow shrink and re-use the existing page templates for the preview. This would allow a full-fidelity preview

However, there are significant barriers to reusing the existing page templates in this way.

The primary one is that the preview would need to be contained in an iframe. Otherwise “position: fixed” elements in the preview will be fixed to the browser window rather than the preview. Depending on the content, iframes take up a lot of browser memory and other resources. In this case, the iframe will be containing a copy of the output of TiddlyWiki, not a fully running TiddlyWiki, but still the overhead is significant.

A related issue is that the page templates include a lot of material that isn’t needed in the preview: dropzones, keyboard and click handlers etc.

Like @Scott_Sauyet I think that the previews here actually work better if we think of them as stylised images that have been semantically zoomed so that the important details are easily visible, and unimportant details are suppressed entirely. I think a photographic reduction of the page ends up being overloaded with distracting detail.