- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 02 Jul 2014 15:46:02 -0700
- To: Ben Peters <Ben.Peters@microsoft.com>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, 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>
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 >
Received on Wednesday, 2 July 2014 22:47:21 UTC