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

[Ryosuke Niwa]

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

> "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)