-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Fix: Frontend Category Label + Make Category and Archive Labels Visible #11219
Fix: Frontend Category Label + Make Category and Archive Labels Visible #11219
Conversation
If needed, I can cherry pick the front-end label only, and revert the changes in this PR so that we can at least get the labels on the front-end until a full decision is made. |
For context, see also #10871 |
@@ -31,7 +31,8 @@ function render_block_core_categories( $attributes ) { | |||
$wrapper_markup = '<div class="%1$s">%2$s</div>'; | |||
$items_markup = wp_dropdown_categories( $args ); | |||
$type = 'dropdown'; | |||
|
|||
$title = __( 'Categories', 'gutenberg' ); | |||
|
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.
It looks like there is a whitespace here that is making the PHP linter unhappy? See https://travis-ci.org/WordPress/gutenberg/jobs/447997322
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.
Thanks, I can make this fix real quick!
@@ -68,7 +68,7 @@ function render_block_core_archives( $attributes ) { | |||
|
|||
$label = esc_attr( $label ); | |||
|
|||
$block_content = '<label class="screen-reader-text" for="' . $dropdown_id . '">' . $title . '</label> |
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.
Is this necessary? Per #10871 (comment) it looks like we may want to keep this class.
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.
So I think I got a little eager with this PR, but essentially I felt it was necessary to make the labels visible because it will provide better context to all users. If we can get some design feedback, I can easily revert the removal of these classes. There was some discussion about this in the original issue for this. Maybe @afercia can also speak to why others felt it made sense to make the label visible.
My concern with this is testing in themes. Have you tested in a range of themes? In the past we've had to scale back what we output and I want to ensure it works across. |
Thanks for your input @karmatosed. I hadn't considered that. Is there a specific way I can test that? Would it look like me simply switching between multiple WordPress themes both vanilla as well as community related? Adding the class in is not much of a big deal, I guess it really comes down to what makes the most sense. Personally I think at this point it probably makes sense to add the class back in, and merge the PR with just the front end label. I could then open another ticket to further discuss the design impact visible labels could have. Thanks again! |
I feel this is best right now. After 5.0 we can do greater testing in a range of themes. I would suggest starting with the default ones. I am very cautious adding styling into this right now. |
Removing the "Needs Accessibility Feedback" label as a11y feedback is clear: visible label are always preferable. |
I's also keep visible labels. I tested with default themes and couple of random themes. There are margin bottom issues in all themes which I'd solve in this same PR. That would be |
@samikeijonen Thanks, I take it this means you figured out whatever was preventing my changes from appearing? I can make those changes to the styles for each of those elements. |
@LukePettway Well, actually I'm now seeing |
…abels, added category label for frontend
…r archives block and update the margin for it as well
…etter in older themes or when the controls are inline
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.
The styles on the frontend here aren't so great; I expect themes to override them but we should provide nicer defaults I think.
Are the screenshots in the first post here up-to-date? I see a margin-bottom: 1.5em
in the styles but the screenshot on the frontend looks like there is no margin and it's really jammed together.
Flagging @jasmussen to have a look and provide some design thoughts.
@@ -1,3 +1,7 @@ | |||
.block-editor ul.wp-block-archives { | |||
padding-left: 2.5em; | |||
} | |||
|
|||
.block-editor .wp-block-archives label { |
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 would rather the label
tag get a specific CSS class and use that selector rather than a tag selector; it's convention in the code and makes overlapping/unintended targeting of selectors less likely 😄
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.
Good point, would .wp-block-archives-label
be a suitable classname for this? One thing I noticed was that the classes in the archive block aren't really following BEM unlike the ones for the category block.
@@ -0,0 +1,3 @@ | |||
.wp-block-archives-dropdown { | |||
margin-bottom: 1.5em; |
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.
Not sure where this value is coming from, cc'ing @jasmussen to check on the visuals of this.
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.
@samikeijonen provided the value to me as a suggestion.
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.
It would be good to have a variable for this. But given this is front-end stuff, and we mean to provide some basics, and in this case I think it's okay to use the em unit, as many of the basic elements are born with browser vanilla ems.
In this case, though, I'd take a cue from the figure
element, though, and make it 1em:
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.
@jasmussen thanks
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.
In some of the existing block margin bottom in the front-end is 1.5em
, that's why I suggested that for consistency.
@@ -5,3 +5,7 @@ | |||
margin-top: 6px; | |||
} | |||
} | |||
|
|||
.block-editor .wp-block-categories label { |
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.
Same here re: preferring a class selector over a tag.
@@ -3,6 +3,7 @@ | |||
@import "./block/indicator/style.scss"; | |||
@import "./button/style.scss"; | |||
@import "./categories/style.scss"; | |||
@import "./archives/style.scss"; |
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 should be alphabetised 😄
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.
Whoops! I'll fix this :)
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.
Also in response to your question about the screenshots, I guess the confusion is from me not updating the first two screen shots. The ones that follow are up to date, I left those in there just in case someone wanted to see what it looked like originally.
There are failing PHPCS style violations here:
|
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.
An issue we now have with this is that, as it stands, revisions to block PHP in Gutenberg don't take precedence over WordPress 5.0 implementations. I don't think that needs to be resolved as part of this pull request, but it must be resolved for the changes here to have any impact to those using the plugin.
@@ -31,6 +31,9 @@ function render_block_core_categories( $attributes ) { | |||
$wrapper_markup = '<div class="%1$s">%2$s</div>'; | |||
$items_markup = wp_dropdown_categories( $args ); | |||
$type = 'dropdown'; | |||
$title = __( 'Categories' ); | |||
$label_class = 'wp-block-categories-label'; | |||
$items_markup = '<label class="' . $label_class . '" for="' . $id . '">' . $title . '</label> ' . $items_markup; |
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 believe $title
ought to be escaped here, perhaps via esc_html__
https://developer.wordpress.org/reference/functions/esc_html__/
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.
As far as the code here, this all looks good 👍
This needs some process consideration since, as noted previously, this code doesn't currently do anything.
I'm fine to move forward with merging this and working separately to change the way by which we extend core blocks (#11015). We'll still need to bring these changes upstream to core, though. I think a Trac ticket may be necessary, including an equivalent patch to as done here. The fact that it's been reviewed here already should hopefully expedite a review for commit.
At the moment, this PR don't require a trac ticket as Core syncs those files automatically from the packages. |
How does this happen? I suppose it has an impact on how #11015 is approached then too, rather than extending the core blocks, needing to substitute their implementations entirely. |
@aduth I think the files are just copied using a grunt task. |
Sign-off for flagged design feedback: #11219 (comment)
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.
Final testing revealed a few more issues.
@@ -1,3 +1,7 @@ | |||
.block-editor ul.wp-block-archives { | |||
padding-left: 2.5em; | |||
} | |||
|
|||
.block-editor .wp-block-archives__label { | |||
display: block; |
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.
Should this not also be display: block;
on the front-end?
This note applies to the categories block as well.
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.
At the time I think I wanted these to be as least opinionated as possible in themes but I can make these changes to render the controls in the same manner on the front end.
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.
So why is it part of the editor styles in the first place?
@@ -0,0 +1,3 @@ | |||
.wp-block-archives-dropdown { |
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 class is never actually assigned to the select
on the front-end, so it's not applied.
This note applies to the categories block as well.
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.
Hmm I thought these were being added with the below code:
$class = "wp-block-categories wp-block-categories-{$type}";
I'll take a look and see what I find out
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.
It looks like it is being applied but it has a low specificity compared to a bunch of other selectors.
@youknowriad do you remember what the issue was with this PR? I think I remember something outside of GH coming up and that's why we never merged it. If this is still a fix we want I can do the necessary work to bring it across the finish line. |
To be honest, I don't remember that much. I know one of the issues was inconsistency between similar blocks. Other than that, I don't remember. Maybe we can try to refresh the PR and get it reviewed once again? Do you think it's ready? |
Looks like this PR is still needed. Do you all have some time to refresh it and rebase it and try to land it? |
Hello everyone. |
Per the latest comments from early 2020, closing this as stale. Feel free to reopen with iterations. |
Description
Fixes #11003
Fixes #11002
In #11003 it was mentioned that the Category Dropdown Label should be visible in the Gutenberg Editor as well as the frontend. For #11002 the same was noted for Archives Dropdown for both Gutenberg as well as the frontend.
I've update the two components to render without the
screen-reader-text
class, while adding a label to the HTML output for the Category dropdown that is rendered on the frontend.As it currently stands, the spacing of the inputs when used together on the frontend leaves much to be desired. I'm assuming this is controlled by the theme so opted not to write an CSS for that particular problem.
How has this been tested?
I checked the text for each label before and after the changes, made sure my CSS selectors wouldn't cause any visual regressions, ran the linting scripts, and used VoiceOver + Safari to make sure screen readers still interacted correctly.
Screenshots
Gutenberg Editor Category and Archives Dropdowns
Frontend Category and Archives Dropdowns
Additional Screenshots from Code Review Comments + testing in multiple themes
Twenty Fifteen
Twenty Sixteen
Twenty Seventeen
Givingpress
Nifty Lite
Specia
Hestia
ModuAgency
Types of changes
Checklist: