- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 May 2023 23:59:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] ? Allow <textarea> to be sized by contents.`. <details><summary>The full IRC log of that discussion</summary> <dael> iank_: The goal is to allow for textarea to grow number of content and grow in inline dimension with content<br> <dael> iank_: Previously discussed to achieve with min intrinsic sizing property. Seems like a reasonable idea<br> <dael> iank_: One way would be add 2 new values, one for textarea and one for input<br> <dael> iank_: you would say min-intrsinzic-sizing and it would switch to being sized based on the area<br> <dael> iank_: Any thoughts or concerns?<br> <dael> astearns: Reason you are using the element names instead of something more generic like from-content?<br> <vmpstr> q+<br> <astearns> ack fantasai<br> <dael> iank_: They sort of work in different axes. textarea is in block and inputs are intrinsic for block dimension. If someone sets a reset it's not clear you want both so probably need indiviual control<br> <dael> fantasai: I had the same question about why 2-axes. If we're splitting the axes we should maybe consider axis. Is it split on axis or on type of input?<br> <dael> fantasai: And then is this going to change the way auto works?<br> <dael> iank_: What do you mean by change how auto works?<br> <dael> fantasai: When the input as an auto-width it currently sizes to a magic number<br> <astearns> from-inline-content-size/from-block-content-size (for those who like to type a lot)<br> <dael> iank_: full width for textarea we haven't heard demand to grow in inline size<br> <dael> iank_: Is theoretically possible but I would prefer to keep. If we did it for both axes for textarea it would be weird behavior when they're in something like flexbox. Current magic is simple and looks at columns<br> <dael> iank_: Prefer to keep textarea just for block. If we split min-intrinsic-sizing that's the other issue if we want to add it.<br> <miriam> q+<br> <dael> vmpstr:<br> <astearns> ack vmpstr<br> <dael> vmpstr: I just wanted to ask for input if I spec from-input:min-intrinsic-size would the input shrink below default size?<br> <dael> iank_: Correct. Expected webdev will put a min-width on that element<br> <astearns> ack miriam<br> <dael> miriam: I like this. For me your argument it does one thing on textarea and another on input seems like an argument for one value. Seems weird to align the right value to the right element<br> <dael> miriam: Why do I need to say textarea as the target and the value rather than getting the right behavior<br> <dael> iank_: Related to next issue which is splitting axes for min-intrinsic-sizing. Might be better to talk about that first. If we split that property in 2 than from-input would only apply to one.<br> <dael> iank_: Could have a from-content but somewhat find that more difficult to understand. I think this is less magic. content is an overloaded word<br> <dael> iank_: I like the explicitness of from-input and from-textarea<br> <dael> astearns: I like solution of splitting min-intrinsic-size as a solution to the reset issue<br> <dael> iank_: I would still come back to some content would be confusing<br> <dael> iank_: It is possible; we could have intrinsic sized text areas in inline axis. I don't think it's desireable<br> <dael> astearns: That's not part of current prop, right?<br> <astearns> ack fantasai<br> <dael> iank_: Correct. Future thing to keep in mind<br> <dael> fantasai: I think this is workable. From author PoV I think the original proposal we had discused to use min and max-content feels more understandable. I'd prefer that if we can<br> <dael> iank_: I don't think we can. Flexboxes are everywhere and it would change the auto min-size. We'd need an explicit switch for switching the algo similar to what min-instrinsic-size does for scrolling. We won't be able to shift that<br> <dael> fantasai: What's the case wehre it changes behavior?<br> <dael> iank_: A few. People use min-content/max-content on things already. Would change any input elements with this already. Other thing is it would change flexbox. Flexbox uses min-content size directly and that would change<br> <dael> iank_: I think emilio tried to implement. I don't think we can shift it<br> <dael> fantasai: Make sense to put keywords onwidth and height? Seems like a pretty indirect method.<br> <dael> iank_: At the moment it's siwtching the algo we use to determine content size. All input elements and textarea have a special metric and this would default to the default. I think min-intrinsic-sizing is a good place to do this since the min size for scrollable is there also<br> <dael> fantasai: I think I'd like to talk this over with TabAtkins. But I agree we need to solve the use case<br> <dael> iank_: As long as it's not...been trying to come up with a proposal that satisfies everyone's desire for a while. I think this is the best so far<br> <dael> fantasai: min-intrinisic-sizing property is about min and not intrinsic sizing. Or is this a new proposal? We have an intrinsic-sizing property. Is this separate?<br> <dael> iank_: This is the original property<br> <dael> fantasai: That's about how we find the min instrinsic size, but not about something like max intrinsic size.<br> <dael> iank_: Weird thing about inputs is they're the same thing<br> <dael> fantasai: Yeah, some elements don't have difference between min and max. A div with one word has equal min and max.<br> <dael> iank_: Input elements that's also true<br> <dael> fantasai: Right, b/c they have a fixed length intrinsic size.<br> <dael> fantasai: We're trying to allow elements to be resized from their content. For a text area in block axis min and max will be the same. Concept does exist for difference if you want it<br> <dael> fantasai: Would make sense if you tried to size as if they're a regular element you get that behavior. And you can't here because it's only giving one size.<br> <dael> fantasai: Probably solves use case, but I think what makes sense is to make this behave more like a replaced element<br> <dael> iank_: Specifically for input case you cannot get an input to wrap multiple lines<br> <dael> fantasai: Yes, they're no-wrap<br> <dael> iank_: You can't get min vs max for these elements today<br> <dael> fantasai: But if we wanted to do something on inline axis for textarea there would be possible 2 sizes<br> <dael> iank_: But no one is asking for that<br> <dael> fantasai: I agree. I think if we can try and get everything to fit in that's a good directly<br> <dael> fantasai: I think min-intrinsic-size...what min-width:auto resolves to is a little different from what is the intrinsic size.<br> <dael> fantasai: I would rather try and talk this over with TabAtkins<br> <dael> astearns: Can you commit to that over the next week?<br> <dael> fantasai: If TabAtkins is available tomorrow or Friday, yeah.<br> <dael> [discussion on TabAtkins availability]<br> <dael> astearns: iank_ okay with you if we put this and 8620 on the agenda next week?<br> <dael> iank_: Sure<br> <dael> astearns: Next week we'll start with content-visibility and then this two 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-1533895045 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 May 2023 23:59:11 UTC