Re: scroll anchoring

On Sat, Dec 3, 2016 at 10:44 PM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On Dec 3, 2016, at 07:27, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>
> Rick already responded (in a way that breaks threading in my client
> > and possibly others, so here's the link
> > <https://lists.w3.org/Archives/Public/www-style/2016Dec/0011.html>).


Sorry about that.  Let's use this thread for the specific question around
scroll anchoring and the other for a more general meta-debate (if we dare
attempt that on www-style)?

> * the spec was pulled into Steve's personal repo just as a temporary
> > measure to isolate it from the WICG/interventions repo, with the
> > intent that it be quickly transferred to its own WICG repo.  The
> > request for a WICG repo was made on Oct 10 (same day as it was
> > extracted), but nothing ever happened.  I pinged the WICG chairs, and
> > it turns out it was just missed - Chris says he accidentally dropped
> > it due to the chaos of prepping for Chrome Dev Summit at the time.
> > That's being fixed now, and it'll be transferred to WICG shortly.
>
>
> Let's leave aside the discussion of whether *starting* a spec outside of
> the CSSWG is a good idea, as this will take us a while to agree on that,
> and it's irrelevant for this spec which has already been started... We'll
> talk through that some other day, preferably in a more cozy setting than a
> mailing list.
>
> Since you're now at the point where you're about to ship it in production
> without flag, isn't that a good point to graduate from incubation, and go
> into a CSSWG ED/FPWD?
>

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.

I think where we fundamentally disagree is that adding ~6 months for some
additional review would ultimately result in a better API than using those
same 6 months to gain experience in the wild (potentially with 4 different
iterations on the design) which can then inform standardization efforts to
help ensure we're actually standardizing the right thing (or even solving a
problem that's worth solving).  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.  The "CR first
then ship" makes it MUCH more expensive to fail and almost impossible to
iterate wrt. the reality of web compat in any reasonable timeframe).  We
know we're going to fail at API design often (to assume otherwise is pure
hubris unsupported by history IMHO).  Incubation+predictability is about
minimizing the cost and damage to the ecosystem of our inevitable failures.

As one of the creators of TCP/IP said
<https://twitter.com/RickByers/status/794517570531389440>: "Standards
should be discovered, not decreed. Seldom has it worked any other way".  In
the CR-then-ship model, we'd all be using the 7-layer ISO network stack
instead of TCP/IP :-)

That said, I'm not trying to argue here that the CSS WG should change it's
policy on such things.  If a WG wants to have the work it promotes governed
by a "CR before ship unless an exception is officially granted" policy,
that seems fine to me (certainly shipping motion-path in blink was probably
a mistake thanks to the multiple rounds of renames
<https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/motion-path/blink-dev/o1C5NzGf9Q0/sbaLF1MbAgAJ>).
But I don't consider the CSS WG to have a monopoly on standardization of
all features that happen to involve a CSS property (eg. touch-action
<https://w3c.github.io/pointerevents/#the-touch-action-css-property>), and
believe that competition between standards groups is essential to a healthy
platform.

—Florian
>