Add a principle discouraging folks from defining novel microsyntaxes

[hober]

This came up when discussing options for Declarative Shadow DOM to specify options for attachShadow() in a declarative context.

[dbaron]

It's possible this principle is more widely accepted for HTML than it is for CSS.

It might be worth figuring out what the criteria are for when to add a new microsyntax.

[marcoscaceres]

An emphasis on encouraging a lot of community communication is important... some rough questions people could ask themselves before embarking on creating a new micro-syntax...

• does a micro-syntax already exists do meet your needs? Did you check HTML or the rest of the platform? Did you ask the TAG or HTML WG?

Should you choose to adopt a micro-syntax in a new context:

• What limitation did the original micro-syntax overcome? (i.e., why was it created in the first place?)
• Do the assumption made, or limitation overcome, by the original micro-syntax still exist since it was created?
• If the micro-syntax is being adapted to a different format (e.g., JSON), are you sure that using a native type wouldn't be better? (e.g., using a "space separated list" when you could just use an array).

Creating a new micro-syntax:

• Are you following conventions already used in the wild (e.g. ES template literals)?

[kenchris]

Examples: viewport meta tag special micro syntax can caused a lot of issues over the years as it was being parsed differently by different UAs

[LeaVerou]

Another example that came up recently was the supports keyword in the src descriptor in @font-face: w3ctag/design-reviews#666

[LeaVerou]

We discussed this with @kenchris in a breakout today and we think there is enough good content in this issue that could be easily turned into a principle. I will try to take a stab at writing one.