W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

contentEditable and forms (was: contentEditable=minimal)

From: Robin Berjon <robin@w3.org>
Date: Tue, 27 May 2014 11:56:42 +0200
Message-ID: <5384615A.1090401@w3.org>
To: Piotr Koszuliński <p.koszulinski@cksource.com>, Ben Peters <Ben.Peters@microsoft.com>
CC: Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
On 27/05/2014 09:19 , Piotr Koszuliński wrote:
> Yes, it should be possible to disable whichever feature you don't need.
> In some cases you don't need lists (because e.g. you're editing a text
> that will become a content of a paragraph). And in some cases you don't
> want bold/italic because your use case requires only structured HTML. So
> being able to handle such commands is a one thing. But first of all
> there should be no assumption that a user needs these buttons, because a
> browser just don't know about that. If I think that users need toolbar,
> I can render a custom one.

Much agreed. The browser should not show any markup/styling affordance 
for cE=minimal.

> There's one more assumption that makes editing on mobile devices
> (especially low-res devices) very hard. It's that if user focuses
> editable, then he/she wants to type, so native keyboard should pop out.
> Very often it's true, but in some cases user may want to select some
> text and using toolbar apply styles or lists, etc. And when the keyboard
> is visible there's very little space to do that. If there was any API to
> control whether keyboard is visible, then we could achieve much better UX.

There are quite a few things from forms that I think could usefully 
become available in an editing context. We could benefit from having the 
inputmode attribute be allowed on any editable piece of text. For the 
specific use case you cite, an additional keyword of "none" might make 
sense too.

It possibly wouldn't hurt to have the placeholder attribute be available 
on all editable content, too. I'm less sure about the validation 
attributes (except perhaps required) but why not.

Obviously validation attributes only make sense if the editable content 
can contribute to forms. But it would make a lot of sense that it could. 
Today you have to resort to ugly hacks in which you somehow copy over 
the edited content into a textarea. That's pretty daft: in most use 
cases you're going to be submitting the content.

There are several ways in which we could handle this. One is to have any 
element with cE=minimal contribute to the form data set (when inside a 
form, or possibly when using the form attribute if someone remembers 
what the use case for that thing was). That's interesting, but I get a 
sense that it conflates two features. Another approach is to add a 
"submittable" attribute that can make the innerHTML of any element 
contribute to the form data set.

Thoughts?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 27 May 2014 09:56:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC