# compose

Stylianos Gakis

03/28/2022, 9:33 AM
While migrating some screen from Views to Compose there was an inconsistency regarding the background color that I’d like to hear more about. Basically we’ve in some places relied on the functionality of the
style having a transparent background. This doesn’t seem to be the case in the compose version as it defines the
color of the
as its background instead. I would love to hear more about what is the idea behind it? More often than not, when using an
button, one would like to have it show the text and the outline but blend in with whatever is in the background by basically having no background. That is since what’s behind it often is not a
. It could be for an image or some color close to surface not not quite the same. My guess would be that this was done to ensure a proper pair of surface/onSurface color to ensure accessibility, so it this the reason? Anything else I’m missing? We’re considering altering our design system’s outlined button to always have a transparent background (while still using onSurface for the content) and I would basically like to hear more about this to see why we may want/not want to do this. Assuming we’re taking care of making the content legible on a per-case basis of course.
Hey sorry for the ping here, but I think this will get hidden in history otherwise but I fell like this is quite a big change considering when one changes from view->compose they wouldn’t expect this inconsistency in the OutlinedButton. I thought maybe you @Chris Sinco [G] have some idea about this?
Also saw that in the material guidelines documentation here in the “Container” section the button is also portrayed as having a transparent background. With a “caution” label of course to be wary of potential accessibility issues. Meaning that the compose implementation also feels a bit counter-intuitive by default maybe?

Chris Sinco [G]

03/30/2022, 5:50 PM
so it this the reason
I’m not entirely sure to be honest but @Louis Pullen-Freilich [G] who implemented those components may know. I agree it’s strange to see that given the callout to transparent container in the guidelines, and that the View implementation also using a transparent background.
The good part is that you can set the background color to
through the
param, so you aren’t totally blocked and needing to reimplement. You just will need to create a custom Composable wrapper.
But perhaps this was a bug/oversight on the default colors for OutlinedButton and we need to fix it 🤷

Louis Pullen-Freilich [G]

03/30/2022, 5:58 PM
The internal specs for outlined button state surface should be the background color, so I’m not really sure how to reconcile that with the other implementations / public information
Assuming you make sure that the content is legible, and you control the background color - I don’t think there’s any problem with having a transparent background color - but it is easy to accidentally place it on a background that leads to illegible contrast

Stylianos Gakis

03/30/2022, 6:12 PM
Yeah I can definitely see the default being either or as I said, not strong opinions on that part. Plus luckily it’s super straightforward to recreate this behavior with a wrapper around the OutlinedButton simply adding
colors = ButtonDefaults.outlinedButtonColors(backgroundColor = Color.Transparent)
on the colors param, so that’s not a problem. I was mostly curious about how it’s inconsistent with the View system and how the docs had this picture that showed a transparent one. I wonder if and how much you’ve tried to stay consistent with the View system, and if this particular case was just an example of a case where you felt strongly against keeping this consistent. I also now wonder what the default is for Flutter for example 🤔 p.s. I believe this change a good step forward since this makes sure that the text is legible by default, just caught me by surprise initially that’s all.
👍 1