Comment by skgough

Comment by skgough 18 hours ago

22 replies

View on Hacker News

Another selfish reason: web pages just work a lot better when you use the actual HTML elements, especially when you compose them together. React projects often mix several component libraries together to make a comprehensive UI. All of these libraries behave differently in subtle ways. When you compose them together, the differences compound: focus is not restored to the button that opened a dialog when it is dismissed, there are 4 different blues used on the page, the date input doesn't use your country's date format.

When you use HTML primitives like inputs with associated labels, the new popover API, dialogs, details + summary elements, their behaviors are all made by the browser vendor and are designed to compose with each other. It really is a difference of night and day, and for free. We don't take advantage of the amazingly powerful tools we have been given.

Flimm 17 hours ago

I wish I could agree with you, but in my experience the built-in controls have many flaws and have remained stagnant for years or decades.

Reply View 14 replies
  • dgb23 9 hours ago

    Btw that's largely our (web devs) fault.

    https://extensiblewebmanifesto.org/

    Good intentions and some good ideas. But ultimately lead to a fractured, overly complicated and bloated web.

    I say yes to lower level, more general capabilities. But why does that have to mean we get bad APIs (web components, indexeddb, service workers...) and lack fundamental and well established UI components (combobox, toggles, tabs, tooltips, data grids...) and incomplete implementations (lacking HTTP verbs for forms)?

    (Also why we're at it, I'm going to sneak in a complaint about half baked and broken language features like `const` and `import`. Also we shouldn't have abandoned Do-Not-Track...)

    Reply View 3 replies
    • WorldMaker 5 hours ago

      How are `const` and `import` half-baked or broken? They work great, and do what they are supposed to do. Browser support is great today for both.

      Reply View 1 reply
      • dgb23 an hour ago

        "Const" is half baked as it implies that you declare an immutable value, but it only prevents redeclaration and direct reassignment.

        "Import" breaks the browser REPL and the dynamic nature of JS. You can't redeclare, look or move into a module. Now JS is already broken in that you can't redeclare variables declared with let/const. But not being able to move into modules an extra crime.

        Reply View 0 replies
    • sfink 8 hours ago

      DNT wasn't abandoned, it was killed.

      Reply View 0 replies
  • ozim 11 hours ago

    Second that and from my experience they are just not feasible for any modern web app.

    Those controls work fine maybe for a static form on a website as parent wrote - but web applications are not websites...

    Reply View 2 replies
    • ryandrake 9 hours ago

      To you and OP, as the movie goes: "Yeah, well, that's just like, your opinion, man."

      My opinion is that we could use fewer "web applications" and more web pages that simply provide structured semantic data and then get out of the way and let the User Agent (and user himself) control the presentation of that data. Sure, some things have to be a web application. I'll grit my teeth and admit that. But many, many sites we visit could easily be raw HTML and maybe some CSS (which the User Agent is free to cherry-pick through or ignore). They would be fast, functional, accessible, (probably) more secure, (probably) more private, free of telemetry, and would better serve the user's interests over the web company's interests.

      Instead we get JavaScript "instructions" from the web site, which require the User Agent to faithfully execute, often removing the user's direct access to the actual content and enforcing the web developer's opinion on how it should be presented.

      If we had more use of standard controls and light markup, and less JavaSludge, maybe browsers would devote more time towards fixing and improving their standard controls.

      Just another random person's opinion, but this has been a terrible direction for the web.

      Reply View 1 reply
      • bigbuppo 7 hours ago

        The whole reason we need web "applications" when a simple web site will do all boils down to the demands of marketing and advertising. If you were to go to a major news organization's web site, the bulk of the javascript isn't for frontend UI frameworks, but advertising. Go to a video streaming platform, and they do Weird Things not to prevent scraping, but to inject marketing analytics for advertisers even when you're on an ad-free plan.

        Marketing and advertising makes the world a worse place. When you look at the real numbers, it rarely achieves whatever business goals it's supposed to achieve, though for some reason they keep throwing money at the crap because maybe this time it will be different.

        Reply View 0 replies
  • flomo 16 hours ago

    Just some blatantly obvious examples: Select Multiple was some Windows 3 garbage, and HTML didn't have a 'combobox', much less a 'multi-combobox'. (MDN says datalist is not supported on Firefox, so maybe it still doesn't.) So write it yourself, or use a library. The form validation stuff is still bad, and idk if modern desktop browsers have a good date control.

    Reply View 4 replies
    • Y-bar 16 hours ago

      I can agree that it is bad. And there might be some examples where <select multiple> is the "best" way, but I cannot ever remember a real-world use case where it was not better solved using a list of <input type=checkbox> anyway.

      Reply View 2 replies
      • flomo 15 hours ago

        Yeah sure, the 'right' way was checkboxes in an iframe. Just that the weblords care alot more about adding syntax to javascript than whatever multi-select-searchable-accessible-box you might want. The form stuff still mostly sucks.

        Reply View 0 replies
      • komali2 10 hours ago

        I must be confused because the use case I'm thinking of is a list of 5,000 somethings that are filtered down through user-input text in the combobox, that they can then select, and selected items are then displayed as bubbles within the input field or elsewhere. Certainly can't just display 5,000 checkboxes instead :P

        Reply View 0 replies
    • shakna 3 hours ago

      Firefox got partial support in 2011. All that's missing, today, is support for date and time fields.

      For most usecases, it'll work. Not so much for meeting scheduling, or calendar management, but everything else.

      Reply View 0 replies
  • naavis 16 hours ago

    What kind of flaws did you have in mind?

    Reply View 1 reply
    • Zarel 7 hours ago

      <input type="number"> is famously really flawed and not worth using even if what you want is semantically a number and not just numeric:

      https://stackoverflow.blog/2022/12/26/why-the-number-input-i...

      Tables have a whole bunch of flaws, like not letting you turn an entire row or cell into a link. (Some things are semantically tabular data!)

      <button disabled> doesn't trigger various DOM events, forcing you to use <button aria-disabled="true"> if you need them.

      These are the ones that come to mind immediately. I wouldn't be surprised if there are others.

      Reply View 0 replies
Toritori12 14 hours ago

I dont remember last time (if ever?) I saw a native date input in the wild.

Reply View 4 replies
  • bob1029 10 hours ago

    Last product I worked on I made this a thing. Every modern browser now renders a very competent date picker for input type="date".

    I find a lot of the arguments for building inaccessible UIs seem to conflate historical web issues with modern times. Virtually everything that sucked in the core web toolkit circa 2010 has essentially been solved in 2025, even on ultra-restrictive platforms like iOS Safari.

    Reply View 0 replies
  • cardanome 12 hours ago

    I have recently used plain old html date input in a internal tool and it works great.

    Not the prettiest but I have seen much worse custom ones that were super buggy.

    Reply View 0 replies
  • dgb23 9 hours ago

    Native date inputs have their problems, but I default to them usually because they typically have the best behavior on mobile and are localized by default.

    Reply View 0 replies
  • pelagicAustral 13 hours ago

    textbox is the warriors way of date input. Anything else is cruft. /s

    Reply View 0 replies
PaulHoule 9 hours ago

Quite a few 3rd party controls have had attention paid to accessibility and have all the right aria- and other accessibility markup.

Reply View 0 replies