See also the video transcript and the slides

An illustration of the brain where one hemisphere is splattered with vibrant colors and extending out to the open space. This is an analogy of unlocking the creativity of developers to make it to their end users

Open UI: Unlocking creativity

For over two decades many of the components and controls in HTML have been locked down across a spectrum of control depending on the browser. This puts developers and designers between a rock and hard place; they often have to re-create the UI in completion to create the experience they're wanting for their users.

The Open UI community group is working diligently to try and solve this problem. Come to hear about this initiative and how you can test it out today in a browser near you.


See slides
photo of Greg Whitworth

Greg Whitworth
Salesforce

Greg Whitworth loves working on the web to create great digital experiences for users through an intuitive and productive developer experience. Currently Greg is a Sr. Director of Product on the Web and Mobile Platform team at Salesforce. He's the chair of the W3C Open UI Community Group and worked for close to a decade on Microsoft Edge web platform. Greg enjoys to travel, playing both video and board games, and hiking with the family.

Twitter@gregwhitworth

Hello.

Yes, thank you, everybody.

Give it up for Dom and Marie Claire, W3C for putting this on.

As they noted, it's great to be with you all.

So I just get the pleasure.

15 minutes is not nearly long enough to go over all the work that's happening in this group.

I'm the the beneficiary of just getting to present some of the work that Daniel, Mason, Brian and also roughly 15 to 20 per week put into Open UI work.

But for those of you that don't know what Open UI, the Twitter is @openuicg.

The URL's open-ui.org.

But to kind of get into the problem for those of you that have heard this, I apologize for restating the problem for the 80th time.

When Edge was moving over to Chromium a few years back then maybe you guys have heard of that.

Basically we started realizing that some of the components within Chromium at the time just weren't up to our desired standards primarily being accessibility.

In this scenario, you're seeing them in high contrast.

At the time the Chromium controls weren't working in high contrast.

However, if you browse the web at all, you'll quickly notice that a lot of the native controls and components aren't leveraged anywhere in a lot of scenarios.

And the reason for this is because you're basically locked down tight.

That's the key reason, is like there's some functionality or styling capability that you're restricted by.

And so leadership of course asks this, Hey, you're spending a ton of time on these controls and components, why don't I see them anywhere?

Which is a good thing for leadership to ask.

And it actually is coming from a product standpoint because of those problems.

So we need to go solve those.

So how do we go about solving them?

First we start with some research.

We did a survey.

We have a ton of results from these.

These are all on my blogs, so gwhitworth.com if you wanna go look at them.

So basically it came down to, “Hey I can't change the appearance efficiently.” You know, we wanted to add some functionality and what's interesting, like for example the functionality, is basically if we introduce a combo box that basically goes to like, 2%.

Browser inconsistencies was another one.

So like, Hey, they either couldn't style them consistently or their functionality was different across them.

So ultimately they had to completely recreate them.

In asking what were the main key controls or components that were the largest pain points, select won out like crazy and even simple ones relatively to most of us, checkbox was second and then date.

And you can see radio, file, progress, button, dialog, textarea, and text followed down the line.

So we wanted to start with <selectmenu>.

Like I said, we could probably spend an hour literally on every single one of these topics.

But one of the key things that we wanted to do again with <selectmenu> is we wanted to make sure that, Hey, when you're moving to this new element <selectmenu>, it feels like <select>.

It doesn't feel like a drastic departure, but it brings about all of solving those solutions that we outlined earlier.

Because a lot of the things that people unfortunately don't realize, and I've kind of excluded but I do want to hit on, is everybody spends a bunch of time going and recreating these.

Unfortunately, not all of them are either performant, fully accessible, all those wonderful things.

They don't put in necessarily the time and energy or maybe have the expertise or users to actually test that, to ensure that that's the case.

So we want to be able to make it so that they can fully control the appearance of the <selectmenu>.

You don't have to rewrite all the behaviors.

So light dismiss, you know, all the keyboard interactions, the up down arrows.

“Hey when you click outside of it, it dismisses.” “How do we handle nested scenarios?” All that other stuff.

And most importantly, that last piece: that it's accessible by default.

