Re: [whatwg] Supporting feature tests of untestable features

On 02/04/15 09:36, Simon Pieters wrote:

> I think we should not design a new API to test for features that should
> already be testable but aren't because of browser bugs. Many in that
> list are due to browser bugs. All points under "HTML5" are browser bugs
> AFAICT. Audio/video lists some inconsistencies (bugs) where it makes
> more sense to fix the inconsistency than to spend the time implementing
> an API that allows you to test for the inconsistency.

[...]

> A good way to avoid bugs is with test suites. We have web-platform-tests
> for cross-browser tests.

Yes, this.

The right way to avoid having to detect bugs is for those bugs to not
exist. Reducing implementation differences is a critical part of making
the web platform an attractive target to develop for, just like adding
features and improving performance.

Web developers who care about the future of the platform can make a huge
difference by engaging with this process. In particular libraries like
Modernizr should be encouraged to adopt a process in which they submit
web-platform tests for each interoperability issue they find, and report
the bugs to browser vendors with a link to the test. This means both
that existing buggy implementations are likely to be fixed — because a
bug report with a test and an impact on a real product are the best,
highest priority, kind — and are likely to be avoided in future
implementations of the feature.

I really think it's important to change the culture here so that people
understand that they have the ability to directly effect change on the
web-platform, and not just through standards bodies, rather than
regarding it as something out of their control that must be endured.

Received on Thursday, 2 April 2015 15:40:40 UTC