On May 27, 2014, at 2:56 AM, Robin Berjon <ro...@w3.org> wrote: > 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 was a discussion about participating in the form submission in general back in Feb: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html > 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? I think we should come up with a generic form participation mechanism that could be used for cE=minimal. - R. Niwa
