- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Wed, 2 Jul 2014 22:12:10 +0000
- To: Johannes Wilm <johannes@fiduswriter.org>, Ryosuke Niwa <rniwa@apple.com>
- CC: Olivier F <teleclimber@gmail.com>, Robin Berjon <robin@w3.org>, "Julie Parent" <jparent@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
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:12:45 UTC