The width of input elements is "hardcoded" by CSS rules. I think it is this rule:

// Reset appearance properties for textual inputs and textarea
// Declare width for legacy (can't be on input[type=*] selectors or it's too specific)
input,
textarea,
.uneditable-input {
  width: 206px; // plus 12px padding and 2px border
}

https://github.com/joomla/joomla-cms/blob/staging/media/jui/less/forms.less#L92-L98

Browsers will first use CSS rules to decide width of field
and then if none CSS rule is found to effect the field's width
only then the size parameter will be used to calculate the width of the field

only an inline CSS rule like the following (i have not tested) could do the trick
.... 'width: ' . $size . 'em;'

but it is wrong to do for all text fields thus overriding the template's CSS,
maybe adding a parameter "enforce size width" is a solution

Closed as expected behaviour

@brianteeman how can you say "expected behavior" when we have a parameter in the form field system that is SPECIFICALLY for specifying size?
EVEN if you said, well we've hard coded the size into .css then it STILL is a bug as it's not following the DESIGN of the form field system by not honoring the param so therefore the param needs to be removed,
No matter how you slice it you shouldn't have closed this.
https://docs.joomla.org/Special:MyLanguage/Text_form_field_type

I think this is a proper way to fix this

since the width parameter has the effect to add:
size="40"

making it also add (i have not tested, it should work, it will be a little off depending on box-sizing setting in effect but this is close enough)
size="40" style="... ; width: 40em;"

should not be bad choice
it would be doing what the user asked for

@ggppdk I think your on the right track.. I believe we need to pull the parm and then either do css calc or calc in php using $width = $this->get(param) . ".ch" or possibly ".pt" but I think its ch

This would be really useful to add

Closed as expected behaviour

@brianteeman it is expected behaviour
in terms that the parameter is meant to add size="..."
and it does add it,
and then CSS has higher priority

but this is looks like worthile making it better and enforcing an inline width CSS style for the text field, to achieve what the user needs for the specific field

I don't see this should be closed
I have <field name="ListFormat" type="text" default="" size="600" label="List layout format" description="List layout format" />

and am using J3.9.3 and I get a text box of 206 wide when I need more (perhaps not 600)
why have an option if it DOES NOT WORK

@frankmayer reopen this please

We can't fix this i the xml because it's not the right place to add styling, the only thing you can do is to add a custom "class" and add css to the template. Even if we add a "style" attribute to the xml tag it would be the wrong approach because we shouldn't do any styling in the form xml.

For mod_search we are using this code:
6160e39#diff-602b029403197b38b1471bf1c6b6c1cd

Means: ressetting the width style with auto using a bad inline style.

I don't think that it's worth to implement things like that. See comment #15727 (comment) (custom class)

Best would be to actually remove the size attribute fromt he XML. As nowadays things like size should be done with CSS. Especially since size isn't reliable anyway.

@Bakual would you like to make a pr for j5?

I don't understand all these comments. If I remove the lines
input,
textarea,
.uneditable-input {
xxwidth: 206px;
}
lines 912 onwards from administrator/templates/isis/css/template.css then the input field display to what look like the correct width

@ramblerswebs The point is: It's correct that the CSS specifies the width, as it is a design question which is in the responsibility of the template. So the CSS is fine, and naturally the size attribute is ignored.

@HLeithner I wasn't aware we're already doing PRs for J5 ?

@HLeithner I wasn't aware we're already doing PRs for J5

iirc there shouldn't be no "big" deprecation in j3.10 for 4.0 so changes is is only possible in j5

Agreed. But I don't think I will remember this here when we start the J5 branch. So don't count on me.

@Bakual makes a "J5"-Label sense?

It may be. Lets ask @wilsonge what his thoughts are about adding issues to the backlog for J5 already :)