MS implemented a "contains" CSS selector - Could TW?

Microsoft has apparently realized that it is beneficial with a :contains selector in CSS, for example to do:

<div>done</div>
⦙
div:contains("done") {background:green;}

(Here’s another, real, use case.)

contains is not implemented in standard CSS, but it would be a neat little addition to TW. (Interestingly, it would be the introduction of - not wikitext - but wikicss :wink: )

One additional consideration is if it would enable targeting of widgets? As you know, widgets are “[…] analogous to elements in an HTML document”.

Thoughts?

When TW widgets are rendered, they are pure HTML code. So there is no native way to tell initial HTML code apart from code created with widgets.

The only thing which can be done by widgets is to assign special tc-xxx classes that correspond with the widget that created it. … BUT that’s not really useful since most widgets do that already. eg. the reveal-widget which creates a tc-reveal class. Since there is no additional info and there are so many elements created with reveal that info is more or less useless.

Create a stylesheet with the following code and you’ll see all the elements created by reveal.

.tc-reveal {
  outline: 1px solid blue;
}

On the other hand there are widgets, that don’t create DOM elements like the transclude-widget.

There is a related discussion at GitHub: Plugin sourcing, find out UI element is caused by which plugin/tiddler #6345 where we discuss a possibility to identify DOM elements by eg plugins that created them for debugging. … Not 100% the same topic, but imo closely related

Thanks for the input. What do you think about the main idea in the OP, i.e a :contains selector, like what MS implemented? I read some stackoverflow comment that this is not in the CSS specs because it is too demanding for the browsers, but within a constrained environment like whatever MS uses it for and for, perhaps, TW, it would be useful… “Custom styles by content” :slight_smile:

The problem is, that if we only can create CSS code, that the browser can understand. We can use wikitext to create CSS, but that CSS has to be valid.

At the moment I don’t know a mechanism in the browser, that would allow us to create custom CSS rules. The mechanisms involved are deeply embedded and highly optimized in the browsers “belly”. … So for new CSS rules we would need our own browser.

In the other hand we do already use very similar things with data-attributes for styling. We can use eg: tags for styling like in https://tiddlywiki.com/#Custom%20styles%20by%20data-tags … See the CSS rules at the end of the info, Where it is possible to do “contains” …

[attr*=“value”]
Represents an element with an attribute name of attr and whose value contains at least one occurrence of string “value” as substring.

Not related to the OP, but just out of curiositty. Why can’t we create an own browser (tiddlybrowser or tiddly OS). Something like tiddlydesktop which can work with browser add ons and also working on mobile.

Is it due to lack of fund, human resources and time to maintain it. Or is it due to some technical or security related reasons.

I don’t have much knowledge regarding browsers except for basic usage skill. I am asking just out of curiosity.

Outside of TiddlyWiki, there have long been examples of CSS preprocessors that implement an extended CSS syntax, compiling it down to standard CSS. There’s more info on MDN.

So, I think what you’re asking is whether TiddlyWiki could incorporate a CSS preprocessor.

In fact, it already does: when we choose to process stylesheets as wikitext instead of plain CSS then wiktiext macros can be used to extend CSS. For example, the core uses a macro for CSS box shadows to make it more convenient to assign the cross browser properties in one operation.

The idea of using an extended selector syntax to target widgets instead of DOM nodes doesn’t seem well defend. Given that we cannot assign CSS properties to widgets that do not generate DOM nodes, what would be the value in targeting widgets in this way?

As you note, TiddlyDesktop is already a custom browser for TiddlyWiki. It has additional features that are layered over the top of the integrated instance of Chromium (notably the ability to track the location of files when importing them from the OS). The chief limitation of TiddlyDesktop is that it is restricted to desktop OSs. The nwjs platform that we use has no plans to offer mobile OS support, so for a long time we’ve been on the lookout for a platform along the lines of nwjs that gives us mobile support. At the end of last year I did some investigation of Tauri as a potential platform – see Investigate tauri.app for building an alternative desktop/server GUI · Issue #7110 · Jermolene/TiddlyWiki5 · GitHub for more details.

