Minimal TailwindCSS classes on standard opt-in menu

[MarcoCazzaro]

Hi Greg, first of all: awesome work and many many thanks for this amazing project. I think and hope it will become the standard (if it's not already) to scaffold a new WordPress theme.
My two cents: adding an opt-in class to the wp_nav_menu call, and adding some TW classes to that specific class only.
So, for example:

<nav class="list-none fixed lg:relative top-12 lg:top-0 left-0 w-full lg:w-auto flex z-10 transition-all" x-bind:class="{ 'opacity-100 h-auto': open, 'opacity-0 lg:opacity-100 h-0 lg:h-auto overflow-clip lg:overflow-visible' : !open }">
	<?php
	wp_nav_menu(array(
		'theme_location' => 'menu-1',
		'fallback_cb' => false,
		'container' => false,
		'menu_class' => 'menu tailwind-menu',
	));
	?>
</nav>

And then, in the CSS file:

.menu.tailwind-menu {
    @apply text-white flex justify-between flex-col lg:flex-row w-full;

    .menu-item {
        @apply py-2 px-4 bg-secondary;

        a {
            @apply text-white flex items-center justify-between;
        }

        &.menu-item-has-children {
            @apply relative;

            >.sub-menu {
                @apply transition-all relative lg:absolute left-0 lg:top-full text-primary bg-secondary w-max min-w-full opacity-0 max-h-0 -z-10 overflow-clip;
            }

            &:hover>.sub-menu {
                @apply opacity-100 max-h-screen z-10 overflow-visible;
            }

            >a:after {
                @apply content-['\203A'] text-gray-100 font-bold grow-0 translate-x-2;
            }

            &:hover>a:after {
                @apply transform rotate-90;
            }
        }

        .menu-item {
            .sub-menu {
                @apply lg:translate-x-full top-0;
            }
        }
    }

    &>.menu-item {
        @apply lg:bg-inherit;

        &.menu-item-has-children {
            &>a:after {
                @apply lg:content-[''];
            }
        }
    }
}

It's the bare minimum and perhaps not even decent, but it's a functional approach, and most of all, opt-in. For the mobile version it still requires a button to show the menu (in the example I am triggering it via AlpineJS, but you could do it via vanilla Javascript as well).

[gregsullivan]

Hi Marco—thanks for this!

Just to confirm, your thinking is that there should be something more in terms of a built-in approach to menu styling and mobile menus?

I agree that things are fairly barebones at present. My concern is always with pushing too far past reasonable defaults, leading to developers having code in their themes that they don't expect to be there and that ends up unused. That's why I ended up removing Alpine.js: While I use it for every project, not everyone who chooses _tw to add Tailwind to WordPress is going to want to use it, and that no doubt means a non-trivial number of websites loading Alpine.js and using nothing at all that it offers.

I do want to document options for styling menus in a lot more depth. That's the biggest priority I have on the documentation side.

In terms of boilerplate code for menus, I think I'd only add that if I were to build some kind of "pro" version of _tw. I would want it to be opt-in, and I would likely want options within the opt-in, and I don't want to add that kind of maintenance overhead to the existing generator.

Hopefully that all makes sense! If I'm misunderstanding anything on your side, please let me know.

[MarcoCazzaro]

Hi Greg,
thank you for your reply. Your point is super clear, I'll stay tuned for the "pro" version then! 😉

[gregsullivan]

You're very welcome! I have a checklist of core improvements to _tw that need to made first, but once I wind down that list, anything is possible. Thanks again!