4 ms·

I know this is a naive criticism given from the proverbial arm chair, but I'm irritated that they're creating a new property just for this use case. Consider th

I know this is a naive criticism given from the proverbial arm chair, but I'm irritated that they're creating a new property just for this use case. Consider the fact that non-form elements have this: width: fit-content height: fit-content Why couldn't they just use that? Isn't it essentially the same thing?

marginalia_nu 3y ago
Cluttering existing properties with overloaded meanings is also not great IMO.
- epolanski 3y ago
  Is it really overloaded though? Without fully reading the spec it seems reasonable.
- danielvaughn 3y ago
  I totally agree, and I assume that's why a new property is being used. But I'm failing to see a real distinction. Yes, it's a form component, so as the user provides more text input, the element grows. But in that case, text nodes are being inserted into the DOM and thus increases the dimensions of the element's content. If a div has `width: fit-content` applied, then it is expected to grow and shrink according to...the dimensions of the element's content. What's different? I know that I must be wrong, but I'm honestly not seeing it.
  - jahewson 3y ago
    For a div, fit-content is already defined as the width of the longest word - that is the minimal intrinsic width of the content. Not amazingly useful, but it can’t be changed without breaking existing pages. The meaning of content width gets more complex when you factor in line breaking, hyphenation and ellipsis.
    - Izkata 3y ago
      > The meaning of content width gets more complex when you factor in line breaking, hyphenation and ellipsis. Don't forget font-face and size. It's usually not done in a noticeable way, or at all, but those can be set to anything for textareas too.
edflsafoiewq 3y ago
They can't change the meaning of an existing property since the web doesn't break backwards compatibility. And AFAIU form-sizing: normal does reuse existing properties by making width/height have the normal meaning.
- jauntywundrkind 3y ago
  You're not breaking backwards compatibility by introducing a new valid value, which before would have been invalid.
  - sharlos201068 3y ago
    If they did as you suggest, there are websites today that would start being rendered differently to before. For the most part, browsers are very reluctant to make such changes.
    - jauntywundrkind 3y ago
      What is your assertion here? Old websites were saying "width: max-content" in the past? That they happened to ask for what was an invalid value that so happens to have this weird name? Can you find any evidence that this happens? This seems incredibly fantastically super unlikely. And it was an invalid use if it did exist. Sounds like a big huge bundle of nonsense FUD to me.
      - edflsafoiewq 3y ago
        max-content/min-content/fit-content already exist, they aren't invalid.
