[css-overflow-3] computed value rules for 'overflow' should not depend on whether something is a replaced element

[dbaron]

css-overflow-3 states rules for determining the computed value of the overflow property that depend on whether something is a replaced element:

On non-replaced elements, the visible/clip values of overflow compute to auto/hidden (respectively) if one of overflow-x or overflow-y is neither visible nor clip.

On replaced elements, all values other than visible compute to clip.

I didn't think computed values could depend on whether something is a replaced element; I don't think that's known at value computation time (e.g., for <object>).

If that's the case, I'd suggest that the non-replaced rule above apply to all elements, and then the replaced rule be handled at used value time. (This is a behavior change in the behavior of combinations of visible on one axis with a value other than visible or clip on the other axis. However, I suspect that behavior matches implementations today (at least Gecko's), in so far as the difference in behavior on replaced elements is observable.)

(Noticed while trying to write edits for #6212.)

[khushalsagar]

This behaviour for replaced elements is a recent addition to the spec. See discussion here. Since replaced elements need to be clipped by default, we also have UA CSS which depends on the element type to apply the default behaviour (see change here).

I didn't think computed values could depend on whether something is a replaced element; I don't think that's known at value computation time (e.g., for <object>).

That's interesting. What are the cases where <object> could be a non-replaced element?

[dbaron]

That's interesting. What are the cases where <object> could be a non-replaced element?

Items one and three in this example. Note that distinguishing items two and three at value computation time is particularly hard, but I think in general it may be difficult to distinguish replaced elements during value computation, just because that's not the sort of information that's expected to be needed during selector matching and value computation.

[Loirooriol]

<img> can also be replaced or not depending on whether src points to a valid image, example.

[khushalsagar]

Had a discussion with @dbaron today. The current implementation for how overflow is applied to replaced elements is dependent on the element's tag (for example img and object in this case). This is required for any values being supplied by UA CSS and wasn't the part dbaron was concerned about. @Loirooriol please clarify if you disagree.

The concern was with modifying the style at value computation to apply the overrides in the spec. Implementation wise they follow the same pattern as UA CSS and depend on the element's tag. But this runs into the case where the same tag might not be rendered as a replaced element (like when img falls back to alt test).

Given that we need to rely on the element tag to identify a replaced element in UA CSS, it seems reasonable to rely on the element's tag (which is known at value computation time) when applying overrides to its computed value as well. I see some precedent for this in code but I could only trace back to the spec here.

@tabatkins for an opinion too.

[Loirooriol]

@khushalsagar overflow: scroll triggers scrollbars on a non-replaced img in both Firefox and Chromium. https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10447

[khushalsagar]

Ok. I see the point now. We can avoid regressing the behaviour for img elements by applying the rule for replaced elements at used value time as David suggested. So only when the element is rendered as a replaced element it won't create a scroll container (consistent with the behaviour today).

But <object> would still be affected because the UA CSS rule is marked with !important to keep these elements from generating ink overflow based on the discussion here.

[tabatkins]

Yeah, it's been years since it's come up, but I remember now that we can't have computed values depending on replaced-ness, due to image fallback and related stuff - we didn't want to have to wait for network responses before we were able to inherit values.

Unfortunate in general, but in this case indeed not a real problem - having the overflow adjust at used-value time works just fine since this isn't an inherited property and it would be very weird to explicitly use inherit on it. I'll go tweak the spec.

[khushalsagar]

The spec has been updated and the implementation change is landing in chromium soon. Could we close this issue now?