Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logo.images should only allow named file paths #22

Open
gadenbuie opened this issue Sep 26, 2024 · 3 comments
Open

logo.images should only allow named file paths #22

gadenbuie opened this issue Sep 26, 2024 · 3 comments

Comments

@gadenbuie
Copy link
Collaborator

gadenbuie commented Sep 26, 2024

Follow up from #18. logo.with was a place for definitions, but we've renamed it logo.images. In practice, I've also found it's much easier to implement and for downstream brand consumers if logo.images is strictly a list of named file paths.

Before After
logo:
  images:
    white: logo-white.png
    black: logo-black.png
    paired:
      light: black
      dark: white
  small: paired
logo:
  images:
    white: logo-white.png
    black: logo-black.png
    # light-dark not allowed here
  small:
    light: black
    dark: white

The advantage is that we're able to consistently know that all entries in logo.images are file paths that (may) need to be resolved relative to the _brand.yml. And brand consumers can know that brand.logo.images["foo"] is a resolved file path, which is much easier to use – someone reaching into that part of brand wants a specific image.

gadenbuie added a commit that referenced this issue Oct 1, 2024
`logo.image` is now a dict of file paths, no internal reference allowed (#22)
@cscheid
Copy link
Collaborator

cscheid commented Oct 10, 2024

Quarto's schema for the small, medium, and large entries:

https://github.com/quarto-dev/quarto-cli/blob/c5c98f2d25e9e5a67c7d3f84ec8f21337ae00032/src/resources/schema/definitions.yml#L2503-L2516

Possible values for the logo field:

logo:
  small: logo-small.png

logo:
  images:
    white: logo-white.png
    black: logo-black.png
  small:
    light: white

logo:
  small:
    light: white
    dark: black

logo:
  medium:
    light: another-logo-white.png

Question: do we want to allow the specification of light but not dark and vice versa?

@gadenbuie
Copy link
Collaborator Author

Question: do we want to allow the specification of light but not dark and vice versa?

Giving light without dark would be the equivalent of saying: "I have a resource that works in light mode, but I don't have one that works in dark mode". I suppose that would translate in practice to showing the light logo when in light mode and then showing no logo in dark mode. As a brand consumer, though, that increases the cost of implementation quite a bit.

I'm in favor of making paired light and dark required to reduce the complexity around "how do I implement this?"

@cscheid
Copy link
Collaborator

cscheid commented Oct 10, 2024

I'm in favor of making paired light and dark required to reduce the complexity around "how do I implement this?"

Great, I agree. I made the change in quarto-dev/quarto-cli@4fe762b and it assumes exactly that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants