5 ms·

One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades. Browsers have a built-in auth system for HTTP-au

One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades. Browsers have a built-in auth system for HTTP-auth—there's no reason it couldn't have been improved over the years, such that it's actually a decent choice for login. Why no built-in sorting HTML tables, and easy hooks into them for custom sorting? Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? Why were features like frames left to rot rather than improved? They're a common element in UI toolkits, and we're using the Web to make "apps" now! The waste of developer and user time due to the Web platform seeming to just abandon tons of its own functionality and failing to address common and high-cost use cases head-on, is truly staggering.

mynameisvlad 4y ago
> Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? I agree with your premise, but this is a bad example. Universal payment systems are not a simple task. Even remotely. Go out to any American city, for instance, and as you walk through the stores, catalog the various credit card terminals you see. Not even the PoS system as a whole, but just the credit card interface. You will see dozens of different designs and play on designs by dozens of different manufacturers. If it's hard to do in the physical world, what makes you think it'd be easy in a browser? Everyone wants a share of the pie and that means fragmentation all the way down.
- yamtaddle 4y ago
  There are enough common elements that it's absolutely do-able. There's no reason the payment methods would have to be hardcoded or anything, they could easily be dynamic but still let the browser supply the UI for greater security, accessibility, and user confidence. Covering 99% of use-cases is far from intractable.
  - mattnewton 4y ago
    But until most of my users update I’m stuck with still maintaining the old implementation anyways. Moving these libraries into the on-demand userspace was done intentionally for a long list of reasons, but by far the biggest advantage to me as a developer is control over the updates.
- criddell 4y ago
  My credit card is stored somewhere on my iPad and the browser fills out payment forms correctly almost all the time. If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.
  - mynameisvlad 4y ago
    What does this have to do with standardized payment systems?
    - carlosjobim 4y ago
      There are standardized HTML elements for autocomplete forms, including attributes for credit cards. If you follow these on your website, it will be easier for the customer to make their purchase. Combine with Apple Pay / Google Pay and something that used to be an annoying chore is just a couple of clicks.
- joshu 4y ago
  the credit card shape, mag stripe, number, and security code ARE standardized. but every website wants you to enter that separately into a different form that autocompletes some fields but not others, etc etc. your objection is short-sighted; there are steps.
  - mynameisvlad 4y ago
    > Payment card numbers are composed of 8 to 19 digits https://en.m.wikipedia.org/wiki/Payment_card_number https://en.m.wikipedia.org/wiki/Payment_card_number They are usually 16 digits. Except when they're 15 like Amex. Security codes are 3 digits... Except when they're 4 digits like Amex. Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both. But yes, tell me more about how all these things are standardized. > your objection is short-sighted; there are steps. My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?
ericmcer 4y ago
How much of this do you think is caused by legacy browsers? If you view the browser as a general purpose OS then it makes sense the features are pretty pared down on it.
dahdum 4y ago
> One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades. Improving the web hurts app store commissions. Apple/Google can't monetize your super awesome fancy web app, but they can snipe 15-30% of your revenue through their stores.
oaiey 4y ago
There is also a layering concern here. Login is not the problem of a presentation layer. We ranted so much when Chrome added Google Login half a decade ago.
armchairhacker 4y ago
This is the Semantic Web. A big problem is that a lot of people like to do things their way. First, there will always be edge cases. What about platforms which use OAuth? What about platforms which use another third-party authentication service? Weird password requirements? 2fa? 3fa? As a result the login implementation will be bulky, making the browser even more huge and creating new CVEs. Second, even accounting for these edge cases, many websites will simply not participate. Which means that now you have 2 types of login forms: ones that use the new API and ones that don’t. And orthogonally you already have n types of login methods that are OAuth, Yubikey, Ledger, …, username/password. So, the login interface itself will also become bulky and old people will be even more confused. With that out of the way, I 100% support a unified login interface, unified sorting, unified payment, unified content embedding, etc. I still think it’s worth it to develop the Semantic Web. But, I’m not counting on Google and Mozilla to work on this. Maybe we should create a Semantic Web community and implement these systems ourselves, as JavaScript libraries with common conventions and a “Semantic Web approved” sticker. And maybe we should develop a Semantic Web browser that can intercept and implement these libraries itself, making them a fallback for traditional Web browsers. If we build up enough support eventually we’ll get new browser competition and regular browsers to start actually adopting the Semantic Web. But…that creates n + 1 different libraries/protocols that all accomplish the same thing…which is ironic considering “a big problem with the Semantic Web is that a lot of people like to do things their own way”. It could be worse: we have username/password autofill which has been around for decades so it actually works for 99% of websites.
ericmcer 4y ago
> Why no built-in sorting HTML tables, and easy hooks into them for custom sorting Because as soon as you do this <table> is no longer a layout element, now it is specifically made for displaying and sorting csv style data.
- yamtaddle 4y ago
  No true at all, just have a "sortable" flag on the th element (which is absent in most layout-focused use of <table> anyway)
mooreds 4y ago
Actually there is discussion about improving the auth experience happening at the w3c. This is driven partly out of privacy concerns. Here's one of the groups: https://www.w3.org/community/fed-id/ https://www.w3.org/community/fed-id/ Here is their meeting notes/use case flows, etc: https://github.com/fedidcg/ https://github.com/fedidcg/ > The waste of developer and user time due to the Web platform I think this is because the development is happening at a higher abstraction level (in JS frameworks, mostly). Why? Because those iterate a ton faster. Browsers are slower moving because of complexity, backwards compatibility and distribution. This is similar to the place the browser put the operating system in the 1990s and 2000s. "The Wheel of Time turns and Ages come and pass."

