Conversation
…<img> This change is important if different ratios are defined via sources. The img itself must not have a default size.
bezoerb
left a comment
There was a problem hiding this comment.
Looks good already :)
Nice work @peterschewe
| {{- $width := .width -}} | ||
| {{- $height := .height -}} | ||
| {{/* Preload hint is added in sources.html */}} | ||
| <img src="{{- $src -}}" width="{{- $width -}}" height="{{- $height -}}" {{ $image_attributes }} alt="{{- $alt -}}"{{ with $params.preload }} fetchpriority="high"{{ end }}> |
There was a problem hiding this comment.
I thought we needed it because with different ratios the sizes come from the <source> elements. Maybe it is enough there. But I just noticed another problem, there is a layout shift when the sources have a media attribute. I am looking for a solution.
| {{- $controls := $params.controls | default false -}} | ||
| {{- $poster := $params.poster | default false -}} | ||
| {{/* Use transparent base64, the real poster should be loaded as <picture> element */}} | ||
| {{- $poster := "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" -}} |
There was a problem hiding this comment.
why not skip the poster attribute completely?
There was a problem hiding this comment.
Good question. I asked myself the same question (see TBD). The poster is not a mandatory attribute, but there was some reason... maybe the background is black when the video is not yet loaded? I don't know. I will try to find out and take it out for now.
| observer.observe(video); | ||
| }; | ||
|
|
||
| export const initVideo = (root = document) => { |
There was a problem hiding this comment.
We should call init automatically without the need to be imported & called from main.js
dlemm
left a comment
There was a problem hiding this comment.
Good job @peterschewe
I've found only small things, and more like suggestions.
| .validations([ | ||
| { | ||
| in: ['hd', 'rectangle', 'square', 'portrait'], | ||
| in: ['1x1', '16x9', '9x16', '4x3', '3x4'], |
There was a problem hiding this comment.
Definitely the better naming and more obviously 👍
There was a problem hiding this comment.
I think so too. 👍 Unfortunately, there is still a bug in Sonar that I don't exactly understand yet. I'll have a look. https://sonarcloud.io/project/issues?resolved=false&types=BUG&pullRequest=45&id=jungvonmatt_create-contentful-hugo-app&open=AYNg2o7ptY5uRUoaXYTE
There was a problem hiding this comment.
Sounds like sonar thinks that this is a mathematical expression and you just could write 1, I guess..
| {{- $loop := $params.loop -}} | ||
| {{- $poster_asset := $params.poster -}} | ||
| {{- $controls := $params.controls -}} | ||
| {{- $muted := $params.muted -}} |
There was a problem hiding this comment.
Do we might need setting a default here? For example true for muted and autoplay or at least for muted since in Safari the autoplay set in Contentful would not work if the editor forgets the muted? Or would this to much control for the markup?
There was a problem hiding this comment.
You are right. I think there are more things we would have to rebuild. It's just a 1 to 1 export from the old c-video (just renamed). However, it also has slightly different requirements now. I might have to create a separate issue ticket for that first.
| img, | ||
| svg { | ||
| vertical-align: top; | ||
| // max-width: 100%; |
templates/theme-default/layouts/partials/components/c-responsive-media.html
Outdated
Show resolved
Hide resolved
|
For the TBD
In my opinion it should be placed inside the c-responsive-media since the caption barely changes. So if you use the component somewhere else, would there be another caption? And another suggestion is that we might need a desktop and a mobile caption since it is possible to maintain two different things now. |
Yes, that is a good point. I can only see a disadvantage if the caption is not directly aligned with the media. For example, the media could be fullscreen and the caption could remain in the content grid. This is also possible in the component. But maybe it's more difficult if it's already in a grid (of the module). The case can probably be ignored...
I would consider the responsive media as a unit. It is meant to be displayed differently, but the purpose of the content is the same. We also use only one alt text for both media. |
|
Kudos, SonarCloud Quality Gate passed!
|
|
Kudos, SonarCloud Quality Gate passed!
|








This PR merges all media components (
c-image,c-video,c-media) into a new componentc-responsive-media.Todos
c-imageand add as recipe insteadc-videoand add as recipe instead (new name:c-video-player)<source>instead of at<img>. This change is important if different ratios are defined via sources. The img itself must not have a default size.c-responsive-mediaTBD
c-responsive-mediavs.m-mediaplaysinlineattribute in the video util yet. I'm not sure if it would cause problems on iOS.New component: Responsive media
The component simplifies the handling of images and short loop videos, which can be used in the hero or media module, for example.
The name (
c-responsive-mediainstead ofc-media) is also a clearer distinction from the modulem-media.Features
Contentful
Markup (simplified)