[cssom-view-1] Further restrictions on resolved values for insets?

[bfgeek]

https://drafts.csswg.org/cssom-1/#resolved-values

Currently today all engines return the used value for the inset properties (top/right/bottom/left).

It could be possible to place further restrictions on when this occurs based on the position of a box.
Specifically it may be web-compatible to do this for:

• sticky (relatively new position mode).
• relative, implementations returning junk information[1] for the "interesting" cases.

The primary use-case for this is to determine the used offsets when things are absolutely positioned.
Thoughts?

[1] See: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11960 - Even though the used value of top should be 0px implementations will non-zero values.

[Loirooriol]

Not a strong opinion about returning computed vs used value, but I want round-tripping. Why should it be zero tough, the containing block isn't 0px tall.

[bfgeek]

Relpos percentages are resolved against the initial block-size of the containing block, not the used. (Try setting the top inset to the output value and see the content shift).

[Loirooriol]

Is this specified anywhere? From the definition it seems it should be the actual size https://drafts.csswg.org/css-position/#valdef-top-percentage

The inset is a percentage relative to the containing block’s size in the corresponding axis

[bfgeek]

Is this specified anywhere? From the definition it seems it should be the actual size https://drafts.csswg.org/css-position/#valdef-top-percentage

Nope - but its what all implementations do. :)

[Loirooriol]

Relpos percentages are resolved against the initial block-size of the containing block

From my testing, what happens is that if the containing block doesn't have a definite size, these percentages are considered cyclic, and are treated as auto (like would happen for height).

If this is required by compat, it should be specified, and CSSOM should take it into account in order to round-trip.

Otherwise I would prefer changing the layout logic to match the spec and CSSOM. I don't think it makes sense to treat the percentage as cyclic, since it shouldn't affect the size of the containing block.

[bfgeek]

Otherwise I would prefer changing the layout logic to match the spec and CSSOM. I don't think it makes sense to treat the percentage as cyclic, since it shouldn't affect the size of the containing block.

My guess as all engines have had this behaviour for many years now this would be pretty baked in. This is also orthogonal to this issue, (for relpos i'm proposing returning computed values, which would round trip in either case).

[css-meeting-bot]

The CSS Working Group just discussed [cssom-view-1] Further restrictions on resolved values for insets?, and agreed to the following:

• RESOLVED: for sticky pos, getComputedStyle will return computed values for insets

The full IRC log of that discussion

<bramus> iank_: i’ll outline how we got here … were investigating bugs when you acces trbl from gCS. these return used values
<bramus> … for pos:rel things are broken in x-compatible ways
<bramus> … but also if there is a new positioning mode ever: do we want to continue returning offsets from gCS?
<bramus> … added use counter for pos:sticky and returning offsets is very rare
<bramus> … want to check if we restricting when to return used insets
<bramus> … as for sticky, everyone has bugs about this
<emilio> q+
<bramus> … are ppl interested in this?
<astearns> ack emilio
<bramus> emilio: do you know how feasible to ??? relative?
<bramus> iank_: need to investigate
<astearns> s/???/also restrict/
<bramus> … usecounters are relatively high but i dont know how they are actually uses
<bramus> … for sticky (with % or calc) it is 0.0001% of page loads (very low)
<bramus> … for relative usecounter is sitting at 20%-ish
<ydaniv> q+
<bramus> emilio: in general the more computed styles that gCS returns the better
<bramus> … this is pretty obvious for non-abs pos
<bramus> … so sounds good in general, but feels a bit weird to treat sticky/relative differently
<bramus> iank_: today, relative only returns good values in chromium if you are non-inline
<bramus> … all sorts of weirdness ???
<bramus> … we may end up in state where sticky and rel need to be treated differently
<astearns> ack ydaniv
<bramus> … but sticky should be web compatible
<bramus> ydaniv: I needed sth for sticky: to get the static offsets of an element that could be stuck. currently impossible. had to force to static pos and read the offsets and then put it back to sticky
<bramus> iank_: but you are not using gCS there?
<bramus> ydaniv: not for ???
<bramus> iank_: yes, just talking about gCS for trbl
<ydaniv> s/???/offsetTop offsetBottom etc./
<bramus> astearns: I agree with emilio about the more we can agree computed values is correct. risk is that if authors have a script to relies on ??? but that seems unlikely to me.
<bramus> iank_: only resolution I am comfortable with right now is about sticky
<astearns> s/???/relative behavior that they want to apply to sticky elements./
<bramus> … only change if your pos;sticky with a % top, gCS would no longer a return a pixel but the percentage
<bramus> astearns: PROPOSED RESOLUTION: for sticky pos, getComputedStyle will return computed values for insets
<bramus> … concerns or objections?
<bramus> RESOLVED: for sticky pos, getComputedStyle will return computed values for insets
<bramus> iank_: thanks!