[question] Should paper-input (and/or other inputs) be redesigned?

[ghost]

Do you have any plans to make paper-input (and paper-checkbox and other inputs) with decorator-pattern? This would solve all of the below issues?

Now using paper inputs and forms is too complicated. Here's a few things which bothers me:

• to use current paper-input you need to use iron-form
• iron-form doesn't work with input type="file"
  • https://github.com/PolymerElements/iron-form/issues/84
  • https://github.com/PolymerElements/iron-form/issues/54
• iron-form has a lot of code which mainly serialize form data to send it .. by ajax perhpas it would be better to allow use old form-submit
• actually old form-submit is used in internals by coping fields to redundant form I did it a few times in my element and it's bad imho
• input attributes are passed down to native input and it's a lot of that, which maybe suggest that it should have been exposed instead of hiding it in shadow-dom
• Component user has to use iron-form where he/she could use the platform's native form if only paper-input were made with decorator-pattern

To balance my complaints I want to write that I like Polymer much, especially the idea of:

• assembling over crafting
• the way Polymer allows to write declarative html over stinky js ;P

so great job :)

Perhaps it's not the best place to raise this issue, but i didn't have better idea.

[notwaldorf]

Technically you can still do this today, using paper-input-container and an iron-input directly. I agree that this element should be refactored, but doing so is an enormous breaking change -- and while doing the refactor, a lot of the features in this element should get rewritten/refactored.

The team is still figuring out how to best rewrite the elements in a pure 2.0 fashion that's more maintainable, faster and efficient than what we have currently -- stay tuned!