Skip to content

Allow contenteditable elements as fillable fields #48

Closed
wants to merge 1 commit into from

2 participants

@JonRowe
JonRowe commented Jan 22, 2013

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

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

Support filling in `contenteditable` elements #911

@jnicklas
Owner

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
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.

@jnicklas
Owner

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
Something went wrong with that request. Please try again.