add more detail to mootools and createShadowRoot examples

[dbaron]

I think it may be useful to add some additional detail to the mootools and the createShadowRoot examples.

In particular, it's not clear from the text currently in the document how the code in both cases behaved when a native implementation was present. I think it might be worth adding, in both examples, an additional sentence or two that says:

• what each library/polyfill did when a native implementation was present
• an example of page JS code that broke as a result of a native implementation being present

[triblondon]

@dbaron Would you be willing to suggest a specific amendment? I think we'd all probably support it in principle

[triblondon]

Picked up on TAG call. David not on the call so have punted this, will deal with it at F2F unless he has time to put something together before then.

[dbaron]

Doing a little research and adding notes here:

So based on @bzbarsky's original comment describing the problem, the problem with MooTools was actually that it depended on:

• being able to adds its own implementation (that still worked, and overrode the one on Array.prototype), and
• depended on the implementation that it added being enumerable (which was not true, since the new native one was not enumerable, and overwriting a non-enumerable property leaves it non-enumerable)

The lesson from this seems a little complicated; it's not clear to me how to boil it down.

[bzbarsky]

The main lesson is to not create "polyfills" that are known to not match any possible standardization effort. Standard properties in ES are non-enumerable, so any polyfill of an ES thing that makes it enumerable is broken by design, no matter what else it does.

[dbaron]

So for the createShadowRoot case, the original issue https://github.com/w3c/webcomponents/issues/129 seems to suggest that the issue wasn't a polyfill at all, but rather Chrome having shipped createShadowRoot. Maybe @dglazkov can confirm this?

[dglazkov]

@dbaron is correct.