On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote:
> > I'm surprised and disheartened that "land it and see what breaks" is
> > considered an acceptable strategy for pretty much any commit, but
> > especially for web compat.
>
> I don't think this is a realistic argument.  Basically any change we
> make to Gecko, including implementing new features, can affect Web
> compat.  We have to use judgment about which ones require measuring.
>

I agree that not everything requires measurement. I am saying that we need
a deliberate approach to risk, and that if we primarily relies on our
prerelease users to file bugs, we are not going to have any strong
guarantees of web compatibility.

Agree that this is not just for feature removals: new features may have
little risk if nobody on the web is using them. Or they may be very risky
if Chrome has deployed them and they already have traction, to the point
where web compatibility means implementing bug-for-bug compatibility with
Chrome and altering the specification.

So I want us to approach this from multiple approaches: what kinds of web
crawling automation could help mitigate webcompat risk?  What about
targeted fuzzing?


>
>
> > In this case, I understand the advantage of shipping CSS 'appearance'.
> I'm
> > less sure about what it would cost us to keep supporting -moz-appearance:
> > none, perhaps indefinitely.
>
> The cost is long-term or permanent differences between rendering
> engines, which leads to extra work for Web developers and to
> Web-compatibility problems for us.
>

And yet, that is sometimes (often?) a cost we should be prepared to bear.
The market costs of breaking almost any existing web content is so high
that we cannot afford to do it without knowing, and we should be prepared
to keep our quirks at the cost of extra engineering time and legacy support.

--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to