allow for different block elements about scribe HOT 13 CLOSED

What are your needs and why? The <p> element is the default because it is the right semantic element for marking up a paragraph of text.

from scribe.

So basically to support any kind of additional rich editing (like medium) you need to have a more complex block structure.

Sent from my iPhone

On Apr 3, 2014, at 8:30 AM, Oliver Joseph Ash [email protected] wrote:

What are your needs and why? The

element is the default because it is the right semantic element for marking up a paragraph of text.

�
Reply to this email directly or view it on GitHub.

from scribe.

any kind of additional rich editing

Such as?

At the Guardian, we do support rich text using Scribe. Our content is represented as JSON, and HTML is only used for inline text. Content is broken down into “elements”. For example, you might have:

1. image element
2. text element
3. embed element
4. video element
5. another text element

Non-text elements, such as images, embeds, and videos, are just JSON structures that contain the necessary metadata, i.e. a URL to an image. A text element just contains the HTML for that chunk of text. It will have things such as lists and inline styling, but no images or any other rich media.

So, we have created an interface that creates this structure seamlessly, as if the user was editing a word document – except with more structure in the [hidden] representation.

from scribe.

Oh interesting. So are you writing JSON within the editor itself to represent the embeds? Or is there something like:

<p>lorem</p>
<div class="embed" contenteditable="false">... some cool graph ...</div>
<p>ipsum</p>

What happens if you need additional HTML in the paragraph block, like say a "star" for favoriting a paragraph, or a grabber for moving paragraphs around.

Or does scribe represent the text elements only?

from scribe.

too much overhead.

from scribe.

@matthewmueller You can place those elements outside of the Scribe instance, and you should be able to position those elements beside the text using CSS/JavaScript. I think that would be the semantic way of marking it up, and we are doing something similar with success in Composer.

from scribe.

👍 Are there any examples of

1. attaching metadata to text blocks
2. making image / youtube embed blocks look like they are in the text flow

?

from scribe.

At the Guardian, we do support rich text using Scribe. Our content is represented as JSON, and HTML is only used for inline text. Content is broken down into “elements”. For example, you might have:
image element
text element
embed element
video element
another text element
Non-text elements, such as images, embeds, and videos, are just JSON structures that contain the necessary metadata, i.e. a URL to an image. A text element just contains the HTML for that chunk of text. It will have things such as lists and inline styling, but no images or any other rich media.

So, we have created an interface that creates this structure seamlessly, as if the user was editing a word document – except with more structure in the [hidden] representation.

@OliverJAsh I was quite curious about how you were doing this since I am thinking of taking the same approach but not sure what the best approach is. Do you essentially have a normalization plugin that takes the markup and matches tags to element above and then creates json based on that?

Could you share your approach or is that already part of library/plugin ecosystem?

Thanks so much!

from scribe.

The CMS doesn't use Scribe to represent and edit anything but text.

It's more like:

CMS
  [scribe instance for text paragraphs]
  [image editing block]
    [scribe instance for editing image caption]
    [textarea for editing image alt text]
  [scribe instance for text paragraphs]
  [video embed editing block]
    [scribe instance for editing video caption]
  [scribe instance for text paragraphs]

Hope this makes it a little more clear.

from scribe.

@theefer Thanks for the response! So if I understand it correctly, the image and video embeds don't necessarily deal with Scribe and are just different modules/components interspersed? And does the CMS support any drag and drop between the text, image or video embeds?

from scribe.

So if I understand it correctly, the image and video embeds don't necessarily deal with Scribe and are just different modules/components interspersed?

Yes.

And does the CMS support any drag and drop between the text, image or video embeds?

Not currently, you have to use up/down/top/bottom arrows on the image/video/etc elements to move them around. There is some extra code that splits text elements so you always move media up/down individual paragraphs. You can also drop images onto empty lines using some other code handlers, which end up as an image element where you dropped it (again splitting the text element).

Drag and drop of elements around paragraphs is possible, but we haven't implemented it yet.

from scribe.

@theefer Appreciate your patience and thanks for your helpful responses :)

Part of me likes the clean separation between text and all other medias. Just to make sure I understand the CMS approach, and that I am on the right path, does the following sound reasonable -

My aims are to be able to drag and drop image, video, or add a link and have that turn into a rich preview. (Paragraph drag and drop would be a nice bonus).

Given that, here is how I am thinking it would work:

1. Initialize the first scribe instance and a user can enter text.
2. If they click on a button to add image or drag and drop one in the editor, it will add it after the 'editor' in the DOM and then auto-generate the next scribe instance.
3. This will allow for simple drag and drop using external libraries around scribe instances.
4. If someone copy-pastes a url in, and I want to turn it into an link preview in-place, it will essentially follow Step 2.

If that is correct, three more questions -

• Is the creating of new scribe instance on the fly the recommended approach or is there a more optimal approach?
• If we are creating multiple scribe instances, how do you deal with using only a single toolbar for all of them?

• There is some extra code that splits text elements so you always move media up/down individual paragraphs.

Is this available as a plugin? Or could you share the logic that you use and I could create a plugin for it?

Thanks again!

from scribe.

Is this available as a plugin?

@oyeanuj Would this make sense as a plugin?

It's not really an editor feature - it's more like the editor is a feature of that interface?

I'm working on something similar, and that's the approach I'm taking - we call them "parts" to avoid ambiguity with HTML "elements", each has a dedicated "driver" that creates and populates the editor interface for it. Each of those drivers create and manage the interface for a particular type of part, the user can add/remove parts, and some of the part drivers happen to use Scribe to create rich content editors, but that seems like a detail. So I'm not sure how this would make sense as a plugin?

from scribe.