Support Indeterminate checkboxes

[jquense]

Adds support for setting indeterminate or defaultIndeterminate props on checkbox elements. The tricky bit was properly setting the initial state from existing markup since indeterminate is not a content attribute. To that end I added a new IDL Only Attribute flag for DOM properties that does not generate any additional markup for said properties. In addition ReactDOMInput is responsible for setting the initial state based on props at mount.

I went with a controlled/uncontrolled approach for the API since that seemed like the most straight forward, and keeps the coupling to checked to a minimum. I am not sure if the caveat about browser behavior differences mentioned in #1798, exists but it's an easy fix to toggle indeterminate to false onChange in the uncontrolled case.

closes #1798

[jquense]

this could be theoretically handled more generally, by having something loop through props propertyInfo and checking for IDL only attributes and setting them. Perhaps that would be more efficient? My assumption is that the above will properly batch everything anyway so it may not matter.

[jimfb]

@spicyj It has been a week, can you take a look at this?

[jquense]

I've been looking back at other issues with non content attributes: #2140, #2094 (comment), and the idea of supporting them seems fairly negative, so maybe this falls into the category as well (although the discussion in #1798 was more hopeful). It seems like this case, at least, fits more easily into a declarative model.

I'd be happy to rebase if anyone thinks this is a reasonable approach.

[jquense]

ping!

[syranide]

I think this is a really tricky subject. React supporting non-attribute properties plays badly with SSR (not that you can avoid it) and it opens up a whole new area of what else. A redeeming factor here is that it is at least local to ReactDOMInput and not a special-case in HTMLDOMPropertyConfig, but shouldn't we then also support all the other properties audio, video, etc has? But that seems contrary to certain previous discussions and will certainly significantly affect the size of the React codebase.

It should be possible to implement this as a user-land wrapper component instead, which may be a better short-term (or even long-term) solution until there is a decision on the larger discussion of where to draw the line on this I think?

[sophiebits]

(cc @azich too)

[jquense]

I agree that is tricky :) I thought that this case in particular was a good one to discuss that line a bit, and explore some of the issues and possibilities.

In this case I think unlike some other non-content attributes it feels like indeterminate, could have easily been an attribute, so there isn't as much to hem and haw about in terms of a declarative api. The input component also already deviates from the native behavior in some significant ways, so this may be less magical feeling than other cases. I also think its a bit more mainstream of a use case than something like audio or video and less awkward than something like scrollTo.

There are some clear limitations here, with regard to SSR. Although they are isolated to cases using renderToStaticMarkup which is less of a SSR use case and more one of using react to just produce static pages correct? I think that otherwise tho this will play nicely with SSR.

[jimfb]

I have very mixed feelings about this one. Ultimately, I think @syranide is right.

This opens a large can of worms. At least for now, this is probably better handled in user land by providing a custom component. This doesn't merge cleanly, and there is no clear path forward, so let's close this out for now. We can come back to this if/when our thinking on this matter changes.