Tag: Context

Semantic menu context

Scott digs into the history of the <menu> element. He traced it as far back as HTML 2 (!) in a 1994 changelog. The vibe then, it seems, was to mark up a list. I would suspect the intention is much like <nav> is today, but I really don’t know.

Short story: HTML 4 deprecated it, HTML 5 revived it—this time as a “group of commands”—and then HTML 5.2 deprecated it again. Kind of a bummer since it has some clear use cases.

So, it’s been quite the roller coaster for ol’ <menu>! There never seems to be any easy wins for HTML evolution. As of now, it’s in “don’t bother” territory:

I really wrote this post as a sort of counter point to the often uttered phrase “use semantic HTML and you get accessibility for free!” That statement, on its surface, is largely true. And you should use semantic HTML wherever its use is appropriate. <menu>, unfortunately, doesn’t really give us all that much, even though it has clearly defined semantics. Its intended semantics and what we actually need in reality are better served by either just using the more robust <ul> element, or creating your own role=toolbarmenubar, etc.. Using this semantic element, for semantics sake, is just that.

To Shared LinkPermalink on CSS-Tricks

The post Semantic menu context appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, ,

Yet Another Mobile Context Menu With No Indication it Can Scroll

Remember Tyler Hall’s personal story of a UX moment where the popup sharing context menu on iOS had no visible indication that the content inside was scrollable? The thing his mom wanted to do seemed impossible iOS isn’t alone here — Terence Eden documents essentially the same problem on Android:

I tried sharing a website using Google Chrome for Android. I hit the share button, and a panel popped-up from the bottom of the screen.

Hmmm. It didn’t have the share destination that I wanted. It was early in the morning – when I’m not at my cognitive best – and I was stumped. There is nothing on this screen – other than the icons – to tell me how I can interact with it. There’s no scrollbar, no handle, no “more” icon, nothing.

I would think even just fairly subtle “scroll shadows” would go a long way in both cases, but some serious user testing should be in order here.

Android menu with no indication of scrolling potential.

iOS menu with no indication of scrolling potential.

The post Yet Another Mobile Context Menu With No Indication it Can Scroll appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

It’s always the stacking context.

In “What the heck, z-index??,” Josh Comeau makes the analogy of layer groups in design software like Photoshop or Figma to stacking contexts in CSS. If you’ve got an element in a layer group A in Photoshop that is below layer group B, there is nothing you can do to push a child of A on top of anything in B, aside from moving the whole layer group A above B, or getting rid of the groupings.

Nothing is going to put that moustache on top of the dog unless you get it out of that stacking context or move the whole stacking context.

Here’s a reduced case:

There is no z-index value that is going to get “Big Thing” on top of the tan <main> element there. But as Josh notes in the article, there are a variety of solutions, such as preventing a stacking context from triggering unnecessarily, or doing a little DOM shuffling to make things work. Like in the example above, “Big Thing” doesn’t need to be a child of the header — and if it wasn’t, the stacking context wouldn’t be as relevant.

If you’re a fan of your tools helping you diagnose this kind of thing, read to the bottom of Josh’s article for a few interesting ones.

Direct Link to ArticlePermalink

The post It’s always the stacking context. appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

Use CSS Variables instead of React Context

Turns out you can use several different libraries to pass color information around components. Or, you could use custom properties, built right into CSS, have no decline in your own developer experience, and deliver a faster experience to your users. Kent proves it here, with demos.

For the record, you could go a step further than Kent has here and not use CSS-in-JS at all, but still be updating CSS custom properties from button clicks in React and managing the state there and such. I’m telling ya, one of the main jobs of a UI component library like React is managing state, and CSS might as well know about that state so you can use it to do any styling you need to do.

Wait, not use CSS-in-JS? Kent:

I’ve never been so productive working with CSS than when I added a real programming language to it.

Extreme side eye, Kent.

We should be calling it CSS-in-React, also, since React is the only major framework that doesn’t have a blessed solution for styling.

Direct Link to ArticlePermalink

The post Use CSS Variables instead of React Context appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

Compound Components in React Using the Context API

Compound components in React allow you to create components with some form of connected state that’s managed amongst themselves. A good example is the Form component in Semantic UI React.

To see how we can implement compound components in a real-life React application, we’ll build a compound (multi-part) form for login and sign up. The state will be saved in the form component and we’ll put React’s Context AP to use to pass that state and the method from the Context Provider to the component that needs them. The component that needs them? It will become a subscriber to Context Consumers.

