Small values like `1px` should remain as `px` units and not be converted to `rem` by `pxtorem`

[aveline]

This issue proposes that small values, ranging from 1px to 4px, should be set in px rather than rem as they are most commonly used for things like borders, which should render consistently regardless of any user adjustments to browser font size.

The range is up for discussion, I thought 1px to 4px would make sense, but we can increase the range.

In Firefox if the user increases the browser font size, border width will scale if set to rem, but in Chrome and Safari border width doesn't seem to scale if set to rem.

Border width set in rem and large browser font size

Firefox (border width is heavier)	Chrome	Safari

Border width set in px and large browser font size

Firefox

---

In all 3 browsers, border-radius will scale if set in rem.

Computed border-radius in Chrome when set in rem

Default font size	Very large font size	Very small font size

Should border radius scale depending on user set browser font size or remain constant? In which case we should also render them in px rather than rem.

[heyjoethomas]

Border width

I think this makes a lot of sense. I think keeping that width consistent makes sense rather than getting bigger/bolder as text scales.

Border radius

I actually wonder if even the 8px values should be in px. I don't know if I see value in the border radius of something like a card changing while a button or text input field remains fixed. I think it might make more sense to keep them all fixed. Just a thought.

[alex-page]

I think that 1px should be the only pixel value everything else should scale. This makes it simple to maintain and removes extra documentation for other pixel values. It will also challenge our design decisions for when to scale or not scale.

Are there many 2px and 3px examples?

[aveline]

Our existing border widths (from the old border width mixin, not sure if it has been tokenized yet) are as follows:

$border-width-data: (
  base: 1px,
  thick: 2px,
  thicker: 3px,
);

@alex-page I don't think it makes sense to not scale the 1px borders, but then scale the 2px and 3px borders.

That makes sense to me @heyjoethomas, keeping them fixed until 8px. We do have a few border radius values that are larger like for badge and on the date picker but in those specific cases I think it makes sense for those to remain rem. But that does introduce some inconsistencies which is not ideal as @alex-page called out.

[sarahill]

My initial thought was don't scale the border or border-radius size but I did some poking around and investigated a bit on how things look when they scale and implications. I'm slightly leaning to keep 1px and 2px for borders and use rems for everything else.

It simplifies things and also lets the UI respond to user preferences.

I agree with @heyjoethomas that it seems odd to have some values scale and others not. I'm leaning a bit towards let things scale since I think the gain of setting a fixed px value is low in this case. It's a loosely held opinion.

@aveline do you know what the 3px width border is being used for?

[sarahill]

Now I'm wondering if we should lean into relative values here. @alex-page I know you mentioned 1px should be the only px value and everything else should scale. Is it worth even having 1px or should we lean into relative values and let things scale?

As I was looking for examples of other web based apps and how they respond to user preferences, I was shocked at how few of them respect those preferences. In the instances where things did scale, I found it felt really nice and cohesive. If everything scales accordingly it feels pretty fluid and intentional.

[aveline]

@sarahill the 3px is used on the Action list and Tabs

And this is actually interesting, the tabs border scales in all browsers when set in rem.

Firefox	Chrome

I suspect that Chrome and Safari don't scale the border-width property, but the way we are setting that tab border is using the height property. So we should also keep in mind that our border width tokens can sometimes be used on properties other than border-width and will behave differently depending on how the browser handles those properties. 🙃

And as you can see in the Firefox example, when the browser starts scaling rems, we can run into pixel rounding issues and things don't always line up the way we intend. But maybe I am being too nitpicky?

If we set the values to px then it doesn't scale and the alignment remains as intended.

It might be a tradeoff. Perhaps we like the cohesiveness with everything scaling and can accept that some minor issues could pop up.

[sarahill]

And as you can see in the Firefox example, when the browser starts scaling rems, we can run into pixel rounding issues and things don't always line up the way we intend.

Huh this makes sense that some browsers may render things in an unexpected way but I don't feel like I'm seeing that misalignment in Firefox? 🤷

You make good points. I haven't seen anything yet that feels like it greatly impacts the experience negatively but I could definitely be missing something. The other thing we could say is maybe going completely to relative units is out of scope for this first pass but it's something we should consider when we revisit the design language + design tokens.

[aveline]

This is the misalignment I was referring to in FF.

Currently all units are rem and everything is relative, so if we want to keep it that way it's definitely not out of scope! 😁

[sarahill]

Had an offline convo with @aveline on the pixel misalignment with tabs.

tl;dr I couldn't replicate this issue in FF. I tried 24, 32, and 48. I also tried it with zoom increased and not and in all instances I couldn't replicate. We discovered that changing the font-size to 28px does create the misalignment most likely due to pixel rounding.

I think we're coming to the conclusion that this is an edge case that doesn't detract from the experience. Leaning toward keeping everything as rem for now and if we start running into more pixel rounding issues in the future we can always revisit.

[aveline]

Thanks for summarizing @sarahill

I will close this issue. It was a good exploration of some of the differences in rendering between rem and px and we can always refer back to it if we run into issues going forward.