By the way; did I understand it right that your smaller stylesheets are transcluded into a bigger one?
And IF “yes”, then I have two follow up questions:
How do you control the cascade order to control which of .foo {color:red} vs .foo {color:green} “wins”?
…and, more critically, the strategy to transclude stylesheets was used in TWC but not in TW5… for some good reason, which I don’t recall right now… but are you aware of that reason and what are your thoughts about it?
That is correct, yes. The main one, base, has different sub-stylesheets transcluded in it, which also transclude smaller stylesheets into them.
so:
base
desktop
viewTemplate
Tiddlers
and in the tiddlers one, you would have the CSS specifically for the viewtemplate version of each tiddler. I did it in the beginning to make it easier to navigate to the correct area of CSS and also to help in debugging issues I might run into, ie if for some reason I couldn’t see the more button anymore, I could remove the transclusion from the parent tiddler.
But, this was also made when I was having some issues with stylesheets rendering in the wrong order, so I think Eric is correct in that using the stylesheet tag would probably be the better approach.
Though I am curious if that specific dragged order he talked about gets messed up when importing / exporting the stylesheet(s) into other tiddlers. 
TBH, I do not know much about cascades, but it is something I was meaning to look into, but if it works similar to what I was doing with my stylesheet collection, then it would be very useful.
BTW I should have added that I think it is good with new takes on the stylesheets. The current monolith is not a good solution for hackability or even overview.
Whichever styledefinition is processed last wins in a conflict. The $:/tags/Stylesheet dropdown will only show the order of those stylesheets as listed in the list field of that tag tiddler.
cascades
Just so no misunderstanding; we’re here talking about the C in CSS, not the TW mechanism.
Ahh… okay understood. that makes more sense.
Mhm. I often look to core tiddlers such as the vanilla base stylesheet for reusing code and found the way that it is all placed inside it to be a bit difficult to quickly navigate. I think having them excised into indevidual tiddlers as mine does helps with readability, but I imagine it takes up more resources to do so. so, trade offs.
So then yes, you would need to reorder them if you brought the stylesheets over to a new TW. Thats unfortunate :\
I have moved these to its own dedicated thread, so we don’t bloat the announcements thread and take it off topic.
Also, to comment on this, I was not aware of that, but I would like to hear about what the downsides to this approach was, it would be a great learning opprotunity.
Similar to how the tags/Stylesheet tag works in that the further down the tiddler the higher the priority, if I recall correctly. I made most of this on a one week sitting and revisit it periodically, so I may get a detail here or there incorrect. If so, my apologies.
FWIW, here’s how I do CSS/Styles in TiddlyWiki
Firstly, I modified the themes I use: $:/themes/tiddlywiki/vanilla/base and $:/themes/tiddlywiki/snowwhite/base, like so:
With a corresponding } at the bottom of each. Now I rarely ever need to add !important to override TW core styles.
Next, all my CSS tiddlers have a tag $:/.rgt/bk/tag/css
I have one $:/tags/StyleSheet tiddler that transcludes the $:/.rgt/bk/tag/css tiddlers.
<$list filter="[tag[$:/.rgt/bk/tag/css]" ...
Up to now I have never needed to worry about the cascade except for rulesets that need to appear later in the sheet. Those are always obvious “catchall” rules, like display:none rules…
And here’s the DevTools inspector display. Note how my styles appear higher up (as displayed by DevTools) overriding the tiddlywiki-defaults further down.
There’s a lot of cool stuff here, I need to give this a few more rereads, but I will say this is the first time I’ve seen @layer tiddlywiki-default used. I’ll need to look into that, if it works as I think it does.
That, is very nice to know. I am against using !important and hate when I find myself having to use it.
Does this provide any additional functions other than providing a grouping of all the stylesheets you’ve specifically made?
Ah… nevermind haha, this was what I was proposing, however without the addition of the stylesheet tag on each child tiddler, as I was afraid it would cause a sort of ordering conflict with with one should show over the other. I’m assuming that doesn’t happen, so that’s a relief.
Now, correct me if I am wrong but, stylesheets prioritize based on how many lines down the code is, and when viewed in the inspect tool its not bottom to top, but inverse, top is the top priority styles, right?
Also mildly offtopic but, have you experimented with the 3D rendering function in the inspect tool? Just wanted to show it exists for any future readers of this thread, I stumbled upon it on accident but it’s helped with dealing with layered elements like sticky titles.
It’s trivial… it’s tagged $:/tags/StyleSheet and contains…
\rules only commentblock commentinline filteredtranscludeinline transcludeinline fnprocdef macrodef macrocallinline html
\rules except dash
debug {
display:none;
height:0;
width:0;
}
<<build-author-elements-css>>
<$list filter="[tag[$:/.rgt/bk/tag/css]sort[]]">
<$transclude />
</$list>
Notice I even sort[] them (purely for display of the list). It has no impact on the cascade because the rules in the individual tiddlers are written to make sure that doesn’t happen. It’s a “problem” I deal with at rule-composition time. See?
Yes, kinda. Deep dive: Cascade Layers Guide | CSS-Tricks and don’t miss the “More Resources” section.
Oh, ages ago, when Firefox first introduced it. I never even think about it these days.