Re: scroll anchoring

Sorry for the delay.

On Thu, Dec 8, 2016 at 3:48 PM, Alan Stearns <stearns@adobe.com> wrote:

> On 12/5/16, 2:48 PM, "Rick Byers" <rbyers@chromium.org> wrote:
>
>
> >
> >No, we don't believe so.  In this case I believe what the feature needs
> most is real-world experience with web compat.  Basically the entire scroll
> anchoring feature is designed around the constraints of web compat, and the
> only way we'll know for sure
> > whether it's really the right trade off is to try shipping it and
> iterate based on what we learn from the bugs that get filed.
>
> In some cases, you have been shipping experimental features behind a flag.
> What’s different about this feature that prohibits that approach?
>

Shipping behind a flag provides only limited data on web compat (because
few users/developers will turn on the flag, and those that do are less
likely to file bugs that reproduce only when the flag is on).  We've done
that already since April, evangelizing it's use and gathering site compat
feedback
<https://developers.google.com/web/updates/2016/04/scroll-anchoring>, which
the team used to overhaul and further tweak the design for maximum compat.
But we've learned from experience that the only way to truly know whether a
risky change is actually shippable is to attempt to ship it.  We won't have
high confidence that this design is an acceptable trade-off until it's been
in Chrome stable for at least a month.

>One good outcome here would be if we shipped this, found it helped a
> little but not so much that any other
> > browser decided to ship it too.  Then, after some time we'd probably
> have to admit the feature had failed to become part of the web platform
> (benefit in practice wasn't worth the complexity cost) and remove it.
>
> That would be fine, I agree.
>
> But we need to consider bad outcomes as well. Perhaps you’ll get stuck on
> a particular iteration because enough content has already started relying
> on it, and you won’t be able to make a change that you’ve discovered would
> make the feature much better.
>

In general that's definitely a risk we worry a lot about (discussed as
"interop risk" in our intent to ship process).  In this case we decided
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/VJmxBRYGVIE>
that
the benefit of shipping at this stage outweighed the risk.

In particular we feel the risk is low because all of the complexity of the
feature is in the anchoring algorithm details which are already a tradeoff
between web compat and user experience which we can continue to refine.

The main interop risk is in the (comparatively trivial) property name and
precise semantics for the opt-out API (overflow-anchor). We expect usage of
this api to be for rare exception (otherwise we couldn't ship the feature
in the first place).  If other implementors become interested in this
feature and consensus emerges that this API should change, we're confident
that we can ship the new API and (over a period of a few months) deprecate
and remove our existing one.  As always our willingness to accept compat
risk is much higher when we're changing something blink-specific and
gaining interop in exchange for the compat cost.

I’d like to see more replies from other browsers about shipping this
> feature now. I see dbaron has been interested in solving this problem, but
> I do not see where he’s commented on this particular approach.
>

So would we.  Fundamentally I see the main problem here as nobody else
being particularly interested in investing in this space.  I feel the only
practical way to determine whether a feature is worthy of investment across
the web platform is to let the market decide: it's shipped somewhere and
either users/developers love it (placing pressure on other implementors to
implement and collaborate on improving the specification), or they
ultimately don't (placing pressure on us to remove a failed feature).  It
would be irresponsible of us to try to "force" other implementors to care
(eg. by costing CSSWG member companies ~$5000/hr discussing in detail in a
call/f2f meeting) before we have hard data from users and developers
backing up our claim (and even then, it wouldn't be worth much without the
larger investment of actually attempting to ship an implementation).

Thanks,
>
> Alan
>