Hacker News Reader

Comment by Grumbledour | Hacker News Reader

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.

View on HN

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.

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.

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

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.

I have an application that is partially broken in Safari only because of the lack of support for input type="datetime-local". Very frustrating.

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

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…

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....

[2] - https://en.wikipedia.org/wiki/XHTML#XHTML_2.0

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.

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"

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.

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.

What you seem to fail to recognize is that the reason nothing has been discussed (whether of the style you want or otherwise) at W3C regarding advancing HTML since XHTML2 is that the colossal failure of the “we’ll right a from-first-principles spec with no concern for pragmatics” approach with XHTML2 resulted in W3C being completely sidelined for HTML development. No one is listening to them, the browser vendors all work through WHATWG and that's where everything that matters happens.

W3C isn't interested in advancing HTML as anything and, even if they were, they'd be screaming into the night because none of the people who build browsers are interested in what they have to say. They’ve got their own club, and that's where HTML happens (and WHATWG and the browser vendors don't seem to be interested in pushing functionality into HTML in any big way, they are happy with the basic shape of the existing HTML/CS/JS trinity and don't see a big need to push for standalone HTML as a platform.)

XHTML was not that bad. It was quite conservative - make serialization/deserialization idempotent, remove document.write, quirks mode, DOM Level 0 accessors.

The stupid part was advertising of writing XML by hand - both XHTML and XSLT. That is machine format - "application" in "application/xml". Not more sense than writing JS AST. And semantic web has no advantage for author.

XHTML 2.0 - XML Events is like IE <script for>, <img>alt</img> is good, <h> is good, removal of <i>, <b> - no one would see, XForms - partly adopted, and RDF - don't know.

Though it kind of understandable - XML was in rage. Everyone pushed it, Microsoft above all, IE5 accepted "text/xml" [1]. And Microsoft pushed XSLT without XSL-FO.

[1] https://www.xml.com/pub/a/1999/03/ie5/first-x.html

thank you for clarifying

i knew there was some drama betweeen the two organziations but didn't know the history

not to mention certificate authentication...

Reply on news.ycombinator.com