[kitsunesoba]

Really cool, seem like it'd make styling responsive pages considerably more easy.

It's interesting that CSS has been moving forward at a rapid pace to make extra tooling (LESS, Sass, etc) increasingly unnecessary, but at least from the layman's point of view (web dev isn't my bread and butter), HTML does not seem to be getting nearly as much attention. Clearly there's a need for more capable HTML as evidenced by the countless Rube Goldberg machines built atop it to make it usable, so why isn't there as much interest in developing it?

[_jesse]

It's not moving as fast as CSS has been, but they have been adding new elements to HTML. <summary> and <details> for accordions, <dialog> for modals, and I've heard murmurs of a <selectmenu> element that does everything <select> does while allowing the developer full control over the look.

[ughitsaaron]

I had no idea about these elements or their APIs. Maybe one downside to living in JSX all the time is that it can encourage ignorance of the foundation it’s built on.

[jakelazaroff]

You can use these within JSX! I use <details> and <summary> all the time. Not so much <dialog> — since there are still accessibility issues by default, I’d rather use a library that wraps it. If and when <selectmenu> drops you can bet I’ll be ditching Radix for the native solution.

[lelandfe]

I've been exploring using dialog for modals - what a11y issues does it have?

[jakelazaroff]

Looks like the sibling comment is correct and that <dialog> a11y has improved recently: https://adrianroselli.com/2020/10/dialog-focus-in-screen-rea...

I still would be careful using it! MDN has a section on accessibility considerations: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

The W3C also has a pretty great set of examples of how to make complex widgets like dialogs accessible (not that a11y is just a checklist): https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

[lelandfe]

> I still would be careful using it! MDN has a section on accessibility considerations

In fact, it seems pretty unequivocal: “The native HTML <dialog> element should be used in creating modal dialogs”

[runarberg]

There is currently a debate about these supposed a11y issues. Some are about what happens to focus after dismissal, some are about related elements and announcements, some are about buggy implementations and non support from screen readers.

However it is my belief that these were mostly true 2-3 years ago but the myth has remained. And people still belief there are issues.

I've heard from actual screen reader users that these supposed issues are mostly non-issue. And pale in comparison from people implementing their own.

[bobthepanda]

What would you suggest, that is compatible with its goal of being a markup language?

A lot of the machines built on top of HTML (e.g. JSX) add non-markup to HTML so you can handle if-else/filter and loop. But I don't think there's ever been interest in expressing that natively in HTML itself.

[jakelazaroff]

Some sort of native transclusion other than <iframe> would be really nice.

[kitsunesoba]

The main thing that feels like it could use work is the lack of adequately capable primitives/widgets. Many are plain missing while others are too basic/limited.

[asddubs]

native support for a form element to allow changing the order of a list using drag and drop.

[cubefox]

Not sure CSS is really moving that much. E.g. doing a CSS transition from/to height:auto is still not supported.

[benfrain]

You can achieve that with grid right now. Set a row to height zero, with a container inside with overflow: hidden, then toggle that row to height 1fr. Stick whatever transition you want on it — job done

[cubefox]

Thanks. A lot of things are possible with tricks that should have long been supported natively.