其他
前端快讯｜一行 CSS 实现 Textarea 自适应内容高度
【前端快讯 09月22日】原生 textarea 元素现在可以自动增加它的高度啦，仅仅通过一行 CSS 即可实现：form-sizing: normal。这个特性将在后续发布的 Chrome Canary 版本得到支持。
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 元素内容自适应高度相关的文章和问题非常多，由此可见是开发者刚需求。你在日常需求里有实现过此种需求吗？可以在文章末尾留言讨论。
3.什么是Chrome Canary？
如果你对 Chrome Canary 不了解，可以详细阅读下本节。
Google Chrome Canary 是由Google开发的处于早期阶段的网络浏览器。它基于谷歌浏览器的开源组件，但直接发布给想要尝试即将到来的新功能的终端用户。开发版本每天都会更新，以反映最新的变化。
它于2013年9月5日作为alpha版本发布，适用于微软Windows（仅XP及以后版本）。2014年12月15日，它正式对Mac OS X和Linux用户开放。
2016年7月22日首次发布了安卓的测试版本。2017年3月16日，iOS版本也紧随其后。
Google Chrome Canary浏览器可从谷歌浏览器网站下载 https://www.google.com/chrome/canary/。