Resolve parameter conflation in RuleSet methods

[JakeQZ]

Several RuleSet methods currently accept a string or a Rule (or null):

• getRules;
• getRulesAssoc;
• removeRule.

For static analysis, it would be good to avoid this overloading.

getRules

From the PHPDoc:

Passing a Rule behaves like calling getRules($rule->getRule())

Does this shortcut have much value, or could we deprecate passing a Rule without offering an alternative?

getRulesAssoc

From the PHPDoc:

This method exists mainly for backwards-compatibility and is really only partially useful.

Can we deprecate and remove it?

removeRule

This method seems to provide two distinct functions, depending on whether a string or a Rule is passed. I think we should create a separate method for one or the other, with the alternative parameter being deprecated in the original.

Question is, which alternative parameter should be deprecated (and moved to the new method)?

I think the most common usage of the original method should be retained. But I don't know what that is...

[JakeQZ]

@sabberworm, @oliverklee, your input and/or agreement would be welcome, particularly regarding removeRule().

[oliverklee]

And I wasn't aware there was even an API for modifying CSS in JS. :-)

[oliverklee]

I've made a note that we might want to closely follow the CSSOM (at least) for the rewrite.

[oliverklee]

For removeRule(), I'd be fine with either way as long as we deprecate and drop one of the parameter types.

[oliverklee]

Ah, that's why:

The values of CSS are represented untyped, that is using String objects.

https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model

So their object model is a bit different to what we have.

[JakeQZ]

Yes, there doesn't seem to be an object/interface in CSSOM that represents a "(property) declaration".