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

Also check out Carota - a webbased editor with the ability to add complex
elements (click the smiley) using the canvas element in order to get around
the problems with contenteditable. http://earwicker.com/carota/


On Thu, Jul 3, 2014 at 11:33 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> 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
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org