Companion commit, branch, pr, etc to jnicklas/capybara#911
include contenteditable elements as fillable fields
I don't like this. While contenteditable elements are editable, they are distinctly not fields. In the context of Capybara it kind of makes sense that we would allow contenteditable fields for fill_in, but even there, those elements behave quite differently from actual fields. They can't have labels for instance. This doesn't provide any functionality that Capybara currently cannot offer, after all, you can just do find("#foo").set("bar") instead of fill_in, and it just confuses the semantics of fill_in needlessly. This has been suggested previously, (even with a pull request, iirc) and I turned it down then, my position hasn't changed since.
To me, fill_in 'x', with: 'text' doesn't semantically say "fill in field x with text". It say's, "user is providing text for x", and contenteditable elements are perfectly acceptable targets, especially as this is a pretty usable part of the HTML5 spec.
fill_in 'x', with: 'text'
I will defer to your opinion on the finding field xpath, your library, your preference and all but please don't discard the other pull request, jnicklas/capybara#911, it's still valid, as find('#contenteditable').set('text') won't work as it stands.
We're still working out the details of jnicklas/capybara#911, and I hope we'll eventually merge it, but I'm closing this pull request.