Browsers are part of your product

If you're on a developer team that's building a web app, you may use

• Babel to ensure the web app can target a broad range of clients
• Bundlers like webpack to include CSS vendor prefixes, modules, dependencies, static files, etc.

All of this has a perceived effect of increased developer productivity, but ultimately it is a business decision:

frontend tooling => dev productivity => added value => better UX for customers => ↑ revenue ($) && ↓ churn rate

But what happens when, despite all of this, the browser implements the same standards differently?

HTML standard vs. implementations

Earlier while I was working on a React frontend web app, I encountered a simple form having a fieldset disabled child:

const someCondition = ...
return (
  <form>
    <fieldset disabled={someCondition}>
      ...
    </fieldset>
  </form>
)

The fieldset had a bunch of a and input tags, which were disabled depending on someCondition

I was asked to change someCondition based on new requirements, which was really straightforward

I finished and began testing locally, and I noticed the form was behaving quite strange: some stuff meant to be disabled were still enabled

I checked the code many more times, but no errors were to be found...

An hour later, I called a coworker who had written some of the production code to see what was going wrong, and after some minutes, he told me:

Oh, you're using Firefox! Let's switch to Chrome and see if it works...

And it worked. Turns out the original coder had intended to use a when he needed something to be enabled under a disabled fieldset, because Chrome wouldn't disable them in contrast to button or input

The assumption here, at the very worst, is that every customer visiting here is using Chrome, which isn't so bold as it may seem, but it bugged me quite a bit...

Was it a hack or a correct use of the HTML spec?

I googled a bit to learn about disabled fieldsets, and it turns out disable prevents child form controls' events from propagating outside the fieldset

It also turns out a isn't a form control element, and it is (kind of?) left to implementation if its elements should be ignored

Some people even opened issues and posted regarding this, even though there are no known issues

IMO this should be tweaked by Firefox so that it complies with the spec in a stricter way

Conclusion, proof of concept

If a target browser has a bug, or implements HTML in a different way than others, then that becomes part of your product and is part of the frontend team decision making process...

I made a proof of concept of this, and I'll be adding any browser bugs/different implementations I find

You're invited to contribute too!