[css-color-4] Is the fallback for device-cmyk() needed

[svgeesus]

The color() function used to have a fallback, which added significant complication to implementation, bulked up the object model, without adding much value, and was dropped.

The device-cmyk() function still as the same style of fallback.

Is this needed? The same arguments against the color() fallback apply here. On the other hand I'm aware the primary use is CSS to PDF converters (which typically do not construct object models) and maybe they rely on having a fallback? What do the proprietary cmyk extensions in various PDF generators use, do they have a fallback or do they depend on the usual CSS falback mechanisms?

Note that now that the preferred way to implement device-cmyk() is to associate it with an ICC profile, so generating an RGB preview for example is much more tractable than it used to be.

Unless there is significant feedback in favor of keeping the fallback, I propose to remove it.

[svgeesus]

Note that dropping the fallback would also simplify the grammar because there would no longer be the need for <absolute-device-cmyk> as distinct from device-cmyk.

[tabatkins]

I agree that now we have @color-profile for giving a correct way to translate the CMYK into a screen-displayable color, we can drop the fallback. Using a profile is vastly more user-friendly than having to specify every CMYK color twice in two completely different ways.

So yeah, unless there's a significant tooling/compat reason to keep it, we can just drop it.

[svgeesus]

The proprietarycmyk() function in PrinceXML does not have a fallback:

color: cmyk(1, 0, 0, 0)       // cyan
color: cmyk(0, 1, 1, 0)       // red
color: cmyk(0, 0, 0, 1)       // black
color: cmyk(0, 1, 1, 0, 0.1)  // translucent red

and their implementation of device-cmyk() is an alias to their cmyk():

CMYK colors can be specified using the cmyk() or, alternatively, the equivalent device-cmyk() function syntax. An optional fifth value is for the alpha channel, i.e. for opacity.