3 ms·

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 ext

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      I've been exploring using dialog for modals - what a11y issues does it have?
      - runarberg 3y ago
        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.
      - jakelazaroff 3y ago
        Looks like the sibling comment is correct and that <dialog> a11y has improved recently: https://adrianroselli.com/2020/10/dialog-focus-in-screen-readers.html#Update01 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/dialog#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/ https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
        lelandfe 3y ago
        > 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”
bobthepanda 3y ago
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.
- kitsunesoba 3y ago
  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.
- jakelazaroff 3y ago
  Some sort of native transclusion other than <iframe> would be really nice.
- asddubs 3y ago
  native support for a form element to allow changing the order of a list using drag and drop.
cubefox 3y ago
Not sure CSS is really moving that much. E.g. doing a CSS transition from/to height:auto is still not supported.
- benfrain 3y ago
  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 3y ago
    Thanks. A lot of things are possible with tricks that should have long been supported natively.

_jesse 3y ago

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 3y ago
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 3y ago
  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 3y ago
    I've been exploring using dialog for modals - what a11y issues does it have?
    - runarberg 3y ago
      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.
    - jakelazaroff 3y ago
      Looks like the sibling comment is correct and that <dialog> a11y has improved recently: https://adrianroselli.com/2020/10/dialog-focus-in-screen-readers.html#Update01 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/dialog#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/ https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
      - lelandfe 3y ago
        > 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”

bobthepanda 3y ago

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.

kitsunesoba 3y ago
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.
jakelazaroff 3y ago
Some sort of native transclusion other than <iframe> would be really nice.
asddubs 3y ago
native support for a form element to allow changing the order of a list using drag and drop.

cubefox 3y ago

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

benfrain 3y ago
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 3y ago
  Thanks. A lot of things are possible with tricks that should have long been supported natively.