css textarea禁止拉伸 现代CSS，一行CSS

原生 textarea 元素现在可以自动增加它的高度啦，仅仅通过一行 CSS 即可实现：form-sizing: normal。

w3c/csswg-drafts 下的这个 issue “[css-ui] ? Allow <textarea> to be sized by contents”， 引发了激烈的讨论，该 issue 在 2022 年 7 月29号被新建，今天有了阶段性的进展：

The CSS Working Group just discussed [css-ui] ? Allow <textarea> to be sized by contents., and agreed to the following: RESOLVED: Add a new property (provisionally "form-sizing: normal | auto") that turns off the "half-replaced" sizing of form controls and makes them content-based like normal elements

完整的 IRC 讨论信息如下：

<bramus> tabatkins: had discussion about ability to autosize … we landed on few possible options<bramus> tabatkins: one is we do simply define that min-content and related keywords when used on … will flex the content size as if they were normal elements<bramus> TabAtkins: option 2 is to add new keywords that mean that, so current beahvior would not change<bramus> TabAtkins: option 3 is we add a new property that toggles these elements into behaving like elements filled with their content.<bramus> TabAtkins: I believe that option 1 is a no go. these existing keywords are used quite widely and would be imcompatbile in practice<bramus> TabAtkins: real concern is new keyword on sizing props or with a seperate property toggle<bramus> TabAtkins: I belive that fantasai prefers keyword based, and iank prefers option 3<lea> q?<lea> q <bramus> TabAtkins: there are a number of places in the sizing algos that invoke min-content behavior implicitly<bramus> TabAtkins: eg. textarea width 100% in table<bramus> TabAtkins: this means that there are lot of cases that would implicitly trigger the older non-content aware behavior if we gave authors access to these keywords<bramus> TabAtkins: if we have a way to say 'act like a normal element' it would be fine.<bramus> TabAtkins: iank’s experiment turned out to confirm this, and its a trivial implmentation, and its predictable<bramus> TabAtkins: 'just act like a normal element' switch seems like to be the right way<emilio> q <bramus> TabAtkins: other ways would be hard to predict<bramus> TabAtkins: would like to move into direciton of a form-sizing property<Rossen_> ack lea<bramus> lea: do we know option 1 is not feasible with facts or are we just worried?<bramus> TabAtkins: have not looked at the date, but am virtually certain that it’ll break things<bramus> TabAtkins: min-content is used fairly regularly, and might also be used on inputs and could thus break the page<bramus> iank_: other concern is typically inputs are used heavily in etnerprise usecases, and we sort of have an anlysis blind spot, can't entirely rely on http archive data<bramus> lea: if compat is not an issue, is then option 1 better for authors?<bramus> lea: maybe we should explore if these concerns are founded? or add UA css?<bramus> lea: just thinking out loud<oriol> q <bramus> TabAtkins: option 1 and 2 are pretty bad on how often we invoke intrinsic layout algos<Rossen_> ack emilio<bramus> emilio: i agree that going for the toggle seems like the most straightforward<bramus> emilio: to what extent do we want to create this toggle? only intrinsic sizing? replacingnes? would they respect display?<lea> q?<bramus> emilio: toggle seems most reasonable but would like more details on it<bramus> emilio: i guess that can b efigured out<bramus> iank_: toggle would only trigger normal intrinsic sizing behavior, so auto would not be semi-magic anymore<bramus> iank_: would change compressability (?)<bramus> emilio: seems easier to implement and reason about<lea> would all three approahes also work for adjusting `<input>` width by its contents?<bramus> oriol: 4th option? would not require any new value<emilio> lea: yes (afaict)<bramus> oriol: remins me of what happens when adding size containment wit cis<bramus> oriol: UA CSS? authors could override<bramus> oriol: seems like less compat issues<Rossen_> ack oriol<bramus> iank_: does not work because some elems are a fixed length, but others are not (depending on UA)<bramus> iank_: some are content based with an implicit minimum<bradk> Is this just for text-entry controls, or for buttons, etc too? Presumably not for iframes?<emilio> q <Rossen_> ack emilio<bramus> Rossen_: looks like we are circling around toggle option<bramus> emilio: maybe we can also use this prop to remove ???<bramus> emilio: can be discussed at other time<bramus> s/???/min line height of normal/<bramus> emilio: its needed for compat<bramus> iank_: we will likely get an implementation up, and then work through the inputs one by one<bramus> iank_: should look at line height thing indeed<bramus> Rossen_: Let’s try to resolve<bradk> 1 for toggle<Rossen_> ack fantasai<bramus> fantasai: i have doubts<bramus> fantasai: trying to understand all the compat impact<bramus> fantasai: ok with resolving, but unsure about the direction we are about to take<bramus> Rossen_: my understanding was you were proponent for option 3<bramus> TabAtkins: nopes, other way around<bramus> iank_: using auto sizing breaks option 1 and 2 very easily<bramus> iank_: eg inputs in table<bramus> iank_: lot of magic needed for 1 and 2<bramus> Rossen_: lets make progress here, can always revert<TabAtkins> proposed resolution: add a new property (provisionally "form-sizing: normal | auto") that turns off the "half-replaced" sizing of form controls and makes them content-based like normal elements<Rossen_> e add a new property that toggles these elements into behaving like elements filled with their content.<bramus> Rossen_: not hearing objections<bramus> RESOLVED: Add a new property (provisionally "form-sizing: normal | auto") that turns off the "half-replaced" sizing of form controls and makes them content-based like normal elements<fantasai> s/auto/contents/2.为什么需要这个属性？

随便从 Chrome 检索关键词 “Textarea auto resize height” 发现，textarea 元素内容自适应高度相关的文章和问题非常多，由此可见是开发者刚需求。你在日常需求里有实现过此种需求吗？可以在文章末尾留言讨论。

如果你对 Chrome Canary 不了解，接口详细阅读下本节。

Google Chrome Canary 是由Google开发的处于早期阶段的网络浏览器。它基于谷歌浏览器的开源组件，但直接发布给想要尝试即将到来的新功能的终端用户。开发版本每天都会更新，以反映最新的变化。