Eek! Wouldn’t that make it impossible to use an HTML element like <button>, as it’d be parsed as a button widget? This seems like a slippery and possibly dangerous slope… Off the top of my head, I can’t say I’ve definitely used <<p>> as a custom procedure or variable, but I also can’t say I haven’t, because TW5 makes it completely safe to do so — and I think this is a strength!
As @pmario said, it’s already tedious enough that core functions/procedures need to add prefixes like tf. to avoid potential collisions with user-defined variables. I think this issue would get exponentially worse if we also had to avoid collisions with plain HTML. And then I’d need to use my.p for my hypothetical variable, or risk replacing every paragraph tag…
Not really … But then again it’s impossible now to use <script> tag but its understandable as to why for security protection…
And <$button> is already a well endowned wrapper for the html <button>… if you really needed a HTML button then you could write a custom widget for it with a new variant of <$genesis> that gave it to you. Or you could use the HTML content type for your tiddler
Not sure the overlap between widgets and html is that big - nor how much demand there is for the original html elements within wikitext ?
Also - no reason why the original syntax has to go - keep using <<p>> or <$p>
I have never come across that in core procedures - not that i use many core procedures beyond tabs, tree, … but surely the onus is on the user to define variables with a unique namespace where it is needed - not the core…
I wasn’t expressing a preference on that front; I was pointing out that this is already the current policy.
You’re right, the <<tabs>> macro doesn’t follow this convention. And, not unrelatedly, more than once I’ve defined a variable <<tabs>> for a given context and then had to work out why the tabs macro wasn’t working…
Quite a lot, in my experience — and I’m actually speaking less of myself than of novice/intermediate users whose wikis I’ve looked at. A number of people come to TW with a specific visual layout already in mind (MediaWiki lookalikes seem to be one common goal) and it’s difficult to achieve complex layouts with HTML, and doubly difficult if you limit yourself to wikitext. If you’re new to TW syntax but already familiar with HTML, why wouldn’t you use what you know?
My point was that if you adopted <widget> syntax as the default, with user/core widgets taking precedent over HTML in case of collision, a widget <p> would replace every instance of the HTML tag <p> in its scope, so the paragraph element would become unusable.
You are right. That’s intentional for security reasons.
The idea in the core is, that it should “go out of the users way”. So for many things, like templates, in the core we use longer and verbose names, to make users live easier.
Yea, for early macros and also some that often have to be written by users, convenience wins. There are a lot of inconsistencies in the core. Mainly because it did organically grow.
New features are only added, if we either use them in the core, or if they are necessary, to make advanced functions usable for plugins.
Because HTML alone has no “local interactivity” built in. Pure HTML forms want to send something to the server, so the server can do something with the input data. But TW is a stand alone app.
There is a reason, why we have react-js and angular-js (V1) to create interactive UIs. They also started at almost the same time as TiddlyWiki.
The big difference is, that the TW “framework” gives “normal” end users the ability to create bidirectional interactive UI.
React and angular target developers and need a full development environment. They are more popular, since they are financially backed by huge companies like Meta and Google.
Angular V1 is unsupported since 2022. TiddlyWiki wikitext is still “healthy”.
Absolutely! I was probably unclear: I meant that users may want to mix HTML and wikitext, and so it strikes me as a mistake to deliberately introduce naming collisions.
While a plain <...> might seem nice, it is hardly reasonalbe considering how arbitrary custom html elements are fully possible since a few years (e.g <yeehaw>). But I think <<...>> would be perfect because, in addition to simple to type, it also very much suggests that it is related to html. A kind of “next level” html.
Apropos the <$ prefix; I recall Jeremy stating that it was intentionally chosen to be a bit intimidating, as in “warning - here be dragons”.
That may be true. At the beginning (2013) we thought widgets would be mainly used by developers to create specific macros for different usecases. So macros would be the main interaction elements for end-users.
But it became clear very fast, that core devs can not maintain all the user specific macros. It was much easier to explain how widgets work. So end users could create their own macros using widgets as building blocks.
Creating reliable and future-proof macros needs planing and also needs maintenance. So for many users it is less work, to directly use the widgets and skip the “macro abstraction” layer.
Also for many very specific usecases at the very beginning it is not entirely clear, what you really need. It often needs several iterations and some refactoring, until it becomes clear how a macro should look like. So – In the meantime “low level” widgets have to be used to create the functionality, that is needed.
