4 ms·
> Developers wrote and tested their sites for and with IE6, and were then surprised they rendered (in)correctly on Firefox and looked wrong But that's the poi
by ndriscoll 3y ago
> Developers wrote and tested their sites for and with IE6, and were then surprised they rendered (in)correctly on Firefox and looked wrong
But that's the point: rendering shouldn't really matter. For things that are important like government systems, we should treat web "apps" much like TeX encourages: you specify the semantics, and let the rendering engine do what it will. Don't try to precisely control it. You can and should assume that users can totally override rendering with a custom agent, that browsers will disagree on default rendering, and that they may ignore your CSS instructions.
Like if someone wants to use a browser that always renders h1, h2, p, etc. with specific fonts and colors, totally ignores any CSS, and adds buttons to each table column header to sort on that column, that should all just work. Or if you want to use a braille output or screen reader.
For important tools and information, not entertainment/shopping, functionality should trump all other concerns.
My bank and now my power company have issues where I need to use chromium to fill out a form, and I don't understand it. I know Firefox supports forms. For whatever reason, javascript is loading the thing and screwing up somehow. I don't see why js is even involved, but frankly it screams incompetence to me. The easiest thing in the world to build, and they've broken it trying to make it look nice.
I don't go to my power company website for fun. I'm there to pay a bill. I need a form with 5 inputs and a submit button, and that's it. The rest of the screen can be plain white for all I care. Literally something I could put together in 2 minutes when I was 11, and it does not work. Paper should not have a better UI than a website.
Incidentally, this is why I'm not too worried about AI. If companies wanted cheap/easy/reliable systems, that's been doable on the web the whole time. People can't resist making things difficult for themselves, and they'll pay very good money to do it.
- pavon 3y agoNone 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 agoYou'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.
- ndriscoll 3y agoThe 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.