Just curious;
A tiddler tagged $:/tags/Stylesheet is a wikitext/dynamic stylesheet unless you explicitly set type: text/css so it becomes a static one. Why can’t the tiddlers content just “speak for itself” in this, so the user wouldn’t have to care about anything more than the tag? Do dynamic stylesheets tax the system significantly more than static ones do? (I figure, they can’t be that bad considering that the huge native stylesheets are dynamic)
text/css does not tell the system it should be used as a stylesheet it only tells it to be shown as a CSS tiddler.
Since there is no special view-template text/plain is used instead.
If any tiddler should be used as a stylesheet it needs to be tagged.
Hi @twMat
text/css stylesheet tiddlers are useful to hold static CSS that wasn’t designed to be run through TiddlyWiki’s wikifier.
The reason that text/css tiddlers need to be explicitly tagged as stylesheets is because users might want to have tiddlers containing stylesheet text that is not intended to be used (eg they are writing a book about CSS and they use text/css for the code samples).
Why the text/css type is not added to a tiddler automatically if it is tagged with $:/tags/Stylesheet
It’s possible for tiddlers tagged $:/tags/Stylesheet to use wikitext like macros and transclusion. This is not possible with type text/css
One “benefit” is to disable the wikitext parsing, so the characters : (:before, :after, …) and -- (css variables) are not converted in list and dashes. It’s possible to only disable these characters however with a rule pragma:
\rules except dash list
…and why is being run through the wikifier a problem? (the dynamic stylesheets evdently are run through it). Does it, for example, burden the system significantly in terms of memory consumption?
This is confusing, and seems to contradict what @pmario says (as well as intuition): If tiddlers are “explicitly tagged as stylesheets” it will be interpreted as a (wikitext) stylesheet, AFAIK. …and IF users in deed want stylesheet text to not be “active” as part of e.g a book about CSS, then they should reasonably just type it like any text but perhaps style it differently (and probably not style that whole tiddler, at that).
Spontaneously there seem to be some kind of backward reasoning behind this all. Usually in TW, a system tag is the MO to specify how a tiddler is to be treated by the system.
IMO it would make more sense if the $:/tags/Stylesheet tag automatically took care of that.
No. The problem is that off-the-shelf stylesheets can have constructions that get accidentally recognised as wikitext.
I think you’re saying that you disagree that there are good reasons for having text/css tiddlers that are not being used as stylesheets. There’s not much I can say; to me it would feel self evidently inconsistent to have a special content type behaving like a system tag. I can’t think of another example where the type of a tiddler affects anything other than how it is parsed and therefore rendered.
The recommended approach is to use \rules only filteredtranscludeinline transcludeinline macrodef macrocallinline macrocallblock at the top of a wikitext stylesheet. The core could automatically restrict the rules that are allowed within stylesheets, but there are actually some specialised but reasonable usecases for allowing almost all the wikitext parser rules within a stylesheet (so that one can use wikitext within content: properties for example).
I always wondered why I had to do double work to create stylesheet tiddlers - both tag it and change the type. Now I see that there is a distinction.
One heavy use case of dynamic stylesheet (tagged with $:/tags/Stylesheet and has type: text/vnd.tiddlywiki) is in Tamasha.
One can have several presentations each uses different theme! Themes are mix set of text/css with no $:/tags/Stylesheet and also those stored in text/vnd.tiddlywiki. There is a logic to create a dynamic stylesheet for any presentation separately! The code is enough smart to do not duplicate the same stylesheet if it is in use in more than one presentation.
I think the problem is, that every single use-case mentioned in the examples above and every combination of type and tag settings are valid.
There can be TW use-cases, where the type is text/vnd.tiddlywiki, because we need wikitext features.
There can be use-cases, where we just want to show text/css because we use it for documentation. …
The same tiddler can be used with a transclusion in a tagged wikitext stylesheet that demonstrates the use of exactly that CSS code. … So if the doc code is changed the demo changes automatically. …
IMO That makes much sense, because it avoids duplicated code.
Usually duplicated code causes maintenance trouble, because the docs and the examples can get out of sync. If there is only “one source of truth” those problems can be avoided.
So when the core code was implemented in an “opinionated” way we did run into problems, because users did use every feature in a way we did not anticipate. … So the core usually needs to be as flexible and “forgiving” as possible.
One more usecase.
type=text/css
myStyles.css and myStyles.css.meta
test.html file that is not a TiddlyWiki.myStyles.css with a normal text editor independent of TW.
IMO that’s a big win.
@twMat
What benefit is type:text/css beyond $:/tags/Stylesheet? good Question.
One consideration here is type:text/css is about the mime type and this can have an effect on the the way information is transcluded and or displayed independently from if its css is active in the wiki. See also Typed Blocks in WikiText
For example the following transclusion {{Custom data-styles}} will produce a different result according to the type field, but not if it does or does not have, the stylesheet tag.
Basically the use of the type field has other uses in addition to its overlap with stylesheet use in tiddlywiki.
According to my experience, sometimes both tag and type are required. If type is missing, css will not work, such as an example I encountered recently(Maybe it’s the double dashes that can’t be parsed by wikitext)
.fancybox__container {
--fancybox-thumbs-border-radius: 50%;
--fancybox-thumbs-ratio: 1;
--fancybox-thumbs-width: 50px;
--fancybox-thumbs-height: 50px;
--fancybox-accent-color: #F472B6;
}
The Problem is “they are parsed by wiki text”, thus setting the type to text/css rather than the empty/default text/vnd.tiddlywiki this is not done.