So we want to unlock all these capabilities but also don't offer footguns to make them inaccessible.

So this is <selectmenu> in basic form.

So this should not be necessarily shocking to anybody.

It's basically a select menu.

It should look identical to <select> effectively, with a bunch of options and it renders, as you can see.

Nothing remarkable yet.

Everybody with me?

All right, okay, cool.

Now this is where things start getting interesting.

Another principle that was left off that first slide is we wanted to make sure we actually just built on top of standards that were already there, so web components.

So what we actually do, we go and we do a ton of research across all the different design systems component libraries across the web, to kinda start saying, Okay what are the key use cases and what is the anatomy structure of this thing supposed to be?

and the use cases to ensure that we unlock.

So here you can actually see this is in...

By the way you I'll show in a little bit how you can go test this.

So here's the <selectmenu> with a correct class of my-select-menu.

And we're using the ::part(button) to fully style this to the extent that we desire.

Again, nothing remarkable here yet.

But this is the anatomy, as noted earlier.

So this is in, if you go to the Open UI <selectmenu> specification, you'll see this anatomy.

And you'll notice actually, on button container in selected value, for example, there's slots, right?

And if you've worked with web components, slots basically give you the capability of inserting things.

The interesting thing is we wrapped all of our parts with slots to make it so you can completely replace them, for your own content, for whatever you want.

So in this scenario, notice we've drastically actually changed what the root box looks like.

So rather than just the normal button that you're used to with the selected value, with the triangle, we now are able to completely open this up.

Again, technically everything works.

All we do is use the normal web component slot=button.

And I'll get into the magic in a second.

That new behavior attribute, behavior=button.

And so basically what this now does is completely re-layed out, but everything about it is the same.

So all of the controller code, we basically like to refer, if you've heard of them, MVC model, so the model view controller.

Ultimately what we want you doing is primarily changing the view and that's the majority of the use cases.

They want to change the visual experience.

Most of the controller code, they want to use.

And generally the model is the same.

“I want to select an option or a series of options.” So the behavior attribute, what this does is that actually wires up that controller code.

So we are standardizing the anatomy.

We are standardizing the concrete parts, and then on those parts we wire up all the necessary controller code.

So when you select an item, we have a part called selected value, which everything has replicated within.

Right now it's texts fields, but we're investigating other scenarios.

But everything just magically works.

All the keyboard bindings, everything.

So here's a scenario where we're replacing - drastic scenarios -, like we're replacing literally everything.

So we've passed in our own list box.

We've made sure to wire up the behavioral list box so that it actually pops up and all that stuff.

You'll see that we have an attribute of popup.

I'll get over to popup in a second.

I'm running out of time, so I'm gonna have to speed up.

This is what I mean, like this could technically take forever.

Here's, again- Technically the one on the left is drastically different, right?

But again, it's still technically just a select, right?

You're just selecting an emoji, but it's drastically different.

The layout's completely different.

Likewise, the one on the right basically ends up doing the popups.

I don't know why these aren't animating, but that's okay.

The one on the left, basically if the video plays, we have scrolling indicators.

We basically added in a slot that actually has mouse events that when you mouse over the arrows, it scrolls up versus scrolls down.

Here you're actually on the images drop-down, we're showing that the images are right within.

The options are no longer excluded to just text content.

You can insert really complex content within them.

So if you're thinking about like when you're on Gmail or Facebook or Outlook and you get the person's avatar with their name and their title, those really complex layouts.

Oh, now they're gonna go!

There you go!

All right.

So in these, these are similar, this is just showing me primarily- But I love this one because it's so flipping complex.

But again, the model is inherently the same.

Like we wouldn't necessarily recommend this, because we do have a semantic <input type=color>.

So we wouldn't recommend this.

But it just kind of shows the flexibility because again, it's inherently still just a model of, “I have a popup.

I have a bunch of options.

I can select them.” Fully keyboard accessible, all that other wonderful stuff.

So the roadmap.

Finalize the details.

Basically PR'd into the WHATWG HTML specification.

And then ultimately upgrade the Chromium prototype to match these enhancements and then ultimately ship it.

In order to try this out, go into any Chromium browser, enable the experimental web platform features, <selectmenu>.

