6 ms·

I think this is an interesting and important argument, because I always felt many shortcomings of the modern web were actually caused by browser vendors and the

I think this is an interesting and important argument, because I always felt many shortcomings of the modern web were actually caused by browser vendors and their reluctance to improve their platforms and the web. We have so many custom UI Elements, because forms did and still do suck. RSS always had a back seat, because it always was second class in browsers. Semantic web died outside of search engines, because browsers did not offer features like "Save event to my calendar". And boy, have I been promised for a long time I might someday be able to sort HTML tables by click. Just a non exhaustive list of my pet peeves, but there are many more examples.

Hello71 6y ago
not to mention certificate authentication...
recursivedoubts 6y ago
I find the projects that the W3C chooses to work on incomprehensible.
- gsnedders 6y ago
  The projects that SDOs decide to work on are those which people there are willing to spend their time on. An SDO could say "we're doing project X", but if nobody shows up…
  - recursivedoubts 6y ago
    Sure, but htmx is small (~1.7K loc[1]), written mostly by one guy part time and, while not perfect, advances HTML significantly as a hypermedia. That something like this hasn't been discussed in a significant, public manner by the w3c in over a decade[2] indicates to me there is either a lack of understanding or of interest in advancing HTML as a hypermedia. I readily admit I may be missing something. [1] - https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js#L1698 https://github.com/bigskysoftware/htmx/blob/master/src/htmx.... [2] - https://en.wikipedia.org/wiki/XHTML#XHTML_2.0 https://en.wikipedia.org/wiki/XHTML#XHTML_2.0
    - Touche 6y ago
      Advancing HTML is indeed something that the w3c members aren't super interested in. There are a few reasons for this: 1) Changes to HTML can create security issues, especially if it results in a change to the HTML parser. You have to consider that non-browser use cases still need to be able to parse HTML correctly. Since we opted to make HTML versionless with <!doctype html> it became harder to do. 2) Big changes are harder to get consensus on. This is one of the reasons why they opt to do smaller, less controversial changes. 3) w3c and whatwg are dominated by large corporations, who hire thousands of engineers to work on their web properties. They are able to overcome the shortcomings of HTML easier than small teams and single-developer websites. I agree though, this is a major problem. HTML is essentially a dead language, no major changes have been made in almost a decade.
      - deleted 6y ago
        [deleted]
      - WorldMaker 6y ago
        4) The W3C HTML spec is now mostly just a placeholder that says "Whatever WHATWG thinks is best" and it is almost but not quite true that WHATWG's Living Spec is increasingly "Whatever works in Chromium/Chrome"
        zokier 6y ago
        Well XHTML 2.0 was such a roaring success that I'm sure they'll be super stoked to take on another project to improve HTML as hypertext without the baggage of browser backing and buyin.
        WorldMaker 6y ago
        Correct, the debate over XHTML 2.0 was exactly why the WHATWG was formed. It's indeed how the W3C lost most of its teeth in browser standards. XHTML 2.0 had some good ideas, but it shows how hard it is to govern standards from ivory towers.
    - 6y ago
fardelian 6y ago
You want "Save to my calendar" but we still don't have full support for date inputs. Chrome has supported the main features since 2012, Firefox joined only in 2017, and we're still waiting on Safari to make a move. https://caniuse.com/#search=input-date https://caniuse.com/#search=input-date
- Grumbledour 6y ago
  Well, I wanted "Save to my calendar" when our self-built date inputs still opened new windows with html tables as calendars to pick a date, but I get your point and I lumped this under "forms suck". I still shudder when thinking about implementing multi-file uploads in php.
- ultrarunner 6y ago
  I have an application that is partially broken in Safari only because of the lack of support for input type="datetime-local". Very frustrating.
earthboundkid 6y ago
Forms suck, but if you actually make a form, it becomes clear that while you can do 90% of stuff declaratively, there's a leftover 10% that just has to be described imperatively, which requires something like JS. Modern forms actually give you a lot for free with pattern matching and whatnot. I could imagine it going a little further and adding properties for "dirty" or not, which right now you have to add using JS onblur listeners. Probably, the standards bodies could add in credit card field types and input masking to get things 99% of the way there. But there's still left over things like: your display name should default to being your personal name plus your family name, but also overridable. I don't see how you can create a declarative language for relationships like that without stumbling into a Turing tarpit.
- Rotten194 6y ago
  The thing is, (at least personally I feel) JavaScript isn't the problem. The problem is because of the lack of tools people have leaned into doing everything with JS, instead of trying to manage the awkward 50-50 split we had before. If 95% could be done with HTML++, then a couple form customizations and a bit of business logic being done with 100 lines of JS would make sense and not be as horrible as the modern web.

