ParentNode.prototype.replaceChildren supported in Chrome 86

[vapier]

Chrome 86 just branched with support for this enabled.
https://chromestatus.com/feature/6143552666992640
https://crbug.com/1067384

[foolip]

https://chromium.googlesource.com/chromium/src/+/ae4c3b705bf511e50ae5902802493f3dffed4bb6 is the commit that enabled this, which indeed is in M86. Since it's enabled by default it will also be in other Chromium-based browsers. Could you also update Edge and Opera?

@ddbeck do you have a process for updating things in the future? For Opera for Android and Samsung Internet it's unfortunately still not known which version will include M86, but once released they should also be updated.

[vapier]

i'm not familiar with Edge & Opera release process to know what to put in there

[foolip]

Sorry for not being explicit! I had a look in browsers/edge.json and browsers/opera.json to see if the latest listed version had engine_version 86 or greater. From that you can figure out which release of both will have these.

One can also run npm run mirror -- --modify=always opera api.ParentNode.replaceChildren, which works, but for some reason npm run mirror -- --modify=always edge api.ParentNode.replaceChildren doesn't do the right thing.

I'll suggest the appropriate edits in a review comment.

[foolip]

Unfortunately I can't leave a comment for opera since it's too far outside the diff. It should say "72".

[vapier]

added edge==72 now too in addition to opera

[foolip]

Looks good now, thanks!

@jpmedley can you review and merge? What's the policy on future browser releases, is that fine because it's filtered out for the MDN views, or should a change like this wait until each browser is released?

[ddbeck]

@ddbeck do you have a process for updating things in the future? For Opera for Android and Samsung Internet it's unfortunately still not known which version will include M86, but once released they should also be updated.

We don't have a process for this, but we probably ought to. I think something rather minimal would do. We could have a tracking issue (something like "Features shipped in Chromium 86") and keep a running checklist of features (with links to PRs) that have appeared in one or more but not all Chromium-derived browsers. Then, we can do a mirroring PR when a corresponding browser release happens. Ideally, we could have a contributor be a sort of release manager for each version (hint, hint).

[ddbeck]

Also, I just saw that this is @vapier's first PR on the project. Welcome to BCD, @vapier!

[foolip]

@ddbeck that sounds good to me! If we have a tracking issues like that, I'd be happy to add to them every time I become aware of a situation like this, and do later check back for what needs fixing. Can you file a process issue for what you have in mind, or something so that we don't forget? :)

How about releases which are still in the future, is there anything special about those, or do we just merge them like any other change?

Also, welcome @vapier, I didn't know it was your first contribution :)

[ddbeck]

@foolip

Can you file a process issue for what you have in mind, or something so that we don't forget? :)

Good idea! Opened #6561, if you'd like to take a look.

How about releases which are still in the future, is there anything special about those, or do we just merge them like any other change?

There's nothing special to do for future releases provided two conditions are met:

• The linter has to pass (i.e., the version number must be in the /browsers data)
• We expect the feature to progress to final release for the given version number (that is, if it's Nightly version X, it'll be in Beta X, and final release X) and it's not being held back for a future release

In the past, I think @jpmedley has been somewhat cautious about including data for features which are recently in Canary, but I imagine he can speak more fluently on the finer points of Chrome releases. Firefox has a notion of "riding the rails/train" to release which can be helpful to watch for, if you end up reviewing Firefox data.