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

[Yoav Weiss]

On Fri, Oct 25, 2019 at 4:04 AM 'Maciej Stachowiak' via blink-dev <
blink-dev at chromium.org> wrote:

>
>
> > On Oct 24, 2019, at 1:49 PM, fantasai <fantasai.lists at 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.
>
> I don’t think anyone at Apple was asked to provide a position. It’s true
> this spec has been out there for a while, but there’s so many specs these
> days that it’s hard to predict which will be up for an Intent to Ship next.
>
> I often see links to an Intent to Ship or Intent to Implement where Safari
> is noted as “no public signals” or “no signals” but no one actually asked
> us. Sometimes I even see this stated when we clearly said somewhere
> (perhaps in an issue comment) that we think the feature is a bad idea, at
> least as proposed.
>
> So on the whole, I don’t think Chrome engineers do as good a job as they
> could of actively soliciting signals. Members of the WebKit team at Apple
> are usually happy to provide an opinion if asked, or at least point to
> someone who can give an informed opinion. We also make sure to sync
> internally on things like this, to be able to give relatively official
> opinions.
>

What would be the best way to solicit such feedback in a scalable way? No
all engineers sending intents personally know someone on the WebKit team to
ask for their opinion.
Would opening an issue on WebKit's bugzilla be the right way to get such an
opinion?


>
> It’s possible that this is a Blink process problem, and that maybe “no
> signals” should be accompanied by a record of the lack of signal and/or
> attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s
> the intention of the signals section.
>
> (This is not an opinion on the specific spec; it seems like a generally
> good feature, but the fragment directive syntax and requirement for UAs to
> strip it seems bound to cause interop problems with browsers that don’t
> implement this spec.)
>
>
> >
> > 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.
>
> It’s especially concerning that WICG does not require either multiple
> implementation experience (like W3C WGs do) or multiple implementor support
> (like WHATWG does). As a result, single-implementation specifications with
> no track to multi-engine implementation look exactly the same as incubation
> projects with multi-implementor support. In addition, because WICG requires
> “multiple party” (but not multiple implementation) support, sometimes we
> end up with specs using the WICG “Community Group Draft Report” logo while
> in an individual’s personal repo rather than in WICG.
>
>
There's ongoing discussion <https://github.com/w3c/tr-design/pull/177> on
making the CG templates look less authoritative. Once that lands, it will
hopefully make it clear that specifications on WICG are in no way a
standard.
Requiring multiple implementations for an incubation would defy the purpose
of incubations. The "barrier for entry" to getting a WICG repo is proving
that you have a use-case that's interesting to solve, not that you have an
well-thought-out solution. That comes later, as part of the incubation work.
And even incubations that are being worked on by multiple implementers
should not look authoritative at first, as presumably they are still in
flux. At the point where a multi-implementer incubation is stable, it
should probably graduate to the appropriate WG.

Regarding personal specifications with a "CG draft report" logo, that
sounds like a bug. Could you point me to such examples?
Maybe we can improve the tooling to make sure that doesn't happen.


I think these are process problems with WICG.
>
> (Note, I’m not commenting on whether this CG report would never have
> multiple implementations).
>
> >
> > 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.
>
> For clarity, WHATWG rules do not require implementation commitments for a
> feature addition, just nonbonding “support”:
> https://whatwg.org/working-mode#additions
>
> So the situation you describe would be more than enough.
>
> In principle WHATWG process could be changed to require a statement of
> support from only a single implementation. But I think that would be a
> change for the worse, and I’d likely oppose it if proposed.
>
> >
> > 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
> >
>
> --
> 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 at chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/989C4174-E645-4547-AE07-F52AF1A66F6D%40apple.com
> .
>