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

# fantasai (4 days ago)

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 mozilla/standards-positions#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

Contact us to advertise here
# Yoav Weiss (4 days ago)

On Thu, Oct 24, 2019 at 10: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.

If you look at the linked TAG review issue w3ctag/design-reviews#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 mozilla/standards-positions#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 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.

  1. 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 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"!

# Anne van Kesteren (4 days ago)

On Fri, Oct 25, 2019 at 10:59 AM 'David Bokan' via blink-dev

<blink-dev at chromium.org> wrote:

The kind of feedback we received here would have been wonderful to have several weeks ago. What should we be doing to get to this step earlier?

For WHATWG, PRs against standards tend to help as they require review, implementer commitments, and adequate test coverage. And editors will provide guidance for all of those.

# Yoav Weiss (4 days ago)

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 w3c/tr-design#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.

# Chris Wilson (4 days ago)

On Thu, Oct 24, 2019 at 6:35 PM Maciej Stachowiak <mjs at apple.com> wrote:

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.

Seconding Yoav's question - what would be the best way for us to write into the Blink process to do this? I think "quote any member of the Webkit team you can get to make a statement in public" has multiple failure modes, so I want to make sure we're pointing to (as you put it) relatively official opinions.

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.

We just had a conversation on precisely this topic, and I expressed the concern that embedding a record of our attempts to solicit opinions might also be taken as shaming, which isn't our intent either.

I think I'm hearing:

  1. Blink needs to be more explicit about asking for signals. It would be good to have those as repeatable channels at the various other platform implementation organizations.
  2. Blink needs to be more intentional about notifying when features are tracking to land, to put appropriate pressure on getting those signals (positive or negative).

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.

I have to disagree with your concern, at least as an entry point. The whole point of starting incubations is that they may not have multiple implementers interested in prototyping -but an incubation is not the end point. Certainly, as specs graduate from WICG incubations into an appropriate WG (or the WHATWG) - their exit point from incubation - I would expect multiple implementers to support and to be working on implementations.

"No track to multi-engine implementation" can be only a matter of time and priority, also. I'm not against declaring more directly/publicly what implementers are "supporting" (in quotes because there's not a precise definition here) any given incubation, if we can come up with a way to do so; would that help?

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.

As Yoav said, I think this is a bug - much like putting the W3C editor draft logo on a spec in a personal repo. Misleading, at best.

I think these are process problems with WICG.

I am strongly against making a higher bar than "multiple independent parties are interested" in order to start an incubation - because a bar such as "must have multiple implementers supporting" would mean the vast majority of incubations would be done effectively outside the community, in personal or corporate repos, with no early contribution IP commitment or outside engagement.

That said, I'm happy to talk about process improvements we can do in the WICG - for example, I proposed above that we enable implementers to tag their support in WICG repos. Would that help? Is there something else we should change?

-Chris (WICG co-chair, among other roles)

# Ryosuke Niwa (3 days ago)

On Oct 25, 2019, at 10:34 AM, Chris Wilson <cwilso at google.com> wrote:

On Thu, Oct 24, 2019 at 6:35 PM Maciej Stachowiak <mjs at apple.com> wrote:

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.

Seconding Yoav's question - what would be the best way for us to write into the Blink process to do this? I think "quote any member of the Webkit team you can get to make a statement in public" has multiple failure modes, so I want to make sure we're pointing to (as you put it) relatively official opinions.

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.

We just had a conversation on precisely this topic, and I expressed the concern that embedding a record of our attempts to solicit opinions might also be taken as shaming, which isn't our intent either.

I think I'm hearing:

  1. Blink needs to be more explicit about asking for signals. It would be good to have those as repeatable channels at the various other platform implementation organizations.
  2. Blink needs to be more intentional about notifying when features are tracking to land, to put appropriate pressure on getting those signals (positive or negative).

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.

I have to disagree with your concern, at least as an entry point. The whole point of starting incubations is that they may not have multiple implementers interested in prototyping -but an incubation is not the end point. Certainly, as specs graduate from WICG incubations into an appropriate WG (or the WHATWG) - their exit point from incubation - I would expect multiple implementers to support and to be working on implementations.

What’s lacking here is the clear indication between the two. For example, how does one supposed to figure out this intent to ship email was based on a feature not being reviewed by Mozilla or Apple? There should have been a clear indication that this is a single vendor feature in the spec itself.

I get that there needs to be some avenue to share ideas. But that avenue can’t be simultaneously something browser vendors use to claim that it’s a well accepted standard API.

Want more features?

Request early access to our private beta of readable email premium.