Stratakit css cleanup

[jjspace]

Description

This pr tackles a few different things but all focused around Sandcastle's CSS and stratakit

• Started using the unstable_loadStyles function from stratakit to initialize all css variables from stratakit inside non-react pages
• Created .stratakit-mimic-* css components to style components in the viewer bucket and standalone pages to match the stratakit styles.
  • The stylesheets in public/styles/stratakit-mimic/components are sourced directly from stratakit with minor changes to the class names to avoid naming conflicts. This was done to reduce duplicated work and make sure we match the styles as close as possible
  • Also added some "base styles" for common semantic elements like <button> to allow matching styles without requiring people to know the classes or html structure
  • This also involved an update to the Sandcastle API to match the new class names and required structure
• Updated all the existing CSS to utilize stratakit token variables
  • There are a few tokens missing related to the borders. I created an "extension" stylesheet to define these for now and make it easy to swap out later
• Updated the "Viewerless Sandcastle" I've been using to test to include all commonly expected inputs in the toolbar for easy testing
  • This might turn into a "Sandcastle API" test sandcastle long term

Issue number and link

Part of #12566

Testing plan

• Run npm run dev from the sandcastle package or npm run build-sandcastle and npm start from the repo root
• Make sure all page layout and styling still looks correct (to verify variables set up correctly)
• Make sure inputs in sandcastle toolbars look good
• Check sandcastles that use the Sandcastle API for inputs
• Check sandcastles that do not use the Sandcastle API for inputs, both should look good
• Check the standalone looks good
• Open a slow loading sandcastle and make sure there is no white flash or anything jarring, both the bucket and standalone pages. I noticed we were having some FOUC issues and tried to address with some embedded styles

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[ggetz]

Totally can be a follow-up action—and we should check with the stratakit designers—but I might suggest styling the slider track consistently with the loading bar by matching colors, removing outlines, and adjusting width.

[ggetz]

Updated the "Viewerless Sandcastle" I've been using to test to include all commonly expected inputs in the toolbar for easy testing
This might turn into a "Sandcastle API" test sandcastle long term

I agree that a sandcastle (or a couple sandcastles, depending) just demonstrating how to use the Sandcastle API would be useful for testing, but would also be good for the sake of documentation as well.

[ggetz]

The background panel of "3D Models Dev" and many other examples appear to be super transparent when compared to the Viewerless example and "3D Models", which are more solid. The contrast looks problematic IMO.

vs

or

It looks like this is due to the custom CSS per-example. Can we remove them here?

[ggetz]

Low priority, so please add it to end the running list if you agree: I just noticed that the Insert > UI element command adds the snippet to the end of the document rather than where the cursor currently is. I would expect it to be added where the cursor is, like how copy/paste works.

[ggetz]

Also low priority to add at the bottom of the list: I noticed the "Loading..." message bounces around as other elements in Sandcastle load. I think we should try to avoid that if possible.

[ggetz]

Some naming suggestions for clarity and future-proofing:

Created .stratakit-mimic-* css components to style components in the viewer bucket and standalone pages to match the stratakit styles.
The stylesheets in public/styles/stratakit-mimic/components are sourced directly from stratakit with minor changes to the class names to avoid naming conflicts. This was done to reduce duplicated work and make sure we match the styles as close as possible
Also added some "base styles" for common semantic elements like to allow matching styles without requiring people to know the classes or html structure

Is the term "mimic" used commonly? I might suggest omitting it, or using something more common like "polyfill".

I would suggest moving the "directly sourced" css to public/node_modules/@stratakit/, public/vendor/stratakit/, or a similar path to make it obvious that these were copied directly. I would also suggest adding a comment at the top of styles.css with the corresponding file path(s) if they are shipped somewhere in the node_module package.

Then I would keep the custom adjustments in public/styles/stratakit/components so there is a clear separation for the sake of any potential future maintenance.

[ggetz]

Thanks @jjspace! That's all from me for now 😅

[jjspace]

Thanks @ggetz, some responses for you:

Totally can be a follow-up action—and we should check with the stratakit designers—but I might suggest styling the slider track consistently with the loading bar by matching colors, removing outlines, and adjusting width.

I set the slider coler to the primary accent color for stratakit. This matches "accented" buttons and the switch toggle. I think the more vibrant glow color would be a bit too aggressive. The way I did it now is also relying on the native element so we don't have to implent custom slider elements. We can revist if we want later but I'm going to leave as is for now.

The background panel of "3D Models Dev" and many other examples appear to be super transparent when compared to the Viewerless example and "3D Models", which are more solid. The contrast looks problematic IMO.

As you said most of the differences here are because all sandcastles that used the toolbar specified their own styles for a long time. Happy to include checking for this in the content pass but I don't think it's necessary for this PR

I would expect it to be added where the cursor is, like how copy/paste works.

Noted. It's a lot easier to add it at the end since we don't have to interact with the monaco editor at all. I'll add it to the list to look into later, maybe it's not too hard.

I noticed the "Loading..." message bounces around as other elements in Sandcastle load. I think we should try to avoid that if possible.

I made many edits trying to combat this as much as possible. I thought I had finally quashed it from happening... I don't see it myself anymore but will add it to the list of bugs to look into later

Is the term "mimic" used commonly? I might suggest omitting it, or using something more common like "polyfill".

I don't know if it's common or not but I think it describes what it's there for pretty well. They're not polyfills and I don't want to omit it as that could cause confusion with the actual stratakit elements.

I would suggest moving the "directly sourced" css to public/node_modules/@stratakit/, public/vendor/stratakit/, or a similar path to make it obvious that these were copied directly. I would also suggest adding a comment at the top of styles.css with the corresponding file path(s) if they are shipped somewhere in the node_module package.

The problem is these files are not distributed with the stratakit packages directly. That's part of the whole frustration in trying to use them outside the react setup.

[ggetz]

As you said most of the differences here are because all sandcastles that used the toolbar specified their own styles for a long time. Happy to include checking for this in the content pass but I don't think it's necessary for this PR

I do see your point, but now with the component styling updates the contrast is really low which makes it a usability issue IMO. I would like to see a content update to fix specifically that background color imminently, if not in this PR.

[ggetz]

I made many edits trying to combat this as much as possible. I thought I had finally quashed it from happening... I don't see it myself anymore but will add it to the list of bugs to look into later

Thanks for looking into this. I agree it's probably not worth the time sink right now.

[ggetz]

The problem is these files are not distributed with the stratakit packages directly. That's part of the whole frustration in trying to use them outside the react setup.

Fair. My concern was mostly around making a clear distinction between what we're doing specifically to duplicate stratakit versus our own adjustments. I think putting them in different locations is the clearest way to do so, but let me know if disagree with that point.

[jjspace]

I do see your point, but now with the component styling updates the contrast is really low which makes it a usability issue IMO. I would like to see a content update to fix specifically that background color imminently, if not in this PR.

@ggetz Per our discussion yesterday I've centralized the toolbar styles to make the background consistent. I put it in a separate PR just to make the review a little easier: #12848

[ggetz]

Thanks for addressing these @jjspace!