[css-ui-3] Can |CSS resize| change the value of the width/height properties which has been set with !Important?

[mjf-g]

https://drafts.csswg.org/css-ui-3/#resize:

When an element is resized by the user, the user agent sets the width and height properties to px unit length values of the size indicated by the user, in the element’s style attribute DOM, replacing existing property declaration(s), if any, without !important, if any.

Does this mean that we can't resize an element with !important width/height? The end of this sentence may not be easy to understand.

The div element with the following style can't be resized indeed in Firefox and Chrome.

#div {
  width: 200px !important;
  height: 200px !important;
  overflow: hidden;
  resize: both;
}

[mjf-g]

@frivoal can perhaps confirm this.

This issue is related to https://github.com/whatwg/fullscreen/issues/171. cc: @annevk, @emilio

[frivoal]

Yeah, the phrasing isn't great. what this means is that the style is injected in to a style attribute, and does not include !important. So:

• If there was an existing style attribute with !important, it gets replaced by the new one
• if there was a !important in the stylesheet (not in a style attribute), it wins over whatever resize would like to do.

This has been a while, so I don't fully remember, but I believe this design was much more driven by existing implementations and compat than by a belief this was a smart approach. If this is causing issues and there's evidence than a better behavior would be web compatible, we could definitely consider it.

Otherwise, maybe just an editorial clarification is in order.

[annevk]

Is that equivalent to

Some rules are intended for the author-level zero-specificity presentational hints part of the CSS cascade; these are explicitly called out as presentational hints.

from HTML? It seems like it might be a tiny bit different.

[tabatkins]

It is different, yes. These are explicitly at the style-attribute level (so they'll win over normal width/height declarations in CSS), which is a much higher specificity level than presentational hints.

[annevk]

How are both of these implemented? Do browsers have a more complicated cascade model than the specification allows for? (I'm wondering if HTML and CSS UI monkey patching the cascade is really what we want long term.)

[emilio]

They're implemented literally changing the style attribute I think.

[annevk]

Ah okay, I guess for this the way we could improve clarity then is by having the appropriate (low-level) calls into CSSOM to do just that.

[frivoal]

@annevk are you suggesting this clarification for css-ui, or for HTML, or both?

[annevk]

CSSOM might need to expose the appropriate hook and CSS UI would have to invoke it. (HTML might need a better integration hook from CSS Cascade I suppose to make presentational hints more formalized.)