Add Block: Title

[DevOnWheels]

Hey, this is just a question/ idea:
I tried to insert HTML in my posts title. It does work, but the HTML is actually written out in the edit field of the title. This looks awkward. Is there any possibility to interpret the HTML in post titles in the same way as in the rest of Gutenberg. Like some kind of a "post title block"?

Reason for the question is that I would like to have overlines in my h1 tag without using ACF for that purpose. If this tracker is not the place for ideas/ enhancements, just drop me a note and close the ticket :)

Best regards, Matt

[designsimply]

Great question! There's some related discussion in #8469 where it is mentioned in the comments that future plans include making the title area into a block which likely means you would be able to add HTML to it. I checked the New Block label and didn't see one made for that specifically though, so I'm updating the title here so we can use this request for tracking. Thanks for raising the issue!

[designsimply]

Related: #8824 (and noting a kicker block may not be needed if title becomes a block that can be reordered within a post)

[designsimply]

Noting another relevant quote about title (and other things) eventually becoming blocks:

Eventually, the title, the date, the author, etc, will all just be blocks you can place in whatever order around the content.

Source: #4482 (comment) (worth noting this one is in the "To Do in Phase 2" project)

[mapk]

I'd really like to see the title block come to fruition in Phase 2. I'll add it to the milestone. We'll need some design input on this though... for instance, where does the meta info that the title provided go?

[DevOnWheels]

I'd really like to see the title block come to fruition in Phase 2. I'll add it to the milestone. We'll need some design input on this though... for instance, where does the meta info that the title provided go?

@mapk what exactly do you mean by "meta info that the title provided"? Happy to help :)

[mapk]

what exactly do you mean by "meta info that the title provided"? Happy to help :)

The permalink is what I mean here. It comes from the Title.

Would the Title block still incorporate the permalink info as it does now? Would that move to the sidebar? Just some things to consider. If there is not Title Block, what happens?

[DevOnWheels]

Yes, the current place is the "correct" one, I would say. A few thoughts on the "title block" here:
The block should be available only once, so there cannot be confusion between different titles. Additionally I would like to have a field for a "working title" so that I can have a short title in my admin lists, but a long title with HTML etc. in the title block. For example "This is my super awesome frontpage! Check it out!" in the block, but only "Static Frontpage" in the page list. And for these reasons I would like to have the settings directly at the block.

[mapk]

The block should be available only once, so there cannot be confusion between different titles.

Definitely possible. But what if the user doesn't want a title block on their page? Then how do we define the URI?

[DevOnWheels]

Good question. This would be a reason to exclude the settings to the options bar of the document. On the other hand, I really get headache about the fact that an article wouldn't have a title, but that's a SEO problem and not related to this issue.

[swissspidy]

Definitely possible. But what if the user doesn't want a title block on their page? Then how do we define the URI?

WordPress uses the post ID for the URL by default if there's no title set. Unless the user manually overrides the permalink with their own liking.

[DevOnWheels]

WordPress uses the post ID for the URL by default if there's no title set. Unless the user manually overrides the permalink with their own liking.

Exactly, but if you don't have the title block in your document (and the permalink option would be tied to the block settings) you will not have the settings either.

[mapk]

A common problem I've experienced is the homepage. I want a homepage, and want the URL to reflect /home or /welcome in the URL, but I don't want to have a title that says that... and I definitely don't want a random number.

[DevOnWheels]

@mapk a solution then would be to put the settings of the title into the document tab of the document so that the user doesn't have to define a title for the document at all.

[mapk]

put the settings of the title into the document tab

I think this is the best solution right now and feel the document tab is a perfect fit for it, but I'd love to hear if others have any more suggestions. Also, @DevOnWheels, are you able to mock this up for us?

[DevOnWheels]

I would love to try, but never worked with this area of WordPress before ;)

[jasmussen]

One idea to consider. If the block can be deleted, then we need a different way to change the title of a post. Google Docs, Dropbox Paper, and many others, show the title in the editor bar, and auto-fill it based on the contents of the post. But with a deletable title block, this would still allow you to customize it. This might also afford us an interface for more intuitively customize the permalink slug.

CC: @paaljoachim, #4573 (comment)

[paaljoachim]

It seems the discussion is going something like this:

The existing title box:

Removing the title:

Now lets say that we removed the title block.
The title defaults to the top bar.

One clicks into the title box. Adds the title.

[jasmussen]

Something in that vein, but in a way that considers responsive 👍 👍

[dannycolin]