bfgeek 3y ago
Its not the same thing. min-content/max-content/fit-content etc for these form control elements are some magical value (for textareas "1lh * attr(rows)") for example. (This works cross browser!) min-content/etc get invoke in more places than you'd expect. For example: <table> <tr> <td> <input style="width: 100%"> </td> </tr> <tr> <td> <input style="width: 100%"> </td> </tr> </table> Here when initially sizing the table the "width:100%" will actually be "width:min-content". (We can't change how this works, it'll break sites, and I'm oversimplifying slightly). This property is basically a switch to say "don't use the magical values for the intrinsic sizes size based on your content instead". With the new form-sizing property (or whatever it gets named) all the inputs in that table will be sized to the maximum input. I understand its frustrating but changing a 20+ year platform isn't an easy/simple affair sometimes :).
- bfgeek 3y ago
  Additionally this property disables the "compressibility" hack which browsers invoke currently. (jsfiddle for previous example: https://jsfiddle.net/vk8fy1bz/ https://jsfiddle.net/vk8fy1bz/ )
  - pests 3y ago
    Compressibility hack?
    - john_the_writer 3y ago
      I was wondering the same thing. The fiddle didn't do anything. Two input boxes is all I got.
derefr 3y ago
Consider: when using `form-sizing: normal`, what CSS properties do you use to specify the size of the textarea when it's empty? (min-width and min-height would be obvious contenders, but nobody's currently doing that, because currently, textareas don't change size except when JS manipulates their width and height.)
- rezonant 3y ago
  min/max width are indeed already used by browsers on textarea, but only to limit how large or small the user can resize them by dragging the corner.
dclowd9901 3y ago
Right; I’m curious what setting a height would mean if you had this property set. This is the kind of non-determinism that makes me despise CSS.
- spankalee 3y ago
  It's not non-determinism. It'll be fully specified.
TacticalCoder 3y ago
[flagged]

marginalia_nu 3y ago

Cluttering existing properties with overloaded meanings is also not great IMO.

epolanski 3y ago
Is it really overloaded though? Without fully reading the spec it seems reasonable.
danielvaughn 3y ago
I totally agree, and I assume that's why a new property is being used. But I'm failing to see a real distinction. Yes, it's a form component, so as the user provides more text input, the element grows. But in that case, text nodes are being inserted into the DOM and thus increases the dimensions of the element's content. If a div has `width: fit-content` applied, then it is expected to grow and shrink according to...the dimensions of the element's content. What's different? I know that I must be wrong, but I'm honestly not seeing it.
- jahewson 3y ago
  For a div, fit-content is already defined as the width of the longest word - that is the minimal intrinsic width of the content. Not amazingly useful, but it can’t be changed without breaking existing pages. The meaning of content width gets more complex when you factor in line breaking, hyphenation and ellipsis.
  - Izkata 3y ago
    > The meaning of content width gets more complex when you factor in line breaking, hyphenation and ellipsis. Don't forget font-face and size. It's usually not done in a noticeable way, or at all, but those can be set to anything for textareas too.

edflsafoiewq 3y ago

They can't change the meaning of an existing property since the web doesn't break backwards compatibility. And AFAIU form-sizing: normal does reuse existing properties by making width/height have the normal meaning.

jauntywundrkind 3y ago
You're not breaking backwards compatibility by introducing a new valid value, which before would have been invalid.
- sharlos201068 3y ago
  If they did as you suggest, there are websites today that would start being rendered differently to before. For the most part, browsers are very reluctant to make such changes.
  - jauntywundrkind 3y ago
    What is your assertion here? Old websites were saying "width: max-content" in the past? That they happened to ask for what was an invalid value that so happens to have this weird name? Can you find any evidence that this happens? This seems incredibly fantastically super unlikely. And it was an invalid use if it did exist. Sounds like a big huge bundle of nonsense FUD to me.
    - edflsafoiewq 3y ago
      max-content/min-content/fit-content already exist, they aren't invalid.

bfgeek 3y ago

Its not the same thing. min-content/max-content/fit-content etc for these form control elements are some magical value (for textareas "1lh * attr(rows)") for example. (This works cross browser!) min-content/etc get invoke in more places than you'd expect. For example: <table> <tr> <td> <input style="width: 100%"> </td> </tr> <tr> <td> <input style="width: 100%"> </td> </tr> </table> Here when initially sizing the table the "width:100%" will actually be "width:min-content". (We can't change how this works, it'll break sites, and I'm oversimplifying slightly). This property is basically a switch to say "don't use the magical values for the intrinsic sizes size based on your content instead". With the new form-sizing property (or whatever it gets named) all the inputs in that table will be sized to the maximum input. I understand its frustrating but changing a 20+ year platform isn't an easy/simple affair sometimes :).

bfgeek 3y ago
Additionally this property disables the "compressibility" hack which browsers invoke currently. (jsfiddle for previous example: https://jsfiddle.net/vk8fy1bz/ https://jsfiddle.net/vk8fy1bz/ )
- pests 3y ago
  Compressibility hack?
  - john_the_writer 3y ago
    I was wondering the same thing. The fiddle didn't do anything. Two input boxes is all I got.

derefr 3y ago

Consider: when using `form-sizing: normal`, what CSS properties do you use to specify the size of the textarea when it's empty? (min-width and min-height would be obvious contenders, but nobody's currently doing that, because currently, textareas don't change size except when JS manipulates their width and height.)

rezonant 3y ago
min/max width are indeed already used by browsers on textarea, but only to limit how large or small the user can resize them by dragging the corner.

dclowd9901 3y ago

Right; I’m curious what setting a height would mean if you had this property set. This is the kind of non-determinism that makes me despise CSS.

spankalee 3y ago
It's not non-determinism. It'll be fully specified.

TacticalCoder 3y ago

[flagged]