Re: [editing] Leading with ContentEditable=Minimal

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