- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Feb 2018 17:31:36 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Please add vertical auto-resize textarea field`, and agreed to the following resolutions: * `RESOLVED: Have a UA defined minimum on content based sizes for these new keywords with suggestions of possible minimums` * `RESOLVED: Single line inputs have no breakpoints for purpose of calculating min and max.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Please add vertical auto-resize textarea field<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2141<br> <dael> TabAtkins: We've got a few details we weren't sure of. First: right now we have it spec thaat the width of something with a placeholder is the larger od the lemeber with placeholder or contained text. That way you won't get size jiggle when you click inside<br> <dael> TabAtkins: Have a comment from fremy it's the right thing to do but hard to impl. Any other opinions or stick with spec?<br> <dael> astearns: Seems like right thing to do to me.<br> <dael> astearns: Other opinions?<br> <dael> astearns: Want a resolution?<br> <dael> TabAtkins: Just a check.<br> <dael> TabAtkins: Next: We could that empty inputs...a 0 size is hard to click into. There's prob some measure of min size that should come from UA in width and height. We wrote UA can enforce the size required to hold a single character as a minimum size, even if it's empty.<br> <dael> TabAtkins: Sound fine? More specific? Remove text?<br> <dael> bradk: Suggesting that could be in UA stylesheet.<br> <dael> TabAtkins: Maybe as a min width or min height. Poss.<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/2141#issuecomment-365745317<br> <dael> fantasai: fremy sent a comment why we shouldn't do it with min ehight in UA stylesheet. Comment here ^<br> <dael> fantasai: Authors might animate height from 0 and if we impose a min now the animation would clamp at non-0 size. He's got a form control with a height of less then min we recommend.<br> <dael> TabAtkins: And more generally there's nor eason to impose a min size on arbitrary form controls. But when they'r ebeing content sized there's a reasonable minimum. I agree we shouldn't use min width and height for this.<br> <dael> astearns: Sounds like discussion is landing with not having a minimum content base size?<br> <dael> TabAtkins: No, we're explaining why not use min-width and height o impose it. We still think you should impose it.<br> <dael> astearns: I'm wondering since at the moment if you don't spec a height on one of these you'll get something with 0 height...is imposing min a breaking change?<br> <dael> TabAtkins: That's not what happens right now.<br> <dael> fantasai: Text area takes its height from the rows.<br> <dael> TabAtkins: THis isn't about auto size. this is when you activate content based sizing which is a new feature.<br> <dael> fantasai: Using min-content keyword. It's a minimum on the used value of this keyword.<br> <dael> fantasai: [missed]<br> <dael> astearns: We're going to add a minimum height to the behavior of these new keyword values when there is no content to size from<br> <dael> TabAtkins: Height and width<br> <dael> florian: Is this only inputs and text areas?<br> <dael> TabAtkins: Only these.<br> <dael> fantasai: Not about content editable things.<br> <dael> astearns: Shall we ahve ar esolution on adding a minimum size to these new keywords?<br> <dael> astearns: Does anyone what to discuss what the size should be?<br> <dael> florian: US defined.<br> <astearns> s/US/UA/<br> <dael> fantasai: Yes, it's UA defined but there is a example<br> <dael> astearns: Is that really UA defined?<br> <dael> fantasai: The UA gets to choose what the minimum to be. Our suggestion is the size for a single 0 width character b/c that gets you straightfoward behavior when you focus the item.<br> <dael> astearns: Why do we want to let UA<br> <dael> fantasai: It's a font control and they have a lot of UA defined behavior. Some UA might decide if they want the form control easy it should be big enough to contain the letter 'n' for example.<br> <dael> astearns: uuuuu....okay. I prefer spec something so you can get more interop if there's no pushback.<br> <dael> TabAtkins: I support fantasai in that we hsould support UAs wanting to be large enough to be a tap target, for example.<br> <dael> astearns: Can you put that suggestion is as the example? Like you're free to make it larger, but not suggest 1px in either direction is useful?<br> <dael> fantasai: It really depends on how they're impl form controls in terms of UA defined items. There's a reason form controls are UA defined and this is the category where too prcise definition locks us in. UA should look for best user experience. If every platform is the same we can standarize then.<br> <dael> TabAtkins: I don't disagree that we can put in tap target size as another suggestion<br> <dael> astearns: Prop: Have UA minimum on content based sizes for these new keywords with suggestions of possible minimums<br> <dael> RESOLVED: Have a UA defined minimum on content based sizes for these new keywords with suggestions of possible minimums<br> <dael> TabAtkins: Next is min content for input type = text. There's no breakpoints there. BUt right now it's magic only. UA style sheets don't clarify, they jsut strip lines and render as a pre. We prob want additional magic clarified. If it's intended to be a single line we'll clarify that the min and max content are the same and the full size of the stuff inside.<br> <dael> TabAtkins: This might be accomplishable through a UA important rule.<br> <dael> fantasai: Alt def is to have min and max content mean different thigns based on where there could be a breakpoint.<br> <dael> TabAtkins: Doesn't sound useful can't get it to size to that. It wouldn't do anything useful.<br> <dael> fantasai: Not sure what you mean. If you set input to be min-content then it's the size of the longest word.<br> <dael> TabAtkins: That has no meaning if content isn't breaking. There would still be scrolling because you'd have lots of content on their size of the big word.<br> <dael> fantasai: There's no word that wouldn't fit.<br> <dael> astearns: I think I agree with TabAtkins. I don't see how it's useful. It would have the weird effect of making input larger as you add characters.<br> <dael> florian: And i18n problems on what's a word.<br> <dael> TabAtkins: Not in that case b/c breakpoints.<br> <dael> fantasai: We know where the breakpoints would be.<br> <dael> fantasai: Question is is there a reason for these things to be different. We as spec writers don't have a reason. If authors do we can make it different.<br> <dael> fantasai: If there's no compelling use case for different then they shouldn't be different.<br> <dael> astearns: If we're not going to have minc-ontent on an input be the longest word are we saying min and max is same result?<br> <dael> TabAtkins: Single line inputs have no breakpoints for purpose of calc min and max.<br> <dael> astearns: I'd be fine with htat.<br> <dbaron> +1 to what TabAtkins said<br> <dael> astearns: fantasai okay?<br> <dael> fantasai: Yeah. As long as there's no one with a reason to do different.<br> <dael> astearns: Objections to resolving?<br> <dael> RESOLVED: Single line inputs have no breakpoints for purpose of calculating min and max.<br> <dael> astearns: Last item looks to be a review of the new text. THere's quite a bit so a few eyes would be good.<br> <dael> astearns: One question is we want to republish sizing as updated CR. THis is a new feature, is there a reason this is L3 as opposed to L4?<br> <dael> fantasai: keywords are introduced in L3 so we need to define their behavior in L3.<br> <dael> TabAtkins: We could underfine the keywords and move the definition to L4.<br> <dael> fantasai: That's true.<br> <gsnedders> s/underfine/undefine/<br> <dael> fantasai: I don't think it's nec at this point.<br> <dael> florian: Depends on if we prioritize rec faster.<br> <dael> [missed<br> <dael> Chris: Is it WD or CR?<br> <dael> astearns: It is jsut a WD. My concern is moot.<br> <dael> gsnedders: THere are no tests for sizing so it won't get rec very fast unless people provide tests.<br> <dael> astearns: Okay. I was wrong on my concern. Anything else on this issue?<br> <dael> TabAtkins: No.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2141#issuecomment-367405759 using your GitHub account
Received on Wednesday, 21 February 2018 17:32:11 UTC