@sarahmonster In it, we provide the option to hide or display the block. A "hidden" title block shows up in the post content (so it can be selected and manipulated), but in greyed-out manner to indicate it's not visible in the front-end.

Just a quick question related to the headings hierarchy and web accessibility. When you said "hidden" does it mean the Title block is removed from the DOM and the page/post will have no <h1> declared ?

[afercia]

I'm going to explore this starting from the mobile experience, in the interests of keeping things constrained and focused on logical source order.

Thanks for this, greatly appreciated as it helps a lot accessibility as well ❤️Could be material for an entire talk 🙂

[sarahmonster]

Just a quick question related to the headings hierarchy and web accessibility. When you said "hidden" does it mean the Title block is removed from the DOM and the page/post will have no <h1> declared?

I'm a bit unsure on this detail right now—my instinct is that the h1 should definitely still appear in the DOM, since users probably wouldn't replace it with a suitable h1 for the page, but that could be problematic if they do use an h1 elsewhere as a title. Maybe this behaviour is less likely though, if you can show a "display title" (ex: Hello!) that's different from the "document title" (ex: Home).

This is a common technique people use on their front page—they don't want the title to appear as part of the page content. (See the Hello/Home example above.) I think people tend to do that using display: none but we can use a visually-hidden technique to move the text offscreen instead.

[CreativeDive]

In reference to my feature request, are there any considerations for the following?

What can we do, if we want to add a custom "Header", which appears above the "Entry Page Title" and the possibility to edit the "Header" like a block inside the block editor?

Which conditions must be fulfilled in the example for a header block?

Always the first position of the block.

--> The block should be positioned above the "Entry Page Title".

Restricting the multiple use of blocks.

--> The block should only be used once without the option to "duplicate" it or add it several times.

Restricting the moving of blocks.

--> The header block should not be movable.

What will the future bring?

Is there a plan about this point in the future?

It would make the editor even better.

This is only an example for a full page header, which is overlaid from the site logo and the site navigation.

At this time there is no possibility to add custom headers like this in a user friendly way inside the block editor.

[sarahmonster]

@CreativeDive It sounds like what you're looking for should be possible once the title is a block (since you could hide it or move it around on the page).

Logo and site navigation are things that are being worked on in the context of whole-site layouts, but since they're site elements, rather than page elements, you probably wouldn't want them included in a page block like this. Your theme could definitely adjust their positioning so they say on top of a header block though. This "sticky" option is something we've been investigating with respect to the navigation menu block (see #16830).

I wouldn't advocate for adding this much complexity to the core title block itself though, since it would be better provided for by either a custom-developed block via a plugin, or an existing block (the cover block comes to mind).

[joyously]

I see this issue has strayed far from the original report, which is about showing the title with the HTML interpreted instead of visible. But showing visible HTML makes it clear to the user that the title actually contains other characters which will affect the user's search and any sorting done by title. It is a big change that should not be taken lightly.
Themes and core already treat the title differently than other fields, since it can contain HTML that should be interpreted as HTML when output. The user needs to understand that the title is different.

[karmatosed]

There has been a little bit of time passed since this issue. I wanted to call attention to the work going on in full site editing that makes all content blocks. With this happening, I think the need for this to be done apart from that might not be the case.

However, it could be great to have some feedback on what examples of HTML are wanted in the title itself.

[paaljoachim]

I went ahead and made a new issue in relation to the Block: Title. To give it some more breathing room. #22621

[karmatosed]

@paaljoachim I am not sure if opening a second one when this is still open doesn't distract. Could you perhaps outline why and consider closing this one?

[joyously]

Yes, it seems odd to split the conversation.

[paaljoachim]

This issue contains a long history of various conversations such as should we move the title to the top bar area. (Full Site Editing has added the title to the top bar.) It is a lot easier to start fresh focusing directly on adding a block title, and keeping this as the history issue. Keeping the fresh issue open and closing this issue. It is also easier getting feedback on a short issue compared to one that is very long.

[paaljoachim]

I will go ahead and close this Block: Title issue containing a lot of history.
Lets keep the focus fresh in #22621
We can always relate back to specific comments here if/when needed.

[joyously]

@paaljoachim the other problem with creating another issue is that the people that commented on the old issue no longer get notified, so you actually reduce the exposure.

[paaljoachim]

People who subscribe to this issue will have also seen the various sent lately messages. I just want to make it easier to handle. A short issue is a lot easier to handle then a long. If important information shows up in the new issue I could always add it to this history issue as well.