Month: October 2023

Lea Verou helped craft the State of HTML 2023 Survey — the first 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 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.

1. I didn’t know you could programmatically open an input’s UI. Like if you have a reference to it, you can dateInput.showPicker(). Funny twist though, you can’t try it within the CodePen 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.
2. 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 already has it. Just to make everything about me: consider the UI 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! 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.
3. 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 was going to be first 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.
4. 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?
5. 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.
6. I knew about JSON imports, like import json from './foo.json' assert { type: 'json' }; which I really like as it saves me from a ceremonious fetch-and-parse. I’ve also heard of the CSS version ala import sheet from './styles.css' 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 } 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.
7. 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 of the most interesting things starting to arrive in HTML is popovers. “Popovers are everywhere on the web.” says Una Kravets introducing them. Menus, tooltips, button dropdowns, etc. It’s like a little chunk of UI that needs to sit over all the other UI. Often easier said than done! CSS’ darning z-index can only take you so far. If you’re deep in a nested DOM, you often can’t get a bit of popover UI high enough, and need to resort to JavaScript manipulation to move it somewhere higher in the DOM, 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). popovers are being proposed by Open UI 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 17 totally does have? Popovers. I’ll paste their example HTML here in case you wanna copy and paste it yourself into a new Pen in Safari 17 and have a test:

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

<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 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). 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>

I think Dave 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 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:

Our 2023 issue is made up of 17 contributions that span modes of digital literature and experiment. We have poetic instruments, interactive fictions, illustrated essays, movable lyrics, linguistic gardens, and pixelated memories.