Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Styled YouTube subtitles: words won't get selected wholly across spans #535

Closed
Des-Nerger opened this issue Feb 23, 2021 · 5 comments
Closed

Styled YouTube subtitles: words won't get selected wholly across spans #535

Des-Nerger opened this issue Feb 23, 2021 · 5 comments

Comments

@Des-Nerger
Copy link

Des-Nerger commented Feb 23, 2021 •
edited
Loading

I made simplest possible furigana-containing YouTube subtitles.
When I hover over, let's say, the word 疲れて, then only 疲 gets selected, れて doesn't. So I can't appreciate the rikaichamp deconjugation feature for this kind of words.
But if I go to Firefox Inspector and remove the <span> tags around both <ruby>...</ruby> and れて then the selection starts working properly. Yet if I just replace <ruby>...</ruby> with 疲, it doesn't fix that. So I believe the bug all has to do with spans and not ruby tags.
youtube_furigana
@birtles
Copy link
Member

birtles commented Feb 24, 2021

Hi! Thank you for filing this issue!

I had a look into it and I suspect the problem is because you have display: inline-block on the spans. Rikaichamp builds up the string to lookup by traversing over inline elements and ruby elements. However, it treats display: inline-block as signifying the start of a new chunk of text so it will stop traversing text if it sees a new inline-block element.

You can reproduce this with the following minimal test case:

<p><ruby><span>疲</span><rt>つか</rt></ruby><span style="display: inline-block">れた</span></p>

Is this HTML something that you are producing or something YouTube is producing?

@Des-Nerger
Copy link
Author

Des-Nerger commented Feb 25, 2021 •
edited
Loading

YouTube is.
Just to be sure, I have just tried multiple browsers and PCs (and with "Add-ons Disabled", too), and display: inline-block is always there. (You can reproduce it yourself if you don't mind retyping the URL from the screenshot.)
I think it's just the way YouTube renders SRV3 spans (denoted by the <s> tag there).
Here's how relevant sections of my source SRV3 subtitles looked like:

<?xml version="1.0" encoding="utf-8" ?><timedtext format="3">
<head>
<pen id="1" rb="1" />  <!-- so that <s p="1"> will work like html's <rb> -->
<pen id="2" rb="2" />  <!-- so that <s p="2"> will work like <rp> -->
<pen id="4" rb="4" />  <!-- so that <s p="4"> will work like <rt> -->
<wp id="0" ap="7" ah="50" av="75" />  <!-- in order to raise subtitles higher -->
</head>
<body>
...
<p wp="0" t="153340" d="5689"><s p="1">夜</s><s p="2">(</s><s p="4">よる</s><s p="2">)</s>に　<s p="1">踊</s><s p="2">(</s><s p="4">おど</s><s p="2">)</s>り<s p="1">疲</s><s p="2">(</s><s p="4">つか</s><s p="2">)</s>れて</p>
...
</body>
</timedtext>

Nothing fancy. The spans themselves are just minimal ones to make a rubied text happen.

Rikaichamp treats display: inline-block as signifying the start of a new chunk of text so it will stop traversing text if it sees a new inline-block element

Is it for something important? If so, would it make sense to at least add an option to disable that behavior?

@birtles
Copy link
Member

birtles commented Feb 26, 2021

Thanks! I'm quite happy to change Rikaichamp to traverse inline-block elements (the main reason for not doing so is just for performance--the sooner we can find the end of the input string, the less we need to traverse and subsequently lookup). Do you have a link to some YouTube content where I can test this?

@Des-Nerger
Copy link
Author

Des-Nerger commented Feb 26, 2021 •
edited
Loading

If a clickable/machine-readable link is absolutely necessary, here's a second example (which is made by some other person): https://youtu.be/f5f5383Pm00

@birtles
Copy link
Member

birtles commented Feb 26, 2021

If a clickable/machine-readable link is absolutely necessary, here's a second example (which is made by some other person): https://youtu.be/f5f5383Pm00

I'm sorry, I completely overlooked that you wrote in your previous comment that I can reproduce it from the URL in the screenshot! You're right, I've been able to reproduce it using that link. It should be fixed in the next release, hopefully.

@Des-Nerger Des-Nerger changed the title YouTube subtitles: words won't get selected wholly across spans Styled YouTube subtitles: words won't get selected wholly across spans Feb 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@birtles @Des-Nerger