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

Chrome: Adding the visibility selector #832

Merged
merged 4 commits into from
May 19, 2017
Merged

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented May 18, 2017

This is largely inspired from Calypso.

screen shot 2017-05-18 at 11 56 03

Open Questions

  • Should we create generic Form Components aka FormFieldset, FormLegend, FormRadio, FormInput?

@youknowriad youknowriad added the General Interface Parts of the UI which don't fall neatly under other labels. label May 18, 2017
@youknowriad youknowriad self-assigned this May 18, 2017
@youknowriad youknowriad requested review from jasmussen and aduth May 18, 2017 10:56
const updatePassword = ( event ) => onUpdateVisibility( status, event.target.value );

// Disable Reason: The input is inside the label, we shouldn't need the htmlFor
/* eslint-disable jsx-a11y/label-has-for */
Copy link
Member

Choose a reason for hiding this comment

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

Can we get rid of this rule?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

you mean completely disable it from the .eslintrc?

@jasmussen
Copy link
Contributor

I love it. Ship it.

I remember there being some concerns about the design of this, but can't recall the details. @folletto might remember? But either way that should not stop us from shipping this and iterating.

@youknowriad
Copy link
Contributor Author

I've added the information toggle, I'd appreciate a second look @jasmussen. Also, I wonder if we should use this "info" icon or design a new one (see calypso)

@jasmussen
Copy link
Contributor

Per slack chat, I think this is good to go. Let's keep the labels, no need to make them toggled.

/* eslint-disable jsx-a11y/label-has-for */
return (
<div className="editor-post-visibility">
<span>{ __( 'Visibility' ) }</span>
Copy link
Member

Choose a reason for hiding this comment

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

Is the <span> necessary? Both here and in the <label> below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's is not required here, but since the parent is "flex", I like the explicitness of having flex children. It's useless though for the label.

Copy link
Member

Choose a reason for hiding this comment

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

It's is not required here, but since the parent is "flex"

Hmm, now I'm curious what is the default flex behavior for handling text nodes. 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems to work properly though

Copy link
Member

Choose a reason for hiding this comment

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

Seems to handle them independently only when they're broken up by other elements (notably not by react-text comments):

Explicitness seems good in these cases 👍

return (
<div className="editor-post-visibility">
<span>{ __( 'Visibility' ) }</span>
<a className="editor-post-visibility__toggle" href="" onClick={ this.toggleDialog }>
Copy link
Member

Choose a reason for hiding this comment

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

If it's not navigational, it shouldn't be an anchor. Core has a .button-link class which gives an appearance close to but not exactly the same as a link which we could use as a base.

@youknowriad
Copy link
Contributor Author

Is this ready to go?

@jasmussen
Copy link
Contributor

👍 👍 from me. If you've addressed all the code comments, visually and interaction wise this is good.

@youknowriad youknowriad merged commit dbc228e into master May 19, 2017
@youknowriad youknowriad deleted the add/visibility-selector branch May 19, 2017 08:46
@folletto
Copy link
Contributor

I remember there being some concerns about the design of this, but can't recall the details. @folletto might remember?

It was mostly in terms of the clarity of the interactor: in the current solution the color, and even more the underline, should be a strong enough signifier. 👍

@jasmussen
Copy link
Contributor

Thanks Davide, appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants