DOM/Web-Observable Changes

Considerations when making web-observable changes

A web-observable change is a change in behavior that a web developer could (theoretically) run into. Examples:

• We add a new API (consider API to include HTTP headers, CSS functionality, HTML elements, JavaScript syntax, etc.).
• We remove an API.
• We change input validation and an API method now starts throwing more or less often.

Whenever we consider making such a change it’s always good to ask these questions:

• What do other browsers do? (Is there cross-browser test coverage and is it adequate enough to answer this in detail?)
• What does the standard say?
• What does the web want?
• What is good for the web?

The answers to these questions will help to determine whether to make the change. For instance, in a scenario where other browsers do X, but the standard and Gecko do Y, it’s likely that the web wants X, so typically we would change Gecko and file an issue against the standard. In certain cases, e.g., when privacy or security are involved, it might well make sense to convince other browsers to change instead or make the change together more-or-less in lockstep. This is a trade-off you will have to make with your colleagues.

ExposureGuidelines goes into more detail about communicating these kinds of changes across Mozilla and to the public.