-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 Additional CSS Classes setting to Link UI #67560
base: trunk
Are you sure you want to change the base?
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @BiDbMAK, @sarahmonster, @prasadgupte, @smerriman, @kticka, @leadclown, @ScotsScripts, @ekazda, @svedish, @frogdesk, @michaelsoriano, @Chillifish, @DougMelvin, @burnuser, @logiclink. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: +398 B (+0.02%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
71312e3
to
11493c0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition, thanks for working on this.
In my testing, I noticed that the classes are correctly applied on the front end:
But when I go back to the editor to change them, the classes input is empty:
The correct classes are still applied to the link markup within the editor.
Also, I think it would be good to add the same help
text used on the paragraph CSS classes input: "Separate multiple classes with spaces." And, maybe even the same input title, "Additional CSS Class(es)" rather than "Additional CSS Classes".
@mikachan Thanks for taking a look at this one. Somehow I had a mistake in the functionality. It should now be fixed. TBH it's probably worth me adding a test for this so I'll do that as well. |
Good functionality, but it looks pretty rough. Any ideas how to clean this up @WordPress/gutenberg-design? |
It is pretty imbalanced, indeed, but it has to be in an inline UI. In places like these, the density of the UI really matters, so the "additional classes" input doesn't end up being weighted similarly to the URL itself. Outside of adding a key-value-pair-like plus button to add, a compact grid that is similar to such a key/value pair UI may be useful here? This would make use of labels on the left, and 32px compact inputs. I wonder if we have some precedence for this, or is this a new pattern that needs establishing? |
This is exactly how I felt about it. Looks imbalanced but didn't want to come up with my own new pattern without getting some wider input from Design folks. I'll await some concrete guidance in order that we can land this. |
I'm not really feeling this quite yet: But in case someone would like to take a stab, the Figma is here. The idea is that the plus button can open a menu that lets you choose among the many different properties you can add: rel, nofollow, CSS classes, |
I think we should be a bit careful about adding too much friction here given the 'Advanced' options are already hidden by default. @jasmussen This pattern reminds me a bit of ToolsPanel. I reckon it could work, but do you think the collapsible 'Advanced' panel is necessary as well? If we wanted to avoid disrupting the existing UX too much, but also hide the input until needed maybe we could add another checkbox: When checked the input appears with focus: |
I would lean towards @jameskoster's implementation for the reasons of friction he's stated. @jameskoster my only query would be whether you want the input to be "full width" rather than "contained" within the boundaries denoted by the Advanced Settings area? Currently it bleeds outside of that box. |
c95443c
to
78d2e70
Compare
Screen.Capture.on.2024-12-17.at.13-41-36.mp4I've updated the PR to reflect #67560 (comment). Let me know what you think. |
<InputControl | ||
label={ setting.title } | ||
value={ value?.cssClasses } | ||
onChange={ handleSettingChange } | ||
help={ __( 'Separate multiple classes with spaces.' ) } | ||
__unstableInputWidth="100%" | ||
__next40pxDefaultSize | ||
/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we could do with some validation and sanitization at this point. There might be some prior art for this.
Flaky tests detected in ba65cee. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12374270509
|
The reason why the "Search or type URL" input is slightly off is because of this 1px padding:
This padding was added a long time ago so it might be possible to remove it now, so maybe we can address it in a follow-up. Regarding the left position of the Advanced button, there was some discussion in this comment as to whether it should be based on the chevron icon or the focus outline. |
What?
Adds and
Additional CSS Classes
to the Link UI for inline links.Closes #13368
Why?
Much requested feature. Brings parity with Classic Editor.
How?
Add requisite logic to allow for rendering custom settings.
Apply to inline links.
Testing Instructions
Additional CSS Classes
fieldSave
Additional CSS Classes
fieldclass
attribute is correct added to the link.class
attribute corresponding to that which you addedTesting Instructions for Keyboard
Screenshots or screencast