Could a dual `colour` and/or `fill` aesthetic called `ink` be supported?

[davidhodge931]

I noticed there is an argument to control foreground colour and/or fill in the new theme_* functions called ink.

A common confusion for ggplot2 beginners is whether to use colour or fill.

From this, I wondered whether ggplot2 would consider fully supporting a dual colour and/or fill aesthetic called ink? Then in general, users could just defer to always using ink - unless they were plotting something polygon-ish and wanted to differentiate the colour from the fill.

Just an idea. Feel free to close, if you think too much effort relative to any benefit

[davidhodge931]

Just noticed this #4121

[davidhodge931]

Will reopen this just in case, as has been a few years since the afore-mentioned issue was closed - and now that there is the ink concept in theme_*, there might be more willingness to entertain this idea?? But feel free to close

[teunbrand]

I don't think we should have an ink aesthetic, as it would introduce a lot of fuzziness where there is no need for it. Yet, I think this issue exposes a different problem.

A common confusion for ggplot2 beginners is whether to use colour or fill.

I was tempted to say this would be an RTFM issue for new users, but then looked at the relevant part of the vignette, and it does not explain the difference between colour and fill. It is explained in the linked page when you click the colour/fill link in the docs, but this page is less discoverable then the vignette. Moreover, the vignette doesn't explain how alpha works, which is very much related to colour and fill.

[davidhodge931]

I disagree that an ink aesthetic would introduce fuzziness. The ink aesthetic would control both colour and fill in a hierarchal way similar to how theme components work in a hierarchal way. If colour or fill was added in addition to ink, then that component would overrule that specified by ink. The other one would still be controlled by ink. The default alpha might need to be changed for boxplot/crossbar - but other than that, I can't see any issues. But agree this might be a pretty big change, and unsure how difficult it might be.. Think it wouldn't break much, as you are adding functionality, rather than taking anything away

[teunbrand]

I'm happy to keep this open for the documentation aspect, but for the 'ink as aesthetic'-aspect I'd need @thomasp85's rubberstamp as it is a larger API changing decision.

Personally, I have reservations for the following reasons:

• I don't know of any usecases where the colour/fill duality is so inconvenient that an ink aesthetic is going to remarkably improve
• 3 colour related aesthetics is harder to reason about than 2
• The overlapping nature of ink with the two other aesthetics is fuzzy, whereas just colour/fill is separable.
• As a colour related aesthetic, it would require a complete set of scale_ink_*() functions

[clauswilke]

One additional reservation: All extension packages would also have to implement this. In most cases it would not just carry over from the base ggplot2 code. So you're looking at a long time (possibly years) where extension packages don't implement ink or don't implement it correctly and you get all sorts of weird bugs. I'm not sure this pain is worth it for a feature that basically just provides syntactic sugar.

[davidhodge931]

Sounds like this is not worth it. Thanks for the consideration and explanation