Material-ui: [system] borderColor not respected anymore

[levrik]

After the upgrade from 4.3.1 to 4.3.2 the borderColor prop doesn't get respected anymore on a Box, at least for the following specific case.

<Box borderRight={1} borderColor="grey.200" height={1} />

The resulting CSS looks like this:

.MuiBox-root-42 {
    height: 100%;
    border-color: rgb(238, 238, 238) rgb(238, 238, 238) rgb(238, 238, 238);
    border-right: 1px solid;
}

Apparently the border color was set for all sides except the one that has a border width and style set.

Maybe this issue is connected to #16875 which seems to have landed in 4.3.2.

• [x] The issue is present in the latest release.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

[elxris]

I found a workaround:

<Box borderRight={1} borderColor="currentcolor" color="grey.200" height={1} />

Is not ideal, I know, but I needed to fix them.

Edit:
Another workaround without setting color

<Box borderRight={1} clone>
  <Box borderColor="grey.200" height={1} />
</Box>

Edit: This didn't solve my problems. We need an actual fix. I will hide this comment.

[trevorblades]

I've been trying to investigate this bug, and I've got some more information to add. You can see the effect in this CodeSandbox that I forked from the one in the docs: https://codesandbox.io/s/material-demo-tue68

The weird thing is that differently-formatted CSS is outputted depending on which side you set the border on.

borderTop={1} and borderLeft={1} produces the following CSS:

border-color: COLOR;
border-top: 1px solid COLOR;

The ones that don't work borderRight={1} and borderBottom={1} produce the following:

border-color: COLOR COLOR COLOR;
border-right: 1px solid;

It would be convenient for the rule to just be border-top: 1px solid COLOR, but this outputted CSS _would_ work if the border-color rule came after the border-right one. Since 1px solid assumes you want to use the default third argument (#000), it can only be overwritten if it's followed by a border-color rule, rather than preceded by one.

I think that the order that rules get applied is a JSS thing. The order that you apply the props doesn't seem to have an effect on the order they're applied to the generated class.

What's more, I found a _possible_ source of the 1px solid formatting on this line, but I can't figure out why all four sides aren't using this formatting rule.

[artegen]

For now it's possible to use color property instead, eg. color="common.borderColor". After this is fixed it can be easily replaced with borderColor="common.borderColor"

[mark-tate]

Adding borderLeftColor, borderRightColor, borderTopColor and borderBottomColor to border.js fixes the issue.

What do you think ?

Happy to raise a PR and update the docs, if that's the best way forward ?

[mark-tate]

Pushed up a simple PR, just in-case.
Alternatively System's transform call in style.js (styleFromPropValue) could pass back a mapper that enables the transformer to extract values from the theme.. You could then use the existing border props (would be useful for other transforms as well, I imagine).
ie. borderRight={"1 solid primary.main"}

[SteveDowsett]

Just hit this problem for the 2nd time (thought the issue rung a bell).

Using the work around mentioned above by setting color and not borderColor, is there any chance this could be fixed though? Many thanks

[malyzeli]

This is my workaround how to display properly coloured bottom border (works for other sides as well).

You have to set border and then unset individual sides. In this case border color is applied as expected. It is better solution than using regular color prop, because it does not apply color to contained text in child elements.

Not very nice since it's adding visual bloat to the code, but it works for now...

<MuiBox
  border={1}
  borderTop={0}
  borderLeft={0}
  borderRight={0}
  borderColor="background.default"
/>

[ZehuaZhang]

I encountered this error again, borderColor is only working for the workaround provided from malyzeli

[ostrebler]

Same here.

[mnajdova]

Seems like this issue is fixed in v5 - https://codesandbox.io/s/material-demo-forked-qvy2m?file=/demo.js (the order of which the rules are added depends now on the order of the props, or the order of the props inside the sx object).

One important thing to note that the order of which the props are written is important. But this is also how CSS works - https://codepen.io/mnajdova/pen/dyXKwWm

Now that we have the sx prop it would probably even help seeing the props in same object and reasoning about their order. I don't think we should process the data and re-order the border props, as we may actually break the behavior in cases when someone intentionally writes the rules in some specific order.

We could probably add in the docs somewhere that the order of which these are applied is important, but even that seems like an awkward thing to do, as then we would open the door to adding many more instructions to many other not so obvious CSS rules that are out there...

[oliviertassinari]

@mnajdova Sounds great, I can confirm that the behavior was unpredictable in v4

but is consistent in v5.

What about we add a test case to enforce this property in case we need to heavily refactor the system's implementation?

[mnajdova]

What about we add a test case to enforce this property in case we need to heavily refactor the system's implementation?

Sounds good will create a PR for it 👍