- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Aug 2022 19:43:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Sizing <textarea> by contents`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Sizing <textarea> by contents<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7542<br> <fantasai> iank_: form control elements all have some default intrinsic size, inline axis and block axis<br> <fantasai> iank_: the way they calculate this is sometimes extra fun<br> <fantasai> iank_: sometimes just a static number, e.g. radio/checkboxes<br> <fantasai> iank_: the way that textarea works, it will more or less read the rows attribute and multiple that by the lh unit (effectively)<br> <fantasai> iank_: this is not fallback or anything like that<br> <fantasai> iank_: Since the dawn of time, ppl have wanted textareas to auto-expand<br> <fantasai> iank_: a lot of libraries that do this<br> <fantasai> iank_: most people want to show some minimum amount of rows<br> <fantasai> iank_: and then let it grow<br> <fantasai> iank_: I filed this issue, what's the best way forward with this<br> <fantasai> iank_: I wasn't previously aware we discussed this 4-5 years ago<br> <fantasai> iank_: I don't think proposed solution is the best, but can go from there<br> <fantasai> iank_: was that enough background?<br> <fantasai> iank_: I can sort of go through the previous proposal, and concerns with it<br> <fantasai> iank_: I've also got an alternate proposal<br> <fantasai> iank_: Previous proposal was to use the min-content/max-content and presumably fit-content keywords on the height<br> <fantasai> iank_: when you specify this, you would flip the intrinsic size to calculate based on the rows<br> <fantasai> iank_: to being based on content instead<br> <fantasai> iank_: I have a few issues with this<br> <fantasai> iank_: it creates a slightly weird discontinuity, currently on form controls there is an algorithm for calculating intrinsic size of form controls<br> <fantasai> iank_: if you say height: auto; height: min-content; or height: fit-content, shoudl behave same<br> <fantasai> iank_: other issue is it's difficult to feature-detect<br> <fantasai> iank_: it also makes it difficult for layout algorithms, when flexbox or grid ask for min-content size of something, do we take into account<br> <fantasai> iank_: very subtle<br> <fantasai> iank_: the final thing is that, and we can debate this, there's a valid path forward<br> <fantasai> iank_: a lot of the time you don't actually want it to be the exact height of the content<br> <fantasai> iank_: 2 reasons<br> <fantasai> iank_: 1, you want space for placeholder<br> <fantasai> iank_: 2, you kindof want it to work the same as the lh unit<br> <fantasai> iank_: if you set min-height: 2lh<br> <fantasai> iank_: max-height: 4lh<br> <fantasai> iank_: you want the content, the intrinsic size, to be based on the number of lines times the lh unit<br> <fantasai> iank_: when you're typing and you fall back to a different font, can create a visual glitch<br> <fantasai> iank_: I'll pause there ...<br> <fantasai> iank_: My proposal is to add a new property, e.g. textarea-rows: auto | <integer><br> <TabAtkins> q+<br> <fantasai> s/integer/number/<br> <fantasai> iank_: You typically don't want to reserve space for the placholder<br> <fantasai> florian: I'm confused about the proposal. I presume auto is the default?<br> <fantasai> TabAtkins: no?<br> <fantasai> TabAtkins: Then what's the default?<br> <fantasai> iank_: ON the textarea, you have textarea-rows: 2<br> <fantasai> iank_: and then preshint mapping that maps rows attribute to this property<br> <fantasai> florian: thanks, that helps<br> <fantasai> iank_: today we have textarea-rows: <number> only<br> <fantasai> iank_: and rows attribute would get mapped to this property<br> <fantasai> florian: that makes more sense, thanks<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: I agree with your reasoning against the older proposal to use max-content<br> <fantasai> TabAtkins: max-content messes with our existing algorithms, and the fact that you do want this to be a multiple of lh<br> <fantasai> TabAtkins: i was convinced by your arguments, so I support adding this property with the auto value<br> <fantasai> iank_: I should also say that we can bikeshed the name, this is a very basic name<br> <fantasai> florian: This new property is alternative to using height with lh?<br> <fantasai> TabAtkins: if that's what you want to impose, yes<br> <fantasai> iank_: It's useful even if you don't support lh unit<br> <fantasai> iank_: currently looking at doing both atm<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I don't really like a new specialzied property to a single element<br> <TabAtkins> fantasai: when we could get the same effect with a generic property<br> <TabAtkins> fantasai: I think the feature detection is one we have for a lot of things<br> <TabAtkins> fantasai: and that's not a reason to invent a new property every time<br> <TabAtkins> q+<br> <florian> s/to using height with lh?/to using height with fit-content, but you'd use it in combination with min-height / max-height with lh?/<br> <TabAtkins> fantasai: in terms of other things being multiples of lh vs actual height, i think that's interesting<br> <emilio> q+<br> <TabAtkins> fantasai: do we actually want that multiple-lh szie? or fit X lines?<br> <TabAtkins> fantasai: can we figure out how to do that with the step-sizing properties?<br> <TabAtkins> fantasai: if so we can apply it to other elements besides text area<br> <TabAtkins> fantasai: other point wrt min/max content sizing<br> <TabAtkins> iank_: discontinuity that height:auto and height:fit-content won't match<br> <TabAtkins> fantasai: I don't think that's a discontinutiy - *usually* auto maps to a content keyword<br> <TabAtkins> fantasai: but on some elements it maps to a fixed number<br> <TabAtkins> fantasai: that's fine, auto can map to anything<br> <TabAtkins> iank_: today auto doesn't map to a fixed number<br> <TabAtkins> iank_: because the way most form elements work is that min/max-content returns a number, and auto maps to one of those<br> <TabAtkins> fantasai: yeah but for some els auto maps to stretch<br> <TabAtkins> iank_: yeah that's fine<br> <TabAtkins> iank_: so like what happens when you do min-height:min-content; height:auto; on the textarea?<br> <TabAtkins> fantasai: min-height would look at the number of lines in the box and come up with a height<br> <TabAtkins> fantasai: and then auto would represent what it currently does<br> <TabAtkins> iank_: which is fit-content<br> <TabAtkins> fantasai: is it? isn't it a fixed number o flines/<br> <TabAtkins> iank_: For us and other engines, that's what fit-content means, yes<br> <TabAtkins> iank_: if you say height:min-content today on a form control, it'll return a form control algo<br> <TabAtkins> fantasai: so your concern is the backwards incompatibility of specifying a content keyword to have this behavior, rather than today's behavior<br> <TabAtkins> iank_: I was considering if it was a compat problem, it's probably not. it's more how the engines work is that auto maps onto two things - stretch or fit-content<br> <TabAtkins> iank_: and all the form elements behave similarly<br> <TabAtkins> iank_: min/max-content is defined by some internal algo; for textarea it's rows*lh, basically<br> <TabAtkins> iank_: and if you have height:min-content we swap the internal algorithm for that<br> <TabAtkins> q+<br> <TabAtkins> fremy: a point that convinced me is you don't want to snap to any random pixel value, but a proper number of lines. can't rely on that with fit-content<br> <TabAtkins> fantasai: content is quite limited; you can't format it<br> <TabAtkins> TabAtkins: but you can have fallback fonts<br> <TabAtkins> fantasai: yeah, but we already have problems with line heights from that<br> <TabAtkins> fantasai: unsure if that's the reason we should add a specialized new property that only works for text areas<br> <TabAtkins> fantasai: we should decide if we want the content to accommodate font changes and if we want a consistent line height we should be able to say that with text properties<br> <fremy> q+ (other question)<br> <TabAtkins> iank_: It's not affecting those line height, it's affecting the intrinsic size<br> <florian> q+<br> <fremy> q+<br> <fremy> ack (other<br> <fremy> ack question)<br> <TabAtkins> fantasai: if height:auto effectively computed to 40px on a textarea, how would that be different fro mthe current situation we're in today? isn't that what's being proposed?<br> <TabAtkins> iank_: it's not, auto only maps to stretch or fit-content<br> <TabAtkins> fantasai: that's not true<br> <TabAtkins> iank_: Where?<br> <TabAtkins> fantasai: It's whatever we define it to be.<br> <TabAtkins> iank_: Right but we don't do anything else today. Today it's just the two<br> <TabAtkins> fantasai: I'd prefer to add a new concept ot the engines than to author-exposed stuff<br> <TabAtkins> fantasai: I'd prefer not having authors have to learn a new concept<br> <TabAtkins> iank_: what happens for things asking for min-content sizes?<br> <TabAtkins> fantasai: typically asking for min-content contribution, not size<br> <TabAtkins> fantasai: if auto resolves to an (effectively) fixed value, your contribution will be taht size<br> <TabAtkins> [missed a bit]<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: It seems 1 point of your objection is about having us this be a special-purpose property<br> <fantasai> TabAtkins: I think for sufficiently magic element,s I think it's fine<br> <fantasai> TabAtkins: we already have a large number of singe-purpose properties from SVG<br> <fantasai> TabAtkins: I don't think it's a problem to add them to HTML also<br> <astearns> ack emilio<br> <dholbert> q+<br> <TabAtkins> emilio: one issue when consdiering whethe rto change height is that the default for textarea is border-box<br> <TabAtkins> emilio: so it may not be right to match content there<br> <dbaron> s/whethe rto/whether to/<br> <TabAtkins> fantasai: we don't have to change that - when you say height:max-content, you don't take the size and make the border-box that height<br> <TabAtkins> emilio: I think for most purposes, block-size max-content is auto<br> <TabAtkins> fantasai: auto is treated as intrinsic, rather<br> <TabAtkins> fantasai: like in grid, it's stretch not auto<br> <TabAtkins> emilio: I'm pretty sure we've discussed how intrinsic block sizes should behave and I'm 90% sure that our beahvior maps intrinsic block sizes to auto except in special cases<br> <TabAtkins> fantasai: you're saying they're treated the same way, and you had "auto" first so you call it that in the codebase, but fundamentally it's the max-content size and "auto" maps to that<br> <TabAtkins> emilio: Not convinced. If you do width:min-content and have box-sizing:border-box and have padding, do we add padding to that width?<br> <TabAtkins> fantasai: yes, or else it would be broken<br> <TabAtkins> dbaron: I think what's supposed to happen is if you're using width/height:intrinsic-stuff, box-sizing doesn't change the box affected<br> <astearns> ack florian<br> <emilio> ack emilio<br> <TabAtkins> florian: One thing fantasai was concerned abou tis that this is a textarea-only property<br> <TabAtkins> florian: But theoretically this could apply to any block container<br> <TabAtkins> florian: So if you leave logical proeprties aside, couldn't this be a new set of properties that fit into the sizeing property?<br> <fantasai> TabAtkins: that's step-sizing<br> <dbaron> s/box affected/size of the box/<br> <astearns> ack fremy<br> <TabAtkins> fremy: great segue<br> <TabAtkins> fremy: i'm wondering about the issue of scrollbars<br> <TabAtkins> fremy: textarea do overflow, and they get scrollbars which can change the lines on the screen<br> <TabAtkins> iank_: we don't have have interop<br> <TabAtkins> iank_: i think most engines do... something complicated<br> <TabAtkins> iank_: effectively, if you have overflow:scroll, we'll reserve space<br> <TabAtkins> iank_: if it's overflow:auto we won't reserve space<br> <TabAtkins> iank_: it's like the text area has word-space;break-all on it<br> <TabAtkins> iank_: very hard to trigger inline overflow<br> <TabAtkins> iank_: if you do manage to trigger it it'll still be like two rows of overlap<br> <TabAtkins> fremy: how do you know in advance what you'll need?<br> <TabAtkins> fremy: will you get in a situation where if you don't have reserve the space it doesn't need a scrollbar?<br> <TabAtkins> iank_: This varies engine by engine, but Chrome's behavior we won't...<br> <TabAtkins> iank_: [compiles chrome in their head]<br> <TabAtkins> iank_: it's complicated<br> <TabAtkins> iank_: we'll only ever add scrollbars. that'll typically result in an extra row<br> <TabAtkins> iank_: but we'll never remove them after that point<br> <TabAtkins> fremy: makes sense<br> <astearns> ack dholbert<br> <TabAtkins> dholbert: going back to needing a special prop<br> <TabAtkins> dholbert: one thing not clear to me is why we are reaching for a css proerty rather than an html attribute<br> <fantasai> TabAtkins: Whether your item is content-sizable, might depend on the layout of the page<br> <fantasai> TabAtkins: in some cases, might have the space, but might change based on MQ<br> <florian> q?<br> <fantasai> TabAtkins: so needs to be in CSS so you can change as needed<br> <fantasai> TabAtkins: based on MQ and CQ<br> <florian> q+<br> <astearns> ack florian<br> <TabAtkins> florian: might have missed part of the discussion but didn't see the answer...<br> <TabAtkins> florian: Can we do this with step-sizing?<br> <TabAtkins> florian: How do we solve this with step-sizing? what's missing?<br> <TabAtkins> iank_: where is step-sizing proposal<br> <fantasai> https://www.w3.org/TR/css-rhythm-1/#block-step-size<br> <Rossen_> q<br> <fantasai> https://www.w3.org/TR/css-rhythm-1/#block-height<br> <oriol> q+<br> <TabAtkins> iank_: where is this actually counting the number of lines?<br> <TabAtkins> fantasai: you write 'block-step-size: 1lh' and it'll round your block to a multiple of 1lh<br> <fantasai> TabAtkins: This doesn't address making textarea content-sizable in the first place<br> <TabAtkins> iank_: there's nothing here that changes the way that the textarea calculates its size otherwise<br> <astearns> ack oriol<br> <fantasai> probably the spec should clarify that the intrinsic sizes are also stepped<br> <TabAtkins> oriol: instead of step-sizing, i also remember in overflow there was a max-lines property<br> <TabAtkins> oriol: [missed]<br> <florian> q+ to respond to oriol<br> <TabAtkins> oriol: what if we had as a pres hint converting the rows attribute into a max-lines, and if you want to size the textarea according to content, you set max-lines:none<br> <astearns> ack florian<br> <Zakim> florian, you wanted to respond to oriol<br> <TabAtkins> florian: Havne't totally followed logic, but max-lines in overflow is a very different beast<br> <TabAtkins> florian: it's fragmentation, not sizing<br> <TabAtkins> florian: what it does with the nmber of lines is very different and doesn't work here<br> <TabAtkins> florian: as a reminder, max-lines triggers a forced break after the number of lines if your container is a fragmentainer<br> <TabAtkins> florian: I don't think we want forced breaks, we want to size things<br> <TabAtkins> fantasai: also max-lines actually uses the line size, if one line is taller it breaks after a whole number of lines<br> <TabAtkins> fantasai: also it's max-lines, if your block is max-lines:5 but has three lines in it, it'll still be 3 lines tall<br> <TabAtkins> <br dur=15min><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-1201637971 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 August 2022 19:43:25 UTC