- From: Johannes Wilm <johannes@fiduswriter.org>
- Date: Mon, 30 Jun 2014 22:43:45 +0200
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Olivier F <teleclimber@gmail.com>, Robin Berjon <robin@w3.org>, Ben Peters <Ben.Peters@microsoft.com>, Julie Parent <jparent@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
- Message-ID: <CABkgm-SXDd9+U2W2c9jME3crjLh2EumgHjgDughTP=ocPZV4Zw@mail.gmail.com>
On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa <rniwa@apple.com> wrote: <snip> > > On Jun 26, 2014, at 3:24 PM, Olivier F <teleclimber@gmail.com> wrote: > <snip> > I agree these all seem the same. Here are a few other use cases I can > think of: > > * Create a web-based structured content editor, where the allowable DOM > elements and/or classes in the content are pre-defined. > > > Could you elaborate on the use case of making such an editor? e.g. > allowing only certain types of styling in comments. > We do that in Fidus Writer. Part of the point is to keep the structure of the document semantically defined. Users can't change font sizes of individual words, etc. . This is because one of the main tasks of scientific journal editors who currently receive drafts in Word or Libreoffice format have to undo all the manual styling the writers have added in order to get everything to look in a similar way. we simply take those styling possibilities away so that we can define the entire design through one stylesheet as well as easily convert to other formats, such as LaTex or an Epub, and be sure that we cover all formatting tags that were used. > > * A complete book/whatever editor, which can contain areas of non-editable > content, nested editable content, etc... See fiduswriter.org, and what > CKEditor are doing with widgets. > > > Could you elaborate on how non-editable content appears/used inside an > editable content? > We also do that - for example in the case of formulas. Generally the text is editable near-Wysiwyg style. But when it comes to formulas, we let the user enter them in Latex format and display the result using mathjax. Each formula object within the text is a noneditable island. If the user clicks on it with the mouse, he can change the formula. Another example are figures: We want them to always be block elements and to have exactly one caption without styling. They are therefore non-editable isalnds and if the user clicks on them he can change the figure's display and the caption text. > > * Browser-based code editor. Currently CodeMirror and others go through > amazing lengths to provide something that looks and behaves like a desktop > code editor. > * Browser based "word art" generator where end-user types some text and it > renders in 3D along a curve and in rainbow colors on a <canvas>. > > > These are great use cases. > > I'd throw in two more: > > - Web-based DTP application: The app can creates a document that > contains pagination, columns, and a complex illustrations. It needs to let > users edit any text that appears in the document. Each editable text needs > to be accessible, and styles applied to text need to be backed by the > application's internal model of the document. > > Yes, but wouldn't this require some fragmentation logic? To create something like what Quark Xpress was in the 1990s, I think you'd need CSS Regions or equivalent. It seems as if that would be a little outside of the scope of the caret moving logic, or how do you mean? I would find it great if this ever happens, but as I understand it the whole fragmentation debate was left aside for a while. > > - Semantic HTML WYSIWYG editor for a blogging platform: The editor > needs to able to add both semantic and visual annotation to the document as > it will be published as a blog. Headings are to be marked up with h1. h2, > etc... and each acronyms, abbreviations, and so forth are marked up with > respective HTML elements. However, the editor also supports visual > annotations such as bolding, italicizing, and enlarging text, each of which > will be interpreted by the editor to respective underlying semantics in > HTML. > > Yes, and in order to keep things consistent he may want to disallow certain types of styling. A few years ago it was common to see people with Joomla sites who just pasted the text into the editor after copying it from a word processor. Each blog post therefore ended up having very different styling. > > > I picked these examples because they illustrate why separate building > blocks are the right way to go. I would expect the developer of the > structured content editor to leverage cursor=true, commandEvents and > Selections API, and if it's available some sort of text insert mechanism. > In contrast the "word art" developer would only leverage commandEvents and > will have to draw their own cursor and selections along with their fancy > curved 3D text. > > > Thanks for a great list of use cases. Now we need a required set of > features/API for each use case. We can then evaluate whether what has been > discussed thus far satisfy enough use cases or not. > > - R. Niwa > > -- Johannes Wilm Fidus Writer http://www.fiduswriter.o <http://www.fiduswriter.com/>rg
Received on Monday, 30 June 2014 20:44:13 UTC