I would say they could be good friends without public legitimation of their relationship.
Love,
Thomas
It seems you use <pre> html-tag in your stylesheet tiddlers. It should not be done that way. Starting with TW 5.2.2 you can use the field code-body: yes.
There are very high chances, that a stylesheet gets broken, if it contains invalid CSS code. Browsers are very sensitive to invalid CSS syntax and stop processing the rest of the tiddler. This can cause hard to find problems.
3 Likes
I did play with the plugin and clicked the delete button next to the CSS code field. … It seems the configuration is gone without any notification. 
Why is the button even there? I think I would prefer a link button that opens the “linked” tiddler. I can still delete it in the normal way if I need to.
2 Likes
I think there is 1 major problem with this type of editing the CSS code this way.
If a stylesheet can be opened and modified within the tiddler, it suggests, that the CSS code is related to that tiddler.
But that isn’t the case. The CSS code is still global – right?.
So if a user changes the code that it fits the current tiddler, it’s very likely that this change has side effects to other tiddlers, that the user doesn’t even know of.
May be it changes some styles that are used by eg: the “More : Tags” sidebar, which the user hasn’t even seen yet. …
Changes are made and several month later the “More : Tags” sidebar is broken. … Nobody knows why…
The result will be help requests here or at GG with broken TiddlyWiki core functions. Even worse if github bugs will be filed and core devs have to deal with them… These problems will be extremely time consuming to be found.
2 Likes
Ah… but will code-body:yes not make everything look as code? For example the first half of the stylesheet that merely lists tiddler titles? And can I still include wikitext stuff like buttons?
Hm, your second half of the comment indicates that you think it is a tiddler being deleted but it is not, it is just a field (likely named the same as a tiddler) inside the special stylesheet. So it doesn’t really make sense to link to the stylesheet and I guess a notification could be introduced but I’d say this is more expected if it actually was a tiddler.
Ah, I see. Then that confused the model (for me). I was led to believe (mistakenly) it was happening at the tiddler itself.
EDIT: confuses ==> confused
Yeah, just like “all” stylesheets, it is global. There is a “relation” between the field and a tiddler in the sense that the field was likely created via the tiddler with that name. This is useful to know because any style definitions in it are likely used in that tiddler, so if you modify them then you have reason to expect consequences there, and possibly elsewhere. But this is the nature of CSS and of making changes to styles. Sure, it would be possible to “block” the use from modifying styles via the editor… but with that reasoning we should also block users from modifying any stylesheet.
The stylefields editor is mostly a shortcut to create or access stylesheets. But it allows access both to full stylesheets (tagged $:/tags/Stylefield) and to a type of “sub stylesheet” (i.e the field in the special stylesheet) that are likely more closely related to individual tiddlers. My guess is that these “sub stylesheets” typically contain only a few style definitions since they are tiddler specific (at least initially), and it would be overkill to make them into full tiddlers full tiddlers, even if that would be fully possible.
I welcome all better ideas for how to access styling and to avoid fighting the monolith.
I’ve kept repeating everywhere that “actually, what you edit is a field in a special stylesheet”. Not sure how else to put it.
The point with this is:
-
It collects all styling in one actual (albeit unusual) stylesheet. If you tire of it, it is simple to delete the special stylesheet in one go. Or to drag it into another TW of yours to copy it.
-
My initial thought was actually to put the field inside the individual tiddlers but this was objected to by Jeremy exactly because IF it was to be reused for other tiddlers then there was no longer a 1:1 mapping. That made sense, so I decided to externalize the fields from the individual tiddlers and into the stylesheet. Now, these fields still needed a name… so I reason that it makes sense to name them like where they are most likely used, i.e the same as the tiddler where it was likely spawned. The field name is a clear indication of a “major” place where the styles are used, but there can also be other places, just like with all CSS.
1 Like
I don’t think this is fair. “Broken core functions” - how? From fooling around with some styling? Currently, the reason why we don’t have much CSS questions is because native TW doesn’t encourage style fiddling. It is too inaccessible and difficult.
But, again, please do come with better solutions for how to handle styling.
That’s fair, now I understand it better.
LOL. Touché 
OK … I think I didn’t catch the concept behind it. … Digging deeper into the modified tiddlers, I think I do get it now. …
There are some elegant ideas in it. … but I do have trouble with some tiddler naming conventions and mixing UI and storage tiddlers. …
Do you have a github repo, where we can discuss dev-related issues. I think they shouldn’t hijack this “presentation” related thread.
1 Like
That’s encouraging to hear. I’d love to discuss what can be improved but I’m afraid real gh use there, to actually work with code etc, is beyond me. Or do you only mean discussion? Then anywhere should be fine (here, email, or wherever you prefer).
1 Like
As a witness to you and @twMat debating I want to comment that it is interesting & informative! Whether @twMat is 100% kosher is I think, ultimately, subsidiary.
IMO what he is trying to do with this tool will help better practical understanding of TW CSS.
At the moment we actually have a rather, rather good “Vanilla” monolith. It is logical (very) and quite beautiful in it’s details. But, as often commented, it is a “monolith” … In the end we do need pragmatic tools to liberate layout.
Side note
TT
I don’t know if I understand how Stylefield works. But I like the idea.
I agree with you, a big and monolitihic CSS is laberinthic. You have done great work spliting the CSS.
There is something that I don’t understand. When, in the demo, I create a new tiddler I always have the selector and search for the stylefield, where you can edit/delete stylefield. So we have a manager for stylefield in every tiddler. Why not create a Style Manager? Something like looks your $:/plugins/TWaddle/Stylefields/main but without put it inside of edit template.
1 Like
Hi Alvaro. Did you see the main stylesheet? You find it in one of the plugin tabs and also under e.g Controlpanel > Appearance > Stylefields
You can edit stylefields in that special stylesheet also, and it lists all separate stylesheets that are tagged with $:/tags/Stylefield
If you don’t mean this, then what functionality is missing from this?
Yes I did. But I focused in the other tiddler because it has the basics structure for a manager and the functionality edit/remove styles easily. It is true that a visible list is more usable than a select element with “hidden” list.
But IMHO, the select, the search and a (extra) editor in the edit template can be confuse. I think that it is better if we have the full functionality in the same place. It is the reason why I talk about a Style manager (where you can search and edit them)
Displaying CSS in Tiddlywiki ( side note )
Hi @twMat
I know @telumire has nice stuff to display the stylesheets and CSS!
Have a look at:
I wish we could have it into the core! Specially when your stylesheet tiddler which is not text/css and you use macros, transclusion, datauri (for images for example) in your CSS.
2 Likes