diogo

Thanks for reporting @monollonom! It seems like our small animation on the logo, breaks the page in Firefox. While we don't figure this out, I removed it from firefox with @-moz-document url-prefix() Not as nice, but at least the page works. Edit: the animation works for Firefox now 👍

Chris Ferdinandi has a valuable opinion on the subject. I would love to agree with him, but I honestly don't know if I can afford to https://gomakethings.com/training-your-replacement/ While you're at it, check his others posts and subscribe to the newsletter, he is a very insightful guy 🙂

@AndZyk just sent a fix for this to Ryan.

@markus-th In my view there's no reason to be confused, there's a disagreement on the strategy, that's all. Your position doesn't confuse me, I understand it perfectly, I just don't necessarily agree that it's the best path. Also notice that I carefully worded that sentence to convey that this is only one of the aspects that we discussed. It doesn't mean that it was the most important one and it doesn't mean we discarded other targets. We still think the site will convince developers to go deeper and discover PW. What we did, in that aspect, is not much different from what greatly successful tools aimed at developers are doing. From the top of my mind, see Next, Astro and Svelte

Thanks you for your opinions and suggestions, they are very welcome! We can always count on this community for engagement 👍 One aspect that we discussed, and that I don't think Ryan mentioned, is that Jan and I had several clients express concern about the tool after visiting the previous website. PW has some recognition among developers, but zero recognition among non technical potential clients, who we need to accept PW as our CMS suggestion. That's also one of the reasons of having "CMS" and not "CMS/CMF" front and center. Design decisions will never please everyone, we were aware of that and decided to go bold anyway. Hopefully it will prove to have been the right decision 🙂 That could be a fun animation to make 😆 Seriously, though, I think we discussed this at a certain point. Not sure why we dropped it, maybe because being headless in PW is a possibility and not a feature, while all the other things on the homepage are inherent to PW. The GraphQL plugin could certainly be on the modules area in the homepage, though.

@markus-th I had this on my list, but somehow didn't get to doing it. Yes, it should be an easy fix.

Tagging three people on your post must mean you really wanted to be heard. Why such an unhelpful post, then? If you want to vent your frustration, at least put a minimum effort on it.

This should be a fairly easy fix. Thanks for reporting it!

Thanks

@adrian hm, after your other message, i thought Tracy panels should be over everything, and dropped the z-index of the dropdowns and the nav to accommodate for that (i think 98 and 99, but not completely sure). But if you want the dropdowns to be over the panels, i would need to separate the numbers more. I can’t really imagine how that would work though, don’t you need the nav to trigger the dropdowns? Or am I seeing it wrong?

Ah, also, I’m happy to isolate the fixed menu and command palette css and js into modules that can be used with the original theme.

Thank you for taking the time to write these insightful answers @jploch! On vacation, and only with the mobile, is hard to keep up with the thread, i feel like I’m getting way behind and missing a lot of stuff. I just want to respond to a post from @bernhard that I had in mind, but couldn’t find to quote. It’s concerning the look of the UIkit buttons. If I took your request out of context, it was not intentionally, and probably because I didn’t understand your question. I just copied the examples from the UIkit documents, and pasted them directly inside a process module, and they got styled accordingly. Just like with the UIkit alerts previously, whose style I added to our CSS, I honestly thought that’s what you wanted. Please just let me know if I was way off in my understanding.

Ah, almost forgot about the toggles vs checkboxes. Independently of what is decided concerning the usage of toggles, our css selector is clearly too aggressive and id trying to turn, into toggles, some checkboxes that should be left alone. We’ll need to fix that. Funny, just before submitting, i noticed this 😆

@adrian i maintain that we can tweak the variables for scenarios like yours. I don't see the default theme as highly customisable, and that's not the intention. For that we have Less. In my view, the default theme should be easily customisable, to a certain extent, for those who don't want many changes and also don't want to use Less. I'll be on vacation for a week, so I won't be able to discuss changes with Jan and Ryan in the next days. For now you can change the color of the menus with: .pw-dropdown-menu { --masthead-active-color: var(--masthead-text-color); } This changes the --masthead-active-color, but only inside the menus. For everything else, it remains how it is defined in the :root. The theme itself defines variables only in the root, exactly so that defining variables in other elements always overrides them without using !important.

In your specific case, you would style the headlines with color: var(--text-color, #000); This will use the text color of the light or dark theme, and default to black, if the variable is not present. For the "today" and "left / right" buttons you can use background-color: var(--button-background); color: var(--button-color); // and for the hover state background-color: --button-hover-background color: --button-hover-color Adding <button class="uk-button uk-button-default">normal button</button> <button class="uk-button uk-button-primary">primary button</button> styles the buttons correctly for me It's true that this is a skin on top of Uikit, and we inherit the decisions of Uikit to style every single element individually instead of inheriting colors. This means that you can use Uikit elements, but that their colors will aggressively try to override ours. This works well in most part for light themes, but, in your case it is breaking on the dark theme. There are two things we can do simultaneously to mitigate the problem: 1. switch to a dark uikit base for the dark theme. 2. override the uikit color with our variables for at least their most important components. For now, the most reliable way to style markup that you add to the admin, is to do what I described before for your calendar.