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

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