What's the issue with IDs again?

Mat

unread,

Jul 2, 2021, 12:56:58 PM7/2/21

to TiddlyWiki

In HTML one can apply an ID attribute to objects. I know this is not possible in TW... but I don't get why. Can someone explain why this is not possible or not appropriate, please.

I have some ideas but need to understand this issue before going further.

Thanx

<:-)

PMario

unread,

Jul 2, 2021, 7:04:37 PM7/2/21

to TiddlyWiki

On Friday, July 2, 2021 at 6:56:58 PM UTC+2 Mat wrote:

In HTML one can apply an ID attribute to objects. I know this is not possible in TW... but I don't get why. Can someone explain why this is not possible or not appropriate, please.

Hi Mat,

It is possible to use IDs with TW. ... BUT it won't be reliable. ...

HTML element IDs are per definition unique. But with TW can't guarantee this uniqueness since we have transclusions. So in the TW story-river it can happen that an ID is visible 2 or more times.

The CSS definitions will most likely work. BUT depending on the browser implementation we can not guarantee a consistent behaviour for all elements.

Have a look at this jsFiddle: https://jsfiddle.net/fLcdq7ut/17/

The HTML code is like this:

<html>
<head>
<title>getElementById example</title>
</head>
<body>
<p id="para">Some ID text here</p>
<p class="para">Some classed text here</p>

<button onclick="changeColor('blue');">blue</button>
<button onclick="changeColor('red');">red</button>

<p id="para">Some ID text here</p>
<p class="para">Some classed text here</p></body>
</html>

The JS code is like this:

function changeColor(newColor) {
var elem = document.getElementById('para');
elem.style.color = newColor;

var elements = document.getElementsByClassName('para');
for (var i=0; i<elements.length; i++) {
elements[i].style.color = newColor;
}
}

If you click the buttons you see, that the ID elements are not updated both. It's only the first one, since the function document.getElementById() assumes there is only 1 of them. ... By definition it will return the first element it finds in the DOM tree.

document.getElementsByClassName() knows there can be many elements with the same class name and it will return an array, so we can use a loop to define the new color.

This is only a fast example, to show the differences in a way that should be understandable. .. It would be possible to add a class to the IDs too, to get them with the class name. ... BUT this would only solve this particular usecase.

The browser assumes there is only 1 ID active at a time. So we just don't know, what happens internally. We can't reliably guarantee that everything works as expected.

hope that helps

mario

Mat

unread,

Jul 2, 2021, 7:55:09 PM7/2/21

to TiddlyWiki

Much appreciated Mario. What a great reply! (did you even create that example? Just for me???)

So does the "ID issue" for "elements" only concern HTML elements then? I just posted an idea on gh:

https://github.com/Jermolene/TiddlyWiki5/discussions/5844

<:-)

TW Tones

unread,

Jul 4, 2021, 7:41:45 AM7/4/21

to TiddlyWiki

MArt,

With my recently developed use of arbitrary html tags for more sliders I needed to make use of an ID, Which I pass to A macro to toggle the state (via CSS). I have some possible approach's

Let the author take control of the uniqueness, easy as below methods
Use a functional prefix like m1 or more1
- Create a custom list in reverse order so it is easy to see the next available, do this by searching for and possibly detecting reuse.
Since the current tiddler is a unique key use it or a uniquid issued on demand to prefix the id name with the current tiddler.
- Then with the the suffix you use you need only ensure uniqueness within the tiddler and for the ID, and this is a logical necessity.
Build a editor too bar to add content that requires a unique ID and determine the next unique number as you do so.
Also you can use a class on one or more tiddlers, and manipulating their css will affect all tiddler with the same class, but that may not be an issue.

By the way this only arises because html is designed effectively for a page at a time, even a "whole document" at a time, yet tiddlywiki is a single html "document" but our documents are tiddlers and we can have an unlimited number of them at a time, on the screen at the same time.

I have not tested it but what happens when you use duplicate ID's?, nothing if the tiddler is not open?

Your idea was deleted?

Tones

clutterstack

unread,

Jul 5, 2021, 12:04:14 PM7/5/21

to TiddlyWiki

I'm going to admit I'm missing something, too. I'm not certain whether there's a technical factor that makes ids worse in TW than in HTML, or if it's just the distinction between an HTML developer (who can easily put duplicate ids into a page) and a TW user that makes them too dangerous (e.g. making id a widget attribute would introduce problems for adopters and thus for the community trying to support them).

Once you're writing macros using qualify etc., because you need some unique identifier for the code to work, then you get the responsibility for the edge cases.

I'm fuzzy on whether there's an intractable technical problem that prevents, for example, a widget for an HTML datalist tag, using qualify to get a unique id. I have to admit I haven't explored it, but I haven't thought of a reason why it couldn't work -- just that if you put that widget in twice in a row with the same attribute values, you would get two elements with the same id, so if policy is that a widget should not allow a user to do that, then...but even then, surely there's technically a way to generate a unique id for each instance?

I admit it gets messy (have to be able to keep track of and refer to that id), and the more complicated it gets, the more attractive other complicated-seeming solutions become (thinking about keyboard-driven-input).

So, those are my thoughts today on that topic! Ha. I have been wondering. I'm more satisfied now that I've thought it through, but still curious about further insights.

Best,

Chris

TW Tones

unread,

Jul 5, 2021, 6:33:13 PM7/5/21

to TiddlyWiki

Chris,

One thing I have observed with issues such as this, is too many people look for "one size fits all" to the detriment of finding a good enough solution. In my last post I hit at a number of good enough solutions for many different cases.

Perhaps the simplest method is to break the content into separate tiddlers, and use the tiddler title as the id (maybe with slugify), and have only one id per tiddler. then there will be no non unique ID's.

Also as I pointed out you could use a class, which can be non-unique, however you try to keep them unique.

In a separate issue I created a solution where at a click, a tiddler was issued a unique serial number (wiki scope), the thing is only some tiddlers need a unique identifier and it can be obvious when this is necessary. If you are concerned about this not being unique when installing in another wiki, you can design an export or import method that clears and reissues the unique ID.

There many solutions and multiple work around available in TiddlyWiki.

Tones

TiddlyTweeter

unread,

Jul 6, 2021, 5:17:51 AM7/6/21

to TiddlyWiki

Ciao PMario

I wanted to join Mat in saying that is a great reply. Very clarifying.

For my own usage I would comment I have used IDs successfully BUT I do it within a single tiddler with transclusions where I want simple in Tiddler navigation.

I always use unique IDs.

The use case is an obvious one. Say you reference a (transcluded) footnote. You want to jump to the footnote on click and from the footnote jump back to where you were. Simple example that of "reciprocal links". The "data design" here is almost trivially easy. No issues in TW for me with it.