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

Add a "Block Title" attribute for List view and for contexts that need block title #33709

Closed
draganescu opened this issue Jul 27, 2021 · 12 comments
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Technical Feedback Needs testing from a developer perspective. [Package] Edit Widgets /packages/edit-widgets [Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@draganescu
Copy link
Contributor

Part of the new widgets editor refinement (see #33242) is to add better support for implementing a traditional Title + Widget layout (Context).

At the same time the List view in block editors (see #33583) seems to be less useful with the generic block names used, and a Block Title may be useful like a sort of human identifier in document's the nested tree view.

What if we combine these two in an universal new attribute for all blocks, say Block Title?

I have explored this idea in the block widgets editor and it is very easy to render an attribute as title, although it would imply an extra parsing of blocks - and maybe even this would be easy to avoid.

Otherwise it seems that for widgets this is a better solution than coming up with a special block or improving on the group block for this particular scenario. I am unsure that even patterns can solve this. My experience is that block Headings are not styled the same as themes style widget titles, and it's very hard to get the same effect. With a Block Title attribute rendered exactly as widget title this would be solved.

For the List view having this universal attribute would open up the possiblity of editing it in the List view, or, if that is not a good and accessible interaction, at least edit it in the inspector and seeing it in the List view for more clarity of a document's structure.

What do you think? Should all blocks have an optional attribute Block Title with an implementation similar to HTML anchor?

@draganescu draganescu added Needs Technical Feedback Needs testing from a developer perspective. [Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Package] Edit Widgets /packages/edit-widgets [Type] Discussion For issues that are high-level and not yet ready to implement. labels Jul 27, 2021
@adamziel
Copy link
Contributor

Just surfacing this relevant comment: #33583 (comment)

@adamziel
Copy link
Contributor

adamziel commented Jul 27, 2021

Some rough thoughts

  • What if I want a single title for a few widgets?
  • What if I don't want a title?
  • What if I want a different font/color/size in my title or a part of it?

@draganescu
Copy link
Contributor Author

In the case of the widget editor we'd emulate with this attribute what the default title of widgets did, so you'd have one title per block. If you don't fill nothing in, no title. The appearance of the rendered title are only controled by themes in the classic context because WP_Widget_Block is the only thing that will even render this. For all the other contexts this attibute would be used internally by the editor (e.g. to improve the List view).

@getdave
Copy link
Contributor

getdave commented Aug 3, 2021

Thanks for raising this 👍

Having tried to catch up with the background here it appears to me that we have two options:

  1. A Block Title attribute which renders a widget heading with the appropriate widget-specific classes applied (with the additional benefit of improving block identification within the List View).
  2. A Block Pattern of heading block + widget block wrapped in a Group block with the appropriate widget-specific classes applied.

Neither of these sounds enormously technically complex. As a result, it would be great if we could evaluate implementations of both approaches. We can treat these as prototypes so no need for perfect code.

This may allow us to better uncover the pros/cons of both approaches.

@Mamaduka
Copy link
Member

Mamaduka commented Aug 3, 2021

I like the first option since we can reuse the "Block Title" attribute for #33583 as well.

@talldan
Copy link
Contributor

talldan commented Aug 3, 2021

I'm not a huge fan of the idea of the universal attribute, because in my opinion it'll become a some technical debt that will end up existing forever. Blocks in the widget editor will forever have this wrapper concept that makes them different to blocks everywhere else.

My preference would be to let the blocks themselves stay as pure as possible, but maybe offer the user some shortcuts to creating a more backwards compatible widget-y block structure.

I think the pattern idea would be an absolutely fine way to solve this, and some UI improvements to make creating that kind of pattern easier would couple nicely with it.

I also wouldn't be against some kind of middle-ground where users can still use legacy widgets if they enable a setting or something. That's another way to solve this problem that hasn't been discussed. Legacy widgets are a legacy concept that already has to be supported indefinitely, so I'd be in favour continuing that support rather than introducing a new kind of complexity.

@getdave
Copy link
Contributor

getdave commented Aug 3, 2021

My experience is that block Headings are not styled the same as themes style widget titles, and it's very hard to get the same effect.

@talldan The only question is how would block patterns or "shortcut" solutions work around the problem @draganescu highlights - namely that many Themes don't support the heading block well within widgets? Are you thinking the pattern you introduce would automatically add the requisite widget-heading classes to better mimic a legacy Widget?

@hellofromtonya
Copy link
Contributor

The context of "Title" is different between Widgets to the List view. I'm concerned of the impact to users when switching between these context. For existing users, a widget title has a specific purpose and meaning, which is not the same as proposed for List view.

How do we work around this?

The title attribute could be its reference within the software whereas the interface could have a user-friendly label that aligns well to its purpose and context.

@talldan
Copy link
Contributor

talldan commented Aug 4, 2021

The only question is how would block patterns or "shortcut" solutions work around the problem @draganescu highlights - namely that many Themes don't support the heading block well within widgets? Are you thinking the pattern you introduce would automatically add the requisite widget-heading classes to better mimic a legacy Widget?

Pretty much that. The pattern would be a group with a heading in it (and space for a widget). There could also be an option for wrapping an existing block with that pattern.

A separate block would be fine too.

@getdave
Copy link
Contributor

getdave commented Aug 4, 2021

Here's an alternative approach - using Block Patterns #33874

@azaozz
Copy link
Contributor

azaozz commented Aug 4, 2021

Blocks in the widget editor will forever have this wrapper concept that makes them different

Yes, best to avoid that if at all possible. Another reason "against" using block titles is that today's widgets areas/sidebars are tomorrow's template parts. Converting/importing of the block based widgets would be better if they are "pure" blocks.

Should all blocks have an optional attribute Block Title with an implementation similar to HTML anchor?

I too think that perhaps best to explore this for #33583. If titles have to be added for each block, can't imagine what the UI will look like. Seems it will clutter the already small writing space. Then explaining to the users that they may want to enter some text that's pretty much invisible/unused except if they look in the list view would be.... tough :)

@draganescu
Copy link
Contributor Author

I'm going to close this issue since for widgets we went the route of a new block and for the list view, the problem is more around editing that tree and accessibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Technical Feedback Needs testing from a developer perspective. [Package] Edit Widgets /packages/edit-widgets [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

No branches or pull requests

7 participants