Foldable embedded pages using custom CSS?

I have a question related to the following Feature Request:

Is there a way to implement foldable embedded pages using custom CSS?

I aim to categorize pages saved as separate files into two main types: sticky notes and idea boards.

Sticky notes are simple, atomic pages for recording fragmented information or thoughts. Idea boards, on the other hand, are pages that aggregate sticky notes, organizing them and supplementing them with additional notes from a specific perspective.

A single sticky note can be added to multiple idea boards and managed as an embedded page.

This approach aims to organize the same information from various perspectives while minimizing redundancy. However, there arises an issue where the process becomes quite cumbersome if embedded pages on an idea board cannot be folded and unfolded as if they were directly written on the idea board itself.

Therefore, I consider the ability to fold and unfold embedded pages crucial. I would appreciate any guidance on implementing this feature in Logseq, even indirectly, perhaps through custom CSS or other methods.

  • This should be possible.
  • However, let’s see if we properly understand the need:
    • If the aim is to fold like a block, why not put the embedded pages inside child-blocks and fold those blocks as needed?
    • As another option, why to fold/unfold embedded pages, instead of opening their references in the sidebar, where:
      • they are foldable
      • they need less scrolling, as they can be picked:
        • in any combination
        • in any order
      • this seems closer to the sticky-notes metaphor than the surface of a page
        • to that direction, instead of a mere page, one could go for an actual whiteboard, which:
          • supports folding
          • provides an extra dimension
  • The overall approach of creating pages out of embedding other pages sounds more rigid than needed.
    • Can a sticky note belong to more than one idea board?
    • If a sticky note contains fragmented info, putting it inside another page doesn’t decrease the fragmentation.
      • The whole metaphor of a sticky note is questionable.
        • Logseq is supposed to be much more than a “better sticky-notes system”.
        • Journals typically serve as a place to stick fragmented info.
          • They are meant to refer to or be referenced from other pages, but they shouldn’t leak their mess to them.
  • In other words:
    • The ability to fold and unfold things is nice.
    • A workflow of constant folding and unfolding is not nice.

In Logseq, information is organized into a hierarchy of blocks, and blocks sharing the same context are grouped together into a physical unit called a page (a file stored on disk).

Logseq provides the block embed feature, which allows many blocks to be grouped differently according to various contexts by using each block’s UUID, thus enabling embedding of the same block across different pages.

I wish to treat each block shared across multiple pages as an independent physical entity. Currently, the only way to do this is by managing each shared block as a separate page.

The reasons for wanting to treat blocks shared across multiple pages as independent physical entities are:

  1. To alleviate the burden of deciding physically which page each block should belong to, and

  2. To make it easier to select only the needed blocks (on a page-by-page basis) to copy to another graph or to share with someone else.

Moreover, since block embeds are represented by UUIDs, which do not hint at their content, I prefer page embeds, which allow content to be inferred from the page title, over block embeds.

Embedding a page as a sub-block is inconvenient because it requires creating a block and repeating the page title every time.

I am currently also making use of the sidebar. Instead of page embeds, I organize page links and open the linked pages in the sidebar if needed. However, I still wish there was a way to display the content of shared blocks embedded within a page in a foldable manner.

So in your view:

  • sticky notes are carriers of difficult to categorize, arbitrary information that may stick potentially anywhere
  • idea boards are contexts for sticky notes
  • embedding is the way to stick a note into an idea board

I personally disagree with that approach, for multiple reasons (see Turn blocks into sticky notes increasing portability).


  • is not:
    • for contextual associations
      • In Logseq, this is done through references (hard links).
    • for grouping
      • In Logseq, this is done through tags (soft links).
    • for avoiding navigation
      • In Logseq, this is done through:
        • pop-ups
        • the sidebar
  • is for combining self-sufficient information into something bigger (e.g. a presentation)
    • But sticky notes:
      • are not self-sufficient
        • they are fragments by their nature
      • are not genuinely atomic either
        • if they were, they would permanently stick somewhere (see lower)
      • don’t combine well, because some parts of them don’t relate to the surrounding environment
        • they contain some parts that fit, but cannot hide the ones that don’t
  • In Logseq, this is done in journals. But even there, notes are longing to find their more permanent natural position.
  • And yet the difficulty of that decision becomes irrelevant, if we think of a block as something that belongs to multiple contexts.
    • Although it may participate to multiple contexts, it doesn’t belong to all of them.
      • If it actually belonged to all of them, it would be multi-dependent instead of independent.
      • The primary context and the one that a block belongs to, is the page of that block’s subject.
        • This page is not an idea board, but a concept page.
        • All other relevant contexts should point back to that single place.

I am afraid that a folding solution, although nice to have, would solve the wrong problem.

Now this is a much needed but separate feature (with no easy solution).

1 Like

I hope for a note-taking method that allows for frictionless recording and orderly reflection from various perspectives. To achieve this, I feel the need for something akin to a sticky note (or napkin) that lies between the block concept and the page concept of Logseq. This issue relates to personal preferences in note-taking methods and, in my view, is not a matter of right or wrong.

Perhaps my explanation of my needs was insufficient, making it hard to understand. In fact, I am more interested in finding a practical implementation method - preferably an easy one - rather than dwelling on the philosophy of note-taking. :slight_smile:

1 Like