mynameisvlad 4y ago

> Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? I agree with your premise, but this is a bad example. Universal payment systems are not a simple task. Even remotely. Go out to any American city, for instance, and as you walk through the stores, catalog the various credit card terminals you see. Not even the PoS system as a whole, but just the credit card interface. You will see dozens of different designs and play on designs by dozens of different manufacturers. If it's hard to do in the physical world, what makes you think it'd be easy in a browser? Everyone wants a share of the pie and that means fragmentation all the way down.

yamtaddle 4y ago
There are enough common elements that it's absolutely do-able. There's no reason the payment methods would have to be hardcoded or anything, they could easily be dynamic but still let the browser supply the UI for greater security, accessibility, and user confidence. Covering 99% of use-cases is far from intractable.
- mattnewton 4y ago
  But until most of my users update I’m stuck with still maintaining the old implementation anyways. Moving these libraries into the on-demand userspace was done intentionally for a long list of reasons, but by far the biggest advantage to me as a developer is control over the updates.
criddell 4y ago
My credit card is stored somewhere on my iPad and the browser fills out payment forms correctly almost all the time. If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.
- mynameisvlad 4y ago
  What does this have to do with standardized payment systems?
  - carlosjobim 4y ago
    There are standardized HTML elements for autocomplete forms, including attributes for credit cards. If you follow these on your website, it will be easier for the customer to make their purchase. Combine with Apple Pay / Google Pay and something that used to be an annoying chore is just a couple of clicks.
joshu 4y ago
the credit card shape, mag stripe, number, and security code ARE standardized. but every website wants you to enter that separately into a different form that autocompletes some fields but not others, etc etc. your objection is short-sighted; there are steps.
- mynameisvlad 4y ago
  > Payment card numbers are composed of 8 to 19 digits https://en.m.wikipedia.org/wiki/Payment_card_number https://en.m.wikipedia.org/wiki/Payment_card_number They are usually 16 digits. Except when they're 15 like Amex. Security codes are 3 digits... Except when they're 4 digits like Amex. Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both. But yes, tell me more about how all these things are standardized. > your objection is short-sighted; there are steps. My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?

ericmcer 4y ago

How much of this do you think is caused by legacy browsers? If you view the browser as a general purpose OS then it makes sense the features are pretty pared down on it.

dahdum 4y ago

> One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades. Improving the web hurts app store commissions. Apple/Google can't monetize your super awesome fancy web app, but they can snipe 15-30% of your revenue through their stores.

oaiey 4y ago

There is also a layering concern here. Login is not the problem of a presentation layer. We ranted so much when Chrome added Google Login half a decade ago.

armchairhacker 4y ago

This is the Semantic Web. A big problem is that a lot of people like to do things their way. First, there will always be edge cases. What about platforms which use OAuth? What about platforms which use another third-party authentication service? Weird password requirements? 2fa? 3fa? As a result the login implementation will be bulky, making the browser even more huge and creating new CVEs. Second, even accounting for these edge cases, many websites will simply not participate. Which means that now you have 2 types of login forms: ones that use the new API and ones that don’t. And orthogonally you already have n types of login methods that are OAuth, Yubikey, Ledger, …, username/password. So, the login interface itself will also become bulky and old people will be even more confused. With that out of the way, I 100% support a unified login interface, unified sorting, unified payment, unified content embedding, etc. I still think it’s worth it to develop the Semantic Web. But, I’m not counting on Google and Mozilla to work on this. Maybe we should create a Semantic Web community and implement these systems ourselves, as JavaScript libraries with common conventions and a “Semantic Web approved” sticker. And maybe we should develop a Semantic Web browser that can intercept and implement these libraries itself, making them a fallback for traditional Web browsers. If we build up enough support eventually we’ll get new browser competition and regular browsers to start actually adopting the Semantic Web. But…that creates n + 1 different libraries/protocols that all accomplish the same thing…which is ironic considering “a big problem with the Semantic Web is that a lot of people like to do things their own way”. It could be worse: we have username/password autofill which has been around for decades so it actually works for 99% of websites.

ericmcer 4y ago

> Why no built-in sorting HTML tables, and easy hooks into them for custom sorting Because as soon as you do this <table> is no longer a layout element, now it is specifically made for displaying and sorting csv style data.

yamtaddle 4y ago
No true at all, just have a "sortable" flag on the th element (which is absent in most layout-focused use of <table> anyway)

mooreds 4y ago

Actually there is discussion about improving the auth experience happening at the w3c. This is driven partly out of privacy concerns. Here's one of the groups: https://www.w3.org/community/fed-id/ https://www.w3.org/community/fed-id/ Here is their meeting notes/use case flows, etc: https://github.com/fedidcg/ https://github.com/fedidcg/ > The waste of developer and user time due to the Web platform I think this is because the development is happening at a higher abstraction level (in JS frameworks, mostly). Why? Because those iterate a ton faster. Browsers are slower moving because of complexity, backwards compatibility and distribution. This is similar to the place the browser put the operating system in the 1990s and 2000s. "The Wheel of Time turns and Ages come and pass."