fix(lit): replace unsafeCSS with CSSStyleSheet for structural styles

[iamrajhans]

This PR removes unsafeCSS usage from the Lit renderer to fix internal build policy failures reported in issue #462.

Specifically, in renderers/lit/src/0.8/ui/styles.ts, unsafeCSS(Styles.structuralStyles) was replaced with a safer stylesheet construction flow:

• build a CSSStyleSheet
• load Styles.structuralStyles using replaceSync
• return [] as a fallback when CSSStyleSheet is unavailable or fails

This preserves behavior (shared structural styles still applied) while eliminating direct unsafeCSS usage.

Fixes: #462

Pre-launch Checklist

• I signed the CLA.
• I read the Contributors Guide.
• I read the Style Guide.
• I have added updates to the CHANGELOG.
• I updated/added relevant documentation.
• My code changes (if any) have tests.

[gemini-code-assist]

Code Review

This pull request effectively addresses the security concern of using unsafeCSS by replacing it with the safer CSSStyleSheet API. The implementation is solid, with a good fallback for environments where CSSStyleSheet is not supported. I have one suggestion to improve debuggability by logging potential errors during stylesheet creation.

[gemini-code-assist]

It's good practice to log errors that are caught, even when providing a fallback. Swallowing the error here could make it difficult to debug if new CSSStyleSheet() or replaceSync() fails for an unexpected reason. Adding a console.error would provide visibility into such issues without changing the fallback behavior.

  } catch (e) {
    console.error('Failed to construct structural styles:', e);
    return [];
  }

[ditman]

This is good advice, and if we were to keep this behavior of returning an empty array, we should also console.error in the cases where CSSStyleSheet() is not available. (But IMO, we shouldn't)

[ditman]

I left some comments, and I think @ava-cassiopeia should have final say, but this looks good to me! Thanks for the fix!

(I'm also modifying the description of this PR to link it to the issue about removing unsafeCSS)

[ditman]

The CSSStyleSheet() constructor seems to be very widely supported, I don't think this check is necessary.

(In case we want to keep this, I'd suggest adding a console.error on the cases where we return [] to let the user know why their stylesheets are not working!)

[ditman]

In what cases would this fail? Why would we want this try-catch here? (I don't see any "Exceptions" sections in the docs?)

[ditman]

This is good advice, and if we were to keep this behavior of returning an empty array, we should also console.error in the cases where CSSStyleSheet() is not available. (But IMO, we shouldn't)

[ava-cassiopeia]

This generally LGTM, but I think @ditman has some solid points, so I'll wait to approve until those are addressed.

[iamrajhans]

hi @ava-cassiopeia @ditman could you please review, made the required changes

[ava-cassiopeia]

I think @ditman's comment still applies here: under what condition do we expect this to fail? And for those, do we really want the application setup to just keep going with an empty set of structural styles?

[iamrajhans]

The only expected failure mode is non-browser module evaluation, where CSSStyleSheet is unavailable (Node/test/SSR). In browser runtime, silently proceeding without structural styles is not acceptable.

I’ll update the behavior to:

• return [] only in non-browser contexts (typeof window === "undefined"), and
• throw on browser-side stylesheet construction failures (constructor/replaceSync) instead of falling back silently.

This preserves test/SSR import stability while ensuring browser runtime does not degrade without explicit failure.