[whatwg] [blink-dev] Intent to Ship: Scroll To Text Fragment
rniwa at apple.com
Fri Oct 25 14:01:48 PDT 2019
> 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
> 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
>> 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
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?
> (WICG co-chair, among other roles)
More information about the whatwg