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=toolbar, menubar, etc.. Using this semantic element, for semantics sake, is just that.
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.
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.
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.
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 a rough outline that shows how the following steps fit together:
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.
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.
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:
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:
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: