Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Update control labels to the new uppercase styles #42789
Update control labels to the new uppercase styles #42789
Changes from all commits
167fac2
c6a4605
932974d
3cbaf52
03af77e
46f4d9e
486f9a3
32fd29f
c536e8e
68e560f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Side effect of the changing the TS types for VisualLabel! We might want to look into a solution if we encounter this more.
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.
This
legend
reset has been moved from being included only inStyledLabel
, to being shared between bothStyledLabel
andStyledVisualLabel
. This is becauseStyledVisualLabel
(a.k.a.BaseControl.VisualLabel
) is also likely to be usedas="legend"
.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 take it we are ok removing the
components-box-control__label
class here given theBoxControl
is still exported as experimental?I ask, as later in this PR, we keep the
components-form-token-field__label
class desite removing the styles for it.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.
Great catch! I am actually quite inclined to remove unused CSS classes even if they are in stable components, unless it's a class that we can imagine a lot of third-party consumers to be overriding in a crucial way (e.g.
components-popover__content
). (@ciampo Does that sound about right or should we be more conservative about it?)The reason I left
components-form-token-field__label
intact is more because it's being used as a selector in an old e2e test 🙃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.
Sorry for the late answer, I'm currently a bit behind on my review queue 😅
I believe we should address this situation in a more general way (and potentially even add a paragraph about the strategy we decide to adopt to the contributors' guidelines).
In general. I'd love to remove hardcoded classnames — in practice, it may cause breakage for consumers that rely on them.
Should we consider the removal of hardcoded classnames a breaking change?
For example, even in the case of the removal
component-box-control__label
, we're not 100% guaranteed that it won't cause breakage to some external consumers.In general, I believe we should at least aim at removing all instances of
component-*
classnames outside of the components' package. After that, depending on how conservative we want to be, we could:What do folks think?
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.
Absolutely, I don't think it's explicitly written anywhere.
Could it cause breakage? Yes. Should we consider it a Breaking Change? No.
I was a consumer of the wp-components package before coming to the maintainer side, and I was never under the impression that CSS classnames (or styling, or DOM structure, for that matter) were guaranteed not to change. I think most people realize that overriding internal styling is fragile, and that it's their responsibility to protect against breakage if they are going to do so. Unless these classnames are publicly documented, as in the examples you raised 😅
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.
Personally, I agree with the notion that while it might cause breakage, we shouldn't necessarily consider it a breaking change. That said, I think communication and documentation will be key to maintaining as much good will as possible.
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.
Agree with both of you. I opened #43083 to keep track of this task separately
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.
For reference, the project does have existing documentation about backwards compatibility around class names and DOM updates.
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.
Thank you @nerrad ! Seems to align with our thoughts above