front: consider using px instead of rem in CSS

[emersion]

Description and goal

Right now the established policy is to use rem in all CSS sizes instead of px. Should we continue doing that?

• rem values are less readable: they aren't round numbers, often times have many decimals e.g. 1.8125rem
• px values are easier to reason about: I can easily figure out how large a 1px or 5px or 100px border is, much trickier to do the same with rem (especially since each project might have its own base font size).
• Browser zoom and the CSS zoom property scale px and rem values alike.
• I don't think we'd want our whole UI to become bigger if the font size changes. A UX designer might want to change the default font size without affecting everything else. If scaling the whole UI is desirable for accessibility, the user can more easily just use the browser zoom feature.
• Our mockups use pixels, currently we need to convert values back and forth when implementing and reviewing.

See also this Stack Overflow discussion, with counter-arguments in the second answer: https://stackoverflow.com/questions/11799236/should-i-use-px-or-rem-value-units-in-my-css

Acceptance criteria

.

[Yohh]

@thibautsailly

[thibautsailly]

There are areas of the app where visual accessibility is less of an issue, considering the tasks at hand: it's very unlikely that someone with visual impairments will be asked to work with complex graphic tools like the space time graph and infrastructure maps. There is simply too much informations to display at the same time for the tool to work as intended, and display size is the main constraint against the functional requirements. For operational studies, we can probably do without rems.

For short term path requests, I don't have a complete picture of the accessibility requirements, but it's very likely end users have to have a good eyesight as they also use space time graphs from other solutions. I will ask about this during the usability tests scheduled in October.

So it's a 85% confidence for pixel sizes for now.

[sim51]

In the front community there is no consensus.

When you create components that will be used by someone else, using relative units is a requirement. But on OSRD, it's not the case, except perhaps for osrd-ui (this is an other discussion).

On my side, I have a preference for using REM & EM. But in my past, I did a lot of public web sites, which is slightly different than doing a web application where you have some controls on the user and their devices.

• If you have 1.8125rem somewhere in the code, it's not an issue with the unit, it's an integration issue. We should not have that. And you will have the same thing in pixel with some magic numbers (ex: why there is margin of 29px here instead of 30px) ?
• For width & height, I prefer to use unit relative to the screen size. And for margin/padding to the font-size. So I never have a REM value that match 100px.
• If you display a web page on a smartphone, or on your TV, you must scale up/down the margin & padding. But again on our case, I don't think we need this.
• a mockup is a fixed image, without interaction/animation and with a dedicated height/width, that we need to translate in web technologies. So doing the px to rem conversion is normal for me (it's the work of an HTML/CSS integrator)

IMHO, to respond to this question, the main question is : what are the devices on which OSRD should work ? (personnaly, I have no idea). If we don't have a truly heterogeneous park of devices, yes we can use PX.

Just a thought : perhaps we are at a point of the project, where we need a html/css integrator.

[emersion]

When you create components that will be used by someone else, using relative units is a requirement.

Not sure why is that…?

If you have 1.8125rem somewhere in the code, it's not an issue with the unit, it's an integration issue. We should not have that. And you will have the same thing in pixel with some magic numbers (ex: why there is margin of 29px here instead of 30px) ?

We're supposed to implement the mockup, not adjust it so that it aligns to an arbitrary grid of 16px. If the designer has decided that a border is 2px, or a padding is 10px, then we need to write it up in the CSS some way or the other.

For width & height, I prefer to use unit relative to the screen size. And for margin/padding to the font-size. So I never have a REM value that match 100px.

Units relative to the screen size work fine for some specific cases, but not if a widget/sidebar/component is really meant to have a fixed size. Margin/padding relative to the font size make it so we get to rewrite all of the paddings/margins if the designer decides to adjust the font size a bit.

If you display a web page on a smartphone, or on your TV, you must scale up/down the margin & padding.

That's up to the designer. Maybe, maybe not. Either way, I believe this is better addressed with CSS variables rather than rem, if it turns out it's desirable.

a mockup is a fixed image, without interaction/animation and with a dedicated height/width, that we need to translate in web technologies. So doing the px to rem conversion is normal for me (it's the work of an HTML/CSS integrator)

I don't see how requiring developers/reviewers to do extra unnecessary work is a good thing. Translating a mockup into HTML/CSS is already hard enough as-is, we don't need to add more hurdles along the way.

what are the devices on which OSRD should work ?

It seems like right now we only care about desktop usage (maybe that will change in the future?).

Either way, I don't believe it matters - I really just see rem as a hack whose goal is better addressed via zoom or CSS variables, if it's really desirable.

Just a thought : perhaps we are at a point of the project, where we need a html/css integrator.

I'm personally not a fan of specializing further roles of developers.