[Userstyle] WaniKani Breeze Dark

prouleau · October 31, 2020, 5:43pm

This is correct.

This is correct. Both Item Inspector and Self Study Quiz automatically generate the filter list when the settings are opened and have some custom css for them.

I would appreciate a lot if you do.

artemigos · October 31, 2020, 6:11pm

I’ll create an issue for myself, I won’t be able to do it today.

Can you point me to a user script that has horizontal lines in settings? I have quite a few them for testing and my own use already, but I can’t find any lines.

prouleau · October 31, 2020, 6:18pm

There is no rush. Take the time you need.

I only know of a version of Item Inspector that is still in development. I will let you know when it is released. If it can help wkof horizontal lines are implemented by inserting an <hr> tag.

Kumirei · October 31, 2020, 6:30pm

Looks like Forecast Detail has a divider

artemigos · October 31, 2020, 6:36pm

Ok, that helps

artemigos · October 31, 2020, 6:59pm

Today’s progress:

1.3.10 release

Added

Styled horizontal lines in WKOF settings dialogs

Fixed

Spacing of the WKOF fieldset title - other view elements shouldn’t ovelap with it anymore
Coloring of WKOF settings sections
Colors of radicals, kanji and vocabulary in the dashboard sections for unlocked, critical and burned items

artemigos · November 1, 2020, 8:25pm

I put a little more focus on the vanilla WaniKani this time, but the checkboxes took the most time

1.3.11 release

Added

Styles for checkboxes - they now follow screenshots from KDE Breeze guidelines

Fixed

Footer styling on ‘Profile’ and ‘Subscription’ pages
Red buttons have a color that’s a little easier on the eyes on ‘API tokens’ and ‘Danger zone’ pages
Colors in tables on ‘Subscription’ page
Text color in orange elements on ‘Subscription’ page
‘Summary’ and ‘Payment details’ sections on ‘Billing’ page changed to dark

Also, there’s an important addition in the repository - scripts running the SCSS build using a docker container. If you have docker installed then it’s a lot easier to contribute now

Kumirei · November 1, 2020, 11:18pm

I love you

artemigos · November 8, 2020, 6:08pm

I started working on styling the Self-Study Quiz+Additional Filters+Item Inspector combo and I’ve run into a problem. The Item Inspector uses style attributes and !important inside them. As far as I’m aware, this makes it impossible to override from a user style. Is it something that you can maybe move to a CSS stylesheet instead?

An example of this:

<a style="padding-right:0;" target="_blank" href="https://www.wanikani.com/vocabulary/%E5%A4%9A%E3%81%84">
  <span class="WkitMainElement WkitItemlang=" jp""="" style="color: #000000 !important">多い</span>
</a>
<div class="WkitTooltipContent">
  <div class="left">
    <span class="vocabulary" style="color: #000000 !important;">多い</span>
  </div>
  <!-- (...) -->
</div>

prouleau · November 8, 2020, 6:53pm

When I made that request I had the styling of the settings in mind.

I see you are interested into styling Item Inspector as a whole. I like this and I will collaborate. Improving Breeze Dark support in Item Inspector is on my to do list.

The user style attributes are there because the current Breeze Dark styling causes havoc to Item Inspector. I couldn’t find a way to style Item Inspector properly with css because Breeze Dark uses !important in its css and I needed to retake control to have a sane styling for Item Inspector. If you plan to fix this I will be able to remove the style attributes.

Currently Item Inspector is a moving target. I keep introducing new features and release new versions. It would be beneficial if I understand how Breeze dark styling works. I would setup my css in such manner that it supports Breeze Darks smoothly as I release the new versions. I don’t think redoing Breeze Dark every time there is a new version is a good approach. It is better if I have a way to set things up on my end. Can you give me advice? Are there classes I can use that will cause Item Inspector to be properly styled?

Distinguishing item types with background colors are very important to the user interface. I wouldn’t like a black background with the item types distinguished by font colors.

I have on my todo list to support the Breeze Dark background colors for the item types. I don’t know yet how to proceed with this. I also want to give my users the choice between Breeze Dark colors and the native WK colors. Are there some classes I can setup that will have that effect?

artemigos · November 8, 2020, 8:48pm

The general CSS rule is that if your selector is more specific, your styles win. In case there are 2 places with !important the rule still stands, so if you make your selector more specific you still can override !important rules. You can see an example of this here - I had to nest these styles deep to win with my border styles.

This is an interesting topic. Depending on what’s required this might end up as some kind of styling framework to make it work. I see 3 approaches here:

Reuse vanilla WK components. The item tables are pretty much carbon copies of the tables that WK already provides. You could emulate the HTML and classes that are used there and you would get Breeze Dark styles practically for free. There are drawbacks to this:
- Whenever WK changes, Breeze Dark must change and by extension your script would have to change too.
- Anything custom (popups, inverted item coloring) still needs to be supported in a different way, probably with specific classes added in the script and custom styling in Breeze Dark.
Define custom components. This is what’s mostly happening with WKOF settings. The view structure and classes are something completely custom, and it needs custom styles for the entire thing. The HTML structure and CSS classes are acting as some kind of API surface for the styles. Drawbacks here:
- The changes in structure/classes in the script are harder, because you want to avoid breaking Breeze Dark (if styling breaks I need to be made aware of the changes, find time, code, test and release). This could be solved by pull requests to Breeze Dark whenever there are breaking changes to the script. Doing PR’s doesn’t scale with multiple supported user styles.
- All custom components need to have styles for vanilla WK provided by user scripts. This is already what happens, so not such a big deal.
Standardize. This would be an extensions the previous approach. In spirit this idea is a lot like Bootstrap - there are some components defined, which require a certain HTML structure and certain CSS classes to be applied. This would benefit WK user styles/scripts in general, because with a standard it’s easier to write something that ‘just works’ with all compliant user scripts/styles. Of course this is much more ambitious and too much for the time I have right now. On the other hand, it doesn’t have to be me doing this . This might also become easier if we can actually piggyback on Bootstrap itself. I’m seeing Bootstrap-like classes here and there, so maybe it’s included and hopefully it isn’t stripped down to include only styles used by WK. Drawbacks:
- A ton of work for everyone (prepare a standard, adapt user scripts to the standard, adapt user styles to the standard)
- Component styles for vanilla WK need to be distributed somehow (assuming we’re not using Bootstrap). I can see this working out with WKOF’s help.
- Most likely many of the components will exist for one user script only, which suggests that this approach might be overkill.

