Fix slider margin

[mcslayer]

Done

Based on the comment of @lyubomir-popov, it seems we need to reduce the top and bottom margins by half the height of the track.
I'm not sure if the calculations needed to be enclosed in parentheses, but I did so for better code readability.

Fixes #5391

QA

• Please review the updated component Slider(Range input)

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix release (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

[webteam-app]

mcslayer is not a collaborator of the repo

[jmuzina]

I think it looks good, @lyubomir-popov can you give a design review here?

[bartaz]

There still seems to be a bit of baseline drift if text in paragraphs is added between sliders. You can see that the middle paragraph moves onto the baseline a bit, and the one on the bottom even more.

The baseline alignment is quite tricky, especially in such old components like slider, so no worries if you can't figure that one out @mcslayer. We can have a look ourselves as well.

[bartaz]

The math seems to be correct. 3px height + 2* 6.5px margins add up to 16px which should be exactly right.

Not sure where the drift comes from. Maybe rounding and/or subpixes issues. Because all of those px values are calculated from fractions of rem values, so maybe rounding kicks in and moves things by a pixel somewhere.

[mcslayer]

Yes, I’ve double-checked the calculation, and it is correct. Interestingly, if I adjust the margin to 6.6px 0 6.4px, it looks perfect!

[mcslayer]

We can apply vertical-align: bottom to input[type=range], though I am unsure if this solution fully meets your requirements. If this approach is acceptable, I can proceed with pushing my changes to this PR.

[jmuzina]

I think there is something Chromium-specific (or possibly Chrome on Mac-specific) happening here. I can't replicate the issue on Firefox, but I can on chrome-based browers.

Firefox:

Brave (chrome-based):

[bartaz]

That looks promising. I think you can push the code so that we can see it in the demo server. Thanks for exploring!

[mcslayer]

Unfortunately, I found a problem with Firefox where the slider height was calculated incorrectly because Firefox includes the thumb in the input height by default. I figured out how to fix it, and I've applied the fix. I've attached screenshots showing Safari, Chrome, and Firefox (before and after the fix) for comparison.

Before:

After:

[jmuzina]

Demo updated to include latest changes

Looks good to me - tested on firefox, chrome, and safari and there are no longer spacing differences between them and the margin is fixed on all of them.

@bartaz Have a look and let me know if I've missed something 👀

[bartaz]

Thanks for chasing that one down @mcslayer