- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 May 2023 16:37:08 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <bramus> tabatkins: had discussion about ability to autosize … we landed on few possible options<br> <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<br> <bramus> TabAtkins: option 2 is to add new keywords that mean that, so current beahvior would not change<br> <bramus> TabAtkins: option 3 is we add a new property that toggles these elements into behaving like elements filled with their content.<br> <bramus> TabAtkins: I believe that option 1 is a no go. these existing keywords are used quite widely and would be imcompatbile in practice<br> <bramus> TabAtkins: real concern is new keyword on sizing props or with a seperate property toggle<br> <bramus> TabAtkins: I belive that fantasai prefers keyword based, and iank prefers option 3<br> <lea> q?<br> <lea> q+<br> <bramus> TabAtkins: there are a number of places in the sizing algos that invoke min-content behavior implicitly<br> <bramus> TabAtkins: eg. textarea width 100% in table<br> <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<br> <bramus> TabAtkins: if we have a way to say 'act like a normal element' it would be fine.<br> <bramus> TabAtkins: iank’s experiment turned out to confirm this, and its a trivial implmentation, and its predictable<br> <bramus> TabAtkins: 'just act like a normal element' switch seems like to be the right way<br> <emilio> q+<br> <bramus> TabAtkins: other ways would be hard to predict<br> <bramus> TabAtkins: would like to move into direciton of a form-sizing property<br> <Rossen_> ack lea<br> <bramus> lea: do we know option 1 is not feasible with facts or are we just worried?<br> <bramus> TabAtkins: have not looked at the date, but am virtually certain that it’ll break things<br> <bramus> TabAtkins: min-content is used fairly regularly, and might also be used on inputs and could thus break the page<br> <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<br> <bramus> lea: if compat is not an issue, is then option 1 better for authors?<br> <bramus> lea: maybe we should explore if these concerns are founded? or add UA css?<br> <bramus> lea: just thinking out loud<br> <oriol> q+<br> <bramus> TabAtkins: option 1 and 2 are pretty bad on how often we invoke intrinsic layout algos<br> <Rossen_> ack emilio<br> <bramus> emilio: i agree that going for the toggle seems like the most straightforward<br> <bramus> emilio: to what extent do we want to create this toggle? only intrinsic sizing? replacingnes? would they respect display?<br> <lea> q?<br> <bramus> emilio: toggle seems most reasonable but would like more details on it<br> <bramus> emilio: i guess that can b efigured out<br> <bramus> iank_: toggle would only trigger normal intrinsic sizing behavior, so auto would not be semi-magic anymore<br> <bramus> iank_: would change compressability (?)<br> <bramus> emilio: seems easier to implement and reason about<br> <lea> would all three approahes also work for adjusting <input> width by its contents?<br> <bramus> oriol: 4th option? would not require any new value<br> <emilio> lea: yes (afaict)<br> <bramus> oriol: remins me of what happens when adding size containment wit cis<br> <bramus> oriol: UA CSS? authors could override<br> <bramus> oriol: seems like less compat issues<br> <Rossen_> ack oriol<br> <bramus> iank_: does not work because some elems are a fixed length, but others are not (depending on UA)<br> <bramus> iank_: some are content based with an implicit minimum<br> <bradk> Is this just for text-entry controls, or for buttons, etc too? Presumably not for iframes?<br> <emilio> q+<br> <Rossen_> ack emilio<br> <bramus> Rossen_: looks like we are circling around toggle option<br> <bramus> emilio: maybe we can also use this prop to remove ???<br> <bramus> emilio: can be discussed at other time<br> <bramus> s/???/min line height of normal/<br> <bramus> emilio: its needed for compat<br> <bramus> iank_: we will likely get an implementation up, and then work through the inputs one by one<br> <bramus> iank_: should look at line height thing indeed<br> <bramus> Rossen_: Let’s try to resolve<br> <bradk> +1 for toggle<br> <Rossen_> ack fantasai<br> <bramus> fantasai: i have doubts<br> <bramus> fantasai: trying to understand all the compat impact<br> <bramus> fantasai: ok with resolving, but unsure about the direction we are about to take<br> <bramus> Rossen_: my understanding was you were proponent for option 3<br> <bramus> TabAtkins: nopes, other way around<br> <bramus> iank_: using auto sizing breaks option 1 and 2 very easily<br> <bramus> iank_: eg inputs in table<br> <bramus> iank_: lot of magic needed for 1 and 2<br> <bramus> Rossen_: lets make progress here, can always revert<br> <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<br> <Rossen_> e add a new property that toggles these elements into behaving like elements filled with their content.<br> <bramus> Rossen_: not hearing objections<br> <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<br> <fantasai> s/auto/contents/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1542505774 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 May 2023 16:37:10 UTC