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.
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.
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.
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.
~fantasai
