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

Fix: Frontend Category Label + Make Category and Archive Labels Visible #11219

Conversation

Luciaisacomputer
Copy link
Contributor

@Luciaisacomputer Luciaisacomputer commented Oct 29, 2018

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

screen shot 2018-10-29 at 3 34 41 pm

Frontend Category and Archives Dropdowns

screen shot 2018-10-29 at 3 34 34 pm

Additional Screenshots from Code Review Comments + testing in multiple themes

Twenty Fifteen
labels-twenty-fifteen

Twenty Sixteen
labels-twenty-sixteen

Twenty Seventeen
labels-twenty-seventeen

Givingpress
labels-givingpress

Nifty Lite
labels-nifty-lite

Specia
labels-specia

Hestia
labels-hestia

ModuAgency
labels-modu-agency

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@Luciaisacomputer
Copy link
Contributor Author

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.

@oandregal
Copy link
Member

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' );

Copy link
Member

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

Copy link
Contributor Author

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>
Copy link
Member

@oandregal oandregal Nov 15, 2018

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.

Copy link
Contributor Author

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.

@mtias mtias added this to the 4.5 milestone Nov 15, 2018
@mtias mtias added [Block] Archives Affects the Archives Block [Block] Categories Affects the Categories Block labels Nov 15, 2018
@karmatosed
Copy link
Member

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.

@Luciaisacomputer
Copy link
Contributor Author

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!

@gziolo gziolo requested a review from tofumatt November 19, 2018 09:07
@karmatosed
Copy link
Member

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.

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.

@afercia afercia removed the Needs Accessibility Feedback Need input from accessibility label Nov 19, 2018
@afercia
Copy link
Contributor

afercia commented Nov 19, 2018

Removing the "Needs Accessibility Feedback" label as a11y feedback is clear: visible label are always preferable.

@samikeijonen
Copy link
Contributor

samikeijonen commented Nov 19, 2018

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 margin-bottom: 1.5em; to .wp-block-categories-dropdown and wp-block-archives-dropdown.

@Luciaisacomputer
Copy link
Contributor Author

@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.

@samikeijonen
Copy link
Contributor

@LukePettway Well, actually I'm now seeing ERROR in ./packages/i18n/build-module/index.js. And can't test at all this branch :) I'm not sure would rebasing from master would help here.

Luke Pettway added 5 commits November 19, 2018 14:53
@mtias mtias modified the milestones: 4.5, 4.6 Nov 19, 2018
@tofumatt tofumatt requested a review from jasmussen November 20, 2018 18:00
Copy link
Member

@tofumatt tofumatt left a 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 {
Copy link
Member

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 😄

Copy link
Contributor Author

@Luciaisacomputer Luciaisacomputer Nov 20, 2018

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;
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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:

screenshot 2018-11-20 at 19 54 24

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasmussen thanks

Copy link
Contributor

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 {
Copy link
Member

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";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be alphabetised 😄

Copy link
Contributor Author

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 :)

Copy link
Contributor Author

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.

@aduth
Copy link
Member

aduth commented Jan 4, 2019

There are failing PHPCS style violations here:

FILE: /app/packages/block-library/src/categories/index.php
----------------------------------------------------------------------
FOUND 1 ERROR AND 1 WARNING AFFECTING 2 LINES
----------------------------------------------------------------------
 35 | ERROR   | [x] Spaces must be used for mid-line alignment; tabs
    |         |     are not allowed
    |         |     (WordPress.WhiteSpace.DisallowInlineTabs.NonIndentTabsUsed)
 36 | WARNING | [x] Equals sign not aligned with surrounding
    |         |     assignments; expected 13 spaces but found 1
    |         |     space
    |         |     (Generic.Formatting.MultipleStatementAlignment.NotSameWarning)
----------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

Copy link
Member

@aduth aduth left a 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;
Copy link
Member

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__/

Copy link
Member

@aduth aduth left a 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.

@youknowriad
Copy link
Contributor

At the moment, this PR don't require a trac ticket as Core syncs those files automatically from the packages.

@aduth
Copy link
Member

aduth commented Jan 21, 2019

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.

@youknowriad
Copy link
Contributor

youknowriad commented Jan 21, 2019

@aduth I think the files are just copied using a grunt task.

@aduth aduth dismissed tofumatt’s stale review January 21, 2019 15:40

Sign-off for flagged design feedback: #11219 (comment)

Copy link
Member

@aduth aduth left a 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;
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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 {
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

@Luciaisacomputer Luciaisacomputer Jan 21, 2019

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 youknowriad removed this from the 5.3 (Gutenberg) milestone Mar 18, 2019
@Luciaisacomputer
Copy link
Contributor Author

@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.

@youknowriad
Copy link
Contributor

youknowriad commented Sep 14, 2019

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?

@youknowriad
Copy link
Contributor

Looks like this PR is still needed. Do you all have some time to refresh it and rebase it and try to land it?
Are these comments the last blockers? #11219 (review)

@paaljoachim
Copy link
Contributor

Hello everyone.
Can we get a status update to where this PR is at?
Thanks.

@mcsf
Copy link
Contributor

mcsf commented Feb 18, 2021

Per the latest comments from early 2020, closing this as stale. Feel free to reopen with iterations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Archives Affects the Archives Block [Block] Categories Affects the Categories Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet