Re: [editing] Use Cases (was: Leading with ContentEditable=Minimal)

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