Here’s what we’re building:

See the Pen React Compound Component by Kingsley Silas Chijioke (@kinsomicrote) on CodePen.

Here’s a rough outline that shows how the following steps fit together:

Form is the provider with state, Form Panel is the consumer receiving state, Panel displays the panel based on the state, and Signup and Login render the form views in the Panel.

Before treading any further, you may want to brush up on the React Context API if you haven’t already. Neal Fennimore demonstrates the concept in this post and my primer on it is worth checking out as well.

Step 1: Creating context

First, let’s initialize a new context using the React Context API.

const FormContext = React.createContext({}); const FormProvider = FormContext.Provider; const FormConsumer = FormContext.Consumer;

The provider, FormProvider, will hold the application state, making it available to components that subscribe to FormConsumer.

Step 2: Implement provider

One panel contains the form to log in and the other contains the form to sign up. In the provider, we want to declare the state, which determines the active panel, i.e. the form currently in display. We’ll also create a method to switch from one panel to another when a heading is clicked.

class Form extends React.Component {   state = {     activePanel: "login"   };    render() {     return (       <React.Fragment>         <FormProvider           value={{             activePanel: this.state.activePanel,             actions: {               handlePanelSwitch: newPanel => {                 this.setState({                   activePanel: newPanel                 });               }             }           }}         >           {this.props.children}         </FormProvider>       </React.Fragment>     );   } }

By default, the login panel will be shown to the user. When the signup panel is clicked, we want to make it the active panel by setting the state of activePanel to signup using the method handlePanelSwitch().

Step 3: Implement Consumers

We’ll use FormConsumer to make context available to the components that subscribe to it. That means the FormPanel component that handles displaying panels will look like this:

const FormPanel = props => {   return (     <FormConsumer>       {({ activePanel }) =>         activePanel === props.isActive ? props.children : null       }     </FormConsumer>   ); };

And the Panel component will look like this:

const Panel = props => (   <FormConsumer>     {({ actions }) => {       return (         <div onClick={() => actions.switchPanel(props.id)}>           {props.children}         </div>       );     }}   </FormConsumer> );

To understand what is happening, let’s understand the approach here. The login and signup panels will have unique IDs that get passed via props to the Panel component. When a panel is selected, we get the ID and and use it to set activePanel to swap forms. The FormPanel component also receives the name of the panel via the isActive prop and we then check to see if the returned value is true. If it is, then the panel is rendered!

To get the full context, here is how the App component looks:

const App = () => {   return (     <div className="form-wrap">       <Form>         <div className="tabs">           <Panel id="login">             <h2 className="login-tab">Login</h2>           </Panel>           <Panel id="signup">             <h2 className="signup-tab">Sign Up</h2>           </Panel>         </div>          <FormPanel isActive="login">           <Login />         </FormPanel>          <FormPanel isActive="signup">           <SignUp />         </FormPanel>       </Form>     </div>   ); };

You can see how the components are composed when activePanel matches isActive (which is supposed to return true). The component is rendered under those conditions.

With that done, the Login component looks like this:

const Login = () => {   return (     <React.Fragment>       <div id="login-tab-content">         <form className="login-form" action="" method="post">           <input             type="text"             className="input"             id="user_login"             placeholder="Email or Username"           />           <input             type="password"             className="input"             id="user_pass"             placeholder="Password"           />           <input type="checkbox" className="checkbox" id="remember_me" />           <label htmlFor="remember_me">Remember me</label>            <input type="submit" className="button" value="Login" />         </form>       </div>     </React.Fragment>   ); };

And the SignUp component:

const SignUp = () => {   return (     <React.Fragment>       <div id="signup-tab-content" className="active tabs-content">         <form className="signup-form" action="" method="post">           <input             type="email"             className="input"             id="user_email"             placeholder="Email"           />           <input             type="text"             className="input"             id="user_name"             placeholder="Username"           />           <input             type="password"             className="input"             id="user_pass"             placeholder="Password"           />           <input type="submit" className="button" value="Sign Up" />         </form>       </div>     </React.Fragment>   ); };

Get it? Got it? Good!

You can use this pattern anytime you have components in your React application that need to share implicit state. You can also build compound components using React.cloneElement().


The post Compound Components in React Using the Context API appeared first on CSS-Tricks.


, , , ,