feat: split no-static-styles-assignment messages

[saberzero1]

Summary

Fixes false positive where no-static-styles-assignment flagged el.setCssProps({ 'padding-bottom': 'unset' }). The rule now enforces the intended API contract: setCssProps is for CSS custom properties (--*) only, and setCssStyles is for standard CSS properties only.

Problem

The rule had a single avoidStyleAssignment message that told users "Use the setCssProps function if the CSS properties need to change dynamically.", but then flagged setCssProps itself when called with standard property names. This was contradictory: the error message recommended the exact API it was reporting on.

Additionally, setCssStyles (Case 4) had identical logic to setCssProps (Case 3); it flagged non---* keys. Since setCssStyles is the correct API for standard CSS properties, this was backwards.

Changes

New message IDs (lib/rules/noStaticStylesAssignment.ts)

• avoidNonCustomPropertyInSetCssProps: reported when setCssProps receives a standard property key. Tells the user to use setCssStyles or CSS classes instead.
• avoidCustomPropertyInSetCssStyles: reported when setCssStyles receives a --* key. Tells the user to use setCssProps instead.
• Updated avoidStyleAssignment: now mentions both setCssProps and setCssStyles as alternatives for the generic el.style.* cases.

Fixed setCssStyles logic (Case 4)

• Flipped the condition: now flags keys that start with -- (custom properties don't belong in setCssStyles) instead of keys that don't start with --.

Tests (tests/noStaticStylesAssignment.test.ts)

• Added valid cases: setCssStyles with standard property, setCssStyles with computed key
• Updated invalid setCssProps case to expect avoidNonCustomPropertyInSetCssProps
• Replaced invalid setCssStyles case: now tests { '--my-var': 'blue' } expecting avoidCustomPropertyInSetCssStyles

What changes for consumers

• el.setCssProps({ '--my-var': 'value' }) -> no error (correct usage)
• el.setCssProps({ 'color': 'blue' }) -> error with a message directing to setCssStyles or CSS classes
• el.setCssStyles({ 'color': 'blue' }) -> no error (correct usage, previously flagged)
• el.setCssStyles({ '--my-var': 'value' }) -> error with a message directing to setCssProps
• All el.style.* direct assignments -> unchanged behavior, updated message text

[liamcain]

I'm not sure that this is necessary. Isn't this already a linting error since setCssStyles expects CSSStyleDeclaration as the key

[liamcain]

This distinction isn't that significant so it's probably not really worth a custom linter rule for the setCssStyles case.

[mnaoumov]

Why

el.setCssStyles({ 'color': 'blue' }) is allowed now?

[saberzero1]

Why

el.setCssStyles({ 'color': 'blue' }) is allowed now?

In the Obsidian API, it is defined as such:

interface HTMLElement extends Element {
  setCssStyles(styles: Partial<CSSStyleDeclaration>): void;
  setCssProps(props: Record<string, string>): void;
}

setCssStyles expects CSSSTyleDeclaration and is meant for standard properties (e.g. border, height, margin-inline-start, etc.) while setCssProps is meant for CSS custom properties

Using classes remains as an option for either.

[mnaoumov]

@saberzero1 this contradicts to https://docs.obsidian.md/Plugins/Releasing/Plugin+guidelines#No+hardcoded+styling

[saberzero1]

@saberzero1 this contradicts to https://docs.obsidian.md/Plugins/Releasing/Plugin+guidelines#No+hardcoded+styling

Using variables or classes is still preferable. At the same time, setCssStyles() is an Obsidian-specific API method; not a standard method. If it is not supposed to be used at all, then the method should be deprecated in my opinion.