Why is "type text/css" needed?

#1

For stylesheets, what would be the drawbacks to always use type: text/vnd.tiddlywiki (be it set explicitly or by default from not setting a type) as is required when a stylesheet has dynamic content in it (e.g macro calls or transclusions)?

#2

I think the main reason is to call it out as just that, a stylesheet. A different view is also presented, and highlight may use this information.

  • Beyond that no idea.

Its true that is suggests a rule that even the core breaks to add tiddlywiki script to stylesheets.

For others passing use of the tag $:/tags/Stylesheet is what nominates a tiddler as a stylesheet to load and Settings > Info > Advanced > Stylesheets allows you to review and even reorder such stylesheets such as is expected with CSS the last definition will win if a CSS statement overrides another (with Last at the bottom)

#3
  1. You need to exlude wiki rules that clash with CSS
  2. For CSS that uses no wikitext, you use a more complex parser with the associated higher overhead for refresh and rendering for no benefit.
#4

But one can transclude stylesheets into <style> tags I believe

#5

Thank you

…via the \rules pragma, right?

  • For CSS that uses no wikitext, you use a more complex parser with the associated higher overhead for refresh and rendering for no benefit.

I suspected this was a main reason. But how much of a deal is it? (Has it ever been investigated?) While such overhead would be avoided with the correct type, I’d still expect a static ss to at least be less burdensome than a dynamic ss for the complex parser, even significantly so, right? Or are there specific constructs in static css that bog down the dynamic parser?

BTW, how much is static css processed by TW at all? I assume the browser does the css processing, only demanding that the ss is properly located/tagged in the document. (And I’m guessing that the parsing TW does is mostly to convert a dynamic ss into static css for the browser - ?)

#6

If you want to use inline transclusions, macro, procedure and function definitions it needs to look like this

\rules only filteredtranscludeinline fnprocdef transcludeinline transcludeblock macrodef macrocallinline macrocallblock
1 Like
#7

Thank you! I note you’re including two more - macrocallblock fnprocdef - than in the docs example.

#8

I think the docs has not been updated to use functions and procedures. IMO the core vanilla/base and co only use macros at the moment.

I am actually not sure, if I got the pragma right for all possibilities. Some experiments would be needed. May be something is missing.

The main problem with CSS definitions is the hash # at the beginning of the line, since it creates an ordered list HTML element, which clashes with CSS ID

The rest of the rules should be OK, But better to be safe. So that’s why \rules only ... is used instead of \rules except list

2 Likes
#9

If you activate Performance Instrumentation in the ControlPanel → Settings tab, and save and reload the wiki, you can see the “styleRefresh” with F12 browser dev-tools, in the Console tab

You can see, that the styleRefresh and mainRefresh are basically done with every key stroke. I think, there is a PR somewhere, that should optimise that but its not merged or still in “draft” mode.

#10

CSS variables also get wikified unless we exclude the dash rule.

#11

It is tricky to draw conclusions from this tool as it changes all the time. I had thought I could get a snapshot measurement with a (static) stylesheet with type: text/css, change it into type: text/vnd.tiddlywiki and get a new snapshot to merely compare them but my interpretation now is that I’d need some kind of average for some longer time of usage. (Or is it this issue that he unresolved PR targets, that you mention @pmario ?)

By the way, in $:/themes/tiddlywiki/snowwhite/base quite a few selector blocks are static, and if we instad look at individual property declarations then the majority have static values. So if type: text/vnd.tiddlywiki does burden the system significantly more than text/css then maybe the static parts of ought to be split out into a separate, static, stylesheet? (…maybe stylesheet tiddlers should have two text fields; one for static and one for dynamic declarations?)

Besides, couldn’t dynamic stylesheets just automatically apply the \rules? … or, even, couldn’t the system just scan any tiddler tagged stylesheet and decide for itself if it is static or dynamic… why do we burden the user with this…? @jeremyruston , or anyone who knows :slight_smile:

#12

Browsers are constantly optimising there code execution internally.

If a code is executed the first it is parsed and executed, which is the slowest execution path.
If code is executed several times, it is converted into an intermediary byte-code, which is more optimised then executing “text”
While executing this byte code internal monitoring can figure out, which code paths are hot. That means, which code is used often.
This code paths can then be converted to machine code using a JIT (just in time) compiler. That’s the fastest, because it directly uses code that the CPU can handle.

That’s the main reason, why the refresh times are so different. On my laptop styleRefresh is in between 9ms to 20ms. So as you wrote in sum it will be an average.

You would need to add a really big stylesheet to see a difference. But if we (the devs) change some low level core code and these values go up drastically, we know there is something wrong.

You do not know what exactly goes on, but it is a good indicator. To get µs level timing the browser dev tools would be needed. But you need to know the core code really well to make sense of those charts.