Now that #1510 has landed we still have one final issue to fix (ironically, the initial reason for #1510). https://github.com/facebook/react/pull/1510#issuecomment-170229012 + https://github.com/facebook/react/pull/1510#issuecomment-170229162, the problem being that `value` is managed as a property for the purpose of `<input>`, but `<progress>` requires it to be an attribute so that the attribute is correctly removed when null.

As discussed in the second comment, it seems to me that the right approach here is to actually remove all the special property logic from DOMPropertyOperations and instead implement it in the appropriate wrappers instead (ReactDOMInput, etc).

Repro: http://jsfiddle.net/670u7ure/8/
Original issue: https://github.com/facebook/react/issues/1431

cc @jimfb, @spicyj

if (props != null && props.value === null && !didWarnValueNull) {
    warning(
      false,
      '`value` prop on `input` should not be null. ' +
      'Consider using the empty string to clear the component or `undefined` ' +
      'for uncontrolled components.'
    );
    didWarnValueNull = true;
  }
}
/**
 * Implements an <input> host component that allows setting these optional
 * props: `checked`, `value`, `defaultChecked`, and `defaultValue`.
 *
 * If `checked` or `value` are not supplied (or null/undefined), user actions
 * that affect the checked state or value will trigger updates to the element.
 *
 * If they are supplied (and not null/undefined), the rendered element will not
 * trigger updates to the element. Instead, the props must change in order for
 * the rendered element to be updated.
 *
 * The rendered element will be initialized as unchecked (or `defaultChecked`)
 * with an empty value (or `defaultValue`).
 *
 * @see http://www.w3.org/TR/2012/WD-html5-20121025/the-input-element.html
 */