Allow contenteditable elements as fillable fields #48

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

JonRowe commented Jan 22, 2013

Companion commit, branch, pr, etc to jnicklas/capybara#911

@JonRowe JonRowe referenced this pull request in teamcapybara/capybara Jan 22, 2013

Closed

Support filling in `contenteditable` elements #911

Collaborator

jnicklas commented Jan 22, 2013

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.

JonRowe commented Jan 22, 2013

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.

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.

Collaborator

jnicklas commented Mar 26, 2013

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.

@jnicklas jnicklas closed this Mar 26, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment