Split CSS shape functions

[jamesnw]

Addresses #3326

Adds features for:

• rect() and xywh()
• shape()

Removes the computed_from from shapes.

Thanks to @vwallen for review.

[ddbeck]

Suggested change

	description: The `circle()`, `ellipse()`, `inset()`, `polygon()`, CSS shape functions create shapes for use with `clip-path` and `shape-outside`.
	description: The `circle()`, `ellipse()`, `inset()`, and `polygon()` CSS shape functions create shapes for use with `clip-path` and `shape-outside`.

[ddbeck]

Optional suggestion here. The way this is written doesn't make it clear that these things are alike. Maybe a phrasing like this would help?

Suggested change

	description: The `rect()` CSS function creates a shape with insets from the edges of an element, and the `xywh()` CSS function creates a shape with an `x` and `y` distance, and a width and height. They can be used with `clip-path` and `shape-outside`.
	description: The `rect()` CSS function creates a rectangle shape with insets from the edges of an element. The `xywh()` CSS function creates a rectangle shifted by an `x` and `y` distance. They can be used with `clip-path` and `shape-outside`.

[ddbeck]

Strictly speaking, we could follow the feature splitting guideline here. We'd end up with a kind: split feature that targets something like:

• circle-ellipse-inset-polygon (this feature, shapes minus rect and xywh—there might be a better ID we could come up with)
• rect-xywx
• shape-function

That said, I think there's something slightly tricky here: the caniuse key (along with a compute_from) indicates that we intended this to follow caniuse's CSS Shapes Level 1 feature. So there are two possible ways to interpret this PR:

1. We're correcting the description to match caniuse, then cleaving some keys into new features silently (e.g., our description was mistaken, but the feature's gist was correct). If it's this, the PR is fine as written.
2. We're splitting up a monolithic feature into multiple parts (e.g., our feature was badly conceived). If it's this, then we ought to use the kind: split.¹

My preference is to do what is less confusing for developers. But it's not clear that anyone is relying on us for a definition of "shapes", so maybe the redirect is needless indirection? I think @jamesnw saying what he was thinking when he wrote the PR would be a very helpful clue.

Footnotes

1. Later on, when we solve the "composite feature" problem, we could reinstate shapes as the superset of all the features described in this PR. ↩

[jamesnw]

Hmm, I think it's somewhere between #1 and #2. This is partly to match caniuse (and to properly reflect the disparate release dates) on the existing feature. But I also think it's true that rect(), xywh() and shape() probably should have been separate features, but weren't due to the coverage push.

As far as less confusing to developers, I think it's a case where separate is less confusing until everything is Baseline high, and then joined is less confusing.

I'm open to a split, but agree that people likely aren't relying on this feature to include the newer ones. Given all this, what do you recommend?

[jgraham]

FWIW my opinion is that caniuse trying to cover rect, xywh or shape just doesn't make sense, because those things either aren't implemented or were implemented much more recently than the widely-available parts of the current definition. shape() in particular wasn't available in any browser until this year, so any caniuse feature predating web-features can't have included it.

Basically I think we should consider the current definition to be an unintentional mismatch from what was intended (assuming the intent was to match caniuse) and therefore consider it OK to land this PR as is. But I'm also OK with splitting it explicitly, if people prefer that.