4 ms·

I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes,

I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc. Then there's the endless layers of fiddly work needed to make accessibility work cross-platform (check out all the work Adobe puts into the react-aria project for an example), and that there's still fundamentally no browser-native no-JS way to submit a form and use the response without loading the whole page again...

zarathustreal 3y ago
“And use the response” Right, because a description of the use of the response would constitute a DSL
lkrubner 3y ago
Agreed. I remember in 2012 we joked that if you used enough Javascript you could get the Web in 2012 up to the level that VisualBasic 1.0 offered back in 1991. But we were certain that in 10 years, by 2022, we'd up to the level offered by VisualBasic 6.0, which would have been amazing, because VisualBasic 6.0 had been amazing. I've been stunned by the lack of progress. The major browser companies/projects have largely stopped innovating. The period from 1993 to maybe 2010 or 2015 was very fluid, and HTML and CSS expanded quickly, but after a certain point the attitude seemed to be "We don't need to fix HTML because we can fix it with Javascript." Which is sort of true, but it is clunky. It would be much better to simply add more to HTML. At a minimum, every form element offered by VisualBasic should have eventually been added to HTML. What is the hold up? Why isn't this happening? It's shocking, but there are still no calendars in HTML. Every calendar has to be custom built with CSS and Javascript. You'd think in the year 2024 we'd have every possible time element added to HTML, with easy customization options. I'm baffled this hasn't happened yet. What will it take to get the major browser companies/projects to start adding more to HTML?
- freeone3000 3y ago
  Input type=“date” was added and is supported in HTML5, no js required. Same with time!
  - crooked-v 3y ago
    ...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.
    - clipsy 3y ago
      What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.
      - wild_egg 3y ago
        _date picker_, yes. Calendar display? No native options. The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do
        deleted 3y ago
        [deleted]
        bombcar 3y ago
        Which is hilarious because it can display a calendar for date picking; but cannot display a calendar.
        smaudet 3y ago
        Likely because the element authors didn't want to overload the existing input semantics. You are talking about <calendar /> not <input type="date" />. Its the same semantic issue that lead to <button /> and <input type="button" />, with different functionality/support in different browser(s), and why we have auto-fill libraries that eventually became javascript component libraries, got rolled into development frameworks and turned into hyper-adware... Its "hilarious" but an "input" that does nothing but show an input calendar is arguably better. Otherwise, you're not writing (semantic) html, you're writing <insert ui framework>.
- yen223 3y ago
  > What is the hold up? Why isn't this happening? One of the problems, and arguably one of its strengths, with the modern web is that there's no single "entity" that owns everything. A large part of why this isn't happening is that there are too many parties involved in the web - browser implementers, standards maintainers, and web developers. If you want to introduce a new feature to the web standard, it's not enough to convince one browser implementer to add it - web devs can't use a feature that only one browser supports! You need to convince the standards body to adopt it, and to convince browser implementers (plural) to support it, and this takes a lot of time and coordination effort. In the case of Visual Basic, you just need to get some PM in Microsoft to add it, and it'll be added.
  - actionfromafar 3y ago
    Is it Apple and Google?
