Andreas Reinhold / reiniandClaude Sonnet 5
42009f3b0c
Plan step 38 (last batch): every showcase view is now rewritten without Tailwind, so the showcase's layout keeps only the JavaScript entries of the application's configured Vite list (Livewire, Alpine) before its own bundle link, instead of the whole array — its own CSS already comes solely from ShowcaseAssetController's bundle (Stylesheets::bundle() of all.css, showcase.css and the scheme), and linking the application's build too meant the package's own CSS (all.css) loaded twice on every showcase page (once through the Workbench's package.css entry, once through the showcase's own bundle), besides pulling in Tailwind's CSS for nothing. ErrorPage:: assets() keeps passing the whole configured list: the error pages have no bundle of their own to fall back on, and step 40 is where their fallback is redesigned. The config's own comment says so. The frame's temporary visually-hidden <h2> rule goes too — it existed only because the first batch could not reach into the still-Tailwind sections/*.blade.php partials it @include's; every section now carries its own real `class="md-type-headline-md"` heading, so the structural rule that quietly hid all of them is dead weight. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qwx5USif3wFFmxtHg5U1g9
216 lines
8.1 KiB
PHP
216 lines
8.1 KiB
PHP
<?php
|
|
|
|
return [
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Component prefix
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Every component is an anonymous Blade component. Without a prefix they are
|
|
| <x-button>, <x-card> and so on; set a prefix such as 'm' when a name
|
|
| clashes with one of the application's own components, and they become
|
|
| <x-m::button>, <x-m::card>. They are always <x-livewire-material::button>
|
|
| as well.
|
|
|
|
|
*/
|
|
|
|
'prefix' => '',
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Theme
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| The head script decides the theme before the first paint and writes it to
|
|
| <html data-theme>. 'default' is used until the visitor chooses: 'light',
|
|
| 'dark' or 'system' (follow the operating system). The choice is kept in
|
|
| localStorage under 'storage_key'; values found under 'legacy_keys' (an
|
|
| earlier theme toggle's key) are adopted once and then removed.
|
|
|
|
|
| 'meta' keeps <meta name="theme-color"> (the colour an installed web app
|
|
| or a mobile browser gives its bar) on the resolved theme's surface, and
|
|
| the active colour profile's: the head script sets it before the first
|
|
| paint, adds one when the page has none, and follows every later change,
|
|
| wire:navigate included. A theme-color meta with a `media` attribute is
|
|
| left alone.
|
|
|
|
|
| 'contrast' is M3's contrast level, the same three the scheme is generated
|
|
| in: 'standard', 'medium' (3:1) or 'high' (7:1), or 'system' to follow the
|
|
| operating system's own contrast setting until the visitor chooses. The
|
|
| head script writes it to <html data-contrast> before the first paint —
|
|
| standard, having the plain blocks, writes no attribute.
|
|
|
|
|
*/
|
|
|
|
'theme' => [
|
|
'default' => 'system',
|
|
'storage_key' => 'material-theme',
|
|
'legacy_keys' => [],
|
|
'meta' => false,
|
|
'contrast' => [
|
|
'default' => 'system',
|
|
'storage_key' => 'material-contrast',
|
|
],
|
|
],
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Motion
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| M3's two motion schemes. 'expressive' (the default) is the bouncy one the
|
|
| library draws with; 'standard' is the restrained set, "minimal bounce,
|
|
| for utilitarian products" — the head script writes it to
|
|
| <html data-motion> before the first paint, and the spatial springs swap.
|
|
| The effects springs are the same in both.
|
|
|
|
|
*/
|
|
|
|
'motion' => [
|
|
'scheme' => 'expressive',
|
|
],
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Navigation rail
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Whether a collapsible navigation rail starts 'expanded' or 'collapsed'
|
|
| until the visitor toggles it. The head script applies the choice before
|
|
| the first paint, from localStorage under 'storage_key'.
|
|
|
|
|
*/
|
|
|
|
'rail' => [
|
|
'default' => 'expanded',
|
|
'storage_key' => 'material-rail',
|
|
],
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Fields
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Text fields, selects and pickers come in M3's two styles: 'outlined' (a
|
|
| notched outline) and 'filled' (a tinted box with an indicator line). This
|
|
| is the style a field takes when its `variant` is not given.
|
|
|
|
|
*/
|
|
|
|
'fields' => [
|
|
'variant' => 'outlined',
|
|
],
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Pagination
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Draw Laravel's and Livewire's paginators in M3: the package's views are
|
|
| put in front of `pagination::tailwind` and `livewire::tailwind` (and
|
|
| their simple versions). An application's own published pagination views
|
|
| still win.
|
|
|
|
|
*/
|
|
|
|
'pagination' => true,
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Node
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| `php artisan material:scheme` runs Google's colour utilities through Node.
|
|
| Set the binary when `node` is not on the PATH of the user running Artisan.
|
|
|
|
|
*/
|
|
|
|
'node' => env('MATERIAL_NODE', 'node'),
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Scheme data
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| The light and dark hexes `php artisan material:scheme` writes beside the
|
|
| stylesheet. The mail theme reads its colours here, and so does an error
|
|
| page when the build is missing; without the file both use the package's
|
|
| default scheme.
|
|
|
|
|
*/
|
|
|
|
'scheme' => resource_path('css/material-scheme.json'),
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Colour profiles
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Named schemes an installation can switch between. Each one is a 'label',
|
|
| a 'seed' (#rrggbb), a 'variant' and an optional 'contrast'; 'spec'
|
|
| ('2025' or '2021') and the 'success', 'warning' and 'info' sources are
|
|
| optional too, taken from the command's options when left out. Without a
|
|
| seed, `php artisan material:scheme` generates every profile into one
|
|
| stylesheet keyed by <html data-scheme>. 'profile' names the default one
|
|
| (else the first); the application says which is active with
|
|
| Scheme::resolveProfileUsing(). Regenerate after changing either.
|
|
|
|
|
*/
|
|
|
|
'profiles' => [],
|
|
|
|
'profile' => null,
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Mail
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Markdown mail takes the theme when `mail.markdown.theme` (MAIL_MARKDOWN_THEME)
|
|
| is 'livewire-material::mail.theme'. 'components' puts this package's mail
|
|
| header and message after the application's own mail components — or
|
|
| publish them with `vendor:publish --tag=livewire-material-mail` instead.
|
|
| 'logo' replaces the app name in that header with an image: an absolute
|
|
| 'src', with 'width' and 'height' in pixels, which Outlook sizes it by.
|
|
|
|
|
*/
|
|
|
|
'mail' => [
|
|
'components' => (bool) env('MATERIAL_MAIL_COMPONENTS', false),
|
|
'logo' => [
|
|
'src' => null,
|
|
'width' => null,
|
|
'height' => null,
|
|
],
|
|
],
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Showcase
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| Every component in every variant, rendered in the application's own
|
|
| scheme. Off unless the application runs locally. 'vite' names the
|
|
| application's own entry points: its JavaScript (Livewire, Alpine) and,
|
|
| for an application that still builds one of its own, a CSS entry. The
|
|
| showcase page draws its CSS only from its own bundle
|
|
| (ShowcaseAssetController serves Stylesheets::bundle() of all.css,
|
|
| showcase.css and the scheme) — nothing on it needs the application's
|
|
| build, Tailwind included — so the showcase's layout keeps only the
|
|
| entries here that are not a stylesheet before passing the rest to
|
|
| @vite(), and links its own bundle after them. The error pages have no
|
|
| bundle of their own to fall back on, so ErrorPage::assets() still
|
|
| passes this whole list, CSS included, to @vite().
|
|
|
|
|
*/
|
|
|
|
'showcase' => [
|
|
'enabled' => (bool) env('MATERIAL_SHOWCASE', env('APP_ENV', 'production') === 'local'),
|
|
'path' => 'material',
|
|
'middleware' => ['web'],
|
|
'vite' => ['resources/css/app.css', 'resources/js/app.js'],
|
|
],
|
|
|
|
];
|