I've managed a Checkbox on the first Line in a Block. Plase help with CSS to hide one of the two bullets

I have managed to have a Checkbox on the first line of a Block with a Markdown Trick that allows me to have an empty, null-pointing URL that occupies the first line of the block. On the second line I place the actual Checkbox but, because the first line is empty, it gets “drawn” on the first line actually achieving a Checkbox similar to a TODO checkbox:

- [](.checkbox " #movieGenre ")
* [ ] 

The only caveat is that I get now two bullets and it is not aesthetically appealing. Is there a way, with a custom CSS to hide the bullet of the Checkbox?

I get this rendering in Logseq:

, while in VSCodium I get:

I would like to get rid, with CSS, if possible, of the characters after the Block Bullet. I am not sure what whitespace characters are there, I assume a tab and the bullet itself. Can it be done with CSS?

As a side-note, I am trying to achieve this because Checkboxes are not Primitives in Logseq and because I am using atm TODOs to fill in for the need of a checkbox, which is nok as it’s polluting my TODO queries so, until I will be able to define a TODO Workflow that says “Checkbox” > “DONE” I have to rely on this hack. I have already REGEXed my whole graph to replace the TODOs that are just placeholders for Checkboxes (fortunately, I have them added by templates and it was easy).


FYI you can do the same with just:

- [:a]
  * [X] Checkbox

Hi Alex, what does [:a] mean? Is it a Logseq thing? I don’t find anything on it from a Markdown or even HTML standpoint.

The great thing about the

- [](.whatever "your whatever text here")

is that you can embed hashtags, properties, timestamps, hidden text that you want someone to read as they review your document, etc and it’s still Markdown. From my pov it’s a goldmine.


Logseq supports Hiccup syntax, a Clojure-like way to write HTML and CSS:


Here there are some examples of Hiccup:

Off, Hiicup/Closure … too advanced stuff for me. I am no developer. Plus, I share my markdown files with a team, I have to have full Markdown compatibility, hence my fierce activity and demand to the Logseq devs/decision makers to at least support standard markdown to the bone and at least leave me the option to embed other features like Logseq Pages ([[ ]]) in Markdown Links by default or let me have properties inside some other Markup structures.

Then you can use <a></a>: Markdown supports HTML tag since its first version. [:a] is just a more compact way to type that.

In my opinion, Markdown is too limited to support Logseq features. They should move to Djot instead, it’s 90% like Markdown but with additional features and it’s by the author of Pandoc and Commonmark.

For who is interested, here there are some ideas about Logseq+Djot:

For the features that I use I can solve everything with Markdown.
Properties can be embedded in Markdown Links:

# the properties embedded in markdown links and title text are only in the backend, in the markdown files on disc;
- Some Block Line 1
  [](.property "property1:: value1")
  [](.property "property2:: value2")
  Text goes here
# in the front-end (in-app) Logseq still renders them with just what is between the quotation marks:
property1:: value1
property2:: value2
# nothing changes for the user

Logseq Pages can be used with markdown links:

[Logseq-Page-Name-Here](../Relative-PAth-to-File-on-Disk " [[ Logseq-Page-Name-Here ]]  " ) #this is in the back-end (in the Markdown file)
[[Logseq-Page-Name-Here]] # this is what shows in Logseq (nothing changes)

and so on … I guess :slight_smile:

I see, but I’d prefer if properties were displayed once the Markdown is rendered, like this:

- Block
  * **key:** value


  • Block
    • key: value

Except for some metadata like block ID or collasped state, properties are part of my notes and should be rendered in other Markdown applications.

I agree with you on that. I believe they use double colon as it’s very rare that it occurs naturally in normal text;

I would still use:

 Some Block Line 1
  [**property1**: value1](.property)
  [**property2**: value2](.property)

so that there is nothing ambiguous about what that is. It’s a property. And this can become so many things if you replace property with something else a script or Logseq itself has as a standard way of communicating stuff. I would use “.meta” for hidden metadata, “.note” to send notes to another team member for document reviewing, etc.

As long as Markdown is widely adopted and until some other text-based framewrk gets to that adoption rate, I believe we should try to work with what we have. For myself, Markdown drop would be catastrophic and I would have to look elsewhere.

Regarding CSS to hide one bullet from the two that are rendered when doing this trick, I am thinking how would it differentiate between the bullets? Most renderers will show a different bullet stye for an indented bullet but I am not sure there is a way to tell, via CSS, that one of the bullets should be hidden or something like that…

I suppose there is no means to work with CSS to only show one bullet for the:

- [](.#)
  * [ ] Animation

Markdown rendering.

Maybe someone cat at least confirm that this is the case, I don’t code nor do I css so this is genuinely a question I need to ask and put behind, if not possible.

Just out of curiosity, is there are reason for not simply do this instead:

- Movie to watch:
  * [ ] Drama
  * [ ] Comedy
  * [ ] Horror


I used to do that, but I want to be able to use these individually in Habit Tracking Queries and don’t want to get results for all of the Checkboxes -as they are in the same block.

Until Checkboxes become available as a Custom TODO Workflow and I can define a Checkbox only one STATE (“DONE”), I will have to resort to such tricks.

Can you try this in custom.css?

.block-body dl>li, .block-body ol>li, .block-body ul>li {
    list-style-type: none;
.block-body dl:last-child, .block-body ol:last-child, .block-body p:last-child, .block-body ul:last-child, li p:last-child {
    margin-left: 0;

It should hide bullet points for all *-list elements, including those without checkboxes. To restrict this to lists with checkboxes only I need the latest Logseq release that I haven’t at the moment, I will try again in a few days.

1 Like

Yes, this works to hide ALL List bullets. However, I only want to hide the bullets from Lists that also have checkboxes, either * [ ] or * [X]. How will this be possible in a future release of Logseq? :-/

As I said:

To restrict this to lists with checkboxes only I need the latest Logseq release that I haven’t at the moment, I will try again in a few days.

Yes, I got it the first time, I was only curious what could change so next Logseq release would allow this :-/ …

The 0.9.11 release from 2 days ago updates Electron to 24.0, that implies I can use :has selector in CSS to implement “if a list element has a checkbox, hide its bullet point”.

I just didn’t get the 0.9.11 update yet, I am still on 0.9.10 :slight_smile:

I read the release notes but nothing ringed a bell as to why I would switch :slight_smile: … Now it just did :)))

1 Like

I raised an eyebrow regarding my empty-looking custom.css when I pasted the code above. Now I wanted to undo those changes to get back my bullets for all list items and I also noticed that my TODOs have both the Checkbox and the TODO text visible. I remembered that I had some custom css to hide the TODO and maybe some other css I can’t remember. Is it possible that 0.9.10 has a bug in showing the custom.css or overwriting it if you add some custom css to an empty-looking in-app custom.css?
Where is this file on disk, I can’t seem to find it.