Styling and display of results

[themoeway-bot]

toasted-nutbread opened issue FooSoft/yomichan#292 on 2019-11-26

---

There are a few things that have occasionally come up related to the styling of the results displayed. This issue is intended to track a lot of them, as well potential future research.

• Additional cosmetic control Bump @playwright/test from 1.31.2 to 1.32.1 #119, Can't search within popup anymore. #317
  While this is partially completed, the usefulness of custom CSS could further extended by adding more metadata attributes to the display HTML and tweaking how certain content is displayed. For example, it could be possible to use the CSS content property to change what is displayed for tags in case someone wants to abbreviate (or omit).
• Update how the audio button is displayed when using "Result grouping = Group results by main dictionary entry". Currently, the audio button only appears when mouse hovering over the text. This does not work nicely on devices using touch inputs.
• Update existing icon buttons to have better hitboxes for touch inputs. There is a lot of empty space between buttons currently. Can't search within popup anymore. #317
• Add additional icon buttons for other features, e.g. Bump actions/checkout from 3 to 4 #237. Having some sort of menu popup with customizable links might be helpful.
• Additional options for the existing buttons. save options after updating them #284, Support for other browsers #52. Maybe add support for right-click/shift-click/long-press opening a popup menu with additional options.
• More sizing options for popup Bump jsdom from 20.0.1 to 21.1.1 #121. I haven't looked into this, but due to the nature of iframes and automatic content sizing, this may not be possible. Might be worth looking into at some point.
• Maybe have an option for context sentence extents modification since sentence extraction can't be 100% perfect all the time? Not sure how feasible this would be yet though.
• Ability to add annotations or update counters for notes Auto-eslint in vscode #285.
• Hiding tooltips during scanning Bump eslint-plugin-jsdoc from 39.3.6 to 46.5.1 #236. This would involve mutation of webpage DOM which Yomichan doesn't "own", which should really be done sparingly to avoid breaking a site's default behaviour.
• Look into using a shadow DOM for encapsulating popups as an alternative to iframes. See if there is any worthwhile benefit to doing this.
• Enable popup resizing on Firefox? CSS resize doesn't work on Firefox, so maybe an alternative would be useful. Not sure how much use that would get however.

[themoeway-bot]

siikamiika commented on 2019-11-26

---

Update how the audio button is displayed when using "Result grouping = Group results by main dictionary entry". Currently, the audio button only appears when mouse hovering over the text. This does not work nicely on devices using touch inputs

I did this to save space (mostly because of the tags), but back then touch devices weren't a concern. I'm obviously biased when I say I like the current behavior on devices that have a pointer. Do you have ideas how the tags and the audio button could be displayed on touch devices? Maybe there could be something with a static width that reacts to a tap and expands the extra information for each expression. Currently it's possible to tap somewhere near the fullwidth comma to do the same thing, but it's not obvious to users.

Hiding tooltips during scanning #236. This would involve mutation of webpage DOM which Yomichan doesn't "own", which should really be done sparingly to avoid breaking a site's default behaviour.

This reminds me that "Deep DOM scan" breaks all the buttons above mails in Gmail. I don't think anything else than blacklisting could fix this, but settings profiles can already be used for that.

Look into using a shadow DOM for encapsulating popups as an alternative to iframes. See if there is any worthwhile benefit to doing this.

This would change a lot of things, especially about nested popups. Iframes work differently with focus on different browsers, but I haven't tried shadow DOM. I also wonder how this would affect keyboard shortcuts.

[themoeway-bot]

toasted-nutbread commented on 2019-11-26

---

I did this to save space (mostly because of the tags), but back then touch devices weren't a concern. I'm obviously biased when I say I like the current behavior on devices that have a pointer. Do you have ideas how the tags and the audio button could be displayed on touch devices? Maybe there could be something with a static width that reacts to a tap and expands the extra information for each expression. Currently it's possible to tap somewhere near the fullwidth comma to do the same thing, but it's not obvious to users.

I understand why it was done, and I don't currently have any better ideas; it's just been something that I've run into a few times.

This reminds me that "Deep DOM scan" breaks all the buttons above mails in Gmail. I don't think anything else than blacklisting could fix this, but settings profiles can already be used for that.

Interesting, I was unaware of any such bug. Can you provide more details on what exact buttons you mean, either here or in a separate issue? It sounds like it should be able to be worked around, but I'm not sure what's happening right now.

This would change a lot of things, especially about nested popups. Iframes work differently with focus on different browsers, but I haven't tried shadow DOM. I also wonder how this would affect keyboard shortcuts.

Yeah, there are likely a lot of issues surrounding this, which is why the intent is primarily for testing to see what it might provide. The two benefits I can think of off the top of my head are encapsulation from the website (i.e. iframe can't be hijacked) and easier to make styles for the outer CSS. The implementation could potentially be just an iframe inside of a shadow DOM, rather than trying to fit everything into the shadow DOM directly. But it's entirely possible that the benefits are completely outweighed by the negatives (focus issues, message passing, code complexity, lack of support, etc.).

[themoeway-bot]

siikamiika commented on 2019-12-01

---

Update existing icon buttons to have better hitboxes for touch inputs. There is a lot of empty space between buttons currently.

I did some changes to history navigation in the popup and search page, and now it's possible to go forward in addition to back. In the process I also made the history navigation buttons static. While it works quite nicely with keyboard and mouse wheel shortcuts, the buttons are very small and difficult to use on touchscreen devices. Increasing the size would take up display real estate, so I'm hesitant to do that, but I was thinking if it would make sense to add support for swipe gestures like on iOS and Mac. It could be difficult because swiping can also be used for scanning.

[themoeway-bot]

siikamiika commented on 2020-01-27

---

Enable popup resizing on Firefox? CSS resize doesn't work on Firefox, so maybe an alternative would be useful. Not sure how much use that would get however.

I think this is fixed by https://www.github.com/FooSoft/yomichan/pull/316, checked as done

edit: oops, that's a completely different thing

[fenn]

Simple Theme

the crazy clashing tag colors and distracting elements in jitendex were driving me mad, so i did a little CSS butchering. not sure where else to put this, since i don't see any theme repository or wiki. consider it inspiration for a different way to live.

yomitan_fennetic_theme.css

light theme:

dark theme:

[stephenmk]

Sorry :(

[fenn]

thanks for making jitendex :)

i really only wanted yomitan as an inline popup dictionary to help with reading manga that has been OCR'd with mokuro, so the word type classifications, dictionary source info, and alternative kanji rarity tables are really not relevant. the context is right there in front of me, so i already know how the word is being used.

it seems like the real issue is that yomitan just dumps the entire dictionary entry into the popup window, instead of selecting only a few elements to display.