Additionally, in Logseq, when we manage context using references or tags, the ‘Pages tagged with’ area for a referenced tag or the ‘Linked References’ for a referenced page list backlinks in an arbitrary order. From this contextual perspective, when organizing pages, the order is important, and there is a need to add additional information, which makes such an arbitrary order backlink list insufficient.

As mentioned earlier, a whiteboard could be a solution to this problem. However, for me, organizing information in an outliner format text seems to be much more time and effort efficient compared to using a whiteboard.

Sure, philosophical discussions go to category General. But avoiding a regrettable choice is a practical discussion. And for me to prepare a solution, I would like some guarantee that at least one person will use it (not just play with it and then dump it).

Would you be willing to use the normal typing for page-embedding (i.e. typing /embed or {{embed }}), then prepend embed with e.g. foldable-, to form in total something like {{foldable-embed [[pagename]]}} , which will use some custom.js to add a button for un/folding?

Thank you so much for the favor!! I believe that at least the users who voted and commented on the Feature Request mentioned above are willing to use it. It would be acceptable to maintain the existing procedure for embedding pages in Logseq as much as possible, if it involves adding a button for un/folding to the embedded page block. It doesn’t matter whether it’s custom css, custom js, or both.

Done in Foldable embedded pages

Thank you so much!!
I’ve confirmed that, by applying the custom CSS and custom JS you posted, clicking on the page icon of the embedded page does indeed make it un/fold as intended.
I will make good use of it. :slight_smile:

By the way, I’ve discovered one limitation.

It works fine on Windows, but on Android, clicking the page icon does not cause it to unfold.

For mobile support, try replacing this part:

        div.querySelector(".embed-page .mr-3").addEventListener("click", function onClicked(e){
            const classList = div.classList;
            if (!classList.contains("unfolded")) classList.add("unfolded");
            else classList.remove("unfolded");

…with this untested code:

        function onClicked(e){
            const classList = div.classList;
            if (!classList.contains("unfolded")) classList.add("unfolded");
            else classList.remove("unfolded");
        const button = div.querySelector(".embed-page .mr-3");
        button.addEventListener("touchend", onClicked);
        button.addEventListener("click", onClicked);

I apologize for the confusion. After closing and restarting the app, it works well on Android just as it does on Windows.

Separately, there is an issue where the un/folding does not work when embedding page with an alias instead of the page name, but this is not a problem as long as we are careful not to embed using aliases

Embedding an alias doesn’t work in general, as instead of the target page it embeds an empty page. Thus there is nothing to unfold, so it is not an issue of this implementation.

Ideas aren’t arbitrary nor random. Sometimes they just aren’t fully organized. Louis Pasteur accidentally injected chickens with a dated virus and they lived. He revealed the power of inoculation. Where do you note that? There is no permanence in complex environments. You need to stay liquid.

I would say that permanence can be found in just about the same frequency as non-permanence. Without enough permanence, Pasteur would have no chance. Granted that some of that permanence is so much fundamental, that it may get overlooked.

There are two types of complex environments:

  • Hardware, which is hard/solid.
    • The circuitry of the computers that facilitate this conversation, represents the most complex environments in the known non-biological universe. Its success primarily depends on its permanence.
    • Biological hardware is even more complex. Its success primarily depends on homeostasis. This is:
      • about maintaining relative permanence
        • many cells get replaced by others, but they are practically identical
      • the reason there was something for Pasteur to discover in first place
  • Software, which is soft/liquid.
    • It can be as complex as the hardware (e.g. virtual machines), but so far we have not reached that level (we use instead abstractions).
      • We have the quantity (e.g. LLMs), but it misses enough complexity (that shows off).

The exact boundary between hardware and software is not always easy to define in a multi-level system (e.g. code is software, but may function like hardware), however their roles are distinct enough. Like a piece of ice on an iceberg:

  • may contain electrons that move all the time
  • may itself be floating along with both:
    • the iceberg
    • the planet
  • yet it has crucially different properties than a drop of water in the surrounding sea
    • no matter they are made of the same type of molecule (same mass etc.)
    • the drop may let a ship pass, the ice may open a hole on it
      • The liquid sea is relatively chaotic, while the solid iceberg is ordered enough.

Knowledge management is like a city. A city:

  • is a complex environment
    • Like a living organism.
      • Though less complicated.
  • has software parts:
    • The various goods produced and consumed within it.
      • They are meant to move from production to distribution to consumption.
    • The inhabitants living there.
      • They move around most of the time.
  • has hardware parts:
    • some of them under construction
      • Things are expected to move around a lot.
    • some of them under maintenance
      • Some things are expected to move a little.
    • the presently useful ones, those settled to their designated permanent positions
      • If any of them moves, it is considered a damage.
      • Pasteur:
        • needed:
          • a stable environment to perform his experiments reliably
          • to consistently follow some rules
            • software in nature, hardware in role
        • used tools that were:
          • stable themselves
          • also produced in very stable environments

Likewise with notes:

  • Their content is software.
    • It is supposed to:
      • be produced and consumed
      • be edited, associated, enriched and generally improved in many ways
  • Their position is hardware.
    • It is supposed to:
      • be constructed and maintained
        • Think also of notes made-up of more than one block.
      • find a permanent page, within which to be used
        • It may still move a little within that page, but less and less.
  • Liquidity of content doesn’t imply liquidity of position.
1 Like

Want to test this, but where is the custom.js file or do i have to create it?

If it doesn’t exist, you have to create it inside subfolder logseq of your graph’s folder.

1 Like