feat(skeleton-loader): new module

[saiponnada]

Fixes #2007, #2160

• This PR contains CSS changes
• This PR does not contain CSS changes

Description

Following changes were implemented part of this PR,

• Added skeleton loaders for all the variants
• By default, animations respect prefers-reduced-motion: no-preference and animates less than 5s
• Implemented RTL mode for text loaders
• Implemented container queries to set image border radius
• Added stories to Storybook

Notes

• By default, setting default height of 40px for all skeletons and let its corresponding variant override the default.
• Container queries work great in storybook but fails to apply on the skin docs website.
• Need to work with either DS/ skin docs to explain proper usage of aria-label to convey loading

Checklist

• I verify the build is in a non-broken state
• I verify all changes are within scope of the linked issue

• I regenerated all CSS files under dist folder
• I tested the UI in all supported browsers
• I did a visual regression check of the components impacted by doing a Percy build and approved the build
• I tested the UI in dark mode and RTL mode
• I added/updated/removed Storybook coverage as appropriate

[LuLaValva]

Before I move further, I would like to hear your thoughts on this—

Our mission with the current approach for skeleton loaders is to provide teams with a framework within which they can build skeletons which match exactly with the content that they are loading. This is extremely important, because as soon as a skeleton loader causes layout shift I consider it to be more harm than good. Since teams are very likely to have components that have different layouts than standard skin components, it is optimistic of us to assume that we can provide them only with skeletons that have dimensions we expect.

I know I'm taking a big step back here (sorry), but I actually think it would be a good idea to provide less specific components like skeleton--circle and skeleton--rounded-rectangle which default to the sizes of other skin components but can be overridden by teams.

One potential approach for this (which I haven't given too much thought to so it may not be ideal) is to use our specific classes to provide CSS variables for general ones. For example, an avatar skeleton could look like this:

<div class="skeleton skeleton--circle skeleton--avatar"></div>

.skeleton--circle {
  border-radius: 50%;
  height: var(--skeleton-circle-size);
  width: var(--skeleton-circle-size);
}
.skeleton--avatar {
  --skeleton-circle-size: 48px;
}

[saiponnada]

I know I'm taking a big step back here (sorry), but I actually think it would be a good idea to provide less specific components like skeleton--circle and skeleton--rounded-rectangle which default to the sizes of other skin components but can be overridden by teams.

Let me play devil's advocate for a moment. In my opinion, if we provide too many reusable classes, we run the risk of teams using them aimlessly everywhere. To avoid this, we can improve our documentation both on skin and DS on appropriate usage of these classes. I personally like to go with conservative approach initially and adapt as per the changing requirements. Once we start adding shapes like skeleton-circle, we cannot really control influx of other shape requests.

Having said that, we are not losing any flexibility, we still provide versatile skeleton base class that can adapt to the layout for teams to extend (that needs to be used rarely).

[agliga]

Before I move further, I would like to hear your thoughts on this—

Our mission with the current approach for skeleton loaders is to provide teams with a framework within which they can build skeletons which match exactly with the content that they are loading. This is extremely important, because as soon as a skeleton loader causes layout shift I consider it to be more harm than good. Since teams are very likely to have components that have different layouts than standard skin components, it is optimistic of us to assume that we can provide them only with skeletons that have dimensions we expect.

I know I'm taking a big step back here (sorry), but I actually think it would be a good idea to provide less specific components like skeleton--circle and skeleton--rounded-rectangle which default to the sizes of other skin components but can be overridden by teams.

One potential approach for this (which I haven't given too much thought to so it may not be ideal) is to use our specific classes to provide CSS variables for general ones. For example, an avatar skeleton could look like this:

<div class="skeleton skeleton--circle skeleton--avatar"></div>

.skeleton--circle {

  border-radius: 50%;

  height: var(--skeleton-circle-size);

  width: var(--skeleton-circle-size);

}

.skeleton--avatar {

  --skeleton-circle-size: 48px;

}

I think the more generic components are fine. This is because teams can use them in their own components and not just ours. Imagine if teams have a component that looks like avatar but isnt avatar. For that case it makes sense if they use the circle one and not avatar one.
I would also be for having generic variables we expose to resize the components though which we can expose so teams can resize them to fit their page.

[agliga]

I looked at some examples in docs. I think there are too many. We should either combine some into 1 group (especially similar ones) or move them in storybook. Generally we should have about 3-5 examples at most in our docs (again depends on the component, some do have more or less and thats okay). The edge cases should go in storybook

• For the first one, we could have button, avatar all in 1. Just call out the different variations. (See signal component). I would put form in here as well.
• Small and large should be in 1 example.
• Small text and large can be in 1 example. (maybe even combine with small and large or in the first one). All other variations can be in storybook.
• RTL should be removed and put into storybook.
• Tiles should have 1 example. No need to have the base case by itself. Just have the responsive case.

I would also have maybe the first story call out all the variations in a table and then show what it looks like. (See EEK)

I think other than that it looks good. I am good to approve it if you want to update the docs later.
Also, we should have a place where we call out how to do different sizes and show a story for that.

[saiponnada]

Made all the code review changes except documentation. The documentation will be cleaned up in the part of next release.

[agliga]

LGTM, don't forget to squash

[ianmcburnie]

I'd like to take a look. Wait for me please :-)

[ianmcburnie]

I think the opening few sections of documentation could use a little clean up, in terms or readability and prose. I'd be happy to do a pass through that before release.

[agliga]

LGTM, just a minor comment and then I think its good to go!

[agliga]

LGTM
Good job!