New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant to be displayed inline, in addition to large ones between paragraphs).
What kind of fragile markup and problematic CSS global rules are you worrying about?
> What kind of fragile markup and problematic CSS global rules are you worrying about?
I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case.
As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.
A lot of applications have a long lifetime. They are not shipped only once. If I want to add a new feature, say allow users to perform a new operation in an existing screen, I will have to update a few components for this.
You want to preserve the theme an consistency of the UI, but adapt its functionality. For this type of changes the semantic version is problematic.
Ordinary changes fall within the boundaries of the existing design system: for example, "a new operation in an existing screen" probably means adding instances of a few existing components (button, paragraph, title, section, pop-up submenu, etc.), with no impact on styles, not "updating" components.
What kind of fragile markup and problematic CSS global rules are you worrying about?