HS-1390414-CSS-updates

[wjames111]

Description
This PR is for HelpScout ticket 1390414
It's intended purpose is to make branded-checkout more friendly for WordPress environments by doing the following:

• Set display property to block on branded-checkout element
• Namespace overly generic selectors such as loading1, loading2, etc.
• Ensure selectors are nested within an applicable parent class such as branded-checkout. Adding specificity and reducing chances of generic styles incidentally being applied to branded checkout
• Reduce fade animations to a single animation
• Fix content shifts (This one might need some extra attention as ng-if edits were done to product-config-form which appear to be used by both branded and give)

Issues:

• For development branded-checkout styles need to be manually added to the branded-checkout component as the dev environment works differently then prod.
• It appears most of the content shifts were due to the having multiple different loading classes within product config component and elsewhere instead of wrapping all of branded checkout in them.
• Additionally it appears branded-checkout styles are already nested within branded-checkout element so not a whole lot was needed here unless I misread the request.

[clonge]

This is much less likely to conflict, however, a give prefix on a give page is still pretty generic. .bc, .cbc or .branded-checkout is much better and less likely to conflict.

[clonge]

I think, however:

branded-checkout loading1 {

is fine, with the assumption that other components are properly scoping their css as well.
Except for the animation name since it can't be scoped.

[wjames111]

So I didn't use bc or cbc because this stylesheet is being used by both branded checkout and standard checkout. Also the reason why it isn't scoped. I thought about creating a separate stylesheet for this but that would mean creating an entirely separate component, unlike the other stylesheets this one is imported directly into the component. Not sure what the best workaround is.

[clonge]

I don't know the specifics of the project(s), but for branded checkout would not including the loader css directly but adding it as @include rule similar to @import '../cru-scss/cru'; work? Seems like a simple solution that will scope the css just like the rest of it.

That would leave only the animation name out of scope and I think give-fade is unique enough to not likely collide.

[wjames111]

That could work, might be a good solution. Worried there's a reason certain components import the stylesheet directly rather then just import them. I'll try doing that and do some testing.

[wjames111]

@clonge I'm having trouble getting rid of the layout shift. It seems like the primary culprit is the two loading components. The second one can't be easily changed as standard checkout uses it as well. Do you have any suggestions on an easy remedy?

[clonge]

@wjames111 Not without research / knowing the project. Normally, you would hide / cover the interface until it's fully loaded and then reveal it all at once instead of letting it incrementally load in. This does come with potential issues of course. It can feel longer to the user, but better for performance. If js produces errors it could leave the loader on the screen even though the error may not be a critical failure.
Without looking into it this is the general idea:

branded-checkout:has(loading) {
  position: relative;
  height: 300px;
  overflow: hidden;
}
branded-checkout loading {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background: #fff;
}

This would cover the entire branded-checkout, limit it to 300px without scrolling and cover it with the loader until the loader disappears. This is probably the quickest / easiest solution.
Now that I've thought about it, I could easily do this in the WP plugin. I just hadn't thought how to do it yet.
-- Edit
This almost works. The loading component is inside other elements with position relative, so it doesn't work as desired. This does it mostly, although things still shift some:

branded-checkout:has(loading) {
  display: block;
  position: relative;
  height: 200px;
  overflow: hidden;
}
branded-checkout *:has(loading) {
  position: static !important;
}
branded-checkout loading {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background: #fff;
}

And I will need to adjust my loading element on the WP side to be centered in the box to match.

[clonge]

@wjames111 There's also a bigger issue in that the loading component moves to a new place in the dom? Just odd behavior and has additional css that's applied after it moves? It seems like the application itself has a double load or something, which can't be good for performance.

Never mind, I see the component is being used several times. The last one is on top, which has a slightly different structure than the first. So, to get stuff from jumping around visually at least this is the css that's needed:

branded-checkout:has(loading) {
  display: block;
  position: relative;
  height: 200px;
  overflow: hidden;
}
branded-checkout *:has(loading) {
  position: static !important;
}
branded-checkout loading {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background: #fff;
}
branded-checkout product-config-form loading {
  z-index: 99;
}

This is not the best solution, but the best css only option.

[wrandall22]

cc @dr-bizz on discussion above ^

[wjames111]

@clonge thanks that's super helpful, I'll give that a try and play around a little more.

[dr-bizz]

Stakeholders are in the middle of http://give-stage2.cru.org/ give site staging UAT and there were some issues giving EFT and CC yesterday.
We think they may have been caused by some deploys to web https://github.com/CruGlobal/give-web/actions.
If you could hold off changes that might break http://give-stage2.cru.org/ until we finish UAT, that will be appreciated.