You're asking government websites to run differently from 99.9% of commercial websites out there.

First of all, that's just not going to happen for all sorts of practical reasons.

But secondly, you're totally ignoring UX and design. "Specifying semantics, and let the rendering engine do what it will" might work for developers who are used to interacting with API's. It will not work for regular users.

Regular users need to understand which button is the primary action. They need to understand which part of the content is the main body, versus a sidebar versus a header. They want columns that are correctly sized for their content. They don't want to have to scroll horizontally. They want responsive design that works on mobile too. They want something that looks trustworthy and familiar.

Websites are apps now. Asking to go back from presentation to semantics is like asking people to use the command line instead of GUI's. It's not going to happen, nor should it, because it's not user-friendly.

The only people it's friendly to are a niche set of developers with certain ideological beliefs that most web technologies shouldn't be used.

The things you describe aren't prevented by focusing on semantics, and are in fact enabled by it. Every modern app looks different for branding purposes, so users don't know what the buttons do. Things are complicated because we abandoned standard UIs that used to use the same widgets across every application.

And government stuff should work differently from 99.9% of commercial websites. Again, the goal should be for it to work. The government does not need to do marketing and make you feel like they are trustworthy. If you want to interact with social security, you go to ssa.gov. If you want to interact with the IRS, you go to irs.gov. End of story. They don't need to act like commercial entities because they do not have to worry about market share. Their share is always 100%. They need to just make their stuff reliably work, easy to figure out, and should make it cheap and easy to build. Basic HTML with minimal optional styles checks all of those boxes.

If you view the computer as a tool instead of a toy, you see that you really just need most websites to be a more convenient version of paper forms. It doesn't need to look fancy. It needs some boxes to type information, it needs to always work, and ideally every form on every website would stick to the same 5 or so types of input (rendered consistently by your OS) with no surprises. Government sites should take the tool approach. Commercial sites can sell toys.

> so users don't know what the buttons do.

They do, though. People are able to figure out commercial websites orders of magnitude more easily than figuring out how to fill out their 1040.

> They need to just make their stuff reliably work

Which is what UX and design help with.

> Basic HTML with minimal optional styles checks all of those boxes.

It doesn't. Layout and design are tools that help with clarify and ease-of-use.

> you see that you really just need most websites to be a more convenient version of paper forms.

Nothing could be farther from the truth.

Do you similarly think that your iPhone or desktop interface would be improved if the UX was "a more convenient version of paper forms"?

Paper forms are an extremely limiting form of UX. Why would you ever want to throw out all of the progress we've made with usability?

Filling out your 1040 is "hard" because people don't understand what the words mean, there's a 100 page instruction manual that defines the terms, and it might require filling out other forms too (which you might just need to know somehow that you need to fill them out too). Other than that, the actual UI design is straightforward. You write/type numbers into numbered boxes, top to bottom, occasionally referring back to numbers you've already completed. You could progressively enhance with automatic calculations for relevant fields, but hand calculations work as a fallback.

Reliability is unrelated from UI, except insofar as simple UIs are easy to build, and therefore less likely to break. A paper form 1040 is perfectly reliable; it's not going to burst into flames when you're filling it out. As I said above, I couldn't even fill out my payment form on a modern site. It did not work at all. The form did not appear. That is not reliable. It also makes no sense if you know the page is ultimately using HTML, and that HTML has forms built directly in, and they always work fine.

And yeah, when I'm doing something like making a payment, setting up a transfer, doing my taxes, or even ordering a pizza, something like a slightly advanced paper form (e.g. with drop downs for options) would work great on my phone or desktop. Have a special request for your pizza that's not on the form? Put it in the free-form instructions box.

The "progress" we've made in the last few years is that I can't do bank transfers without switching browsers, which requires selecting a "to" account from a drop-down, a "from" account from a drop-down, and typing an amount. I don't see how something so basic can be so hard to do correctly. There's literally no need for any javascript at all. I don't see the usability gain from whatever they're doing.

> It needs some boxes to type information

Would an address lookup service be acceptable? One of those where you start typing your address into a box and it fills in all of the address fields based on which address you select.

If a new version of this is created, shouldn't it be tested on browsers? Which browsers should it be tested on?

We could simple put an input for each part of the address and let the user fill it out.

Requires exactly zero lines of javascript, no third party api that may or may not work.

None of that negates the need to test on various browsers to ensure compatibility.

What compatibility? If Firefox breaks forms, then Firefox broke forms and needs to fix it. Not your bug. If Chrome renders differently from edge because they decided the default color on .gov sites will be pink on white and all padding will be multiplied by 1.5, then that's fine. Not a bug. Chrome just decided to present a different look.

If it's even possible for basic functionality to break in a way where you wouldn't obviously say the browser is broken, then you've built it wrong. That means you need to test that TLS/HTTP protocols are implemented correctly and that your documents conform to a schema.

You are assuming that your developers were perfect and write sites exactly to the standard every time. In the real world they don't and XHTML lost, so all browsers tolerate and mask non-compliant pages to various degrees and in various ways, and will surface different bugs in your work. So it behooves you to test with the browsers your users are using to find those bugs before they do.

I am assuming that a professional can do their job, yes.

The whole XHTML thing where allegedly it never caught on because people can't write valid markup has never made sense to me. They're able to get typescript to compile now, right? If a dev couldn't write react code that compiles, we would fire them, right?

