IMHO, I prefer not to add too many customizations to Markdown or property.
I've another idea:

• When any props like text-color:: were added to a block, a data-logseq-property-text-color HTML attribute will be added to the block component.
• Users can customize the style by CSS selector: .ls-block[data-logseq-property-text-color="red"] { color: red; }

CC @xyhp915

• When any props like text-color:: were added to a block, a data-logseq-property-text-color HTML attribute will be added to the block component.

With "props like text-color::" do you refer to a set of html styles, like text-color, text-font-family, text-font-size, etc.? If that's the case, I can create a new subset of editable-built-in-properties called block-style-properties. I think the naming then should be consistent with tables, like logseq.text.color, logseq.text.font-family and such.

Users can customize the style by CSS selector: .ls-block[data-logseq-property-text-color="red"] { color: red; }

Yeah, it's true that, in HTML, a node style is pretty difficult to override as it has a very high priority. It would be better to add a class or data-* to make it easier for themes to adapt it.

Nevertheless, I'd add a default set of CSS rules in common.css at least to make the color, font family and font size work with the default theme. In the special case of the color, we could add css rules to match the seven built in color names and use a nice red instead of HTML's default red.

If this new proposal looks fine to be merged, I'll code it this weekend.

Hi @daviddavo. Thanks for the contribution. I'll defer your questions to @andelf and @xyhp915. It's worth noting that #10132 will add a number of colors so it's probably worth holding off on adding colors until those are in

With "props like text-color::" do you refer to a set of html styles, like text-color, text-font-family, text-font-size, etc.? If that's the case, I can create a new subset of editable-built-in-properties called block-style-properties. I think the naming then should be consistent with tables, like logseq.text.color, logseq.text.font-family and such.

Regardless of which approach we go with, we'll need to rename the property to have a logseq prefix e.g. logseq.text-color or logseq/text-color as we don't want built-in properties to prevent users from creating their own properties or pages with the same name

Yes, In the meantime I could just implement the property per se and the "fallback" to HTML colors, and then when cmdk is merged use those colors too.

Users can customize the style by CSS selector: .ls-block[data-logseq-property-text-color="red"] { color: red; }

Currently, it is customizable by editing the --ls-text-color-* CSS variables. I grabbed the background color of dark mode as text color in light mode and vice-versa. Some colors need some tweaking for readability.

Using data- would be great if attr() supported colors, like this:

.ls-block {
  ...

  &[data-logseq-property-text-color] {
    color: attr(data-logseq-property-text-color color);
  }
}

But it's not yet supported by any browser. If we use data-logseq-property-text-color, we would have to code a CSS selector and properties for every supported color:

.ls-block {
  ...

  &[data-logseq-property-text-color="red"] {
    color: ...;
  }

  &[data-logseq-property-text-color="green"] {
    color: ...;
  }

  .
  .
  .
}

And it would not support custom HTML colors like #fabada

I think a good compromise would be using the data- just when it is a built-in-color? and perhaps even removing the --ls-text-color-* variables.

But I would have to move it to the :div.ls-block logic.

Keep in mind that I coded it this way because I wanted to be consistent with the way the :background-color property was done, but I think changing it is a good idea, to be able to add other properties like :logseq.font-family

Furthermore, because currently, it uses merge, If you use both background-color and logseq.text-color, only the :style property of the latest is kept, so this logic would need to be redone. We should also be thinking on how other properties like logseq.font-family could be added.

Ping @andelf @xyhp915

Tldr of my previous post:

• Using .ls-block[data-logseq-property-text-color="red"] doesn't allow users to use custom HTML colors like #01ab23
• A good compromise would be using the data-... when it's a built-in color, and modifying the style of the block otherwise.
• I wanted to be consistent with how background-color was implemented, which uses CSS variables like --ls-background-color-red

I tried putting it in .ls-block, now the colors are inherited too. Is this intended behavior? @andelf @xyhp915

Now the way of modifying the background-color:: property behaviour also changed:

• Variables are defined inside vars-classic.css
• They are defined as var(--rx-<color>-05), and is the value of this variable the thing that changes between light/dark mode.

As I see it now I have to declare a new set of 7 variables in vars-classic.css called --ls-text-color-<color>, and then:

1. Put it in the style of the span inside the .block-inline, same thing as the background-color property. (Won't have inheritance).
2. Use the data-logseq-property-text-color. But then, where do I put the CSS? I would do it in block.css but there are no coloring things there, that file seems to be aimed to modify the layout. Furthermore, I would also need to add 28 lines (7*4), 4 for each color. Nevertheless, I might need to move the data-logseq-property-text-color to the .block-content level, to avoid inheritance and be coherent with the behaviour of background-color::.

Imho I would use the first approach as its similar to what it has been already done with background-color::. Another option would be to kill two birds with one stone and also do background-color:: with data-logseq-property-background-color.

cc @xyhp915 (I see in git blame that he was in charge of some related code)

Done with radix-11. I still prefer the vars-classic approach (see commit 8b02041 )

Ready for review.

Btw, I'm still on board about refactoring background-color, just say if you prefer to do it in this PR or in another one.

Ready for review

Ping @andelf @xyhp915

Ready for review

Ping @andelf @xyhp915

Hi @daviddavo I'm sorry for replying so late. This feature is a great idea, but after careful consideration, it may not be possible to merge it into the master branch immediately. Since a lot of work is currently being modified on the feat/db branch, merging it will result in conflicts that cannot be resolved. We will handle this PR after merging the db branch into the main branch. Thank You for Your Efforts! :)

Thank you! I'll be happy to learn about the db feature when it is merged and do the necessary changes!