I like the Remnote customs views by hannesfrank (that was my inspiration to make the kanban view css for logseq) : kanban and columns view activated by #kanban ; #columns ; …
more exemples here : RemNote Library
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.
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.
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.
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 Scrapbox.io, RemNote, ObsidianMD and Workflowy do. Some of their solutions are very interesting.
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
data-refs
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.
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?
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.
