- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Oct 2023 23:47:30 +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: Values will be fixed | content`
<details><summary>The full IRC log of that discussion</summary>
<lea> Straw poll posted in https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1747785298<br>
<fantasai> iank_: Put on agenda again because some discussion about current name and values and suggestions for other ones<br>
<fantasai> iank_: so agenda to bikeshed these<br>
<fantasai> iank_: I've seen a few variations. A lot keep 'form-sizing' but use 'content' instead of 'auto'<br>
<fantasai> iank_: another suggestion was normal | auto?<br>
<fantasai> TabAtkins: don't think we should go with generic keywords, Lea's suggestion is better<br>
<TabAtkins> content | fixed<br>
<TabAtkins> s/Lea's/later/<br>
<fantasai> iank_: So 'form-sizing: content' and also 'field-sizing: content'<br>
<lea> q?<br>
<fantasai> TabAtkins: based on the suggestions in the thread, I suggest 'content' and 'fixed'<br>
<lea> q+<br>
<fantasai> TabAtkins: weak pref, but sound reasonable<br>
<astearns> +1 to -sizing & content<br>
<fantasai> TabAtkins: and even if the precise definition is wonky, it's easy to guess what the behavior is<br>
<astearns> ack lea<br>
<fantasai> TabAtkins: unlike auto / normal / default / legacy<br>
<fantasai> lea: how does this interact with width/height?<br>
<fantasai> iank_: this changes how you resolve the intrinsic values<br>
<miriam> q+<br>
<fantasai> iank_: if you specify 'width: 100%', during intrinsic sizing might behave as min-content/max-content<br>
<fantasai> iank_: if you specify 'width: 100px', won't get a behavior change<br>
<fantasai> TabAtkins: this makes form contents use the content-based sizing rules that normal non-replaced elements do<br>
<fantasai> TabAtkins: form controls by default have weird intrinsic sizing due to legacy<br>
<fantasai> iank_: This also disables the compressibility quirk<br>
<fantasai> iank_: this quirk gets around the fact that form control elements have a fixed intrinsic size<br>
<fantasai> iank_: if you set e.g. width: 100%, the min-content size will be zero<br>
<fantasai> iank_: this will opt you out of that behaior<br>
<fantasai> iank_: it existed because there wasn't a good intrinsic size before<br>
<astearns> ack miriam<br>
<fantasai> lea: does it have other effects? e.g. Chrome doesn't allow visible overflow<br>
<fantasai> iank_: this only affects intrinsic sizing<br>
<TabAtkins> compressibility thing: https://drafts.csswg.org/css-sizing/#min-content-zero<br>
<fantasai> miriam: I'm liking 'content', but curious how it interacts with the sizing *-content keywords<br>
<fantasai> miriam: they're doing slightly different things in different places, will it be confusing?<br>
<fantasai> iank_: I don't think so, we suspect ppl already using min-content/max-content on these form controls already<br>
<florian> q?<br>
<fantasai> iank_: if you use this, set 'form-sizing: content', then this'll change how *-content behave, make them follow the content<br>
<fantasai> florian: This is actually a good relationship, because it ties the *-keywords to be based on the contents<br>
<fantasai> iank_: Any preferences on form sizing vs field sizing<br>
<fantasai> astearns: slight preference for field, because form means other things too<br>
<fantasai> miriam: same<br>
<fantasai> lea: also form-sizing feels like it affects <form><br>
<lea> control-sizing?<br>
<fantasai> iank_: we got similar feedback on Twitter<br>
<TabAtkins> huh. I woudn't have thought about field-sizing. Like input fields?<br>
<TabAtkins> I guess, sure.<br>
<florian> q+<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: We don't use "field" in a lot of othe rplaces<br>
<TabAtkins> fantasai: what about input-sizing?<br>
<TabAtkins> fantasai: This is all about input elements<br>
<lea> fixed reminded me, what about something-layout to match table-layout as a precedent ?<br>
<fantasai> iank_: also affects textareas, select, etc.<br>
<TabAtkins> iank_: That might be a little confusing since it also affects textarea and select<br>
<fantasai> iank_: so input might not be great<br>
<fantasai> iank_: talking about these elements on MDN, "field" appears a lot, so I think it would match ppl's expectations<br>
<fantasai> miriam: we also do have <fieldset> which refers to same idea<br>
<TabAtkins> I wouldn't have thought of "field", but I suppose it makes sense, and we don't ahve any other concepts using that term in CSS so I think it's clear to use<br>
<astearns> ack florian<br>
<TabAtkins> (I do prefer form-sizing tho)<br>
<lea> nah, I think -layout would be a bad idea here. auto | fixed might be good for the values though (same as table-layout)<br>
<fantasai> florian: I think I like form better here, but just to be complete, we have a term for elements that can have native appearance, and we call them "widget".<br>
<iank_> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input ("field appears 29 times")<br>
<fantasai> florian: I don't think it would be very helpful here, so my preference still goes to "form"<br>
<iank_> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input ("control" appears ~70 times)<br>
<lea> input-sizing<br>
<TabAtkins> fantasai: Seems like fixed|content for values. Any alternatives for fixed? Seems like we're happy for content<br>
<TabAtkins> florian: Someone suggested legacy?<br>
<fantasai> astearns: Should we resolve on 'fixed' and 'content'?<br>
<TabAtkins> lea: There were many arguments in the thread about legacy being bad<br>
<fantasai> lea: another would be 'auto' and 'fixed', which would match 'table-layout'<br>
<fantasai> iank_: pretty strong to keep 'content'<br>
<fantasai> astearns: Proposed 'content' and 'fixed' as values for this property, any objections?<br>
<fantasai> RESOLVED: Values will be fixed | content<br>
<TabAtkins> fantasai: Should we run a poll for these names too?<br>
<chrishtr> form-sizing?<br>
<TabAtkins> +1 to another poll<br>
<fantasai> florian: not a fan of input-sizing because <input><br>
<lea> TabAtkins: sync or async?<br>
<TabAtkins> async again<br>
<fantasai> POLL: 1. form-sizing 2. field-sizing 3. input-sizing<br>
<florian> 1<br>
<miriam> 2<br>
<TabAtkins> 1,2<br>
<astearns> 2<br>
<fantasai> no strong opinion<br>
<lea> abstain, I think<br>
<vmpstr> (abstain)<br>
<iank_> 2,1<br>
<chrishtr> 2,1<br>
<iank_> (no strong opinion however)<br>
<schenney> (abstain)<br>
<changseok> 1<br>
<flackr> 2<br>
<fantasai> [discussion of poll results]<br>
<TabAtkins> Since there's no active disagreement I'm fine with a straight majority, fwiw<br>
<TabAtkins> We don't need a strong consensus when it's not controversial for the group<br>
<fantasai> fantasai: I think it would be useful to poll authors on the two names, to see if there's a strong drift one way or another<br>
<fantasai> lea: if we're pressed for time...<br>
<fantasai> TabAtkins: we're not that pressed that a week is critical<br>
<fantasai> astearns: faster to resolve on the call, after getting poll results<br>
<dholbert> 2<br>
<fantasai> [discussing poll mechanics]<br>
<fantasai> proposed to have a poll using Lea's mechanism, but add in an emoji option<br>
<fantasai> also discussing running polls over twitter / mastodon<br>
<fantasai> astearns: So we will run a poll on form-sizing vs field-sizing, with values content and fixed.<br>
<fantasai> astearns: We'll be able to also evaluate Lea's proposed async poll system<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues<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-1747803316 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 October 2023 23:47:33 UTC