- From: Johannes Wilm <johannes@fiduswriter.org>
- Date: Wed, 9 Jul 2014 15:46:37 +0200
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Ben Peters <Ben.Peters@microsoft.com>, Robin Berjon <robin@w3.org>, Olivier F <teleclimber@gmail.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-RpHmHDwS34mY5Hk1cYVnmaKt7aCVQiL+768fidzDZzJw@mail.gmail.com>
Also check out Carota - a webbased editor with the ability to add complex elements (click the smiley) using the canvas element in order to get around the problems with contenteditable. http://earwicker.com/carota/ On Thu, Jul 3, 2014 at 11:33 AM, Johannes Wilm <johannes@fiduswriter.org> wrote: > Do you mean browser developers or editor developers? Wouldn't this task > force group be a good place? I've notified the Substance.io team about it. > Some others that might be interested, that I haven't seen here yet: > TinyMCE, Aloha, Wikimedia Wysywig editor, the WYSYWIG editor project of > PLOS, HalloJS, Codemirror, Booktype (another project to write books in the > browser), Firepad, ShareLatex, WriteLatex, WebODF, ICE (I have contributed > most of the Chrome code to it, but I'm not part of the core developer > team). Others? > > I don't know what your procedures are for such things, but maybe send them > all an email? We may have to accept that a lot of projects are slightly > tired of contenteditable/caret-moving fixing efforts, given that so many > attempts to fix it have failed in the past. Lets make sure this doesn't > happen this time. :) > > From my experience, the issues/use cases mentioned will cover just about > all the main problems. I would personally move the DTP out of this, at > least if DTP is to understood mainly as fragmentation stuff. That is very > important, but the debates on fragmentation are there already and we should > be able to find an agreement on cursor movement even if the issues around > fragmentation cannot be resolved. > > > > > On Thu, Jul 3, 2014 at 12:46 AM, Ryosuke Niwa <rniwa@apple.com> wrote: > >> Thank you Ben! >> >> It would be great if we could get more use cases from developers who are >> interested in improving editing API. >> >> Is there any communication channel we can use for that? >> >> - R. Niwa >> >> On Jul 2, 2014, at 3:12 PM, Ben Peters <Ben.Peters@microsoft.com> wrote: >> >> > Great discussion on this! I have added these to the Explainer Doc[1]. >> Please let me know what you think of the list so far. I would also like >> discuss this in the meeting next Friday[2], so anyone that can come would >> be great! >> > >> > Ben >> > >> > [1] http://w3c.github.io/editing-explainer/commands-explainer.html >> > [2] >> http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0011.html >> > >> > On Mon, Jun 30, 2014 at 10:33 PM, Johannes Wilm < >> johannes@fiduswriter.org> wrote: >> >> >> >> >> >> >> >> On Tue, Jul 1, 2014 at 4:39 AM, Ryosuke Niwa <rniwa@apple.com> wrote: >> >>> >> >>> On Jun 30, 2014, at 1:43 PM, Johannes Wilm <johannes@fiduswriter.org> >> >>> wrote: >> >>> >> >>> On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa <rniwa@apple.com> >> wrote: >> >> >> >> <snip> >> >>>> >> >>>> >> >>>> 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. >> >>> >> >>> >> >>> CSS regions is still shipped in iOS/OS X Safari, and I don't expect >> it to >> >>> go away anytime soon. CSS columns support is still in Blink as well. >> >>> Furthermore, I don't think CSS WG is halting the work on >> fragmentations >> >>> either. We should still keep it as a use case for the new editing >> API. In >> >>> addition, I would suggest that you go talk with people in CSS WG and >> add >> >>> your use case. >> >> >> >> >> >> Yes, I am aware of that. I spent a year creating a CSS Regions based >> book >> >> layout engine ( http://fiduswriter.github.io/pagination.js/ ) , so I >> am >> >> absolutely interested in fragmentation coming back one day. In the >> meantime >> >> I have created an ad-hoc solution using CSS columns ( >> >> http://fiduswriter.github.io/simplePagination.js/simplePagination.html >> ) >> >> >> >> The main difference is that the CSS fragmentation based version allows >> to >> >> combine it with contenteditable (text flowing from page to page while >> >> editing/writing it). Using Javascript/CSS multicolumns to create the >> same >> >> design means cutting up the DOM, so it has to be done after the text is >> >> written. We switched to this second approach when it became clear that >> CSS >> >> Regions would be removed from Chrome. >> >> >> >> The way we handle it is to let the user write the text in one large >> page >> >> with the footnotes off to the right. When the user hits CTRL+P, the >> current >> >> contents of the edited doc are copied, the original contents is hidden >> and >> >> the copied version is cut up into individual pages. By the time the >> user >> >> gets to the print preview, page numbers, headers, table of contents, >> >> footnotes, etc. have all been put in place. Fragmentation would be >> great to >> >> have, but for now I would already sleep much better if we would have a >> more >> >> solid selection/caret-moving base to build upon. >> >> >> >> >> >>> >> >>>> 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. >> >>> >> >>> >> >>> Could you elaborate more on what kind of inline styling you're >> thinking >> >>> of? And how and why you want to allow/restrict certain styles? >> You're >> >>> providing us of really important information here, and I really >> appreciate >> >>> if you could give us more information here :) >> >> >> >> >> >> For example a blog may decide not to allow any inline-css styling. And >> to >> >> emphasize words they may only want to allow bold and italics, but not >> >> underline and not a combination of italics and bold on the same word. >> >> >> >> Of course visually this may be achievable using a lot of !important >> >> statements in a general css file for the page. But the contents will >> turn >> >> messy and if users copy from a social media site to a word processor >> to a >> >> blog, and from there to another blog and then into their html-based >> email >> >> and then into another blog... things will end in disaster for certain >> at >> >> some point. >> >> >> >> -- >> >> Johannes Wilm >> >> Fidus Writer >> >> http://www.fiduswriter.org >> > >> >> > > > -- > Johannes Wilm > Fidus Writer > http://www.fiduswriter.org > -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Received on Wednesday, 9 July 2014 13:47:06 UTC