Applying NOT in custom styles by data-tiddler-title

[Hubert]

Hello,

In reference to custom styles by data-tiddler-title, I would like to make some CSS styling that will be applied everywhere except system tiddlers.

I have the code below, put I would need to flip it to NOT somehow. Would anyone have an idea how this could be done?

[data-tiddler-title^="$:/"] .tc-titlebar h2 {
background: yellow;
}

Thanks,

Hubert

[@TiddlyTweeter]

I don't think that CSS method supports negative regular expressions.

One way to acheive what you want might be to define a global rule and then override it for System Tiddlers ...

.tc-titlebar h2 {

background: yellow;

}

[data-tiddler-title^="$:/"] .tc-titlebar h2 {

background: transparent;

}

This uses the CSS "cascade" to over-write the standard rule for specific cases.

Best wishes

TT 

[Hubert]

Thanks TiddlyTweeter.

The problem I have is that I want to leave the default browser styling for the system tiddlers and only style whatever is a non-system tiddler. I don't know what the default styling is (it most likely differs from browser to browser) and so naturally I don't want to guess and then do it explicitly. I'd rather just leave it as it is by default and only focus on styling non-system tiddlers.

The example I gave with background was just for ease of illustration. What I'm actually trying to do is remove system tiddlers from my heavy styling affecting checkboxes, these affect many cascading attribute selectors etc.

Many thanks,

Hubert

[Sycom]

Hello,

Something like this should work

.tc-tiddler-frame:not([data-tiddler-title^="$:/"]) .tc-titlebar h2 {
   background: yellow;
}

Cheers

Sylvain

@sycom

[Hubert]

Thanks Sycom, I came here just to post my solution (below) but will keep your solution for reference. Thank you!

For the record, I've fixed it with a list filter as found here:

<$list filter="[all[tiddlers]!is[system]]">
[data-tiddler-title^="<$view field=title/>"] CSS {
    something: something;

}

</$list>

Regards,

Hubert

[Hubert]

I meant to say, thank you Sylvain.

Regards,

Hubert

[Sycom]

No offense. I'm both (and also many others ;-)

Regards,

Sylvain

@sycom

[A Gloom]

Hubert,

Ingenious : )  So you're using the list the apply the css to tiddlers en mass (or in batch)? Filing that one in my tiddler of tricks.

[Hubert]

Hi A Gloom,

Yes, that's exactly it.

I should mention that I'm retracting this solution because it does not meet my own requirement to have my wiki optimized for speed on mobile (where having non-system tiddlers free from expensive filters is one prerequisite). Not a problem at all on desktops/laptops.

Thanks,

Hubert

[PMario]

Hi Hubert,

I did see your "chosen" solution, which seems to be a bit of an overkill, since it creates a lot of CSS rules.

I think the following may be much easier:

.tc-title {
  background: yellow;
}

.tc-tiddler-system .tc-title {
  background: initial;
}

System tiddlers (prefixed $:/) do have a class definition on the "tiddler" level. ... tc-tiddler-system

So if you style tc-title for every tiddler, you can reset it back for system tiddlers with the code above, using CSS hirarchy.

have fun!

mario

[Hubert]

This! Thank you so much Mario. It works as advertised and is probably the cleanest solution for my use case.

Thanks again.

Best regards,

Hubert

[A Gloom]

Hubert

I should mention that I'm retracting this solution because it does not meet my own requirement to have my wiki optimized for speed on mobile (where having non-system tiddlers free from expensive filters is one prerequisite). Not a problem at all on desktops/laptops.

I was wondering about suxh a massive list.  I'm overhauling the utilities section of my first wiki, paying particular attention to streamlining all the massive lists I ended up with after the wiki grew to over 1600 content tiddlers.  I'm looking at having lists "activated" on demand with a button rather than constant with the list widget alone.

[PMario]

The DOM structure of a list is only created, if the tiddler that contains the list is shown. ... The only problem with long lists may be in the sidebar.

-m

[PMario]

On Tuesday, October 22, 2019 at 1:04:52 PM UTC+2, Hubert wrote:

This! Thank you so much Mario. It works as advertised and is probably the cleanest solution for my use case.

Thanks again.

You are welcome :)

-m

[A Gloom]

I was wondering about suxh a massive list.  I'm overhauling the utilities section of my first wiki, paying particular attention to streamlining all the massive lists I ended up with after the wiki grew to over 1600 content tiddlers.  I'm looking at having lists "activated" on demand with a button rather than constant with the list widget alone.

The DOM structure of a list is only created, if the tiddler that contains the list is shown. ... The only problem with long lists may be in the sidebar.

Thank you kindly, your answers are always appreciated.  I was afraid I was going overboard with my lists and the twenty column sortable tables (actually 10 but I put 2 separate field values in each column).

I broke up my ToC's into several tabs 'cause they were getting unwieldy-- the long sidebar lists problem would be their length or performance issue?

I was at your site Gitmemory, and couldn't find your TocP macro : (

[PMario]

On Wednesday, October 23, 2019 at 11:06:14 AM UTC+2, A Gloom wrote:

I was at your site Gitmemory, and couldn't find your TocP macro : (

my plugins are listed at https://wikilabs.github.io/

-m

[PMario]

On Wednesday, October 23, 2019 at 11:06:14 AM UTC+2, A Gloom wrote:

...

I broke up my ToC's into several tabs 'cause they were getting unwieldy-- the long sidebar lists problem would be their length or performance issue?

It's the long lists that may make problems. ... HTML performance problems start with lists >1000 (especially on mobile), if they have to be redrawn.

So a limit[250] filter may be an option. BUT there should be a button below the list with eg: "Show Full List", which opens a full list in the story river.

-mario

[A Gloom]

It's the long lists that may make problems. ... HTML performance problems start with lists >1000 (especially on mobile), if they have to be redrawn.

So a limit[250] filter may be an option. BUT there should be a button below the list with eg: "Show Full List", which opens a full list in the story river.

Yep, it was involving over 1000 toc entries-- I didn't know of the hrml issue-- would multiple toc macros in a sidebar tab (another trick I use, to break a larger toc list into "sections") also fall under this (all section list entries summed as one) or be considered individually?

[PMario]

Hi,

The TOC macros use the reveal-widget. This widget has a parameter named: retain. This parameter defines, if "invisible" elements are kept and updated in the DOM. The default value is no.

So elements in a hidden branch in a TOC won't cause any performance issues. Only visible elements do.

-m

[A Gloom]

most exclellant!  Your answers are greatly appreciated : )  Sorry Hubert for taking over your post-- hopefully this info about ToC's will be helpful to others cause I'm sure others have had the ToC overpopulation issue.

[Hubert]

Sorry Hubert for taking over your post

Not a problem for me! I'm getting tremendous value from the info here as well :)

Regards,

Hubert