You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the spec says if an h-entry contains a video, then it's a video post. In practice, there are often h-entrys with both a video and photo property, where the photo is intended to be the poster frame of the video. This also serves as a fallback for consumers that don't know about videos.
It'd be useful for the spec explicitly say how to handle poster images, and what to do when there is a photo property in addition to the video property.
The way I've been explaining it is:
if there is a single value for both the video and photo properties, the photo is a poster frame for the video
The text was updated successfully, but these errors were encountered:
I think this is a good improvement and makes sense.
I also think "poster frame detection" could be a video-type-specific algorithm that could be specified independently rather than confounding the return value(s) of Post Type Discovery.
I suggest brainstorming this on the indieweb wiki, perhaps as indieweb.org/poster-frame-discovery and normatively referencing Post Type Discovery for first determining that a post is a video post.
Right now the spec says if an h-entry contains a video, then it's a video post. In practice, there are often h-entrys with both a video and photo property, where the photo is intended to be the poster frame of the video. This also serves as a fallback for consumers that don't know about videos.
It'd be useful for the spec explicitly say how to handle poster images, and what to do when there is a photo property in addition to the video property.
The way I've been explaining it is:
The text was updated successfully, but these errors were encountered: