- From: Lea Verou <notifications@github.com>
- Date: Mon, 27 Feb 2023 11:23:10 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/986/1446925179@github.com>
> Trying to adhere to the way native components works is possibly one of the best solutions. Where outside specificity easily overrules component-level styles. Not sure what you mean. Outside specificity does not overrule anything in shadow dom in native components. > I think a main problem occurs because custom web components generally are far more complex and deeper than form controls and the like. They end up involving a whole series of children. Native components involve 1 text style or 1 background style more often than not. Whereas custom webcomponents can easily see 2 type/color treatments. While the goal is to not style components, the user of a component may have special `em` styling or such. There are some pretty complex native elements, e.g. `<video controls>`. > I think webcomponents having weaker specificity by default, allowing things to overridden would be good. That will involve some unintended side effects when implementing some in your code. But I also think anyone who implements one will see that straight away. This is not a specificity problem at all. I think you may be referring to another issue (potentially the problems discussed in https://github.com/w3c/csswg-drafts/issues/7922 ?). > The other side is more easily invoking the shadow DOM later in the chain. Rather than it being binarily on, encapsulating everything, or not on at all. I think this is the point of #909. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/986#issuecomment-1446925179 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/986/1446925179@github.com>
Received on Monday, 27 February 2023 19:23:22 UTC