6 ms·

> It should support a standard like HTML 4 with no CSS or JS required. i.e. make the actual functionality on their sites simple to reduce the chance it doesn't

> It should support a standard like HTML 4 with no CSS or JS required. i.e. make the actual functionality on their sites simple to reduce the chance it doesn't work somewhere. You're right of course. It's not really a case of 'supporting' browsers, it's a case of testing their sites against other browsers in case developers have accidentally written some non-portable Chrome only code. This was very much the case in the IE6 era. Developers wrote and tested their sites for and with IE6, and were then surprised they rendered (in)correctly on Firefox and looked wrong. At least these days there are shim libraries, rather than having to explicitly rely on things like the box-model hack.

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 ago
  None of that negates the need to test on various browsers to ensure compatibility.
  - ndriscoll 3y ago
    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.
    - 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 ago
        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.
        3y ago
crazygringo 3y ago
Exactly this -- it's about testing and ensuring something works. And no matter how "standardized" things get, there are always going to be implementation differences (whether due to mistakes or underspecified specs or partial implementation) and also just straight-up bugs between browsers.
stcredzero 3y ago
At least these days there are shim libraries, rather than having to explicitly rely on things like the box-model hack. Are people actually now using the older term, "shim," and not the newer "polyfill?" I was a grumpy old man when people started to tout the new terminology, when there were perfectly good terms already.

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 ago
None of that negates the need to test on various browsers to ensure compatibility.
- ndriscoll 3y ago
  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.
  - 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 ago
      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.
      - 3y ago

crazygringo 3y ago

Exactly this -- it's about testing and ensuring something works. And no matter how "standardized" things get, there are always going to be implementation differences (whether due to mistakes or underspecified specs or partial implementation) and also just straight-up bugs between browsers.

stcredzero 3y ago

At least these days there are shim libraries, rather than having to explicitly rely on things like the box-model hack. Are people actually now using the older term, "shim," and not the newer "polyfill?" I was a grumpy old man when people started to tout the new terminology, when there were perfectly good terms already.