New feature: Callouts

[vinicius73]

• Resolves: Callout box support #2184
• Target version: master

Summary

Add a new feature called Callouts

It allows putting more than one paragraph.

[vinicius73]

We also have tried some variations of background color.

And icon colors.

The main problem of the alternatives is the text and background combination, to create a good contrast.
Despite using CSS variables like --color-primary-light, --color-warning-hover, --color-error-hover and --color-success-hover to make easy to user change the color of blocks. It's hard to define a good solution for background and text color contrast.

Those variables are in hexadecimal, it should be rgba or hsla to be possible to define a good and automatic color change for readability.

Refs: https://css-tricks.com/switch-font-color-for-different-backgrounds-with-css/

[jancborchardt]

Very nice! :) Some design feedback:

• A more descriptive and shorter word for this would be "Callouts".
• The warning icon would look better as a triangle: https://fonts.google.com/icons?selected=Material%20Icons%3Awarning%3A
• Would be better with some border-radius just like the "Code block" element: var(--border-radius)
• Good on trying out the different backgrounds – what would be best is indeed using a -light variant of each of the colors also in the background. For primary, we use 10% saturation of the color for that. But it’s also fine as is now and can be done separately, since you say it needs the variables to be adjusted.

[nimishavijay]

Looks great! And agreed with Jan, left border for each type of callout could be 100% opacity of its corresponding color, and background could be 10% opacity of its corresponding color. If we are using --color-main-text for the text then it should have enough contrast. It would look like this:

Additional tiny bit of feedback from me, we could use --color-main-text for the icon colors also, seems like it is #000 now.

[julien-nc]

This looks very nice!

I don't know about using the primary color for info blocks. It looks weird when it is similar to the warn/error/success color. How about something blueish or greyish?

Those variables are in hexadecimal, it should be rgba or hsla to be possible to define a good and automatic color change for readability.

While waiting for potential new css vars for the light backgrounds, we could just hardcode them:
rgba(236, 167, 0, .1) for warning for example.

I played with your changes, made some changes to img/warn.svg and it's not effective. How can we make sure new versions of those text-specific icons are loaded?

[max-nextcloud]

I played with your changes, made some changes to img/warn.svg and it's not effective. How can we make sure new versions of those text-specific icons are loaded?

I think i had similar issues in the past. I think the server is caching the images. Setting up my docker dev environment from scratch fixed it for me - but that is obviously far from ideal. I suspect there is some occ command or so to clean up image cache or even disable it.

[juliusknorr]

Suggested change

	label: t('text', 'Error'),
	label: t('text', 'Danger'),

Maybe danger would be a bit less technical as the user facing term?

[juliusknorr]

Just curious, is limiting to paragraph done on purpose or would there be also a way to have other blocks like headings/lists in the callout container as well? Fine to keep it but if there are limitations maybe a quick code comment might be good about the reasoning ;)

[max-nextcloud]

@vinicius73 and me came up with this during a call.
One of the issues we were facing was having different callouts nested - like a warning inside an info. That would be super confusing.

I also thought it would be good to try and keep the schema as simple as possible to make it easier to reason about. I was afraid we might create such complex structures in text that the generated markdown will not be parsed by other markdown consumers. Today i tried to create such a document by nesting lists and quotes etc. and the resulting markdown was parsed well by github. So markdown is able to handle much more complexity than i thought.

So now i think we actually need to allow for the same level of complexity in the schema. If we have a file that has content that the schema does not allow for it will fail to load in text. In case of the callouts this would currently already be invalid:

::: info
### heading in the info
Some text
:::

So I think we should allow for all block content in infoboxes to be able to parse markdown that contains these.

At the same time I would like to try to discourage creating too complex structures in the UI. For example... when you are in an info box and click the warning box button... we turn the infobox into a warning box rather than adding a warning box inside the info box.

[juliusknorr]

I'd be fine either way, but iirc yesterday (in our call after the message) you mentioned that now you think that supporting different node types would be more fitting to what markdown can actually represent.

We could also get this in first with that limitation and look into the further sub-node types in a follow up.

[max-nextcloud]

When working on tables i noticed that content that is out of spec for prosemirror will still be inserted as the text content.
So this:

::: info

## Heading

content
:::

Would render like

::: info

Heading

content
:::

Which seems fine for a start. I would also be okay with allowing headings in there - but let's avoid any generic container such as lists or quotes that then allow everything inside them.

[juliusknorr]

I think i had similar issues in the past. I think the server is caching the images. Setting up my docker dev environment from scratch fixed it for me - but that is obviously far from ideal. I suspect there is some occ command or so to clean up image cache or even disable it.

During development a occ maintenance:repair and redis-cli flushall should do the trick there.

[nimishavijay]

I don't know about using the primary color for info blocks. It looks weird when it is similar to the warn/error/success color. How about something blueish or greyish?

So @jancborchardt and I talked about this, and we think we could use Nextcloud blue #0082c9 but we should make it a separate variable like --color-info or similar :)

[juliusknorr]

Looks good as discussed with removal of the line height adjustments 👍

Lets give @max-nextcloud the chance for a review and feedback on the content nodes before merging 😉

[max-nextcloud]

Looks great - both code and ui wise. 🤩

One minor thing that i would like would be if removing multiline callouts worked like changing them to a different type. When i am on one line and i turn the callout off it would be nice if the entire callout would be gone - not just the line i am on. Could be done separately though...

I'll approve this so we can get it in.