- marcus_holmes 3y ago
  I think Web Components was seen as the fix for this; that (in the same way VB4 did) we'd have packages of standard components as building blocks for UIs. So rather than each browser implementing a calendar defined in HTML, you'd use a third-party library Web Component that implemented a calendar. Which is happening. You can get a Web Component calendar, and they mostly work. I just don't think it's taking off as "the way" for doing web UI (yet). This might change, I guess. But probably not. I think the big difference from the VB days is design. In the old days, we dev monkeys would design UIs by slapping together controls in a form. Which is why they all looked the same, and while they worked well they didn't exactly inspire. Now in Web Dev we have designers as the first step, and every designer designs their UI differently. You can't slap together a UI and call it done. Well, you can, and I do, but everyone thinks the result is ugly and needs a designer to make it usable - we've moved the bar of acceptable aesthetics to the point where this VB way of creating UIs doesn't work any more.
  - smaudet 3y ago
    You hit the nail on the head (well, half) - design is an incredibly tricky problem. Mostly because it at its core is the process of adding constraints, and once you've added those its far harder to un-add them. That's why CSS was so janky for so long - there were design paradigms (tables, box model, flex box, etc) and once they were there, you hoped they worked and you hoped that your specific design didn't break one of its core assumptions, leading to large amounts of work-around code that was either slow or exhibited constant random bugs in different versions of browsers... The other half of the nail was backwards compatibility. Unfortunately you can't have web components and your stuff working on 20 year old devices. So any new design/paradigm etc. served to splinter the ecosystem (your stuff only works on this browser, that device, our operating system). Graceful degradation sort-of would have provided a work around, but it would have done so by shifting the workload onto the provider (please make sure your calendar works, in these browser, and also has fallback implementations as a clock that doesn't break your back-end code because they entered hours as farsi, test on on these 40 browsers and also target moving backends). So instead we invented polyfills as a way of "automatically" back-filling for a lot of stuff. Unfortunately, you can't do much about the Web Component calendar. The design paradigm that once existed doesn't support it without a lot of busy work, even if newer browsers could natively implement one and never load a line of javascript or any of your shitty thousand line long html layout code... I don't think its a completely lost cause, HTMX + Web Components seems like our best path forward so far. Right now, a lot of people who've written millions of lines in non-html frameworks like React and the like are very reluctant to give up their codebase(s), however terrible they might be. It is unfortunately, the result of someone somewhere making a design decision that added constraints, now causing headaches and difficulties un-adding those constraints...
lmm 3y ago
> I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc. This is completely backwards IMO. The problems come from browsers natively implementing all of these things, in ways that are almost, but not quite, good enough for those web apps. The browser has the Python standard library problem of being "where modules go to die", but even worse since browsers can never deprecate anything; as a result we have all these 80% implementations that don't quite solve the problem but are enough to suck all the oxygen away from any good solutions. And then we just pile hacks on hacks to improve these things without ever fixing the underlying stuff. I mean FFS, Chrome will save and sync passwords that I enter in some web form flow based on heuristics, but it won't save actual username/passwords that I enter via the built-in username/password functionality that the browser has; how screwed up is that? If I was somehow king of the web, what I'd be looking to do is: standardise one of the various "web components" proposals that lets people implement custom tags as libraries. Reimplement almost all of the things that are currently implemented as browser builtins as web components instead, move them out of the core rendering engine and into what are effectively polyfills-in-reverse; make the actual "browser" piece only implement div/span/canvas or something. Normalise pages loading components from libraries, where they can be iterated on and improved more quickly. But for some reason web folks and especially HN seem to hate the few parts of the web technology stack that actually work well (Javascript, NPM) and love implementing as much as possible in the parts that are awful and unfixable (CSS). So I don't see things ever improving.
- crq-yml 3y ago
  The elephant in the room is that the majority of the standards we end up with are the same thing done three or more different ways in a great rush by a bunch of industry players, with the most popular one being sufficient for a demo app, and the rest being unknown and NIH'd out of parlance. What we've managed to seriously agree on: * 8-bit bytes * IEEE 754 * Unicode Still up for grabs to a motivated dissenter: * Endianness * Line endings * 3D coordinate systems * Structured data encoding * Networking protocols * Calendars * Everything else The browser does work and do some useful things. At the same time, it is mostly a defacto-standard in the post-Chromium era. Specifications like Web Audio did not appear through a lengthy process like, e.g., what created MIDI 2.0. A team at Google appointed themselves a rubber stamp for the thing they wanted to do. But if you actually want to implement it, you look at what Chromium did. These days I go with the assumption that most of our interfaces are not seriously standardized, and starting over is correct once you have an application that really needs control.
Zak 3y ago
> no browser-native no-JS way to submit a form and use the response without loading the whole page again I think a lot of badness comes out of the desire to avoid loading the whole page again. Sure, there are lots of more desktop-like webapps where that's definitely undesirable, but a whole lot of interactions are just fine as a page load, as long as the page load itself doesn't suck.
- _factor 3y ago
  The real problem isn’t the page load, it’s that it’s visible. If only one picture and a bit of text update, why does the whole screen have to blink?
  - skgough 3y ago
    The view transitions API addresses this: https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
    - p_l 3y ago
      And seems to require JS and doesn't support (yet) cross-document transitions (i.e. anything that causes a reload)
  - deleted 3y ago
    [deleted]
  - Zak 3y ago
    I question whether that's a real problem in a web form. Even unsophisticated users have probably seen it more than a few times and know that it's normal.
hawski 3y ago
Regarding a form submission without a reload I got this idea years ago: If the page that is loading has the same origin as the page before it the browser would do the equivalent of DOM diffing and replacement. Basically doing what those new batch of JS libraries did in browser.
deleted 3y ago
[deleted]

zarathustreal 3y ago

“And use the response” Right, because a description of the use of the response would constitute a DSL

lkrubner 3y ago

Agreed. I remember in 2012 we joked that if you used enough Javascript you could get the Web in 2012 up to the level that VisualBasic 1.0 offered back in 1991. But we were certain that in 10 years, by 2022, we'd up to the level offered by VisualBasic 6.0, which would have been amazing, because VisualBasic 6.0 had been amazing. I've been stunned by the lack of progress. The major browser companies/projects have largely stopped innovating. The period from 1993 to maybe 2010 or 2015 was very fluid, and HTML and CSS expanded quickly, but after a certain point the attitude seemed to be "We don't need to fix HTML because we can fix it with Javascript." Which is sort of true, but it is clunky. It would be much better to simply add more to HTML. At a minimum, every form element offered by VisualBasic should have eventually been added to HTML. What is the hold up? Why isn't this happening? It's shocking, but there are still no calendars in HTML. Every calendar has to be custom built with CSS and Javascript. You'd think in the year 2024 we'd have every possible time element added to HTML, with easy customization options. I'm baffled this hasn't happened yet. What will it take to get the major browser companies/projects to start adding more to HTML?

freeone3000 3y ago
Input type=“date” was added and is supported in HTML5, no js required. Same with time!
- crooked-v 3y ago
  ...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.
  - clipsy 3y ago
    What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.
    - wild_egg 3y ago
      _date picker_, yes. Calendar display? No native options. The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do
      - deleted 3y ago
        [deleted]
      - bombcar 3y ago
        Which is hilarious because it can display a calendar for date picking; but cannot display a calendar.
        smaudet 3y ago
        Likely because the element authors didn't want to overload the existing input semantics. You are talking about <calendar /> not <input type="date" />. Its the same semantic issue that lead to <button /> and <input type="button" />, with different functionality/support in different browser(s), and why we have auto-fill libraries that eventually became javascript component libraries, got rolled into development frameworks and turned into hyper-adware... Its "hilarious" but an "input" that does nothing but show an input calendar is arguably better. Otherwise, you're not writing (semantic) html, you're writing <insert ui framework>.
yen223 3y ago
> What is the hold up? Why isn't this happening? One of the problems, and arguably one of its strengths, with the modern web is that there's no single "entity" that owns everything. A large part of why this isn't happening is that there are too many parties involved in the web - browser implementers, standards maintainers, and web developers. If you want to introduce a new feature to the web standard, it's not enough to convince one browser implementer to add it - web devs can't use a feature that only one browser supports! You need to convince the standards body to adopt it, and to convince browser implementers (plural) to support it, and this takes a lot of time and coordination effort. In the case of Visual Basic, you just need to get some PM in Microsoft to add it, and it'll be added.
- actionfromafar 3y ago
  Is it Apple and Google?
marcus_holmes 3y ago
I think Web Components was seen as the fix for this; that (in the same way VB4 did) we'd have packages of standard components as building blocks for UIs. So rather than each browser implementing a calendar defined in HTML, you'd use a third-party library Web Component that implemented a calendar. Which is happening. You can get a Web Component calendar, and they mostly work. I just don't think it's taking off as "the way" for doing web UI (yet). This might change, I guess. But probably not. I think the big difference from the VB days is design. In the old days, we dev monkeys would design UIs by slapping together controls in a form. Which is why they all looked the same, and while they worked well they didn't exactly inspire. Now in Web Dev we have designers as the first step, and every designer designs their UI differently. You can't slap together a UI and call it done. Well, you can, and I do, but everyone thinks the result is ugly and needs a designer to make it usable - we've moved the bar of acceptable aesthetics to the point where this VB way of creating UIs doesn't work any more.
- smaudet 3y ago
  You hit the nail on the head (well, half) - design is an incredibly tricky problem. Mostly because it at its core is the process of adding constraints, and once you've added those its far harder to un-add them. That's why CSS was so janky for so long - there were design paradigms (tables, box model, flex box, etc) and once they were there, you hoped they worked and you hoped that your specific design didn't break one of its core assumptions, leading to large amounts of work-around code that was either slow or exhibited constant random bugs in different versions of browsers... The other half of the nail was backwards compatibility. Unfortunately you can't have web components and your stuff working on 20 year old devices. So any new design/paradigm etc. served to splinter the ecosystem (your stuff only works on this browser, that device, our operating system). Graceful degradation sort-of would have provided a work around, but it would have done so by shifting the workload onto the provider (please make sure your calendar works, in these browser, and also has fallback implementations as a clock that doesn't break your back-end code because they entered hours as farsi, test on on these 40 browsers and also target moving backends). So instead we invented polyfills as a way of "automatically" back-filling for a lot of stuff. Unfortunately, you can't do much about the Web Component calendar. The design paradigm that once existed doesn't support it without a lot of busy work, even if newer browsers could natively implement one and never load a line of javascript or any of your shitty thousand line long html layout code... I don't think its a completely lost cause, HTMX + Web Components seems like our best path forward so far. Right now, a lot of people who've written millions of lines in non-html frameworks like React and the like are very reluctant to give up their codebase(s), however terrible they might be. It is unfortunately, the result of someone somewhere making a design decision that added constraints, now causing headaches and difficulties un-adding those constraints...

lmm 3y ago

> I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc. This is completely backwards IMO. The problems come from browsers natively implementing all of these things, in ways that are almost, but not quite, good enough for those web apps. The browser has the Python standard library problem of being "where modules go to die", but even worse since browsers can never deprecate anything; as a result we have all these 80% implementations that don't quite solve the problem but are enough to suck all the oxygen away from any good solutions. And then we just pile hacks on hacks to improve these things without ever fixing the underlying stuff. I mean FFS, Chrome will save and sync passwords that I enter in some web form flow based on heuristics, but it won't save actual username/passwords that I enter via the built-in username/password functionality that the browser has; how screwed up is that? If I was somehow king of the web, what I'd be looking to do is: standardise one of the various "web components" proposals that lets people implement custom tags as libraries. Reimplement almost all of the things that are currently implemented as browser builtins as web components instead, move them out of the core rendering engine and into what are effectively polyfills-in-reverse; make the actual "browser" piece only implement div/span/canvas or something. Normalise pages loading components from libraries, where they can be iterated on and improved more quickly. But for some reason web folks and especially HN seem to hate the few parts of the web technology stack that actually work well (Javascript, NPM) and love implementing as much as possible in the parts that are awful and unfixable (CSS). So I don't see things ever improving.

crq-yml 3y ago
The elephant in the room is that the majority of the standards we end up with are the same thing done three or more different ways in a great rush by a bunch of industry players, with the most popular one being sufficient for a demo app, and the rest being unknown and NIH'd out of parlance. What we've managed to seriously agree on: * 8-bit bytes * IEEE 754 * Unicode Still up for grabs to a motivated dissenter: * Endianness * Line endings * 3D coordinate systems * Structured data encoding * Networking protocols * Calendars * Everything else The browser does work and do some useful things. At the same time, it is mostly a defacto-standard in the post-Chromium era. Specifications like Web Audio did not appear through a lengthy process like, e.g., what created MIDI 2.0. A team at Google appointed themselves a rubber stamp for the thing they wanted to do. But if you actually want to implement it, you look at what Chromium did. These days I go with the assumption that most of our interfaces are not seriously standardized, and starting over is correct once you have an application that really needs control.

Zak 3y ago

> no browser-native no-JS way to submit a form and use the response without loading the whole page again I think a lot of badness comes out of the desire to avoid loading the whole page again. Sure, there are lots of more desktop-like webapps where that's definitely undesirable, but a whole lot of interactions are just fine as a page load, as long as the page load itself doesn't suck.

_factor 3y ago
The real problem isn’t the page load, it’s that it’s visible. If only one picture and a bit of text update, why does the whole screen have to blink?
- skgough 3y ago
  The view transitions API addresses this: https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
  - p_l 3y ago
    And seems to require JS and doesn't support (yet) cross-document transitions (i.e. anything that causes a reload)
- deleted 3y ago
  [deleted]
- Zak 3y ago
  I question whether that's a real problem in a web form. Even unsophisticated users have probably seen it more than a few times and know that it's normal.

hawski 3y ago

Regarding a form submission without a reload I got this idea years ago: If the page that is loading has the same origin as the page before it the browser would do the equivalent of DOM diffing and replacement. Basically doing what those new batch of JS libraries did in browser.

deleted 3y ago

[deleted]