Don't monkey patch

[annevk]

We should incorporate some variant of https://annevankesteren.nl/2014/02/monkey-patch into https://w3ctag.github.io/design-principles/#spec-writing.

[dbaron]

related to #99.

[hober]

Also related to #68.

[dbaron]

@hober and I are discussing this in a breakout at our "Cork" virtual face-to-face. One point in our discussion is that we probably want the framing to both be "don't monkey patch" (although we probably want a less colloquial way to say this) and also "ask for and create extension points when needed".

[annevk]

Maybe not so much extension points as integration points. Arbitrary extension points often run into ordering issues.

[LeaVerou]

I'm coming to this issue late and may be lacking some of the context, but these are my thoughts:

If extending an existing API in a way that is not explicitly permitted by its current extension/integration points yields better usability for web page authors, I think that is desirable, and the API just needs a new extension/integration point, rather than the extension itself being a bad practice that should be discouraged by a design principle (web page authors above spec writers etc etc). The ability to have a single source of truth for the entire API surface sounds like a tooling problem to me.

[annevk]

This is not so much about what is currently permitted, but how something is specified once it's decided that something is worth doing. I don't see it being in conflict with priority of constituencies at all.

[LeaVerou]

@kenchris and I discussed this during a breakout today and we agree this should be incorporated in https://w3ctag.github.io/design-principles/#spec-writing

@marcoscaceres would you like to take a stab at this? Ken said you have a lot of background on this topic.

[marcoscaceres]

Sure, I can draft something up.

[torgo]

Hi @marcoscaceres we're just circling back on this. Did you get a chance to write something?

[marcoscaceres]

Sorry for the delay: #355