- From: Jan Miksovsky via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Jan 2019 22:05:53 +0000
- To: public-css-archive@w3.org
@caridy I think that's unavoidable — and also fine. I'm starting from the assumptions that: 1. Devs want to build components from smaller subcomponents. 2. Components (including subcomponents) may have idiosyncratic state, i.e., conditions that are not universally applicable or meaningful for all components. 3. Page authors want to style components, including those portions provided by subcomponents, and including styling for unique states at both the component and subcomponent level. So if I build components from subcomponents, then I also take on both the risk _and opportunity_ of being able to swap out those subcomponents for better ones in the future. That might break someone's careful styling of my component that assumes the old subcomponent. That's unfortunate, but to me no different than the possibility that future work might force me to make a breaking change in a component's JS API. And the very existence of a `part` at all implies a contract that might get broken. If I add a `part`, I can't guarantee to the world that I'm never going to take that part away. I would think devs could approach CSS support exactly like JS support: try hard not break contracts, but allow for that possibility, and use conventions like semver and documentation to signal when contracts are getting broken. -- GitHub Notification of comment by JanMiksovsky Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-451292518 using your GitHub account
Received on Thursday, 3 January 2019 22:05:55 UTC