- From: Johannes Wilm <johannes@fiduswriter.org>
- Date: Tue, 1 Jul 2014 07:33:46 +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-SitruRODck5P3LO+QnYKfcZj=PqFSrBWdg4Pfvp-Q-9w@mail.gmail.com>
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 Tuesday, 1 July 2014 05:34:15 UTC