Chris’ Corner: Things I Totally Didn’t Know About That I Learned From Taking the State of HTML 2023 Survey

By admin

Lea Verou
PERSON

helped craft

the State of HTML
GPE


2023
CARDINAL

Survey — the

first
ORDINAL

of it’s kind! HTML, you say? What is there to ask? HTML isn’t exactly what I’d think of as a fast-moving technology. I hear there is a <search> element now, so that’s new. It’s sugar for <div role="search"> . I like it. Is there much more than that? Well lemme just have a click over to the survey and take it for myself. 😳.

Uhm
PERSON

yes there is much more than that.

I actually do try to keep up with this sort of thing, and I’ll tell ya going through this survey had me clicking that “🤷 Never heard of it” choice quite a bit. Allow me to pick out a few that surprised me.

I didn’t know you could programmatically open an input’s

UI
ORG

. Like if you have a reference to it, you can dateInput.showPicker() . Funny twist though, you can’t try it within the

CodePen
ORG

editor or else you’ll get a HTMLInputElement::showPicker() called from cross-origin iframe. error. It’ll work fine in Debug Mode though. I don’t think you can declaratively open it, though, right? You should be able to. I knew that you could make an element “editable” by adding the contenteditable attribute, but I didn’t know you could opt-out of the rich tech formatting with contenteditable="plaintext-only" . Looks like everybody but

Firefox
ORG

already has it. Just to make everything about me: consider the

UI
ORG

of the header area of a Pen. If you own it and hover over the title, you can click a little ✎ icon to edit it. We don’t use contenteditable there because I’m worried someone will copy and paste the entire

Yahoo
ORG

! homepage in there (kidding, kinda). But rich text is entirely irrelevant there, and this would be a nice alternative to the text-element-flip-flopped-for-a-text-input like we currently do. I didn’t know that there is a plan to allow the name attribute across multiple <details> elements, which makes it so only one can be open at a time, a common “accordion” pattern. I somehow thought

Safari
PERSON

was going to be

first
ORDINAL

out of the gate with this with v17, but I was wrong. So nobody is shipping it, but I do like it. Clever idea, if a little hard to discover. I knew about <script> attributes like async and defer but didn’t know about this one that essentially does the opposite: blocking="render" . That’s not, like, a great performance characteristic, but if you’ve got JavaScript that really needs to execute before a user sees anything (rather than showing something and having it flop out post-rendering), I could see this being useful. I guess any bundle that includes React should use this eh? I didn’t know there was a <model> element, for showing 3D models. I have no idea how it works. I would guess it’s largely semantic rather than functional. Seems early. I knew about JSON imports, like import json from ‘

./foo.json
PERSON

‘ assert { type: ‘json’ }; which I really like as it saves me from a ceremonious fetch-and-parse. I’ve also heard of the

CSS
ORG

version ala import sheet from ‘

./styles.css
PERSON

‘ assert { type: ‘css’ }; which then allows me to donk those styles onto the document or any resistant shadowRoot. But I didn’t know the idea was being extended to HTML like import {

TabList
PRODUCT

} from "./tablist.html" with { type: ‘html’ } ; I guess it’ll make it easier to define custom elements that reside within that chunk of HTML? I can’t quite picture it yet so would love to see examples. I had never heard of the focusgroup attribute. I read up a smidge and it’s very interesting! If I understand it right, it essentially allows you to make a group of focusable elements respond to arrow key navigation within the group. If you hit tab again, you’d leave the whole group of focusable elements. Like a group of radio buttons! But with whatever group you want.

While we’re deep in HTML land here, allow me to reach into my bag of links and share some of the most interesting ones related to HTML I’ve saved lately.


One
CARDINAL

of the most interesting things starting to arrive in HTML is popovers. “

Popovers
PERSON

are everywhere on the web.” says

Una Kravets
PERSON

introducing them. Menus, tooltips, button dropdowns, etc. It’s like a little chunk of

UI
ORG

that needs to sit over all the other

UI
ORG

. Often easier said than done! CSS’ darning z-index can only take you so far. If you’re deep in a nested

DOM
ORG

, you often can’t get a bit of popover

UI
ORG

high enough, and need to resort to JavaScript manipulation to move it somewhere higher in the

DOM
ORG

, which has it’s own set of problems, like positioning complexity and accessible connective tissue to what controls it. Native popovers promote themselves onto some magical higher rendering layer which is on top no matter what. Awfully fancy.

I would think anchor positioning goes together with this like peanut butter and jelly. If you just wank the popover in the middle (which I think it does by default)… isn’t that just a <dialog> ? Fortunately Hidde de Vries has us covered here with Dialogs and popovers seem similar. How are they different? I wish I could but I can’t do better than his summary so:

OK, so, in summary: modality of a component is a state in which only that component can be used. When something is modal, everything else is inert: blocked from access in any way, unfocusable and usually obscured with a backdrop. Making something modal is a substantial decision, it should be used sparingly. Dialogs can be modal or non-modal (also called modeless). popover s are being proposed by

Open UI
PRODUCT

as a new way to build non-modal dialogs with a specific set of behaviours and characteristics, like top layer presence, JS-less toggleability and browser-provided light dismiss. Unlike <dialog> , a popover does not have a built-in role: as a developer, you can add the popover attribute to the semantically most relevant element

You know what

Safari
PERSON

17 totally does have?

Popovers
PERSON

. I’ll paste their example HTML here in case you wanna copy and paste it yourself into a new

Pen
ORG

in

Safari
GPE

17 and have a test:

<button popovertarget="info-box" popovertargetaction="show">More

info</button
NORP

> <article id="info-box" popover="auto"> <h2>Additional Information</h2> <p>Here’s something I wanted to tell you.</p> <button popovertarget="info-box" popovertargetaction="hide">Close</button> </article>

Just a quick high-five to

Rian Rietveld
PERSON

for a darn fine overview of crafting the perfect link. Introductory content is everywhere, but the good stuff is hard to find (this is from

2021
DATE

). Not a ton of code examples, which to me makes an article like this even harder to write.

I just used a little link-related trick I nearly forgot about the other day: using the download attribute like:

<a href="/files/pitch.pdf" download>Download Pitch

PDF</a
ORG

>

I think

Dave
PERSON

has a good point here: Markdown images are an anti-pattern. I’ve always said images are hard, in part because of how many attributes you need to know about and put on the <img> tag. Just loading="lazy" alone is huge. Some Markdown processors allow for additional attributes in the

Markdown
ORG

syntax, but not all, and the format for that isn’t particularly pretty (and of course, totally non-portable to other processors). Thankfully Markdown supports HTML, so just use that.

I’ll leave you with the html review: