I don’t know if this change was intentional, but it’s now harder to see the border of the composer when the text area is not focused. While it’s a minor change in theory, I find that now the composer blends in too much with the background, which makes it harder to differentiate which part is clickable to focus and which part isn’t.
It happens on both mobile and desktop. Here are some photos showing the difference on mobile.
The change was intentional. The goal was to make the text stand out more and to make secondary UI elements blend a little better.
The idea is that pretty much all the space in the composer that’s not taken by buttons/shorter input elements is the text area. Or in the case of the default desktop composer it’s split into two columns, for writing and for preview, so even a slight visual separator could be enough.
In any case, I’d like to give this change some time, and after an acclimation period we could adjust the colors. Maybe split the difference between the original border color and the current one. We’ll see!
Some of the fields didn’t have their border color adjusted. Fixed in a follow-up PR. Same with the iOS margin.
How does changing the border color do that exactly?
But there is still a lot in the UI surrounding the composer that is not the composer itself and can’t be clicked, and now it’s harder to see where the surrounding part ends and where the composer begins.
Honestly, now if feels like there are just a whole bunch of floating elements (i.e. the composer and all the buttons above it) with no border at all because the border lacks contrast so much. Even the separators between (for example) the italics button and the link button are basically pointless now because it’s nearly impossible to see them.
Yeah, clearly I’m missing the point of the change, but I definitely get having an acclimation period. I’m just finding this change particularly jarring for reasons that are hard to explain.
Looking through the dev console, I see the border went from --primary-medium (#909090) to --primary-low (#313131). which is a pretty drastic change. I just tried it with #616161 to split the difference as you mentioned, and it really is a huge improvement. It provides more much-needed contrast, while not taking so much attention like the original #909090 did. Experimenting with various values, I think even something like #515151 would strike a really nice balance between contrast and not being overwhelming. Hopefully this is something you’ll consider after a little bit of time.
(I noticed there is a --primary-low-mid all the way up at #7a7a7a. Guess it’s time to add --primary-low-not-quite-mid for #515151. )
Yeah When I was originally playing with border colors here, I went with a bit more contrasty color, but eventually had to choose between low and low-mid. Maybe I will have to add a new variable after all.
But first, it’d be good to check where the existing two are used, and to see if these colors could use an adjustment, or if any of these places would benefit from a new var.
And if we’re introducing a new color, I’d be worth considering a new naming scheme for the variables, e.g. number based, like --primary-600 (similarly to what some css frameworks use; tailwind for example)
That would probably make sense anyway. Right now low-mid (#7a7a7a) is fairly close to medium (#909090), so it feels kind of pointless. Moving it to around #616161 would fill a nice gap between low (#313131) and medium (#909090), putting it about halfway in between.