I have tested this item ✅ successfully on c68011c

?
that size was made with purpose, no need to change it

I have tested this item ✅ successfully on c68011c

Works as expected. While generally I like to maximize space usage for certain input fields, it's rare that someone will need beyond 210px of text width. And of course it still works for those who have a lot of text.

And of course it still works for those who have a lot of text.

but it will become hard to edit the text in these fields,
that why the width was extended for these particular inputs,
so I am against this changes

it's rare that someone will need beyond 210px of text width

rare to input what ?
e.g. parameter for folder path will not fit, and the most relevant part of folder (its ending) will always be hidden, you will need to click and scroll to view / edit it (and changing text-align is not a solution, hiding its start)

e.g. then the 3 "elements" parameters could even be considered to be of "textarea" type,
if we make them smaller it will be quite annoying to edit, unless you copy paste their contents to a text editor and then back to the parameters

let's make it (maybe) a little more beautiful, regardless of usablilty for people that will actually use these parameters
there should be PRs doing the reverse of what this PR does

Yeah, wasn't thinking about paths. Valid point. Textareas did come to mind.

RTC after two successful tests.

textarea

the textarea make not much sense, as the code expect "Single line", and in textarea user can think that he can use "new line"

Please remove the RTC status - just because it has had two successful tests doesnt mean that the issues that @Fedik raised can be ignored

Imho it doesn't make sense to make the fields smaller beside it looking a bit ugly. So the usuability argument for the CSS file field wins over the design one hands down. Textarea is no option for this field as well.

I'm closing this PR as it will not get merged in this state.