New principle: Patterns for x() vs xSync()

[cynthia]

This was brought up in our discussion of w3ctag/design-reviews#771.

TL:DR; we don't have guidance on what to do when an API wants to be synchronous, and the very small subset of cases where this is valid (for the time being).

[LeaVerou]

I think both naming schemes are useful in different cases, basically x() should be the common case and xSync()/xAsync() the exception. I.e. if the main usage is sync, then x() and xAsync() seems preferable. If the main usage is async, then x() and xSync() seems preferable.

[anssiko]

@LeaVerou @cynthia, thank you for considering this and for sharing your guidance on this naming pattern issue. I will bring the above principle back to the WG without blocking on the corresponding Web Platform Design Principles doc update.

[LeaVerou]

I think both naming schemes are useful in different cases, basically x() should be the common case and xSync()/xAsync() the exception. I.e. if the main usage is sync, then x() and xAsync() seems preferable. If the main usage is async, then x() and xSync() seems preferable.

Note that sometimes the common case and the case you want to encourage may be different.

@LeaVerou @cynthia, thank you for considering this and for sharing your guidance on this naming pattern issue. I will bring the above principle back to the WG without blocking on the corresponding Web Platform Design Principles doc update.

Might be a good idea to wait for us to at least discuss, as right now that's just my personal opinion and not TAG consensus. We can add it to the agenda for next week, so you'd only need to wait a few days.

[anssiko]

@LeaVerou your personal opinion was well received in the WG and helped us reach consensus. That said, we’ll track this issue for any further guidance. For now, we settled on x() and xSync() for this API in question.

[torgo]

We discussed today and agreed to write a temporary principle.