Hello71 6y ago

not to mention certificate authentication...

recursivedoubts 6y ago

I find the projects that the W3C chooses to work on incomprehensible.

gsnedders 6y ago
The projects that SDOs decide to work on are those which people there are willing to spend their time on. An SDO could say "we're doing project X", but if nobody shows up…
- recursivedoubts 6y ago
  Sure, but htmx is small (~1.7K loc[1]), written mostly by one guy part time and, while not perfect, advances HTML significantly as a hypermedia. That something like this hasn't been discussed in a significant, public manner by the w3c in over a decade[2] indicates to me there is either a lack of understanding or of interest in advancing HTML as a hypermedia. I readily admit I may be missing something. [1] - https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js#L1698 https://github.com/bigskysoftware/htmx/blob/master/src/htmx.... [2] - https://en.wikipedia.org/wiki/XHTML#XHTML_2.0 https://en.wikipedia.org/wiki/XHTML#XHTML_2.0
  - Touche 6y ago
    Advancing HTML is indeed something that the w3c members aren't super interested in. There are a few reasons for this: 1) Changes to HTML can create security issues, especially if it results in a change to the HTML parser. You have to consider that non-browser use cases still need to be able to parse HTML correctly. Since we opted to make HTML versionless with <!doctype html> it became harder to do. 2) Big changes are harder to get consensus on. This is one of the reasons why they opt to do smaller, less controversial changes. 3) w3c and whatwg are dominated by large corporations, who hire thousands of engineers to work on their web properties. They are able to overcome the shortcomings of HTML easier than small teams and single-developer websites. I agree though, this is a major problem. HTML is essentially a dead language, no major changes have been made in almost a decade.
    - deleted 6y ago
      [deleted]
    - WorldMaker 6y ago
      4) The W3C HTML spec is now mostly just a placeholder that says "Whatever WHATWG thinks is best" and it is almost but not quite true that WHATWG's Living Spec is increasingly "Whatever works in Chromium/Chrome"
      - zokier 6y ago
        Well XHTML 2.0 was such a roaring success that I'm sure they'll be super stoked to take on another project to improve HTML as hypertext without the baggage of browser backing and buyin.
        WorldMaker 6y ago
        Correct, the debate over XHTML 2.0 was exactly why the WHATWG was formed. It's indeed how the W3C lost most of its teeth in browser standards. XHTML 2.0 had some good ideas, but it shows how hard it is to govern standards from ivory towers.
  - 6y ago

fardelian 6y ago

You want "Save to my calendar" but we still don't have full support for date inputs. Chrome has supported the main features since 2012, Firefox joined only in 2017, and we're still waiting on Safari to make a move. https://caniuse.com/#search=input-date https://caniuse.com/#search=input-date

Grumbledour 6y ago
Well, I wanted "Save to my calendar" when our self-built date inputs still opened new windows with html tables as calendars to pick a date, but I get your point and I lumped this under "forms suck". I still shudder when thinking about implementing multi-file uploads in php.
ultrarunner 6y ago
I have an application that is partially broken in Safari only because of the lack of support for input type="datetime-local". Very frustrating.

earthboundkid 6y ago

Forms suck, but if you actually make a form, it becomes clear that while you can do 90% of stuff declaratively, there's a leftover 10% that just has to be described imperatively, which requires something like JS. Modern forms actually give you a lot for free with pattern matching and whatnot. I could imagine it going a little further and adding properties for "dirty" or not, which right now you have to add using JS onblur listeners. Probably, the standards bodies could add in credit card field types and input masking to get things 99% of the way there. But there's still left over things like: your display name should default to being your personal name plus your family name, but also overridable. I don't see how you can create a declarative language for relationships like that without stumbling into a Turing tarpit.

Rotten194 6y ago
The thing is, (at least personally I feel) JavaScript isn't the problem. The problem is because of the lack of tools people have leaned into doing everything with JS, instead of trying to manage the awkward 50-50 split we had before. If 95% could be done with HTML++, then a couple form customizations and a bit of business logic being done with 100 lines of JS would make sense and not be as horrible as the modern web.