Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TinyMCE per block prototype: Add image with caption block #155

Merged
merged 1 commit into from
Mar 1, 2017

Conversation

youknowriad
Copy link
Contributor

No description provided.

@youknowriad youknowriad added the [Type] Enhancement A suggestion for improvement. label Mar 1, 2017
@youknowriad youknowriad self-assigned this Mar 1, 2017
@youknowriad youknowriad force-pushed the add/image-caption-block branch from 85bee96 to 1e0fb5d Compare March 1, 2017 12:48
@aduth
Copy link
Member

aduth commented Mar 1, 2017

Do you think this ought to be a separate block or an option to the existing base image blocks?

Related is how we'll need to support existing content which may include [caption] shortcodes that should be treated as equivalent blocks, however we decide to implement them.

@youknowriad
Copy link
Contributor Author

youknowriad commented Mar 1, 2017

Do you think this ought to be a separate block or an option to the existing base image blocks?

I don't have a final answer for now. I decided to go separate for now to show an image without any caption text field which changes the way the keyboard (arrows, enter, backspace) behaves. I can answer with another question.

How do we "enable" a caption for a simple image block? In case of a separate block, we could use the "transform" API (same as switching between paragraph and heading for example). but what if it's the same component, should we always show the caption input?

[caption] shortcodes that should be treated as equivalent blocks

My personal answer to that, is to limit the way the editor stores the post content to one unique way. So maybe the answer to this question is having the grammar parse those different ways of writing the same block into the same structure, but serializing this data would use one way only.

@youknowriad youknowriad merged commit 84507cb into master Mar 1, 2017
@youknowriad youknowriad deleted the add/image-caption-block branch March 1, 2017 14:17
@aduth
Copy link
Member

aduth commented Mar 1, 2017

but what if it's the same component, should we always show the caption input?

Per the current mockup, I think this is what to expect, yes (cc @jasmussen).

My personal answer to that, is to limit the way the editor stores the post content to one unique way.

We'll definitely need to think on this. I agree ideally if we settle on a block syntax, that should be the recommendation for all new posts. If that were the case, we'd certainly need to be able to detect and upgrade the previous syntax to the new variation, if only in the context of the editor itself. The most contentious question might be: If we detect old syntax, should we save it as new syntax if the user updates the post? What impact does this have on plugins that, for example, hook into and modify a [caption] shortcode?

@jasmussen
Copy link
Contributor

Thanks for the ping @aduth.

How do we "enable" a caption for a simple image block? In case of a separate block, we could use the "transform" API (same as switching between paragraph and heading for example). but what if it's the same component, should we always show the caption input?

We will likely want captions for lots of blocks. I can easily imagine inserting video with a caption, or even a code block with a caption. Which blocks might need a dedicated caption vs. just a single linebreak with a simple text, that's up for discussion. Maybe best discussed in #16.

UI-wise, we could show the caption input field only when the block is selected? I.e. Insert an image and move on, no caption field is shown. Click the image later on, and the caption field "pops out" below.

CC: @mtias

nylen pushed a commit that referenced this pull request Mar 16, 2017
hypest added a commit that referenced this pull request Nov 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants