[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

Parsoid ignores manualthumb for non-image media
Closed, ResolvedPublic

Event Timeline

Change 775960 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] [WIP] Apply manualthumb consistently across media types

https://gerrit.wikimedia.org/r/775960

@Arlolra says:

For T302114, if a file and its manualthumb differ in media type, what should the annotated rdfa type be? For example, [[File:Test.jpg|thumbnail=Test.ogv]] ? This might be a reason to just switch to mw:Media from T273505. All this fun is being had in https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/775960

So in @Arlolra's example, the "main" media is a static image, while the thumbnail is a video? Presumably the opposite case is more usual, where there's a video for which we have a static thumbnail. I guess I could imagine a image thumbnail for a video clip as well?

I think we just need to pick one of thumb/main to follow, and my suspicion is that we should follow thumb in this case, because the rdf type is "what is the type of the thing embedded on this page" (which is the thumbnail) not "what is the ultimate type of the thing at the other end of this link" (which is not generally marked).

Presumably the opposite case is more usual, where there's a video for which we have a static thumbnail

Yes, and to this point we've just been putting the thumbnail image in the poster attribute of the video, which was kind of nice.

my suspicion is that we should follow thumb in this case, because the rdf type is "what is the type of the thing embedded on this page" (which is the thumbnail) not "what is the ultimate type of the thing at the other end of this link" (which is not generally marked).

Agreed

Yes, and to this point we've just been putting the thumbnail image in the poster attribute of the video, which was kind of nice.

Ah, that's the rub -- when you use a static image thumb for a video, we're not *really* doing <a href="video"><img src="thumb"></a>, we're using a hack that works only for video-(and-audio?)-with-static-image-thumbnails: <video src="video" poster="thumb">. And so it seems "weird" to tag this with the rdf Image type because we *are* actually embedding the video in the page in this case. Whereas in the more unusual cases we can't do <img src="thumb" poster="video"> so we have the dilemma. Hm.

I think "rdf type of the thing actually embedded on the page" still makes sense, it's just slightly annoying that the various cases aren't fully orthogonal.

And so it seems "weird" to tag this with the rdf Image type because we *are* actually embedding the video in the page in this case.

I'm going to stop doing that though, for consistency

when you use a static image thumb for a video, we're not *really* doing <a href="video"><img src="thumb"></a>, we're using a hack that works only for video-(and-audio?)-with-static-image-thumbnails: <video src="video" poster="thumb">.

To be clear, that's not something that the legacy parser does, it was just something I did in the Parsoid implementation because it seems reasonable and I hadn't explored how manualthumb worked in the timedmedia case.

Change 776993 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] Derive rdfa type from the thumb

https://gerrit.wikimedia.org/r/776993

Change 776995 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/TimedMediaHandler@master] Test that rdfa type is coming from the thumb

https://gerrit.wikimedia.org/r/776995

when you use a static image thumb for a video, we're not *really* doing <a href="video"><img src="thumb"></a>, we're using a hack that works only for video-(and-audio?)-with-static-image-thumbnails: <video src="video" poster="thumb">.

To be clear, that's not something that the legacy parser does, it was just something I did in the Parsoid implementation because it seems reasonable and I hadn't explored how manualthumb worked in the timedmedia case.

I approve of this hack! I believe there was at one point a proposal for an <image> or <picture> tag in HTML5 that would work the same way that <audio> and <video> did, but it never got traction. So the non-orthogonality is W3C/WHATWG's fault, not yours. Embedding the <video> tag with a poster attribute is definitely the more semantic and reasonable way to handle video thumbnails, so the practical benefit in the common case is definitely worth the non-orthogonality.

I approve of this hack!

Ok, but I'd first like to make things consistent and then I'll open a task to restore it and upstream the change in the legacy parser

Change 775960 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Apply manualthumb consistently across media types

https://gerrit.wikimedia.org/r/775960

Change 776993 merged by jenkins-bot:

[mediawiki/core@master] Derive rdfa type from the thumb

https://gerrit.wikimedia.org/r/776993

Change 776995 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Test that rdfa type is coming from the thumb

https://gerrit.wikimedia.org/r/776995

Change 784338 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/vendor@master] Bump parsoid to 0.16.0-a6

https://gerrit.wikimedia.org/r/784338

Change 784341 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/vendor@wmf/1.39.0-wmf.8] Bump parsoid to 0.16.0-a6

https://gerrit.wikimedia.org/r/784341

Change 784338 merged by jenkins-bot:

[mediawiki/vendor@master] Bump parsoid to 0.16.0-a6

https://gerrit.wikimedia.org/r/784338

Change 784341 abandoned by Arlolra:

[mediawiki/vendor@wmf/1.39.0-wmf.8] Bump parsoid to 0.16.0-a6

Reason:

Will just ride the train next week

https://gerrit.wikimedia.org/r/784341

when you use a static image thumb for a video, we're not *really* doing <a href="video"><img src="thumb"></a>, we're using a hack that works only for video-(and-audio?)-with-static-image-thumbnails: <video src="video" poster="thumb">.

To be clear, that's not something that the legacy parser does, it was just something I did in the Parsoid implementation because it seems reasonable and I hadn't explored how manualthumb worked in the timedmedia case.

Restoring that behaviour is covered in T121617