Bugzilla

(In reply to Ian Kilpatrick [:iank] from comment #11)
> Hey - yeah scrollbars for textareas are very weird today. [...]
> We basically do what you describe today - in that if the <textarea> has "overflow-wrap: normal" we'll reserve the space for the scrollbar.

Thanks!

So, that is indeed very weird.  The code linked there is documented with this code-comment: "We are able to have a horizontal scrollbar if the overflow style is  [...] auto and there's no word wrap."

This is clearly wrong/incomplete.  That comment and the associated code are asserting that `overflow:auto` textareas with the default `word-wrap` styling **will never have a horizontal scrollbar**.  That's clearly incorrect, given e.g. [testcase 2](https://bug1830576.bmoattachments.org/attachment.cgi?id=9330850) here, where WebKit and Chromium both show a scrollbar on at least some of the textareas.

(Having said that: the cases where a scrollbar is needed are admittedly a bit edge-casey; they require the textarea to be on the order of 1em wide, which might (?) be pretty rare in practice.  So maybe it's a net win to optimistically not-reserve-space for the scrollbar, and then take the hit and cover up content if it ends up being needed?)

> (Note we also just received a bug for always reserving space for the scrollbar in the inline dimension - I'll likely update this to match you - e.g. only reserving space for auto/scroll overflow).

Can you share a link to that bug?

(And just to clarify, by "space for scrollbar in the inline dimension", are you talking about a vertical scrollbar (which contributes width i.e. space in the inline dimension), or a horizontal scrollbar?  I want to better understand what change you're tentatively planning on, so we know to what extent it influences whether there's anything to be done on our end here. :) )

(In reply to Ian Kilpatrick [:iank] from comment #11)
> Hey - yeah scrollbars for textareas are very weird today. [...]
> We basically do what you describe today - in that if the <textarea> has "overflow-wrap: normal" we'll reserve the space for the scrollbar.

Thanks!

So, that is indeed very weird.  The code linked there is documented with this code-comment: "We are able to have a horizontal scrollbar if the overflow style is  [...] auto and there's no word wrap."

This is clearly wrong/incomplete.  That comment and the associated code are basically asserting/expecting that `overflow:auto` textareas with the default `word-wrap` styling **will never have a horizontal scrollbar**.  That's clearly incorrect, given e.g. [testcase 2](https://bug1830576.bmoattachments.org/attachment.cgi?id=9330850) here, where WebKit and Chromium both show a scrollbar on at least some of the textareas.

(Having said that: the cases where a scrollbar is needed are admittedly a bit edge-casey; they require the textarea to be on the order of 1em wide, which might (?) be pretty rare in practice.  So maybe it's a net win to optimistically not-reserve-space for the scrollbar, and then take the hit and cover up content if it ends up being needed?)

> (Note we also just received a bug for always reserving space for the scrollbar in the inline dimension - I'll likely update this to match you - e.g. only reserving space for auto/scroll overflow).

Can you share a link to that bug?

(And just to clarify, by "space for scrollbar in the inline dimension", are you talking about a vertical scrollbar (which contributes width i.e. space in the inline dimension), or a horizontal scrollbar?  I want to better understand what change you're tentatively planning on, so we know to what extent it influences whether there's anything to be done on our end here. :) )

(In reply to Ian Kilpatrick [:iank] from comment #11)
> Hey - yeah scrollbars for textareas are very weird today. [...]
> We basically do what you describe today - in that if the <textarea> has "overflow-wrap: normal" we'll reserve the space for the scrollbar.

Thanks!

So, that is indeed very weird.  The code linked there is documented with this code-comment: "We are able to have a horizontal scrollbar if the overflow style is  [...] auto and there's no word wrap."

This is clearly wrong/incomplete.  That comment and the associated code are basically asserting/expecting that `overflow:auto` textareas with the default `word-wrap` styling **will never have a horizontal scrollbar**.  That's clearly incorrect, given e.g. [testcase 2](https://bug1830576.bmoattachments.org/attachment.cgi?id=9330850) here, where WebKit and Chromium both show a scrollbar on at least some of the textareas.

(Having said that: the cases where a scrollbar is needed are admittedly a bit edge-casey; they require the textarea to be on the order of 1em wide, which might (?) be pretty rare in practice.  So maybe it's a net win to optimistically not-reserve-space for the scrollbar, and then take the hit and let the scrollbar cover up content if it ends up being needed?)

> (Note we also just received a bug for always reserving space for the scrollbar in the inline dimension - I'll likely update this to match you - e.g. only reserving space for auto/scroll overflow).

Can you share a link to that bug?

(And just to clarify, by "space for scrollbar in the inline dimension", are you talking about a vertical scrollbar (which contributes width i.e. space in the inline dimension), or a horizontal scrollbar?  I want to better understand what change you're tentatively planning on, so we know to what extent it influences whether there's anything to be done on our end here. :) )