You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I didn't realized we have previously discussed this - that's great!
I have a few concerns about overloading the by using the min-content / max-content keywords however.
It creates a slightly weird discontinuity between height: auto and height: min-content. E.g. the auto keyword effectively maps onto either stretch of fit-content within layout (depending on the context). There shouldn't be any difference between a height:auto (where auto maps to fit-content) and height:min-content to height:fit-content.
This is difficult to feature detect. E.g. it'll be difficult for web developers to test if this feature/mode is supported, and min-content/max-content/fit-content is widely supported.
Easy to get wrong when various algorithms request min-content/max-content sizing of different elements.
The definition here will also need to be tweaked. Here you actually don't want it to be strictly the height of the content, rather you want to count the number of lines, then multiply that by the lh unit. The reason for this is that you'll get very subtle "glitches" when typing, e.g. type in a character that uses a font-fallback and has difference ascent/descent metrics, and the textarea will appear glitchy when typing.
+1 to solving this, as well as sizing horizontally, which is insanely difficult to get right today (especially given the spinner arrows, date & time icons etc which are different per UA).
I missed this discussion, but here are my two cents about what was said:
Absolutely agree with @fantasai that we shouldn't have a separate property for this.
I really like the elegance of height: max-content. Placeholders are essentially shadow DOM descendants and thus should automatically be taken into account when calculating intrinsic size.
You don't need separate syntax to round to a multiple of 1lh, we already haveround(up, max-content, 1lh), no? We just need to allow intrinsic size keywords in there, which IIRC was the plan all along.
Scrollbars is a tough one, but perhaps round(up, max-content + 1, 1lh) would suffice for use cases? Or a box-sizing keyword to add scrollbars to height rather than subtract from it?
Chrome and Safari currently implement -webkit-line-clamp to control the number of lines of text, how will the new lh unit interact with the standard line-clamp property in the future?
One option that was brought up at the F2F was using the min-intrinsic-sizing property which messes around with what intrinsic sizing algorithm to use. See notes: #7552 (comment)
A simple proposal which uses this would be:
textarea { min-intrinsic-sizing: from-textarea; }
input { min-intrinsic-sizing: from-input; }
/* or for a global setting */
* { min-intrinsic-sizing: from-textarea from-input; }
(Note see: #8620 that min-intrinsic-sizing needs to be per-axis, above example might be better using min-intrinsic-block-sizing, and min-intrinsic-inline-sizing respectively).
Combined with the lh unit this allows for control over what most folks desire, e.g.
Add max-input keyword to width/height that triggers this behavior on form controls, and maps to max-content behavior on all other elements. @bfgeek is uncomfortable with how this can mix with the existing intrinsic sizing that form controls use (like width: fit-content; max-width: max-input;); auto min size will still look at the intrinsic form stuff.
Add an independent property (e.g. form-sizing: normal | contents) that switches input elements to use content-based sizing in all aspects. @fantasai is concerned this is less discoverable than a width/height keyword.
I would much prefer re-using existing syntax than expanding the language even more, and I share @fantasai's concerns about a new property. Also, I think it should be an antipattern to add syntax that only applies to specific types of elements (e.g. this is why we re-used ::marker for rather than introduce a new pseudo-element).
I think we should explore the compat implications before we rule it out. I could ping the httparchive folks if that would be useful, but we need to formulate a query first. E.g. what about this: % of pages where there is at least one -->
We've observed that in the wild the auto-min sizing behaviour triggers a lot as acting as a floor. Developers often regularly under-size flexboxes (lots of different cases, but one example is when the flexbox is a scrollable area, and sometimes authros will explicitly set a flexbox to 0px in order to trigger this behaviour!). Flexboxes are also used everywhere now - sometimes as the "default" layout (due to the main layout that react-native supports - see https://reactnative.dev/docs/flexbox).
For option (1) switching the min-content/max-content/etc to be different will result in significant compat pain. The primary concern is hanging the auto-min size in flexboxes. E.g. . E.g. this is triggering new behaviour even if you aren't using one of the min-content/max-content/etc keywords.
For option (2) the concern is similar. You might specify something like:
The min-content size would still be the old behaviour, leading to a weird sizing above when you had content exceeding the "legacy" min-content size, the element would size to the "legacy" min-content size.
I think we should explore the compat implications before we rule it out. I could ping the httparchive folks if that would be useful, but we need to formulate a query first. E.g. what about this: % of pages where there is at least one -->
Also, the concept of input sizing needs to take placeholders into account. Generally, when there is no input, you want to use the placeholder for sizing (when one exists), rather than the empty string.
Yeah that's fine, the placeholder is content. It should Just Work.
One thing that makes this a little tricky: when the form element is empty, you almost never want full-blown input sizing, because that would make it 0! You usually want a minimum width/height of 1 character / 1 line. This can be done with min-* of course, but it's somewhat annoying that every use of width: min-content for form elements would also require this boilerplate. I suppose min(1lh, max-content) is more palatable, but we still can't use identifiers in calc functions.
Note: you want max() there. The fact that you use max() to implement min-* behavior, and vice versa, will always be confusing.
Wouldn't you usually be using height here, so min-height: 1lh; is still available? That is, textarea { form-sizing: auto; min-height: 1lh; } would do what you want, right? Are there cases where you need to use height for some other value, but still want to restrict it to a minimum size expressed both in terms of content and an explicit length? (I could maybe see this, with a height: 100% perhaps? I think you could shuffle them around then, tho, with a height: auto; min-height: max(1lh, 100%);.)
If we do have such cases, is it actually form-specific, or is it a more general issue with wanting to apply multiple min/max constraints to an arbitrary element? If the latter, we should handle it in a generic way, such as by making min/max take a comma-separated list of constraints.
Note that for an editable areas, rendering engines will preseve 1lh of height even if its empty to allow content to be added (there is an implicit minimum of 1lh).
@bfgeek If the main problem is with min-width/height: auto, we can define auto there to resolve to the current width/height calculation. In other words, define the “content size suggestion” for form controls to be the current default size. You'll often want to shut off the automatic minimum to allow it to shrink further, but as @LeaVerou points out, authors need to specify an explicit minimum to get reasonable behavior there anyway. I think this interpretation would give us a pretty reasonable and useful behavior tbh.
Disregard my last (deleted) comment. Was concerned about box-sizing: border-box, but seems like I can move to content-box safely and still use something like form-sizing: auto.
Wouldn't you usually be using height here, so min-height: 1lh; is still available? That is, textarea { form-sizing: auto; min-height: 1lh; } would do what you want, right? Are there cases where you need to use height for some other value, but still want to restrict it to a minimum size expressed both in terms of content and an explicit length? (I could maybe see this, with a height: 100% perhaps? I think you could shuffle them around then, tho, with a height: auto; min-height: max(1lh, 100%);.)
If we do have such cases, is it actually form-specific, or is it a more general issue with wanting to apply multiple min/max constraints to an arbitrary element? If the latter, we should handle it in a generic way, such as by making min/max take a comma-separated list of constraints.
Yes, I'd expect min-height to be available, this is not about applying multiple constraints. None of this is particularly hard, it's just that authors need to remember to do it, and the UX without it is pretty terrible. Boilerplate in general is an API smell (though sometimes unavoidable).
Of course, if we define it as a new value, I suppose it could have the reasonable minimum baked in. Are there any use cases where you don't want that minimum?
I have to revert back to border-box. That will probably put in the question the usefulness of form-sizing: auto. The problem is the textarea has vertical padding. That means it's not as simple a min-height: 1lh in all use cases.
Edit: Sorry, keyboard was stuck and commented early.
We would need a value that can be used with calc to play nice. We want to set a max-height of 100%, which is border-box based, so we can't use content-box.
As @bfgeek pointed out in #7542 (comment), it turns out that engines interoperably apply an implicit minimum content-box block-size of 1lh when an element is editable. I opened #8800 to get us to document that. So this actually moots @LeaVerou's concern; a textarea that is switched to "normal block" behavior will not collapse to zero height by default; it'll collapse to 1lh height and still be usable.
@brechtDR This is just about the intrinsic size, so you can always set e.g. width to some explicit value, and that will take precedence over the contents. So individual axis control may not be needed.
The resize property seems an entirely different functionality, so I would be against conflating the two.
I suggest this property be called intrinsic-size, and instead of content and fixed, it should be none and auto.
...
(For iframe maybe dynamically resizing its height according to content is too difficult to implement and/or introduces security risks. But at least the width should behave like all other display: block elements. Potentially the height should just resolve to 0px as if there were no contents?)
...
(For iframe it may not be feasible to actually resize the width according to its contents. Potentially it should just resolve to 0px as if there were no contents?)
When intrinsic-size is set to auto, all the crazy sizing behaviours for img, video, input, select, textarea and iframe are kept as they are currently defined, with img and video sized to their natural width, input, select and textarea to platform defined widths, and iframe to be 300px x 150px, regardless of whether they are block or inline.
Resizing iframes based on their contents is discussed in #1771. And it was resolved on adding a contain-intrinsic-size: from-element.
So that somewhat overlaps with your suggested intrinsic-size property. And I wonder whether that should be reused for this use case.
In any case, I like the idea of introducing something that covers all the mentioned cases, as they are related.
I gave this some more thought of how this should play with intrinsic sizes of replaced elements, and I suggest renaming my previous proposal to intrinsic-sizing to make it clearer that the intrinsic size isn't the thing being changed, but how the intrinsic size affects the layout is being changed.
Suppose you have an . Assuming we apply display: block and intrinsic-sizing: none, and the containing block had 800 pixels, the img tag should occupy the space of 800 x 450 pixels. So the intrinsic size of the replaced element is still 1600 x 900, but the intrinsic size now only contributes to the intrinsic aspect ratio, and not directly to the width and/or height.
For form elements (input, select, textarea), it works either way to describe it as the intrinsic size no longer being platform defined but relying on the content, or the platform defined intrinsic size no longer applies and the element is laid out like a normal element.
This covers:
- input element as a text entry widget
size attribute is ignored if field-sizing:content
- input element as domain-specific widgets (optional)
- input element as a file upload control (optional)
- select element
size attribute is used only for dropdown/listbox switching if
field-sizing:content
- textarea element
cols/rows are ignored if field-sizing:content
Issue: whatwg#6807
Issue: w3c/csswg-drafts#7542
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Oct 30, 2023
This covers:
- input element as a text entry widget
size attribute is ignored if field-sizing:content
- input element as domain-specific widgets (optional)
- input element as a file upload control (optional)
- select element
size attribute is used only for dropdown/listbox switching if
field-sizing:content
- textarea element
cols/rows are ignored if field-sizing:content
Issue: whatwg#6807
Issue: w3c/csswg-drafts#7542
This covers:
* input element as a text entry widget: size attribute is ignored if field-sizing: content is set.
* input element with number state
* input element as a file upload control (optional)
* select element: size attribute is used only for dropdown/listbox switching if field-sizing: content is set
* textarea element: cols/rows are ignored if field-sizing: content is set
This also stops applying "presentational hints" and "user-agent-level style rule" for width and height properties in order to match to major browser behaviors.
Fixes#6807. See also w3c/csswg-drafts#7542.
This covers:
* input element as a text entry widget: size attribute is ignored if field-sizing: content is set.
* input element with number state
* input element as a file upload control (optional)
* select element: size attribute is used only for dropdown/listbox switching if field-sizing: content is set
* textarea element: cols/rows are ignored if field-sizing: content is set
This also stops applying "presentational hints" and "user-agent-level style rule" for width and height properties in order to match to major browser behaviors.
Fixeswhatwg#6807. See also w3c/csswg-drafts#7542.
Uh oh!
There was an error while loading. Please reload this page.
Why not
height: max-content? See https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes