The datalist examples definitely work on my iPhone. They integrate into the autocomplete suggestions above the native iOS keyboard. There’s no way to browse all the suggestions, but I suppose that’s not an intended use case for datalist.

However, the disabled attr on group definitely does not work!

Ugh this is the dose of cold water from reality that I didn't want but definitely needed.

More than a decade ago I had a project that used a pretty aggressive input-suggestion widget on the UI. We used a jQuery plugin for it and it was by far the most complicated part of the frontend. In fact, it was the main use-case for jQuery in that project.

Reading the article, I thought it would be pretty much a breeze re-implementing that frontend in a lightweight JS-minimalist version. But of course, unless I ship my machine to the users, not really. Sad state of affairs.

Nonetheless, I'm really impressed with what's included in the HTML spec nowadays! I haven't kept-up with developments in the spec since I read all about XHTML in high school. I ought to take some time every now and then to see what's changed though, again, browser compatibility is a PITA today as it was back in high school.

Doesn't work with Firefox on Android either.

Way back when I was working my first job, datalist didn’t work on Firefox. That’s what got Firefox removed from the list of supported browsers.

It has been a problem for a long time if you want to support anything other than Chrome.

They work well but not with GBoard on iOS.

Mind that input + datalist is the HTML equivalent of the Windows combobox, once generally regarded as the worst UI element ever. (This was enjoying meme status in usability related articles and write-ups. So probably not a recommendation.)

Not broken, but strange since it should be working on latest Safari.

https://caniuse.com/mdn-html_elements_optgroup_disabled

I think it may be a Safari bug.

This is the kind of thing I struggle with on using native HtML for more than the basics. Even if you do enough reading and have enough confidence to write an article like this the comments end up with quirks, limitations, or notes on lack of support about different browser+device combos.

Div soup is probably a bit far in the opposite direction, but even then it's at least pretty consistent and apparent what the quirks and limitations are because it aligns with what you or the framework wrote much more consistently.

I think that’s OK.

When I first had to use XML, I had to learn the XML spec and output it manually - serialization libraries didn’t really exist yet. I’ve since seen generation of juniors come up through the ranks using XML as an interchange format (and then JSON) without ever learning it fully. It was fine, and nothing terrible happened.

I’ve seen AJAX go from the hot new thing to people not knowing what it stood for, to now most people not even recognizing the term. AJAX didn’t die; it became so common we don’t need a word for it anymore.

My problem is I thoroughly learned HTML twenty years ago and am only incidentally aware of how it has changed and improved since. Doubly so for CSS.

To be honest HTML is a pain.

For example the HTML approach to style parts of a control is to use pseudoclasses. Sometimes the selectors are different across browsers! Then you have to test across browsers because who knows if it will actually work correctly.

React is not just easier it's more dependable. If I make something with React and some divs I know it's going to work the same in all browsers.

I've used a datalist for autocomplete suggestions and it's worked great.

I think I’ve tried building a combobox using datalist once but it didn’t work

Closest thing I know of is https://github.com/kristoff-it/superhtml#diagnostics

  SuperHTML validates not only syntax but also element nesting and attribute values. No other language server implements the full HTML spec in its validation code.

Enforce semantic tags? HTML is first and foremost meant for authors to get creative. Enforcing one tag over another doesn't make sense to me. Accessibility yes, but there are plenty of constraints already.

Because for the user experience, it is identical to <ul>. Use <menu> if it helps you to understand your code but in the browser's accessibility tree and in all other respects, it's just an unordered list.

Conveying that something is a list of actions requires adding ARIA attributes. The article mentions `role=menu` but that's not enough, each item also needs the `menuitem` role. The WAI Authoring Practices Guide explains the roles and interaction expectations; don't copy their coded examples and definitely don't use the roles for navigation menus.

https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

big brain no learn hyperspeak when many div do trick

<menu>, <dialog>, lots of fun stuff in html now.

I like to ask people what they imagine <ruby> does, because I certainly didn't guess right.

In my experience, lack of style customizability is the biggest obstacle to using native HTML features

and it is not styleable

    <BLINK>
      <MARQUEE>
        <OL>
          <LI>One</LI>
          <LI>Two</LI>
          <LI>Three</LI>
        </OL>
      </MARQUEE>
    </BLINK>

FTFY

You mean a sitemap? Because you're talking about a sitemap. Most blogs have a sitemap.xml that lists all of the posts.

Also, why would you want to go through all 235 posts?

It was changed to description list in HTML5, which you would've learned if you actually read the article

This is called out explicitly in the article as a shift from HTML4 to HTML5.

In HTML 4. HTML 5 redefined it.

I will probably write an entirely separate article just on the CSS options for lists. So ... don't hold your breath. But that will come. Eventually.

I'm writing articles like this just because I think the internet deserves some humanity for a change. Thanks for noticing.

Yet the article and comments still feel the need to talk about AI when it was not otherwise involved. The inescapable topic!

Somehow I'm still in the mode where I'm surprised where it is, rather than when it isn't, but yeah it's annoyingly often. Do you come across it so much that it's your default expectation now?

I thought of the 2000 version first which made this much funnier in my head