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

Replace <!-- wp: with <! -- block: #4636

Closed
rheinardkorf opened this issue Jan 22, 2018 · 5 comments
Closed

Replace <!-- wp: with <! -- block: #4636

rheinardkorf opened this issue Jan 22, 2018 · 5 comments
Labels
Framework Issues related to broader framework topics, especially as it relates to javascript

Comments

@rheinardkorf
Copy link

Issue Overview

I understand that the comment tags are used as a "serialized" representation of a block so that it may be deserialized and used in the Gutenberg editor. However, I believe that blocks can be so much more, not just in a WordPress and editor context. So I am suggesting that <!-- block: may be a more forward looking alternative to <!-- wp:.

Dreaming Big

If block meta were able to be exposed in the DOM there could be interesting projects built on top of existing content. Think schema.org, but schemas representing standardised blocks. If this is hidden behind <!-- wp: it may be a missed opportunity to the impact that Gutenberg might have beyond WordPress. (I understand that this is just a WP implementation of the block tree and that other middleware could represent it in its own way, but there are some improvements required before this is a reality, future tickets... changing the prefix seems like a reasonably quick win)

@danielbachhuber
Copy link
Member

Thanks for the suggestion, @rheinardkorf.

If block meta were able to be exposed in the DOM there could be interesting projects built on top of existing content.

I think this is unlikely, given block meta is expected to be computed before it's publicly accessible.

Think schema.org, but schemas representing standardised blocks.

Interesting thought. Given schema.org is already a standard, it probably makes sense to adopt schema.org instead of inventing our own standard.

changing the prefix seems like a reasonably quick win

Is it non-trivial though? What about all existing stored block data?

@danielbachhuber danielbachhuber added the [Status] Needs More Info Follow-up required in order to be actionable. label Jan 23, 2018
@rheinardkorf
Copy link
Author

Is it non-trivial though? What about all existing stored block data?
Didn't say non-trivial... but quick win.

Like I said before, I understand that the WP implementation is just one way to store and retrieve the block tree. Other middleware could do its own implementation, but that is non-trivial. Perhaps that is an area to focus on more so than changing the WP implementation.

My main concern is that Gutenberg should not be too nearsighted to only serve WP. I think it has so much more potential.

Interesting thought. Given schema.org is already a standard, it probably makes sense to adopt schema.org instead of inventing our own standard.

I guess schema.org adoption could be left open to block developers in the output, but the quicker this happens the more potential there is for content reuse or other interesting uses we haven't even thought of yet.

Perhaps I should instead create a ticket regarding abstracting the reducers and middleware. Perhaps by configuration rather than hardcoded.

@danielbachhuber
Copy link
Member

My main concern is that Gutenberg should not be too nearsighted to only serve WP. I think it has so much more potential.

I agree.

However, changing <!-- wp: with <! -- block: seems more about semantics at this point, than yielding any true benefits. Furthermore, the prefix isn't a blocker for some other service to consume the data.

@mtias
Copy link
Member

mtias commented Feb 7, 2018

My main concern is that Gutenberg should not be too nearsighted to only serve WP. I think it has so much more potential.

Thanks for your thoughts @rheinardkorf! I agree this would be exciting to explore, and I also think it could be useful for the web beyond WordPress. It shouldn't be hard to introduce the notion of a project namespace project:block when initializing the parsing. Maybe some truly general purpose blocks could arise. Maybe they could mature and become entangled with web-components. That said, I'm cautious of over abstracting too early before needs are evident.

Please, do open issue if you have ideas or want to explore abstracting some utilities, even if it cannot be adopted as is for WP. There is https://github.com/WordPress/packages where some more general purpose modules had started to be generated. The parsing library could potentially live there if it appeals to a wider audience and people are willing to contribute.

@dmsnell
Copy link
Member

dmsnell commented Feb 7, 2018

It's my hope too that Gutenberg can grow to live outside it's WordPress home.

If this is hidden behind <!-- wp: it may be a missed opportunity to the impact that Gutenberg might have beyond WordPress

This seems like a pretty big overestimation of the impact of <!-- wp:. A change to the entire system should actually be quite trivial in my estimation. Also, I doubt that wp would prevent a good system from being used outside of WordPress. We could deny its heritage and say it stands for well-planned or web-part

changing <!-- wp: with <! -- block: seems more about semantics at this point

Technically I don't think it's about semantics. That is, whether wp or block the semantics are the same. It's the syntax we're discussing - a very superficial and ancillary detail of the implementation.

the WP implementation is just one way to store and retrieve the block tree. Other middleware could do its own implementation, but that is non-trivial.

Again I'm not sure this would be as hard as it may seem at first glance. The parser interface is pretty small and we could easily load from JSON or from a database row instead of printing the HTML. Similarly, the serialize() function has a small surface area and could produce whatever we want.

At some point (it's been on my TODO list for eight months or so) we'll have a way for a plugin to replace the load/store functionality and free up developers to choose their own backend.

@mtias mtias closed this as completed Mar 6, 2018
@mtias mtias added Framework Issues related to broader framework topics, especially as it relates to javascript and removed [Status] Needs More Info Follow-up required in order to be actionable. labels Mar 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues related to broader framework topics, especially as it relates to javascript
Projects
None yet
Development

No branches or pull requests

4 participants