IE doesn't set value when creating element if css attributes are used #2178

leon opened this Issue Dec 20, 2011 · 6 comments


None yet

5 participants

leon commented Dec 20, 2011

Try running this in IE9
new Element("input.ok[type=submit]",{
value: 'OK'

the button doesn't get a value, which means IE sets the default "Submit Query"

arian commented Dec 20, 2011

This has to do with IE, if you first set the value, and then set the type, for example:

new Element('input', {value: "hi", type: "submit"})

doesn't work either.

If you use the selector syntax, the parsed properties are appended to the other properties, so the value is first set, then the type.

A fix for this would be to set the type first, and after that the value. Not sure if we should do this in MooTools, or that this should be done in your code...


I think it makes sense to have a special case for the type property since this is a very unique case. AFAIK It's the only attribute that changes the behavior of a DOM element.

It may also be difficult to control the order in which properties are defined. For example if you're merging two property objects (options) and either one can have type or value. E.g:

new Element('input', Object.append({ type: 'defaultType', value: 'defaultValue' }, options));

I think the solution is not to enforce a certain order, because that makes chained set calls inconsistent. Instead, "type" should have a propertySetter that reads the current values and re-sets them after the type has changed. But that is a slight performance hit for all input element creation. Although minimal.

@arian arian added a commit to arian/mootools-core that referenced this issue Dec 24, 2011
@arian arian Fixes #2178 - A input field should keep its value even when the type …
…property is changed (in IE)

to be fair, there are certain implications with this in general, browsers deal with type changing differently. eg, input[type=password][value=foo].set("type", "text") - should it really keep the value? not to mention this will actually fire an exception in Ie6/7/8. consider input[type=text][value=c:\autoexec.bat].set("type", "file")


Where it works, it works. Where it can't, it won't. :)

It rarely makes sense to dynamically change the type of an input element. This fix only applies where it does make sense. Initialization in particular.

Inviz commented Dec 25, 2011

I thought IE < 8 never allowed changing of type attribute once it was once set. So you have to create a new element.


This patch isn't to allow changing type attribute once set. It's to allow the type and value properties to be initialized out-of-order.

@arian arian closed this in 5c6b2d2 Jan 30, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment