Component: LinkControl tracking issue

[fabiankaegy]

The LinkControl Component was added via #17557 as an experimental component in September 2019.

This Tracking issue is here to keep track of the items that are needed to get the Component out of the experimental state.

See also the Link UI Overview Issue which tracks currently priorities.

High Priority

• LinkControl Refresh #50891
• Stabilize LinkControl Component #56384

Medium Priority

TBD

Low Priority

TBD

---

Issues to organize

Enhancements

• Add nofollow option for links #13542
• Link builder arguments - 'wp_link_query_args' filter is ignored #31496
• Link Control: Add more controls. #23011
• LinkControl - Add Users and Taxonomy Terms #22833
• Block Editor: URLInput: Remove "required" as a default prop of URLInput #22442
• Block Editor: LinkControl: Migrate suggestions rendering to URLInput #22439
• Block Editor: URLInput: Soft-deprecate label prop #22438
• Block Editor: LinkControl: Remove Popover-associated styling #22437
• Restore the full search visibility in embed links #21343
• Refactor URLInput to remove requirement for Promise in fetchSuggestions #19526
• Provide an option to display an icon for links that leave the domain of the website or open in a new tab or window  #21905
• Design improvements to the Link UI #26351
• Enable page & post creation via the "Add Link" interface #26317
• Remove link by deleting value of URL #25414
• Bulk editing in link popover doesn't work #24753
• Link editor: Show full URL in picker #31482
• Block Editor: LinkControl: Add label prop #22435
• Hide LinkControl rich preview placeholders if no content available #32547
• Link control rich preview - improve image placeholder #32548
• DRY up LinkControl normal and "Create" suggestions code  #20271
• Remove unnecessary suggestion types in LinkControl  #20051
• Block Editor: Improve UX for the URL link viewer #17972
• url-details endpoint doesn't look for og:description when searching for a description #33754
• Add subject to "mailto:" links #28850
• Standardize required clicks for adding a link #33146 Unrelated to LinkControl.

Bugs

• Manually added link attributes are stripped when editing URL or toggling Open in new tab #27345
• LinkControl: screen jumps when you click on the search result to select the  #28373
• Suggestion for internal links not working on Gutenberg paragraph block (Multisite) #34125
• Format Library: Link popup positioned incorrectly (Safari?) #20250
• Add "unlink" button to Block toolbar when link UI is open #33850
• Find better location for __experimentalFetchRichUrlData function #32725
• Hide LinkControl rich preview placeholders if no content available #32547
• Link UI does not preserve link relationships for Post (entity) links #32282
• Click on "Open in new tab" control causes hyperlink creation UI popover to close  #25946
• Opened Link popover component changes position when pressing Bold or Italic keyboard shortcut  #23799
• [ LinkControl ] Bug with position when closed #21835
• Link with one line looks out of line in interface on navigation #34779

Accessibility

[getdave]

Great work on this. We should add a dedicated Accessibility section so as to ensure these are given a high priority.

[jasmussen]

Fresh mockups here: #26351 (comment)

[fabiankaegy]

Question:

What's holding us from stabilizing this component?

It was introduced into the codebase in September 2019 #17557 and whilst it is currently undergoing another design revision that from my perspective has very little to nothing to do with the actual API of the component. Which has changed very little in all these years.

I feel strongly that this is a core component that is being used widely throughout the Gutenberg codebase and because it was introduced before the new private API system is also widely used outside of core.

I would love for us to recognize that fact and stabilize the LinkControl component sooner rather than later.

We can always tweak the underlying tech / the visuals of the component further as we are doing with other stable components.

CC: @getdave

[getdave]

@fabiankaegy Your arguments are sound.

Because the work to update the UX of the component is still ongoing from 6.2 -> 6.3 (and on into 6.4 where we hope to wrap up) it didn't seem like a great time to stablise the component.

I think @richtabor (who's been working with me on this) would agree that we should be able to wrap up the updates to the component in the 6.4 cycle and thus we could look to stablise for that release.

This depends on contributors and where we need to allocate time however, so it might be better thinking of it as "a near future release" as opposed to committing to an specific release.

[richtabor]

I think @richtabor (who's been working with me on this) would agree that we should be able to wrap up the updates to the component in the 6.4 cycle and thus we could look to stablise for that release.

Yes, it really should be ironed out and used throughout the experience for 6.4.

[fabiankaegy]

@getdave @richtabor coming back to this, do we now feel like we can finally stabilize this component?

Looking at the usage stats there are over 200 plugins in the official Repo already using the component, many of which have a really large user base.

Regardless of us continuing to evolve the actual UI of the component I think it is way past time for us to stabilize the API of the component.

[getdave]

Just tying up loose ends and making sure that the Design / UX refresh for this component is linked here.

[fabiankaegy]

@getdave like I said before, I do not think that stabilizing this component has much to do with us still iterating on the UX & design of the component.

The API itself has remained stable for over 3 years now and is getting used in hundreds of plugins in the repository.

Therefore I think it is time to stabilize the component now.

The work to improve the UI can be an ongoing effort like it is for other components we have.

[getdave]

@fabiankaegy my comment is purely for update purposes because I realised the Design refresh was not linked here anywhere. Your previous comments still stand. Let's look at landing your stablising PR in 6.5.

[otakupahp]

Another year has passed and this is still on the experimental phase. Any plan to move this fordward?

[getdave]

We should look to stabilise in 6.8 which basically means reviewing and landing #56384