Can tiddlyclip browser add on work with tiddlydesktop.

I have seen that github discussion last month and it will be good to see if some cross platform solution evolve out of these discussions.

1 Like

Because a modern general purpose browser consists of close to 30 million lines of code if comments are counted and 25 mio without comments.

https://www.openhub.net/p/firefox/analyses/latest/languages_summary

And even if you would use open source components which are called “browser engines” you still would probably need close to 1 mil lines of code for a competitive general purpose browser that lives longer than 2 or 3 years.

I can see two possibilities:

  • TiddlyDesktop could offer a browser bookmarklet that could be dragged to the bookmark bar of other browsers. Clicking the button would establish a network connection to TiddlyDesktop and then push the clipping data about the page to be inserted into the appropriate wiki by TiddlyDesktop
  • TiddlyDesktop’s custom browser could be extended to be used for general purpose browsing. TiddlyDesktop could offer a “clip” button of windows display external links

The trouble with the second approach is that we’re then building a general purpose browser, and we’ve already found that an overwhelming amount of work is required to build a general purpose browser interface that matches Chrome, Safari etc.

As far as I know, the only obstacle to the first approach would be getting the work done.

May be @buggyj can provide his inputs regarding this option. Anyways I am happy using firefox on my desktop to use TW (Except that I am encountering a bug with keyboard navigation plug in by @MaxGyver83 in Firefox)

My point here is that Microsoft apparently have implemented a custom pseudo selector called :content, and which presumably does not require a separate browser (it merely requires a mega corporation with unlimited resources to implement it :wink: ).

data-attributes is not the way because it obviously requires the user to predefine the attribute as opposed to have the styling depend on the content of the tag. For example, how would I colour the background of the cells here by the color given in the cell content:

|red|green|
|green|yellow|

Circling back around to the OP, what Mario writes is exactly what you need:

div[class*=done]

will target all divs with “done” somewhere in the class name. I reckon ID works the same. Microsoft simply made an alias that may be more intuitive to use.

Hm, I think that’s over-generalizing it. I’ll repeat the example that I just posted above: How would I colour the background of the cells here by the color given in the cell content:

|red|green|
|green|yellow|

To preprocess this via some macro that extracts, first the full tiddler text, then the table cell content, etc, is clearly not a viable way. I’m hoping for a direct:

table :contains("red") {background:red}

Imagine this obviously construed case:

text: |{{!!color}}|

Thus, the value in the color field is arbitrary. How do you specify div[class*=???] ?

I don’t really know what this is. Is |{{!!color}}| the text field of some tiddler? So it’s some sort of table? Why?
How would your construed case work with the :contains selector from the OP?
Wouldn’t you be able to use something like div[class*={{{[[Some Tiddler]get[color]}}}] in a stylesheet, just like you would use the colour macro?

1 Like

Hm… OK, beyond that a hypothetical :contains selector would allow the user to more conveniently stick to wikitext when defining the table, which is not possible with your/@pmarios variant, I think you’re right that your variant does cover it. Thanks for making it clear me.

When a tiddlywiki is docked to tiddlyclip a config tiddler is sent from the tw to configure the context menu - it allows a customizable clipping experience. There is actually a conversation between tiddlywikis and tiddlyclip that uses inter-tab messaging provided by the (multitab) browser. This would not be possible with TiddlyDeskTop.

As I told before, I am quite happy using TW in Firefox. I want to use tiddlyclip. This is the major reason for me not trying any other options like chrome or tiddlydesktop.

Sorry for slightly derailing the OP. May be these comments can be cut into a separate thread by the @admins

@twMat You’re linking to an old (defunct?) set of services circa 2019 which were designed to enable automation services (in the Testing realm, I believe).

:contains pseudo class selector was dropped by CSS3.

https://www.w3.org/TR/selectors-3/#content-selectors