Turn a browser failure into a testable Interop proposal
A useful Interop proposal connects a product failure to a stable platform gap. Tests strengthen the case while vendor objections and selection still matter.
By 
Paul. Architecture and infrastructure
A browser compatibility complaint becomes more useful when another engineer can identify the platform behavior at issue and the test that would demonstrate agreement. The useful Interop proposal starts with a concrete product failure and narrows it into a stable, testable gap. A broad wish for browsers to behave better leaves too much of the engineering question unanswered.
The September 3, 2026 call for Interop 2027 proposals made the entry conditions explicit: a stable specification, no outstanding browser-vendor objections and a sufficient test suite. It described prior implementation in at least one browser as typical of past selections. These distinctions matter. Historical precedent and a requirement should not quietly become the same rule.
Begin with the product consequence
A product team should first explain what the compatibility problem prevents someone from doing. That statement gives the investigation a purpose. It also separates an inconvenience in the codebase from a failure in the user's task. Both can merit attention, but a proposal becomes easier to assess when it says which consequence is actually at stake.
Next, narrow the claim. “This feature is missing” may hide a difference in one operation, a disputed interpretation or an application assumption. The proposal needs a behavior small enough to compare against the specification. That does not make the product impact small. It makes the technical claim precise enough for someone else to challenge or confirm.
Keep those two levels connected. A minimal case that omits the behavior causing the product failure would be tidy but irrelevant. A complete application that leaves every dependency in place may be difficult to interpret. The useful reduction preserves the causal link while removing unrelated complexity. Its purpose is to explain what needs to agree across implementations.
Define success before advocating priority
The proposal call explains that success is measured through browsers passing the relevant tests. That makes test coverage part of the substance of a proposal. A persuasive description of developer pain cannot substitute for a way to tell whether the proposed area has improved.
For a technical leader, this suggests an ordering of work. Establish the expected behavior and the evidence that would distinguish success from failure. Then explain why the difference matters to a product. Advocacy becomes stronger when its importance and its verification refer to the same behavior. Otherwise, a large promise can rest on a test that covers only a small, unrelated corner.
The test boundary should remain visible in the proposal. Agreement on a narrow case does not establish complete compatibility for every use of a feature. Describe what the tests cover and what remains outside them. A limited, defensible claim gives implementers something they can evaluate without asking them to accept a wider conclusion on trust.
A workaround is a lead for investigation
Later, on September 18, web.dev published coding-agent discovery guidance. It suggested examining workarounds and matching candidate gaps to proposals. It also stated that proposals must be written by humans. This later article is useful hindsight about discovery assistance. It does not establish that its guidance was available when the September 3 call opened.
The engineering inference is bounded. A workaround can identify a place worth inspecting, but its presence does not prove a browser defect or an Interop candidate. The code may preserve behavior needed by older supported environments, or it may address an application concern. Someone still has to explain the link from the workaround to a stable platform behavior.
An estimate of removable code deserves the same restraint. Removing a wrapper is only useful if the product can still meet its supported behavior. The proposal should explain the dependency that prevents removal. Counting lines without that explanation would measure an implementation detail while leaving the compatibility claim unresolved.
This article makes no claim to have run an agent audit or reproduced a browser issue. The point is how a team should assess candidate evidence before treating it as a proposal. Discovery produces leads; a defensible compatibility claim requires technical judgment about those leads.
Tests cannot settle every objection
The strongest counterargument is that a well-tested request can still fail selection. Tests do not resolve an outstanding vendor objection, establish standards consensus or guarantee implementation capacity. A testable disagreement can remain a disagreement. Treating proposal quality as a promise of acceptance would erase the selection process itself.
That limit strengthens the case for being specific. A proposal with an unresolved prerequisite should name it. If the expected behavior is still under debate, the immediate work may belong in the standards discussion. If the behavior is stable but coverage is weak, improving the evidence has a clearer purpose. These situations call for different next steps even when the product pain is similar.
The product's own plans need a separate decision. An Interop proposal should not become a delivery dependency merely because it has been submitted. Until the relevant compatibility is established for the environments the product supports, the team still owns its fallback and support policy. Participation in a coordination process cannot transfer that responsibility to browser vendors.
For software maintenance, keep a compatibility issue tied to its product consequence, expected platform behavior and evidence boundary. That record can support a useful proposal and guide the application's own choices. Selection remains uncertain; the quality of the technical claim is something the team can improve directly.