I don’t have a definitive answer which option is the best. For now, if I were you I would mix approaches 1 and 2. First, try to reuse WK styles as much as possible and then add custom classes for everything I want to change about those components. In case of the items table, it has the main class kotoba-table-list on a <section> and there’s an <h3> and a <table> inside. Then I would add a custom class kotoba-table-list-inverse and add CSS, that inverts the colors in the table. Then Breeze Dark needs to style only kotoba-table-list-inverse for your script . If there’s no component in WK that can be used, make it completely custom (while still maybe reusing WK classes here and there), then try not to change it too much.

Well… I made a huge description about how to differentiante it, but I actually agree that using the colors as background would have better readability. I’ll do that for the WK sections, so this will be unified. The above example about reusing WK components but differentiating with custom classes still stands, though

I could provide some simple classes like .kanji-background-color, .vocabulary-color, etc. I’m not sure this will be sufficient. There’s also the option to use CSS variables. Or both

This became a behemoth of a post

Sinyaven · November 8, 2020, 8:53pm

Maybe Breeze Dark could define some CSS variables so that userscripts can access the color palette. I suggested something like that before:

Sinyaven:

can you add
body {
	--radical-color: /*[[radicals-color]]*/;
	--kanji-color: /*[[kanji-color]]*/;
	--vocabulary-color: /*[[vocab-color]]*/;
}
to the theme? This would allow userscript authors to access these user-defined colors in their own CSS with var(--radical-color, #00AAFF) , var(--kanji-color, #FF00AA) and var(--vocabulary-color, #AA00FF) .

It might be useful to also have CSS variables for the background colors, or whatever else might be needed for userscript authors to style the interface they are adding.

artemigos · November 8, 2020, 9:08pm

I can do that, but I’m not sure it’s sufficient: https://caniuse.com/css-variables
Is there a list of recommended supported browsers for WK?

Sinyaven · November 8, 2020, 9:13pm

Internet Explorer users can’t use userscripts anyway ^^
And I think this is also true for Opera Mini.

artemigos · November 8, 2020, 9:19pm

Ok, that’s a good point
The variables open interesting options, like defining expected colors for different component types. This is starting to look very promising.

prouleau · November 8, 2020, 9:48pm

You guys know more about css than me.

I like the ideas of css variables. Then I can setup classes depending on the preference of the users for their colors and have the proper style applied. But I wonder. How do we detect Breeze Dark is being used? The css variables won’t be defined if Breeze Dark is not the current style. How can I write styles that won’t break when Breeze Dark is not there? Can we add something to the selector that causes the rule not to be used when Breeze Dark is not there? Or is there a better way?

I had the tables styled according to vanilla WK. Breeze Dark used not to style that properly and the result was totally broken. I had to depart from this to get something that works under Breeze Dark. Anyway the tables are a small part of Item Inspector styling requirements. I have to use custom styling.

I agree that standardizing is too much. One problem is adoption. Individual script writers go their own way.

One advantage of providing classes and variables is that much of the styling is delegated to the script. If it breaks Breeze Dark it is up to the script writer to fix it. This avoids the need for pull requests to change Breeze Dark for every script.

This is a good advice. I will look at how to do things this way.

artemigos · November 8, 2020, 10:07pm

If all you need is a different color, then there are fallback values in case the variable doesn’t exist: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#Custom_property_fallback_values

If you need more than that, then I don’t think it’s possible, unfortunately.

prouleau · November 8, 2020, 10:25pm

I think fallback values will do. This way I can always revert to vanilla WK style when Breeze Dark is not there. The key would be to have a custom variable for each property that is relevant to Breeze Dark. Then I style by referring to Breeze Dark first and vanilla WK second. This way everything should autodetect nicely. I just need to know which property and which variable I need to apply and when.

I can handle user preferences by inserting classes in the html to match the preference. Then a selector will apply the right style.

Custom variables can be used for properties other than color if I understand correctly.

Thank you for your advices. I feel like a thorny problem in my to do list is getting solved.

artemigos · November 15, 2020, 7:30pm

I finally found some time (and energy) to work on the style.

1.3.12 release

Added

CSS variables for commonly used colors
styles for Item Inspector’s filters settings
styles for WKOF’s script menu on review an lesson pages

Fixed

background colors of menu’s, submenus and their arrows

CSS variables

In this release, I added CSS variables to the style (thanks @prouleau and @Sinyaven) . They are global and can be used by user scripts to style custom UI components in a more “portable” way. The variables as of now are:

--kanji-color - color used to denote kanji
--radical-color - color used to denote radicals
--vocabulary-color - color used to denote vocabulary
--text-color - default text color; light text od dark background
--inverted-text-color - dark text color, can be used on kanji/radical/vocabulary backgrounds
--page-background - background color of the WK pages
--section-background - background color of WK sections/panels

Kumirei · November 15, 2020, 8:10pm

Niiiiiice