Why does CSS ::part override JavaScript element.style?

Question

I have an HTML custom element that inherits from HTMLElement. The template contains:

<input type="text" part="input"/>

Sample CSS:

  my-element::part(input) {
    padding-right: 1px;
  }

Sample JavaScript (inside class MyElement {}):

  this.input.style.paddingRight = "25px";

The Style inspector in DevTools (Rules in Firefox) crosses out the ::part declaration for padding-right and shows:

  element.style {
    padding-right:25px;
  }

But the computed value inspector shows padding-right:1px and it's rendered as 1px.

The JS code is running after the page fully loads. I don't see a straightforward way around this behavior. If I modify a CSS property for this element in JS, then I cannot declare it CSS. At least not with padding.

Why does a pseudo-element of the custom element take precedence over the element's own style?

The fact that the Style/Rules inspector disagrees with the Computed inspector makes me think this is a bug in both browsers, but I'm no expert. I have not yet tried this on browserstack to check other platforms. Right now I'm focused on working around this unexpected behavior.

It's a bit of work to create a working demo snippet, and the behavior is the same across Firefox and Chrome in Win11, so I'll wait until someone requests it.

I need to check the specs, but iirc the idea of ::part is to allow to overwrite the style of the custom element; you add a basic style to your elements but expose elements with part so that the user of the component can change the style. Due to that it has a higher specificity. — t.niese
– t.niese, Commented Oct 9, 2024 at 17:34
If I modify a CSS property for this element in JS, then I cannot declare it CSS. At least not with padding. what do you mean with that? — t.niese
– t.niese, Commented Oct 9, 2024 at 17:36
@t.niese - I mean what my hypothetical example illustrates, and what the accepted answer here details: Styling this in CSS with ::part takes precedence over modifying the value in JavaScript with input.style. To me this was a surprise because it's the first time I've seen a CSS rule override element.style. Not even CSS #id does that. important solves it, thankfully. — Sideways S
– Sideways S, Commented Oct 9, 2024 at 17:42
@Kaiido - given the agreement on the spec, the part that seems like a bug to me is the display in the DevTools inspectors. — Sideways S
– Sideways S, Commented Oct 10, 2024 at 12:35

ipodtouch0218 · Accepted Answer · 2024-10-09 17:33:11Z

2

The ::part pseudo-element works in conjunction with browser rendering layers and the cascade order of styles. To fix this you can force higher specificity in JavaScript code:

this.input.style.setProperty('padding-right', '25px', 'important');

This code will ensure that the inline style with !important takes precedence over the ::part pseudo-element styles.

edited Oct 9, 2024 at 17:33

ipodtouch0218

3,4259 gold badges17 silver badges31 bronze badges

answered Oct 9, 2024 at 17:18

ajdina

361 bronze badge

Sign up to request clarification or add additional context in comments.

2 Comments

Sideways S Over a year ago

Great. My only issue is trivial: I was using Object.assign() to assign a block of CSS properties, now I can't do that. Thanks for the prompt reply.

Sideways S Over a year ago

fyi - I see you're new here. You can format code using Markdown. Here are the local docs: stackoverflow.com/editing-help

Sideways S · Accepted Answer · 2024-10-12 15:07:17Z

Here's a workaround for the issue as it relates to font properties. It avoids ::part and thus !important, which @Danny'365CSI'Engelman deemed a "red flag".

Setting all of the shadow DOM <input> (the ::part element)'s CSS font properties to inherit allows me to set those properties for the custom element itself, not the ::part. If you have multiple shadow DOM elements with different font settings then this is not possible, but how often does that happen?

<template id="my-template">
  <style>
    input {
      font:inherit;
      font-kerning:inherit;
      font-size-adjust:inherit;
      font-synthesis:inherit;
      font-optical-sizing:inherit;
      font-palette:inherit;
    }
    ...

AFAICT that's all the CSS font properties that are not "experimental" or quasi-deprecated (like font-feature-settings). No more ::part or !important for fonts.

This solution might work for other non-layout properties. For example, it doesn't work for padding because it doubles the amount of padding by applying it to both the DOM and shadow DOM elements.

Danny '365CSI' Engelman · Accepted Answer · 2024-10-10 09:38:34Z

-1

I can't replicate your findings, there must be something else in your code

Needing !important is almost always a red flag for CSS issues

<style>
  my-element::part(input){
    background: green;
  }
  my-element::part(input2){
    padding-right: 1px;
  }
</style>
<my-element>
  <template shadowrootmode="open">
    <style>
      input{
        padding-right:25px;
      }
      span{
        background:pink
      }
    </style>
    <input part="input input1"><span>25px padding-right after input1</span>
    <br>
    <input part="input input2"><span>1px padding-right after input2</span>
  </template>
</my-element>

input1:

input2

edited Oct 10, 2024 at 9:38

answered Oct 10, 2024 at 9:28

Danny '365CSI' Engelman

22.3k2 gold badges49 silver badges64 bronze badges

3 Comments

Kaiido Over a year ago

They're using inline style, you're not.

Danny '365CSI' Engelman Over a year ago

ah yes, tnx, in HTML inline styles overrule CSS styles. (and in SVG the other way round)

Kaiido Over a year ago

Nope, same in svg, you're confusing with presentation attributes

Collectives™ on Stack Overflow

Why does CSS ::part override JavaScript element.style?

3 Answers 3

2 Comments

Comments

input1:

input2

3 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

2 Comments

Comments

input1:

input2

3 Comments

Your Answer

Sign up or log in

Post as a guest

Related