Propositions to empower css mods:

@tienson here’s some suggestions to make css more powerful in logseq.

use-cases and benefits

  • trigger custom css via #tags, to enable custom views / layouts for blocks including their childs (like kanban views, card views, etc)
  • make it easier to target specific elements (for instance, one user wans to hide bullets for admonition blocks Allow non-outline (freeform) text - #20 by Tony )

some examples and resources

it’s already possible to implement custom views (kanban/cards/minmaps/etc) in Logseq, what’s missing is the ability to trigger those views via #tags so that the styling applies only to selected blocks instead of globally.

how ?

current logseq structure

  • with the latest logseq, divs have an id=“block-content-uuid” and a tailwind class, some blocks have extra infos in the class like “admonitionblock”, “tip” or “tag” etc…
    -> while it’s easy to target a specific block with CSS selectors, it’s not possible to select/affect its parent or sibling divs
    -> it would be really great if the parent and grand-parent divs would ‘inherit’ tags and attributes from the block : in example 1 above, this would mean that the top ls-block (div haschild=“true” …) would also have a data-attribute (or class|id) “admonitionblock” because its children block is an admonition block. This way, it bacomes easy to select the bullet from the admonition to style it via css.
  • the same reasonning applies to tags, but tags would need to be explicitly listed : not only as a class="tag" but with the actual name of the tag like class="mytag" (in case of #mytag) or data-attribute="mytag, some_other_tag" (in case of #mytag, #some_other_tag exists in one of the children blocks)
    -> use-case : mark a block with #kanban, then we can style the whole block including children blocks using css selector .kanban div {...} | #kanban div {...} | [tag=kanban] {....}

Probably the best way to implement this is via data-attributes, what do think @tienson ?

I’m sure other users (maybe @catominor and @rcvd_io ?) can provide more insights and have a better understanding of the requirements and possibilities, it would be great to have your contributions to the topic.

For some reason the ‘like’ on this post is disabled for me. Just wanted to say awesome detail on the suggestion!

yeah, I’m not sure why there’s no like button for the post, I will check the configuration options.
@cannibalox Thank you very much for the details, yeah, I think we can give the data-attributes a try, I’ll try to enable the tag’s attributes for today’s release, I need to read the articles you listed to learn more about both the needs and how to implement it.


I believe there’s no like button because you can vote on the feature.

1 Like

Great suggestions - yes, this is one of the main features I am missing currently in logseq, i.e. tags affecting the whole blocks.

You can also look at my other suggestions for Roam I did some time ago. Many of them would be valid for logseq as well: Roam Research – A note taking tool for networked thought.

However, I would also suggest looking at some unique possibilities in Logseq, e.g., to be really something different and unique (though similar enough to quickly pick up).

A couple of things coming to my mind:

  • Collapsible metadata block
  • Properties in metadata blocks affecting their appearance
  • Properties of page affecting their appearance

I would also suggest looking at what, RemNote, ObsidianMD and Workflowy do. Some of their solutions are very interesting.


some requests to further improve the current implementation:


is it possible to assign the [data-page-tags] to the div.cp__sidebar-main-content instead of the current div (so 2 divs higher up) ?

if we can select this div, it is possible to alter the width of the main container, to get full-width for kanban or mainmaps for instance


regarding the [data-refs] and [data-refs-up] we discussed : it would be really useful to distinguish between the .ls-block where the user typed the tag and its parent blocks (parent blocks could use [data-refs-up] for instance).
Currently, since parent and children blocks share the same [data-refs], selecting a .ls-block[data-refs=tag] will select the whole tree above the tagged block.

thanks !

I’ll work on both soon, thank you for the update!

Reading it again and I’m curious why you need the data-page-tags to select the div.cp__sidebar-main-content? I think you can already select it using the .cp__sidebar-main-content class.

Also, how about calling it data-refs-self instead of data-refs-up? The purpose is to select the blocks that have those refs inside it instead of its children, is that right?

1 Like

Also, the data-refs-up here is not similar to what @catominor used in his article, I remember it’s used for the parent container which includes the current block instead of the parent block.

I’d like to select .cp__sidebar-main-content with [data-page-tags*="mindmap"] to adjust the container’s width only for pages with the #mindmap tag for instance, while keeping the other pages with the normal width.
when I change the .cp__sidebar-main-content it currently modifies logseq globally.

edit: ok, scratch that apparently it’s possible to change the width in the current state, I had another css running that was messing things up : / sorry for the trouble.

Also, how about calling it data-refs-self instead of data-refs-up ? The purpose is to select the blocks that have those refs inside it instead of its children, is that right?
Also, the data-refs-up here is not similar to what @catominor used in his article, I remember it’s used for the parent container which includes the current block instead of the parent block.

what I was trying to achieve is something like this :

so when you call a #tag, at a sub level, it becomes possible to adjust the width disregarding of the indentation level from the current block.
for instance, when I tag a block with #kanban, currently, its width id constrained by the indentation, so if you call it in level 6, the kanban’s max-width is very small.

maybe there is a simpler way, what I was thinking is (it’s a mockup as I’m currently not able to achieve the result):

  • current data-refs is already on the parent container, so it is already providing what catominor’s data-refs-up were used for
  • it’s already possible to target the current block using [data-refs=tag] > div > div > div or something along the way
  • but if we have both [data-page-tags- on the div.cp__sidebar-main-content and [data-refs-up] on containers above the parent container of the selected block, then it will be possible to tweak the max-width on a specific block with #tag.
  • data-refs-self would be useful nonetheless

maybe there is a better solution though?

just tried the new [data-refs-self], it’s working great !


Awesome, glad to hear it’s working for you! Anything else I can do for you? :smiley:

Hey guys, is this working already?

I just want to have a tag (i.e: #falsified) that strike through the current text where the tag is placed. Roam example:

Could you guys provide some instance on how to achieve this?

in your custom.css add:

div[data-refs-self*="falsified"] {	
	text-decoration: line-through;