Closed Bug 1597529 Opened 4 years ago Closed 1 year ago

Implement contain-intrinsic-size

Categories

(Core :: Layout, enhancement, P3)

Product:
Core
Component:
Layout
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: vmpstr, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Steps to reproduce:

Please consider implementing CSS intrinsic-* set of properties (aka intrinsic-size).

Spec draft: https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override
w3c issue: https://github.com/w3c/csswg-drafts/issues/4229
tests: https://wpt.fyi/results/css/css-sizing/intrinsic-size

Component: Untriaged → CSS Parsing and Computation
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Status: UNCONFIRMED → NEW
Component: CSS Parsing and Computation → Layout
Ever confirmed: true
Priority: -- → P3

FYI, this has been renamed to contain-intrinsic-size and only applies with contain:size:
https://github.com/w3c/csswg-drafts/issues/4531

Summary: Implement intrinsic-size → Implement contain-intrinsic-size

See https://github.com/w3c/csswg-drafts/issues/5432 where this property has now been converted to a shorthand, with per-axis longhand values.

See Also: → 1755565
Depends on: 1778062
Depends on: 1780475
Depends on: 1781045
Depends on: 1781097
Depends on: 1781995
Depends on: 1782025
Depends on: 1778296
Depends on: 1782297
Depends on: 1782312
Depends on: 1782529
Depends on: 1782540
Depends on: 1782589
Depends on: 1782673
Depends on: 1783006
Depends on: 1783296

Depends on: 1783611

Depends on: 1783611
Depends on: 1783687
Depends on: 1783953
No longer blocks: 1672641
Depends on: 1785063
Depends on: 1788068

Are any documentation impacts of this work that need to be recorded now? (I'm investigating for the docs team).

My understanding is that

  • content-visibility can be applied to an HTML element, such as a canvas, or an SVG element to effectively tell the user agent that the element doesn't have to be rendered (or that it may not need to be rendered and the user agent can decide when/if).
  • The contain-intrinsic-size can be applied at the same time to hint to the user agent how big the rendered element is so that the required space can be reserved for layout.
  • All of this is being delivered behind the pref layout.css.contain-intrinsic-size.enabled.
  1. I assume the plan is to ship content-visibility and contain-intrinsic-size when all aspects as covered in the current spec are complete?
  2. Any ETA on that?
  3. Is there any reason not to add the preference for FF104 with a note that this is partial against content-visibility and contain-intrinsic-size ?
  4. Is there a different pref for content-visibility?
Flags: needinfo?(dholbert)

(In reply to Hamish Willee from comment #6)

Are any documentation impacts of this work that need to be recorded now? (I'm investigating for the docs team).

I don't think the contain-intrinsic-size work has had any effect without enabling layout.css.contain-intrinsic-size.enabled, and it's disabled by default.

  • content-visibility can be applied to an HTML element, such as a canvas, or an SVG element to effectively tell the user agent that the element doesn't have to be rendered (or that it may not need to be rendered and the user agent can decide when/if).

But that's bug 1660384.

  • The contain-intrinsic-size can be applied at the same time to hint to the user agent how big the rendered element is so that the required space can be reserved for layout.

contain-intrinsic-size: <length> doesn't need content-visibility, it works with any feature that triggers size containment, like contain: size.

contain-intrinsic-size: auto <length> needs content-visibility, otherwise it behaves as contain-intrinsic-size: <length>.

  • All of this is being delivered behind the pref layout.css.contain-intrinsic-size.enabled.

That's for contain-intrinsic-size, content-visibility has its own flag.

  1. I assume the plan is to ship content-visibility and contain-intrinsic-size when all aspects as covered in the current spec are complete?

They are related features but can be used independently and can be shipped separately.

contain-intrinsic-size is basically complete except for https://github.com/w3c/csswg-drafts/issues/7598

  1. Any ETA on that?

A bit tricky to say for contain-intrinsic-size, since it's basically complete but supporting multiple fragments according to https://github.com/w3c/csswg-drafts/issues/7598 will probably require changing ResizeObserver, which in turn will require discussing various issues with the CSSWG. Though maybe this can be deferred and ship without support for multiple fragments (like Blink did).

For content-visibility better ask Martin Robinson, but probably it will take longer, especially content-visibility: auto.

  1. Is there any reason not to add the preference for FF104 with a note that this is partial against content-visibility and contain-intrinsic-size ?

I don't know what "add the preference for FF104" means.

  1. Is there a different pref for content-visibility?

Yes, layout.css.content-visibility.enabled.

Flags: needinfo?(dholbert)

Thanks Oriol Brufau - very helpful.

I don't know what "add the preference for FF104" means.

FYI Only, it means publicly recording the preference so that the feature can be tested/has external visibility. In this case: https://github.com/mdn/browser-compat-data/pull/17840 and https://github.com/mdn/content/pull/20911

Does Firefox also (separately) support the associated longhand and logical contain-intrinsic properties (either as part of this or in some other bug item)?

  • contain-intrinsic-width
  • contain-intrinsic-height
  • contain-intrinsic-block-size
  • contain-intrinsic-inline-size

I'd like to copy the firefox browser compatibility data for the contain-intrinsic-size property for the width/height.

Note, Chromium already implements all of these apprarently: https://bugs.chromium.org/p/chromium/issues/detail?id=1157844, https://chromestatus.com/feature/5737051062272000 , https://chromestatus.com/feature/5709654999957504

Flags: needinfo?(oriol-bugzilla)

Yes, it looks like those per-axis properties were all added as part of the same commit, in https://hg.mozilla.org/mozilla-central/rev/a5256a2aded7

See e.g. this chunk which added testing for all 4 of those plus the contain-intrinsic-size shorthand:
https://hg.mozilla.org/mozilla-central/rev/a5256a2aded7#l5.12

Flags: needinfo?(oriol-bugzilla)
Depends on: 1792886

Enabled by default in bug 1792886.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

Docs for this are nearly done. The example allows you to toggle content-visibility values and also to toggle the contain-intrinsic-size. What it shows mostly for the contain-intrinsic-size case is that if you don't specify this and the content is not being drawn then the element collapses to zero.

It doesn't feel all that great as an example though because it shows more about content-visibility than size. I.e it shows that the child element can overflow the parent when visibility is "visible" but otherwise is cropped to the specified size. If you have time would appreciate advice - do you think it would be better just display the hidden state and toggle contain-intrinsic-size on and off or is there value in showing what it shows?

If you don't have time, cancel the need info and I will move on.

Flags: needinfo?(dholbert)

Maybe the demo could offer non-auto values too, and add contain to make it less about content-visibility?

<p>contain-intrinsic-size:
<select>
  <option>none</option>
  <option>40px 130px</option>
  <option>auto 40px auto 130px</option>
</select></p>
<p>contain:
<select>
  <option>none</option>
  <option>size</option>
  <option>strict</option>
</select></p>
<p>content-visibility:
<select>
  <option>visible</option>
  <option>auto</option>
  <option>hidden</option>
</select></p>

(I'll take Oriol's comment 13 as addressing the needinfo from comment 12.)

Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.