Using @apply h-screen for the layout container, gives me scrollbars in every backend pages.
https://github.com/wintercms/wn-tailwindui-plugin/blob/a34b50bd0273c1a6950ba147b08950e09b2ff968/assets/css/src/custom.css#L140

Tested on Windows on Firefox, Edge and Chrome.

Replacing it with height : calc(100vh - 4rem) remove the scrollbars. Need to remove layout-topmenu container's height.

I don't think the colors generated are the best.

With amout set in percentage as actual :

https://github.com/wintercms/wn-tailwindui-plugin/blob/c757d8f0a2cabead86454326c1b1a715358e15fc/skins/tailwindui/layouts/_branding.php#L11-L19

With amout set as integer :

According to comments in phpColors.php, amout must be an integer. https://github.com/mexitek/phpColors/blob/e10e44f67632096072237ff0822674a442d4bb50/src/Mexitek/PHPColors/Color.php#L401-L408

But if the base color is already dark (or light), it results in the generation of black (or white) past a certain percentage when using integer.

$color = new Color($colorString);
return [
    'dark' => $color->darken(20),
    'darker' => $color->darken(30),
    'darkest' => $color->darken(40),
    'light' => $color->lighten(25),
    'lighter' => $color->lighten(30),
    'lightest' => $color->lighten(35),
];

This is because the phpColors library calculates the percentage to be added based on 100% of the channel but not on the remaining percentage to reach the 0% (darker) or 100% (lighter).

$hsl['L'] = ($hsl['L'] * 100) - $amount;

The trick

So I've slightly modified the shade generation to caclulate a percentage of luminance :

$color = new Color($colorString);
$luminance = $color->getHsl()['L'] * 100;
return [
    'dark' => $color->darken($luminance * 0.20),
    'darker' => $color->darken($luminance * 0.30),
    'darkest' => $color->darken($luminance * 0.40),
    'light' => $color->lighten($luminance * 0.25),
    'lighter' => $color->lighten($luminance * 0.30),
    'lightest' => $color->lighten($luminance * 0.35),
];

And I think it give better results : Maybe the amounts should be finely tuned.

Or equally spaced in the channel:

$color = new Color($colorString);
$luminance = $color->getHsl()['L'] * 100;
return [
    'dark' => $color->darken(($luminance / 4) * 1),
    'darker' => $color->darken(($luminance / 4) * 2),
    'darkest' => $color->darken(($luminance / 4) * 3),
    'light' => $color->lighten((100 - $luminance) / 4 * 1),
    'lighter' => $color->lighten((100 - $luminance) / 4 * 2),
    'lightest' => $color->lighten((100 - $luminance) / 4 * 3),
];

The color-mod function requires the --primary & --secondary CSS vars to be present during compile time which fails under the current configuration rendering any color-mod defined colours unavailable at the moment.

A couple of different options are available:

• Find a way to inject variables during the compilation process and require each project using this plugin to recompile the styles for themselves
• Perform colour modifications in PHP and inject them as root CSS variables like we're doing now with primary & secondary and then refer to those variables in the tailwind.config.js file. (This is my preferred solution).

@joseph-sm @jaxwilko thoughts?

This PR disables the default button styles for .ml-btn and replaces it with a simple darken on hover.

Original:

New: New on hover:

It looks more obvious in practice than the screenshot suggests :)

• Added fixed sidebar, scrollable in beside & text only modes.
• Added sticky topnav

Sidenav with fixed sidebar & sticky topnav

Topnav sticky

Known issues

In sidenav tile mode if there are a lot of items they will flow off screen as it is not possible to make modes with the flyout sub navigation scroll-y without cutting off the sub menu, one solution would be to implement javascript (like we did for top menus) to modify the position to allow it to pop out @see https://css-tricks.com/popping-hidden-overflow/. In most cases there aren't enough items to make this a problem at the moment.

• Sidebar is now scrollable if content is overflows on y axis

• input-group-addon buttons should now align correctly with form-control

• Froala default style fixes for heading, links, ordered & unordered lists

• Froala checkbox controls now align with label

If navigation gets registered under a different context then the href of the anchor does not get used. Instead, the JS that listens for the click event looks for a data attrib which is non existent. This PR will simply return if that attrib is undefined.

The backend.css also had changes after compilation, this might have been forgotten in a previous commit.

Redesign of the brand's color palette while waiting for a better way to do it with a library. Fix #14

The three darker or lighter shades are evenly distributed over the luminance channel.

Before :

After :

This commit aims to fix an issue with the Crop and Insert feature of the media manager. Also, it fixes some of the issues with borders for grouped buttons. While here I have gitinored some IDE path - hope this is not an issue.

For the sake of UI, I have created a separate PR https://github.com/wintercms/winter/pull/673 that increases the width of the input fields as the value was being cut off, especially with large numbers.

Preview:

This adds a fully working dark mode with a dark mode toggle button in the account drop down menu and user preferences form. The dark mode settings is stored in backend user preferences.

This PR also updates to tailwind 3.2

CSS for setting dark mode was taken from https://github.com/WebVPF/wn-darkbackend-plugin

The #20 PR introduces a display bug for me.
The sidenav layout overflow the content layout :

@joseph-sm can you test it with the default WinterCMS logo?

This updates tailwind to version 3.2 and adds some missing dark mode colors that work well with the dark backend plugin.

Note:

had to rename the class collapse to collapsible in the side menu as collapse is already used by tailwindcss https://tailwindcss.com/docs/visibility#collapsing-elements

A backend button with class icon-pencil doesn't render the icon, it renders a square with a cross in it

<button
    class="btn btn-primary icon-pencil"
    data-request="<?= $this->getEventHandler('onEdit'); ?>"
    data-request-data="id: <?= $id; ?>"
    title="Edit">
</button>

This is a POC for allowing plugin vendors to compile css patches used to include their required tailwind css as a seperate file.

The idea being users should not have to recompile the Winter.TailwindUI package to add addtional tailwind css rules for custom plugins, but instead should be able to use the plugin to compile an additional backend.css file specific for their plugin.

Usage:

The target plugin must implement a tailwind.config.js file, however this can be an import of the original. For example:

const config = require('../../winter/tailwindui/tailwind.config.js');

config.content.push('./controllers/example/assets/src/**/*.{vue,htm}');

module.exports = config;

Then run the following:

./artisan tailwind:plugin author.plugin (I also added support for passing webpack args to mix:compile) ./artisan tailwind:plugin author.plugin -- --stats-children

And a file will be created: author/plugin/assets/dist/css/backend.css which will only include the additional tailwind css rules added by their config extension.

Improvements:

This POC is implmented using some file hackery, it would be better to extend our mix support so we can inject custom mix configurations, allowing us to configure the tailwind config path. I attempted to do this using the postcss.config.js approach but it didn't seem to work properly.

If we did add the above override we could also dynamically rewrite output instructions, allowing us to not have to move the tailwindui plugin's backend.css file around.

Adding support for watch would also be very nice.

Any thoughts very welcome :)