Quickly reading Button code gave me an impression that backgroundColor has a special meaning there. I wanted to customize border-color and figured it is used as a style prop so I thought that using css prop names is the correct solution. But after making a deeper investigation I realized I was mistaken.

So according to the docs https://legacy.reactjs.org/docs/dom-elements.html#style we should use camel case for the prop names. The fact that border-color worked correctly is surprising - it shouldn't work. So I'm going to update this diff with camel case name.

By the way, I realized our Button component is really inconvenient to use. We're mixing two concepts: its shape and color, e.g. when using outline variant we're forcing var(--btn-bg-outline) color, unless we're overriding it like in this diff. For this component to be convenient to use, I would expect to be able to specify variant="outline" buttonColor="danger" which would result in red, outlined button. I've created a task for that https://linear.app/comm/issue/ENG-4308/allow-web-button-color-and-variant-to-be-specified-independently.

Overall I agree that there are some downsides of using <br /> or \n, especially when they are used multiple times just to introduce a margin between text blocks. But in this case it seems like the intention is different: in the design this whole copy is present as a single block of text. Additionally the height of the space between the parts looks like one line height. I don't think it is a good idea to try to recompute line height and somehow assign the value to a margin.

I think that using <br /> here is better in matching the design. But a separate question is if we really need a margin that is as high as one line height. And the answer is that probably not (@ted do you agree?). I'll update the code to use margin (or gap) instead (also in other places where this kind of separation was used).

https://www.figma.com/file/a1nkbWgbgjRlrOY9LVurTz/Comm-%2F-Desktop-app?node-id=11341%3A280517&mode=dev

1. By the description I was talking about this You may also disable the community public link text. In native designs it isn't present.
2. Sure. I've sent a message to @ted and we will discuss the issue.

Got your message, thank you Tomek

The result of the discussion:

1. Save & enable public link button text should be used consistently on web and native
2. Disable link button should contain just Disable text
3. Both platforms should contain You may also disable the community public link text. On native it will be displayed above Disable button. The button and the text will be placed as one section.

Agree we don't need it to be that high. Let's avoid <br /> and \n for spacing, and make the spacing between paragraphs less than one full line height

I've introduced 12px gap

Native updates will be made in a separate diff.

Created D8444 with these

Sorry about that! Let me check if simple drag-and-drop works correctly (it should according to https://www.notion.so/commapp/Attaching-files-and-images-on-Phabricator-af8e2195fc91462689cc8de5c96a6759)
{F630056}

It seems like drag-n-drop doesn't work any more