Andreas Reinhold / reiniandClaude Opus 5
70c983b7bb
Plan step 46, from SealShare's breakpoint walk: an application imports the stylesheets its own views render, and none renders the error layout, so under a real build its 403/404/500 pages drew unstyled. With a build the page now keeps the app's Vite tags (foundation, tokens, scheme, font) and inlines Stylesheets::bundle() of components/error-page.css and its imports beside them (ErrorPage::layoutStyles(), cached). Without a build the fallback is unchanged. An application imports nothing for its error pages; one that imports all.css gets the same layered rules twice, which is harmless. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
215 lines
8.1 KiB
PHP
215 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
|
|
| the CSS entry that imports this package's stylesheets. The showcase's
|
|
| pages pass @vite() only the entries that are not a stylesheet: their
|
|
| CSS is a bundle of their own (all.css, showcase.css and the scheme,
|
|
| served by ShowcaseAssetController), so they need nothing from the
|
|
| application's build. The error pages pass this whole list, CSS
|
|
| included, to @vite() (ErrorPage::assets()) for the foundation, scheme
|
|
| and font, and inline their own layout's rules beside it
|
|
| (ErrorPage::layoutStyles()), so the entry needs no import for them.
|
|
|
|
|
*/
|
|
|
|
'showcase' => [
|
|
'enabled' => (bool) env('MATERIAL_SHOWCASE', env('APP_ENV', 'production') === 'local'),
|
|
'path' => 'material',
|
|
'middleware' => ['web'],
|
|
'vite' => ['resources/css/app.css', 'resources/js/app.js'],
|
|
],
|
|
|
|
];
|