- From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Oct 2023 20:14:15 +0000
- To: public-css-archive@w3.org
> If this is entirely a non-starter for <reasons>, the new property should at least make it clear what dimension is being altered (width/height/block/inline). We discussed this at length previously (see previous discussion), the concerns you've described above were considered, in particular see the discussion about compressibility, and interactions with percentages. This is agenda+ for a bikeshedding discussion. > Compat: The upgrade path to supporting <input> width autosizing is unclear. If this feature launches working only for <textarea> then it may not be web compatible to also allow it to work for <input>. So then what do we do? Introduce a separate property for input? And what about <select> even later? Another one? Yikes! I'm unclear what you are describing here - but the implementation in Chrome Canary (with the experimental web platform features enabled) sizes both `<input>` and `<select>` based on their contents. Please file implementation bugs if this doesn't work as you expect. > If this is entirely a non-starter for <reasons>, the new property should at least make it clear what dimension is being altered (width/height/block/inline). I believe we discussed this previously, and people thought that it was better just to control both axes simultaneously. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1747573184 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 20:14:16 UTC