Text: handle legacy structures

[mtias]

Input could be any of:

// Just text
Some text

// With p tags
<p>Some text</p>

// With comment tags
<!-- wp:core/text --><p>Some text</p><!-- /wp:core/text -->

Output is only one.

[nylen]

This implies that loading a post and saving it will rewrite content into our "expected" form. I think we should avoid this rewriting as much as possible.

[mtias]

Not necessarily, I think we need the mechanism in the API, whether it's enabled by default and in which contexts, is a separate discussion altogether.

[ellatrix]

At some point, I think it was discussed that we shouldn't use delimiters for text blocks. It sounds like that would automatically make it compatible with old paragraphs?

[ellatrix]

So it sounds like the in and output should be

<p style="text-align:center;" class="...">Some text</p>

where the attributes are part of the HTML? As soon as it's so other format, we let it be freeform? Or do we want to use the delimiters when there are attributes, and leave them out if there is nothing?

I also sounds like we want to upgrade just text without any HTML tags.

[dmsnell]

the in and output should be

I see the in. :smile:

would you propose that the output be like this?

{
    name: 'core/text',
    content: [
        <p style="text-align:center;" class="...">Some text</p>
    ]
}

[ellatrix]

Yeah that's the question. I'm not sure if we should add the delimiters if there are attributes, or put them on the p. But if there is nothing, it's just the HTML without delimiters. Cc @matias

On 7 Jun 2017, at 17:54, Dennis Snell notifications@github.com wrote:

the in and output should be

I see the in. 😄

would you propose that the output be like this?

{ name: 'core/text', content: [

Some text

] } — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[dmsnell]

I spoke with @mtias about possibly adding a new core/soup block type which is nothing more than "non-bock content outside of proper block boundaries" by the way. this could be related here.

[BE-Webdesign]

nothing more than "non-bock content outside of proper block boundaries" by the way. this could be related here.

My interpretation of the free form block, or whatever it ends up being named, is that it is solving that niche. What does the free form block do differently than a soup block?

[dmsnell]

What does the free form block do differently than a soup block?

It indicates that we had out-of-block content. Whereas the freeform block lives within block boundaries and can carry the additional assertions as a result, soup is just there and we're not entirely sure why. We can try to make assumptions but we have no ground on which to stand them.

[BE-Webdesign]

I think reading through the context of this issue, I understand maybe a bit better. I would second nylen's comment, and add onto that a bit. I don't think it is necessary to translate "legacy" content into block content. The coolness factor is very high and I like the concept, but I am not sold on what practical benefit that brings to the table. I see Gutenberg as more of a progressive enhancement on top of the current editor experience. What benefit does translating the arbitrary HTML to blocks bring? It is also kind of prescribing somehow that we know the intent of the content. People use <p> tags for all sorts of stuff that is not text.

[ellatrix]

Older PR: #413 "Propose block APIs for backwards compatibility"

[ellatrix]

@mtias Is this still relevant now? :)