-
-
Notifications
You must be signed in to change notification settings - Fork 335
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
🚸 🩹 [SVG_Support: Logo Image] #680
Conversation
…o support SVGs. Add warning discouraging specifying the same asset as both logo and logo_dark.
✅ Deploy Preview for hugo-congo ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
I think this is a good change, I'm just wondering what hard coding the width and height to 25 for SVGs achieves? Doesn't this constrain the image to a tiny area? |
I thought the goal was to have the logo entity reside within the height of the menu element, which is ~26px so constraining to 25x25 to avoid being surprised |
The logo supports any image dimensions as some users prefer to hide the site name and use only a logo, in which case they provide large assets and the rest of the menu is laid out accordingly. It would be odd constraining the SVG but allowing any size for other assets. |
ah! `k.. (the examples I saw when perusing the discussions all seemed to use it as a menu element. mah bad) I could see the options of:
got a better idea? |
I played around with the svg logo a bit today while working on a dropdown menu implementation. I'm open to feedback WRT how you'd like this improved; or what concerns you have. Currently Hugo's image as it sits, I see a couple options... if you see more, by all means, lets hear 'em.
Going much further than this will quickly tread into scope creep / yak shaving territory, as robustifying and do-what-I-mean-nerfing the user-facing knobs has a plethora of nuance4: My gut says the most helpful thing to do is to simply emit a warning if AND5:
With something like:
...And then just continuing to do what the user asked us to do. Combing this behavior with clear documentation/instructions on usage. AUGHT be aligned with most users' expectations, I THINK? This does kinda set the stage to start using the new image pipeline stuff, which has a bunch of new fun features.... but that's all out of scope for this simple change.... thots? Footnotes
|
I came up with a different, mechanism you might like a lil more?
header:
layout: 'grace' # hybrid, hamburger, basic.
showTitle: false
logo:
source: '/svg/Atticus-in-square-frame.svg'
width: 100
height: 100
logoDark:
source: '/Wolfspyre_Logo.svg'
width: 100
height: 100
showAppearanceSwitcher: true you like this more? I can update the PR; but I'd want to tweak a bit more, as currently this breaks existing behavior, since it converts the struct from a string to a dict.. I'd need to wire in support for what exists today (string as $logo/$logoDark) so it's still backwards compatible, and update doc to say that this is how one would support svg's... but turning the image construct from just a bare string to an object allows us to bolt in other stuff later (ie, output format/ image type to emit, pipeline operations to perform, caption, description, src_url for remote assets, etc ) if we want to... ¯\_(ツ)_/¯ |
for the record I'm not even sure I like this more, just trying to come up with other ways to solve the problem.... I was INITIALLY crazily hoping that if I added .Width/.Height as params of the image, that I could sidestep the .Width/.Height methods not working on vectors problem... but that was a stroke of insanity, not genius... however since I was already halfway thru banging it together, I figured I'd at least put it together enough to see if you like this approach more. |
Add logic brace around img dimension math, so as to support SVGs.
Add warning discouraging specifying the same asset as both logo and logo_dark.