How to use the colour macro as an attribute value

Tips & Tricks
, ,
#15

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}}
2 Likes
#16

“==” 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

1 Like
#17

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!

#18

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).

#19

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. :sweat_smile:

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.

4 Likes
#20

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.

1 Like
#21

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!

1 Like
#22

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

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:

380087836-549bfa8c-f7af-4cf7-beb5-94a1826ca0f7
380087836-549bfa8c-f7af-4cf7-beb5-94a1826ca0f71920×1882 314 KB

4 Likes
#23

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?

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

2 Likes
#24

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.

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.

1 Like
#25

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

#26

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.)

2 Likes
Should palettes help with html details?
#27

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

1 Like
#28

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.

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.

image
image1199×676 53.6 KB

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:

image
image1199×676 53.6 KB

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

#29

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?

#30

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.

1 Like
#31

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

#32

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.

#33

perhaps i missed a development somewhere, but is there a strong case for/against the wikify[] filter operator that was brought up above? that seems very natural for tw syntax and would be nice to use in cases where you want to parse tiddler text fields in larger filters, whether or not the == syntax is also implemented.

#34

I updated the description of the pull request to clarify some of the issues:

  • The performance issues arise from the fact that the wikify operator does not allow us to use the usual mechanism for caching parsed tiddlers. This means that to evaluate the operator always requires a full parse of the input text as well as the construction of a widget tree (which would always be required, even if caching were to be implemented somehow)
  • The issue with dangerous patterns is that users might be tempted to replace complex filters with a wikitext equivalent, for example using the <$list> widget to generate a set of numbers instead of the [range[]] operator. Besides being horribly inefficient, there are pitfalls with unexpected wikification
1 Like