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

Linking to blocks / Autogenerating IDs for blocks #17264

Open
Witoso opened this issue Oct 15, 2024 · 1 comment
Open

Linking to blocks / Autogenerating IDs for blocks #17264

Witoso opened this issue Oct 15, 2024 · 1 comment
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:bookmark package:engine package:link squad:core Issue to be handled by the Core team. type:feature This issue reports a feature request (an idea for a new functionality or a missing option).

Comments

@Witoso
Copy link
Member

Witoso commented Oct 15, 2024

📝 Provide a description of the new feature

Context

This feature idea came from the work on the Bookmarks (#1944). When we were working on it, we tried to understand how bookmarks should behave on block elements. Should they be added "inside" the block (think a inside figure element) or before? How user interaction should look? What integrators that create their own block widgets would need to think about?

In the end, we decided that bookmarks will be added before those elements. This saved us some amount of time, making the feature more consistent and simpler.

But having linkable blocks is an interesting idea, so we want to gather feedback.

A linkable block is basically an element that a user can link to:

  • heading,
  • table,
  • paragraph,
  • image,
  • and others...

For the simplicity's sake, let's only think for now about the scenario when a block is in the same document as the link to it.

Flow 1:

  1. Select a table.
  2. Copy its ID (link).
  3. Create a link to it.

Or

Flow 2:

  1. I open a link insertion interface.
  2. I select a specific table from the prefilled list.

The first flow sounds more reasonable, in the second one how would we determine the name of table, paragraph, image on the list? Filename, caption, preview of content? Tricky.

Of course, this could go further into linking blocks across editors. Notion style UI comes to mind with Copy link to block:

Scope

To fulfill linking to blocks, we would need to:

  • autogenerate ID for each block automatically if it's not present. Figure out duplication, copy/pasting id collision detection, etc.
  • provide user actions, such as as copy id/copy link, and give integrators options to work with them (the editor knows nothing about the links to full links assets).
  • extend the linking interface to allow linking to blocks in the same editor as well as in other documents.
  • another aspect would be showing the anchors to block in the editor. The most known pattern for headings is a # mark before the heading. A user clicks on it, navigates, the URL in the browser changes and it can be copied. But this is a pattern for the published content. To be refined in the future.

Materials


If you'd like to see this feature implemented, add a 👍 reaction to this post.

@Witoso Witoso added type:feature This issue reports a feature request (an idea for a new functionality or a missing option). package:core domain:ui/ux This issue reports a problem related to UI or UX. package:bookmark squad:core Issue to be handled by the Core team. package:link package:engine and removed package:core labels Oct 15, 2024
@Witoso Witoso changed the title Linking to blocks / Autogenerating IDs Linking to blocks / Autogenerating IDs for blocks Oct 15, 2024
@CobriMediaJulien
Copy link

That would be awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:bookmark package:engine package:link squad:core Issue to be handled by the Core team. type:feature This issue reports a feature request (an idea for a new functionality or a missing option).
Projects
None yet
Development

No branches or pull requests

2 participants