Textfields not responsive design friendly

Textfields don't work this way. You would have to do something special, perhaps with jQuery. We don't provide this type of support in this issue queue. You might try the forums or IRC. Good luck!

The maxlength attribute refers to the maximum number of characters that can be entered into the form component. If you want to make sure the component is not wider than its parent element, use CSS "max-width: 100%".

There is a major issue with the webform module. It automatically inserts the 'size' attribute into input type text, with a default of 60. The problem here is that (in firefox at least), even when setting a width on the input:text with CSS, the wrapper element is pushed out to the width that it would be if the CSS hadn't been applied. This is not responsive design friendly at all. The only way I could find around this was to set a font-size on the input, so that 60 characters at that font-size properly fits into the width of phones in portrait view.

The 'size' attribute of textfields should only be set if the user sets that value through the admin interface. And in fact, it really shouldn't be set at all, as this is a display element, and display should be controlled through CSS, not through HTML. However, for legacy reasons, I can see leaving the option available through the admin interface, but only inserting this attribute if/when the user has explicitly set it through the admin interface.

If you want to ensure that user's sites are not affected with an upgrade, you could set the default as 60 through the admin interface, and let users remove it if they so wish.

As it stands right now, I tried setting 'auto' or '-1', but these didn't work. So we are forced to put some width in the textfield, even though this is not responsive friendly.

@jaypan, every core field I see has a required size field. Am I mistaken? If not, then it would seem that webform should follow core's lead here.

Also, if you are really using 4.1, you should upgrade ASAP as there are security issues with that version.

I don't actually know what version is on the site - I was just adding to this issue.

If core is inserting the size attribute, it should also be removed from core as well. It's not design friendly, and it goes against the principle of separation of design and markup.

If you really want to have it in there, there should at least be a method to remove it - adding 0 (zero) to the width field or something.

I agree that it should not appear in the markup. I also agree that Webform should follow core.

You can probably remove it with a hook implementation. If nothing else, you can remove it by overriding the appropriate theme function.

Here's a little discussion:
http://stackoverflow.com/questions/1480588/input-size-vs-width

You could use jQuery to remove them, which would be easier than overriding all the core and webform theme functions. Regardless of the merits, webform will follow D7 core. If this is still an issue in D8 and D8 doesn't use size, then I would agree that it should be removed from webform D8.

Wow, I don't actually use webform, I'm just doing some work on a site that already uses it. But the unwillingness to even add an option to remove the size has convinced me that it's not a module I will be wanting to implement in the future.

Sorry you feel that way. It has been Webform policy to follow core's lead. This seems like reasonable and prudent to me. I didn't create this policy -- quicksketch did -- but I agree with it.

Even if we implemented this fix for webform, it would leave you the much larger issue of fixing all of the rest of core. If you wanted to fix it everywhere, the jQuery solution I suggested would be easy and would fix it everywhere in Drupal. Further, the size attribute provides support for older browsers, as indicated in the stack exchange thread I referenced.

The form I'm typing on now has size attributes, FWIW. :)

EDIT: You might consider Entity Forms as an alternative to Webforms. But, oh wait, it uses core fields so they will all have size attributes too. Drat. ;)

Sorry you feel that way. It has been Webform policy to follow core's lead.

And that is fine. I'm just amazed that you won't even create an option to remove it if the user wants.