Re: [whatwg] [blink-dev] Intent to Ship: Scroll To Text Fragment

On Thu, Oct 24, 2019 at 10:49 PM fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 10/9/19 8:10 PM, Nick Burris wrote:
> >
> > Summary
> >
> > Scroll To Text allows URLs to link to a piece of text in a webpage
> rather than
> > just linking to an existing element fragment. The motivating use cases
> are to
> > enable user sharing of specific content and allow deep-linking
> references to
> > information.
>
> So, like, this sounds conceptually like a great feature to have for the
> Web.
> But this
>
> > Edge: No signals
> >
> > Firefox: No signals <
> https://github.com/mozilla/standards-positions/issues/194>
> >
> > Safari: No signals
>
> makes it seem like you really haven't put much effort into figuring out
> where
> the other browser vendors stand on the issue. Given this is an Intent to
> Ship,
> I interpret not having figured out where the other vendors stand even at
> the
> coarse level of “excited to have spec, plan to implement”, “supportive but
> not
> prioritizing; will accept patches”, or “opposed to the feature in its
> current
> state” as not really caring what they think. You have contacts into these
> organizations; I am sure you could solicit such answers where there aren't
> any
> if you thought it was necessary.


> Google engineers keep asserting that, no, we really care about
> standardization
> and moving the Web forward together with the other browser vendors. Look
> at
> the processes we made to help us do that! But Web standardization efforts
> have
> always tried to move forward on the basis of consensus. Meanwhile the
> attitude
> here seems to be ”There was a template for the positions of other
> browsers, a
> blank answer could be provided in the template, nobody reviewing it cares
> that
> there was a blank answer, so let's just ship the thing we (Google) want.”
>
> If this was a blank code review in your template, I imagine you would try
> harder to get the reviewer's answer, and give a good explanation of your
> attempts and their failure if indeed you could not solicit a response,
> before
> asking for lgtm.
>

If you look at the linked TAG review issue
<https://github.com/w3ctag/design-reviews/issues/392>, you could see that
we have solicited and got opinions from various engineers working for said
browser vendors. (and addressed multiple concerns raised)
However, at least when it comes to Mozilla, my understanding is that
opinions of their engineers don't count for the purpose of stating
support, *unless
expressed on their standards positions repo alongside an official
commitment*.
An issue <https://github.com/mozilla/standards-positions/issues/194> was
opened on that repo almost three months ago, trying to solicit their
opinions and commitment. We have received zero replies on that issue.
If you have any suggestions as to what we could have better done on that
front, we'd definitely take them into consideration for next time.


>
> Yoav Weiss wrote:
>
> > When it comes to venue, the current spec's processing seems to be mostly
> > monkey-patching the HTML and URL specs, indicating that WHATWG is
> probably
> > the right venue for this to graduate to. At the same time, landing
> features
> > in WHATWG specs require multi-engine commitment, and looking at
> Mozilla's
> > 2.5-months-old standards position issue doesn't really indicate
> implementer
> > commitment, or anything at all. From a practical standpoint, it's
> clearer
> > and easier for the spec to live as a standalone document rather than a
> > WHATWG PR, while we're waiting for multi-engine commitment.
> >
> > But, that in no means preclude collaboration. The spec is in WICG, which
> > was built specifically to enable multi-vendor collaboration when
> incubating
> > new ideas. I'm sure everyone would be thrilled to have your feedback
> directly
> > there, to make sure we get this right.
>
> I would like to point out a couple things:
>
> 1. WICG is explicitly billing itself an incubation venue, not a
> standardization venue. At the point you're planning to ship a feature, I
> think
> that qualifies as beyond incubation, yes? So continuing work there at this
> point would be inappropriate.
>

The WICG is indeed not a standardization venue, and once we have support
from other vendors, we should definitely move the specification to one. But
as can be noted reading through the Blink interoperability principles
document
<https://docs.google.com/document/d/1romO1kHzpcwTwPsCzrkNWlh0bBXBwHfUsCt98-CNzkY/edit#heading=h.t71a2ioil8j0>,
"being on a standards track" is not a shipping requirement for a feature.
We aren't always going to wait until Mozilla and/or Apple are officially in
favor of the feature before we ship it. At the same time, one lesson we can
take from this is that when other browsers haven't come to an official
position at all, we should do a better job of capturing the outreach we've
attempted.


>
> 2. If the WHATWG rules for incorporating something are too stringent to
> allow
> standardization in a timely manner, maybe you should consider changing
> them?
> It's not like Google has no say in the WHATWG process. Perhaps something
> like
> “two implementation commitments *or* implemented in one browser with other
> browsers at least in favor of the feature and willing to implement it at
> some
> point in the future even if they haven't committed to apply their own
> resources yet” could be enough for inclusion.
>

Such a rule would still not have helped in this particular case, where we
have no official signal from other vendors that can qualify as "in favor".


>
> To paraphrase Sir Tim Berners-Lee, process is a tool to help you do good
> work:
> if your process is inhibiting you from doing said work, you should fix
> said
> process. Allowing Google to do standardization work in an appropriate
> multi-vendor standards forum, and using that process to seek positive
> consensus on its proposals prior to deciding to ship, would be better than
> the
> circumvention of the standardization processes *and spirit* being
> demonstrated
> here, I would think.
>

I strongly reject your accusation that working in the open (for the last 9
months
<https://discourse.wicg.io/t/proposal-allow-scrolling-to-a-specified-text-snippet-in-a-navigation/3442>)
and actively seeking out feedback from the web community at large and from
other vendors in particular is somehow "circumventing the standardization
processes and spirit"!


> ~fantasai
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscribe@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aea912b9-01c6-e518-7abe-4478d3354348%40inkedblade.net
> .
>

Received on Thursday, 24 October 2019 22:30:00 UTC