[css-images-4] [css-values-5] [css-mixins] The `type()` function is underspecified

[bramus]

The type() function appears in https://drafts.csswg.org/css-values-5/#attr-notation, https://drafts.csswg.org/css-images-4/#funcdef-image-set-type, and https://drafts.csswg.org/css-mixins/#typedef-type without one of these really specifying what exactly it is.

You can derive it’s meaning, but there’s no single source of truth describing it as a standalone thing. Can we specify the type() function in one spec (which one) and have all three uses point to it?

I also noticed it has two slightly different kinds of usage:

• In css-images-4 the argument to type() itself is parsed into a mime-type, which the UA uses to check whether it supports the format or not. It does not determine how the <image> of the [<image-set-option>](https://drafts.csswg.org/css-images-4/#typedef-image-set-option) should actually be parsed.
• In css-values-5 and css-mixins the argument to type() is meant to determine how the preceding value should be parsed.

Kinda the same, but not exactly.

[svgeesus]

Seems like css-values-5 would be the correct home for this?

[cdoublev]

See #10810 for a related discussion. But I do not know if having both a context-sensitive type() and a context-insensitive <type()> is a problem. I agree that CSS V&U would be a good place for <type()> defining a syntax.

[tabatkins]

All three of these usages are completely distinct functions doing different things, and should not be merged, any more than we should have one location for describing what auto does in CSS.

[bramus]

OK, I’ll file a PR to fix css-values-5 in that case because it links to the definition in css-images-4.