Rajdeepc commented 3 months ago

This PR adds a way to use fill-start="0" as reference point as well as respecting a provided normalization function to correctly calculate fill offset and length.

Description

First check, if we really just have the attribute fill-start provided with no number value, if so, use centered point of track like before. For all other number values, use normalization function of model of active handle to calculate real fill-offset and fill-length.

Related issue(s)

4559

Motivation and context

2 current problems:

Currently fill-start attribute only allows to set values !== 0, but sometimes clients have sliders with min<0 , so for example: min="-100", max="200" - so we need a possibility to define fill-start="0" to not start from centered track position
Also currently the fill-start calculation doesn't respect any provided normalization function, so we'd like to calculate all fill-related values (offset + length) by a given normalization function of model of active handle

How has this been tested?

[x] Storybook Try here

Screenshots (if appropriate)

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] If my change required a change to the documentation, I have updated the documentation in this pull request.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

github-actions[bot] commented 3 months ago

Branch preview

Visual regression test results

github-actions[bot] commented 3 months ago

Lighthouse scores

Category	Latest (report)	Main (report)	Branch (report)
Performance	0.99	0.98	0.94
Accessibility	1	1	1
Best Practices	1	1	1
SEO	1	0.92	0.92
PWA	1	1	1

What is this?

[Lighthouse](https://github.com/GoogleChrome/lighthouse) scores comparing the documentation site built from the PR ("Branch") to that of the production documentation site ("Latest") and the build currently on main ("Main"). Higher scores are better, but *note that the SEO scores on Netlify URLs are artifically constrained to 0.92.*

Transfer Size

Category	Latest	Main	Branch
Total	222.647 kB	210.875 kB	210.583 kB 🏆
Scripts	54.687 kB	48.511 kB	48.261 kB 🏆
Stylesheet	34.929 kB	30.42 kB	30.379 kB 🏆
Document	6.024 kB	5.32 kB 🏆	5.337 kB
Font	127.007 kB	126.624 kB	126.606 kB 🏆

Request Count

Category	Latest	Main	Branch
Total	45	45	45
Scripts	37	37	37
Stylesheet	5	5	5
Document	1	1	1
Font	2	2	2

github-actions[bot] commented 3 months ago

Tachometer results

Currently, no packages are changed by this PR...

adobe / spectrum-web-components

feat: Silder: adjust fillStart calculation for value=0 and normalization function #4573

Description

Related issue(s)

4559

Motivation and context

How has this been tested?

Screenshots (if appropriate)

Types of changes

Checklist

Best practices

Branch preview

Lighthouse scores

Transfer Size

Request Count

Tachometer results