-
-
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
feat: picture partial #693
Conversation
✅ Deploy Preview for hugo-congo ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
{{ partial "pictureDefaults.html" (dict "img" . "alt" $altText "class" $class) }} | ||
{{- else -}} | ||
<img src="{{ .Destination | safeURL }}" alt="{{ $altText }}" class="{{ $class }}"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no usage of lazy param for this case, and it's intentional. I think it's better to not use lazy for images without dimensions
would it make more sense to include this as a well documented shortcode as initial implementation? further work would likely involve documentation changes to point out the integration as it gets rolled into default page templates? |
Which scenario do you have in mind? This partial just replaces similar functionality which is already there (in image render hook, figure shortcode and "single" template). Can't see how it would be useful as shortcode |
the thought was: introduce the new component in a way that it can be evaluated without forcing it to be used.. this looks like a pretty slick wrapping of figure/img. I could see this being introduced as a picture shortcode which invokes your partials. That would get the partials available, and allow tire-kicking without a hard requirement to use it in the default page templates all in one go.... |
Oh I see. I didn't get the idea from the first message, sorry. Anyway it's up to the author |
I've finally had a little more time to have a look at this PR - sorry it's taken a while. Having the option to disable webp in the config is good and I think defaulting it to I don't see any reason why this couldn't be used across all the templates... it doesn't seem to reduce the functionality in those places and makes everything consistent. The only thing we need to be mindful of is to not lazy load the feature image. |
What about this part?
It is different compared to all other places. Shall I remove it? |
is that in the screenshot shortcode? it's hard to know without referencing the file in question |
The screenshot shortcode exists mainly because when I post HiDPI screenshots taken on my Mac they would all end up output at double their actual size. This was my way of solving that issue... but maybe there's a better way that doesn't require this? |
I think yes - add css class with img, video {
max-width: 100%;
height: auto;
} browser will calculate ratio based on |
The problem here is it makes the screenshots appear blurry when they are scaled up and I like to maintain consistency between the sizes of the screenshots when there are multiple in the same article. Otherwise you end up with some that are larger than others. I guess I'm just too picky about this one and that's why it exists as its own shortcode. This is one of the only things left in the theme that is selfishly there to solve my own use case. 😆 This is also why it's not referenced in the documentation. Perhaps it doesn't need to exist at all and I could just move it to my own project. |
It's fair point. We should not upscale images (at least they should not be blurry). I need to test how it works, for some reason I think it should be ok, because |
a6fde7c
to
6f0d70e
Compare
Wait a second. At first I thought issue is DPI (and browser upscales image), but really problem is in this part:
Image size is This problem exists in original code. And I knew about it
UPD: nope it doesn't really fixes the issue, but it is definitely improvement: |
I'm not sure simply preventing upscaling solves the issue though. For instance, if I had a 600px wide HiDPI screenshot, that should be displayed at 300px wide in the HTML, not 600px. That's why I divide the dimensions by 2 in the |
Yes, you are right. In fact there were both problems. Upscaling in Hugo and upscaling in the browser. I fixed issue with Hugo. And it makes things look better, but not ideal |
I don't think the screenshot use case is going to be easy to solve with the existing functions available because there's no easy way to determine if the image is a HiDPI screenshot and not just a photo or some other asset. I think it makes sense to just keep it separate for now. I don't think many people are as pedantic as me when it comes to that particular display issue. I also wonder if this new partial should try to solve the EXIF rotation issue described in #600 too? It has been raised a few times by users and is a silly oddity in the way that Hugo handles the EXIF data (that is to say it seems it just ignores the EXIF orientation). |
Sounds like a separate PR to me |
I think this is a good solution and it makes everything uniform across the various image types. It also allows me to get rid of the |
954fd7f
to
11fd48f
Compare
If use code like this: {{ $2x := .2x | default false }} Hugo complains:
I can change it in query params though. Or we can come up with different name for internal variables |
171cdba
to
0c6c30f
Compare
I didn't remove |
c160d9d
to
c8b33ae
Compare
This is looking good now. I'll merge it in at this point and we can make future adjustments as necessary. I think the next logical step is to remove the |
Thanks for your work on this PR @stereobooster, it's much appreciated! This is a great refactor and it removed a whole bunch of code duplication. |
Example to demonstrate what is discussed here #649 (comment)
Example of generated code:
It can detect width and height for SVGs. There is branch for LQIP in code, but it's not used now.