Like, please go mess with it.

Ping us.

File issues with us.

It is up on Twitter.

Stoked to see what you guys come up with.

Moving on to popup.

So as we just saw with <select>.

That's the thing I love about Open UI, is it basically highlights primitives we likewise need.

So cool, let's go make a select.

But also on top of that, there's a need for content to popup and render on top of all other content.

What we refer to in the top layer for example.

So there's numerous different types of popups.

Some of them have specific anchors, and I've avoided including anchor positioning in this talk.

But there's different anchoring, and then there's also tooltips where it's like, technically you don't wanna move focus to them, for example, but you do want them to pop up - maybe dismissed after a certain amount of time.

Then there's others, such as the <select>, where when you click it you actually want focus to move into it and so on and so forth.

So this is where the popup attribute comes in.

By the way, I should probably say, as we have some members from the TAG here.

This is all works in progress.

Still incubating, he's laughing.

Still incubating.

We're still figuring this stuff out.

But hey, this is where feedback is great.

So in order to use this, basically all you do is we have this <div>.

We've added this attribute of popup.

And then to bind it, so basically to toggle it, we add the attribute popuptoggletarget, and then we tie them.

And sorry the names are so long, but a lot of you all already use show-popup as an attribute, so it's your fault the names are so long.

Anyways, so when you click it, and this is very ugly.

Basically the content pops up, right?

It's that simple.

And it seems like a simple thing to do.

But, let me go back here.

(mutters) There we go.

So it actually shows something.

So this is a much prettier version of the exact same scenario.

This is using the popup API within, I guess there's more movies to watch or whatever.

But basically, the cool thing about it is that we basically take these three different things.

And this is actually changing focus scenarios, dismiss, nesting capabilities.

auto is gonna be probably the one that you wanna lean into the most.

It allows the nesting, it has your more common light dismiss behavior.

So if you press the escape key, if you press click outside of it, it dismisses all the other popups.

hint, this is again primarily for the tooltip scenario.

So it's not gonna necessarily dismiss just because I'm clicking somewhere else, because it's supposed to be ephemeral.

I can't say that word.

Off to the site.

And then manual is, in a lot of respects, you are trying to manage the popup yourself.

So it's going to pop it up in the top layer but it's not gonna have all the dismiss capabilities tied to it.

You need to go implement those yourself.

So yeah, and I went over this.

Basically, we have three different- I didn't actually go over this.

But we have three different ways in which to bind them.

So the one that you were seeing earlier was actually just show it.

But technically there are scenarios where you want just a button to open a popup and then maybe you want a separate like, little X icon that closes it.

So you technically need two binds.

So you have …showtarget, …hidetarget and then …toggletarget is basically, “I wanna show and hide using the same binding attribute.” One thing I do wanna hit on, another great thing about this is because of those bindings we do, ARIA has popup hookups for you.

So all the accessibility requirements, we handle those for you.

So here's another great example by Jay from Google DevRel.

And this is actually, I'll get into it in a second, basically how...

I don't know why it's not going.

So this is a popup using the :open pseudo-class with transitions.

If it'll render.

Come on, internet.

Given this is like a ten second, seven second video, this is funny.

How much time?

We have three minutes to wait for seven seconds.

Oh, there we go okay.

So you can see the popup is on top and basically what it does is it animates in.

And that's the...

I don't know what I just did.

There we go, okay.

So basically what's awesome about it, and again Open UI's key thing, is we don't want to introduce something that ultimately you end up replacing because we've added so many restrictions to it.

We want to give you the base styles, that again are probably gonna be ugly but come with the key functionality that you want.

And so what's great about this popup is we know there are a lot of scenarios where you actually want to animate between those states.

So we support the onpopup, the :open pseudo-class so you can actually see that we have transitions - that's why you were seeing the balloon transition in, it wasn't just like appearing and disappearing.

For this one, same scenario, it's in the Chromium implementations.

Turn on the experimental platform features.

The second bullet, actually just this morning- So thank you Rachel, Jay, everybody at the Google Dev Row team.

He published probably it's an entire thesis on the popup API, and remarkable demos from very basic to a ridiculously complex.