5 ms·
None of that negates the need to test on various browsers to ensure compatibility.
by pavon 3y ago
None of that negates the need to test on various browsers to ensure compatibility.
- ndriscoll 3y agoWhat 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.
- crazygringo 3y ago> 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.
- ndriscoll 3y agoThat'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.
- crazygringo 3y agoBut 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...
- ndriscoll 3y agoThe 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.
- crazygringo 3y agoNo -- 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.
- ndriscoll 3y agoLike 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.
- pavon 3y agoYou 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.
- ndriscoll 3y agoI 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?
- deleted 3y ago[deleted]
- sunshowers 3y agoTesting on target platforms is an inherent part of shipping production software.
- ndriscoll 3y agoNot 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.
- sunshowers 3y agoTo 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.
- NegativeK 3y agoUS 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.
- ndriscoll 3y agoThey'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.