We have tools to check that your document parses and conforms a schema. We've had them for 20 years. It's easy enough to have that be part of your CI pipeline. The tooling is 1000x simpler than modern frameworks, and the thing that was allegedly difficult was that if you enabled conformance mode (which was opt-in based on DTD and/or MIME type), you had to open and close your tags instead of just opening them. Surely any middle schooler understands when you open a parenthesis, you need to close it?

US government websites, as they exist, are often ancient, decrepit, and poorly funded. This will make them all worse and it will cost more. It will get in the way of people actually trying to interact with the government, and the leaders in the government will crap all over the project due to the angry calls they'll get from their constituents.

If we try to stick to pure ideals without any consideration for reality, reality will ignore us and move on. Or, to borrow an example from another field: in infosec, the most secure computer is the one that's never turned on.

They're not decrepit; they're unfashionable. Programs and websites that were somewhat decently written 20 years ago should and pretty much do run exactly the same today as they did then. It's not until "web 2.0" and SaaS that you find things that stop working after a few years/months.

That's exactly what you need for "poorly funded" sites, and I don't see why a site that's meant to be functional needs a Hollywood budget.

> then Firefox broke forms and needs to fix it. Not your bug.

Not in the real world. In the real world, you've delivered a site that doesn't work and contractually, you can be sued or not paid for not fulfilling your contract.

That's the whole point of a standard (note that I said for .gov): the government says what standard they interop with. They either conform or don't. If other implementations don't conform, they are wrong. If the site doesn't conform, it is wrong. If it's not in scope for the standard (e.g. layout/font), it's out of scope. If the standard is underspecified or wrong somehow, you fix that and .gov now targets the new revision.

The government doesn't need to worry about market share. They can just dictate that this is what your browser needs to do to work with government systems. This is both more fair and easier for everyone; you don't have a moving target to aim for, and can just refer to the standard for what to do.

But government don't exist to serve standards.

Governments exist to serve their citizens -- their users.

It's extremely user/citizen-hostile to say, "well our site works but no commercial browsers do, so I guess you can't register for a health plan this year over the web."

And I don't know about you, but I sure don't want the government building its own standards-based browser required for accessing government websites...

The government should set or adopt standards, not serve them. And they can and should provide a reference implementation.

We could easily and reliably do forms on mainframes. This is not complicated. And de facto, every browser supports HTML 4 forms anyway, so that's a non-concern.

They already set standards for things like needing to support TLS 1.3 with specific cipher suites. There's no reason they can't say HTML 4 forms and links are required for browsers to work on their sites.

No -- I don't want the US government (or any other) involved in setting web standards. The W3C is not going to be helped by being run by governments instead.

No -- I don't want the US government providing a reference implementation of web browsers.

No -- I don't want to log into a mainframe computer to fill out my taxes or sign up for Medicaid or a health plan.

The government should simply build services that work, in practical ways that are familiar and friendly to their citizens, according to the tools and habits their citizens are already accustomed to.

That means websites and apps for popular OS'es and browsers. It means phone numbers that work with existing telephones. It means offices in population centers.

Good governments come to where users/citizens already are. The shouldn't make users/citizens jump through hurdles to come to it, any more than necessary.

Like I said, the US government should just adopt the existing W3C standard.

It's crazy to me that 10 years ago people were against the standard for government documents being essentially "whatever Microsoft office does", but in 2023, we've decided it makes sense for the standard for government web sites to be "whatever Chrome and Safari do".

And as I've pointed out, for historical reasons, we already have an adequate standard that the major browsers already support. So just target that standard. It happens that this is also the cheapest, simplest, most reliable way to do things anyway.

But you're saying that the government should create websites according to those standards, and if it breaks in Chrome or Safari, the government shouldn't test and fix it. Rather, the browsers should fix it.

That's a position I just can't get behind. These are all just tools. The point isn't to follow some ideology, the point is to function.

And no, the government shouldn't formally "adopt" any specific W3C standard either, because standards evolve, and we don't want the government to get stuck in time. It should just write and maintain websites that work.

This isn't complicated. Businesses all seem to manage it just fine. The government doesn't need to do it any differently.

If a browser breaks forms somehow, then yeah I don't think it's reasonable for anyone to try to fix their website to somehow work (if it's even possible). Same as if they break links, or TLS, or HTTP. The government should just say "chrome 287 doesn't work".

The "evolving" standards of browsers mostly add a bunch of useless toys that create security vulnerabilities. There's no reason for serious sites to target them. The old standards do everything you need to quickly and easily make a functional tool that will require no maintenance for years or decades, which is exactly what you want from tools.

Testing on target platforms is an inherent part of shipping production software.

Not if you're targeting a standard.

I worked on fibre channel networks at IBM. They were all about high touch customer service, and had great data gathering and would debug issues that ultimately were caused by some other vendor breaking the standard. After proving we were doing the right thing, our answer would always be to tell the customer to turn off the broken feature on their other vendor's device (other vendors would do things like inject fake ACKs for large transfers to reduce latency ("acceleration"), which is kind of a no-no in reliable networks. We lowered latency in a standard compliant way by using multiple concurrent exchanges that we put together at the application level).

We did test with some other vendors, but IIRC only at a fairly basic level, and didn't support any of their non-standard behavior. We just used them to validate our own compliance to standards.

To clarify, I think it would be very bad if the government merely "targeted a standard" and did not test its websites on various browsers. I would consider it irresponsible professional behavior.