[w3c/webcomponents] Need consensus on relative priority of ::part styles and inline styles (#847)

I’ve discovered that early implementations of CSS Shadow Parts show a discrepancy with respect to the relative importance of a `::part` selector and inline styles. I’m filing this so we can confirm agreement on what behavior is expected.

In this [demo](https://jsbin.com/megipav/edit?html,output), a test-element defines a shadow containing a part named “swatch”. The inline style for that part specifies `background-color: green`, while the outer page defines a rule with `::part(swatch)` that specifies `background-color: red`.

```html
<style>
  test-element::part(swatch) { background-color: red; }
</style>
<test-element>
  #shadow-root
    <div part=“swatch” style=“background-color: green;”></div>
</test-element>
```

What color is the swatch?

* Chrome says that the outer page wins, so the swatch is **red**. That had surprised me, so I'd filed this [Chromium bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1013754#c8). @emilio closed it as Won't Fix, commenting that: "The ::part rule belongs to a different tree context than the style attribute, and the ::part rule tree context comes before the shadow tree in the [shadow-including tree order](https://drafts.csswg.org/css-scoping/#shadow-cascading)”.
* Firefox Nightly shows the inline style winning; the swatch is **green**. Emilio filed a [Mozilla bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1588431) to address that.
* WebKit exhibits the same behavior as Firefox, so the swatch is **green** (according to Emilio on the above bug thread). He filed a [WebKit bug](https://bugs.webkit.org/show_bug.cgi?id=202919) to track that.

I hold no strong feelings on this, but my initial expectation had been the Firefox/WebKit behavior. Inline styles on an element in the light DOM win the cascade, so I’d been surprised that inline styles didn't win in this case.

I asked @fergald for his opinion. He replied:

> I would expect that from outside the component ::part always wins, unless the component has set important. Whether the element got its style from an inline attribute or matched a selector shouldn't really matter and in fact that seems very much like an implementation detail that shouldn't leak outside.of the component.

I can live with that, but it still seemed worth surfacing here to confirm.

One potential challenge with having ::part styles override inline styles is that it constrains how component authors style the shadow tree. Our own components make extensive use of inline styles to render changes in component state, and inline styles can’t be marked as important. In some cases, a component might have critical styling — i.e., styling without which the component can’t function — that we’re currently defining with inline styles.

It’s possible that we’ll be able to rewrite such components to define the critical styles through a stylesheet that made use of `!important`, but it will take some time to confirm whether we can do that everywhere. I'm slightly concerned that we'll hit cases where a critical inline style contains calculated values that will be challenging to workaround using stylesheet rules — but it's possible we'll be fine.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/847