Conversation
20d716f to
1ffaf35
Compare
a7b7698 to
9effde3
Compare
|
|
||
| W0024: 'Invalid accent color: \'{0}\'. The accent color is left unchanged.', | ||
|
|
||
| W0025: 'The \'{0}\' theme does not support a custom accent color. Use a fluent-next theme.', |
There was a problem hiding this comment.
| W0025: 'The \'{0}\' theme does not support a custom accent color. Use a fluent-next theme.', | |
| W0025: 'The \'{0}\' theme does not support custom accent colors. Apply a Fluent Next theme to use the \'customAccentColor\' method.', |
| + '{0}\n\n' | ||
| + 'Interoperability between different versions of the products listed herein cannot be guaranteed.\n\n', | ||
|
|
||
| W0024: 'Invalid accent color: \'{0}\'. The accent color is left unchanged.', |
There was a problem hiding this comment.
| W0024: 'Invalid accent color: \'{0}\'. The accent color is left unchanged.', | |
| W0024: 'Invalid accent color: \'{0}\'. The previous accent color remains in effect.', |
| const themeName = current(); | ||
| const isCustomAccentSupported = isFluentNext(themeName); | ||
|
|
||
| if (!isCustomAccentSupported) { |
There was a problem hiding this comment.
current() is null until the theme marker is readable from CSS and nobody has called current(name)
(no <link rel="DevExpress-theme"> -> knownThemes is empty -> resolveFullThemeName gives null).
That is the state while a theme <link> is still loading, is injected later, or ships in a deferred
styles bundle. In that window isFluentNext(null) is false, W0025 logs with an empty theme name and
the accent is dropped on the floor.
The variable is inert on every other theme, so refusing to write it buys nothing - it only makes the call
order-dependent. Suggestion: always set the property; warn only when a theme IS known and is not
Fluent Next. As a side effect an accent set while generic is loaded survives a later switch to
fluent-next, which is what a caller would expect.
(+1 to Arman's wording for W0025; with this change '{0}' can no longer come out empty.)
| return window.getComputedStyle(root).getPropertyValue(ACCENT_COLOR_PROPERTY).trim(); | ||
| } | ||
|
|
||
| if (color === null) { |
There was a problem hiding this comment.
The getter answers '' for "nothing set", the setter refuses '' with W0024, so
themes.customAccentColor(themes.customAccentColor()) on a fresh page logs a warning. The CSSOM itself
treats setProperty(name, '') as removal (measured: the ramp goes back to the designed one).
Either treat '' like null (my pick - the d.ts stays as is and whatever the getter hands out is
accepted back), or make the getter return null and type it string | null. The test at
__tests__/themes.test.ts:186 encodes the current asymmetry and flips with either choice.
|
|
||
| export type ColorInstance = Color; | ||
|
|
||
| export function isValidColor(value: string): boolean { |
There was a problem hiding this comment.
#a703ff80 and rgb(167 3 255 / 50%) pass, and every step of the ramp is oklch(from src l c h) with
no alpha channel of its own, so the whole primary scale inherits the alpha (measured / 0.501961 on
step 100). This function now defines what an accent may be, so the decision belongs here: refuse it with
W0024, strip the alpha, or pin / 1 in _accent-color.scss as a follow-up. Passing it through silently
is the one option I would not take.
There was a problem hiding this comment.
Applied — pinned / 1 on all 18 steps, in this PR rather than as a follow-up: it is the only option that also covers var() and color-mix(). Held by accent-palette.test.ts and by a testcafe case that sets #a703ff80 and requires no step to carry an alpha.
| @@ -1,5 +1,7 @@ | |||
| /* eslint-disable spellcheck/spell-checker */ | |||
|
|
|||
| import domAdapter from '@js/core/dom_adapter'; | |||
There was a problem hiding this comment.
color.ts was a DOM-free parser; this adds domAdapter, and themes.ts - present in every build - now
pulls the whole module in, name table included (~7.6 KB of source). The package declares no
sideEffects: false, so bundlers keep it. Nothing else needs isValidColor: a local function in
themes.ts or a small module under core/utils would do.
There was a problem hiding this comment.
Applied — local function in themes.ts, color.ts is DOM-free again. __tests__/color.test.ts is gone with it; its value cases moved into themes.test.ts and now run through customAccentColor.
| return color === undefined ? '' : undefined; | ||
| } | ||
|
|
||
| const root = domAdapter.getDocument().documentElement; |
There was a problem hiding this comment.
readThemeMarker and init work with the module-level context (settable through init({ context }));
this reads domAdapter.getDocument(). Under a custom context the marker is read from one document and the
accent written to another. context.documentElement keeps them together.
|
|
||
| const THEME_MARKER_PREFIX = 'dx.'; | ||
|
|
||
| const ACCENT_COLOR_PROPERTY = '--dx-accent-color'; |
There was a problem hiding this comment.
tools/naming/accent-contract.json says setBy: "the application, on the root element". From this PR
the runtime writes it too, through style.setProperty - exactly what runtime-contract.json records.
Update one of them (I would extend setBy in accent-contract.json with themes.customAccentColor) so
both entry points are on record, and say which one the docs present as primary. The same file should
also state whether var(--x) is a supported input - see C7.
| 'hsl(280 100% 50%)', | ||
| 'oklch(0.6 0.15 250)', | ||
| 'color-mix(in oklab, red, blue)', | ||
| 'transparent', |
There was a problem hiding this comment.
isValidColor('var(--brand)') is true (any var() parses at set time) and the ramp resolves it
(measured). Handy, but today it is undocumented behaviour. Either add var(--brand) to this list so it
becomes a promise, or reject it explicitly.
There was a problem hiding this comment.
Applied — promised. The list is gone along with color.test.ts (see the bundle-size comment), so the promise now sits in themes.test.ts, a testcafe case, and acceptedForms in accent-contract.json.
| expect(log).toHaveBeenCalledWith('W0024', 'inherit'); | ||
| }); | ||
|
|
||
| it('warns and sets nothing when the loaded theme knows no accent color', () => { |
There was a problem hiding this comment.
One case is missing next to these two: no theme marker at all (see C1). Whatever the decision on the
gate, that state needs a test - it is the one a real page is in while its stylesheet loads.
…e's numbered parameters (DevExpress#34742)
…ss#34744) Co-authored-by: Andrei Kharitonov <pharret31@users.noreply.github.com>
…, fix hardcoded colors in Widget Gallery (DevExpress#34698) Co-authored-by: Andrei Kharitonov <pharret31@users.noreply.github.com> Co-authored-by: EugeniyKiyashko <EugeniyKiyashko@users.noreply.github.com>
Rebase onto main brought the adduse/dead-import rules; fluent-next was written before them. Removes 257 adduse markers and 141 dead theme-root imports (27 files become empty placeholders), plus the formatting fixes the new @Stylistic rules require.
They were unrelated to the theme: 13 workflows had gained a `push: branches: [26_1]` trigger (default_workflow a `[0-9][0-9]_[0-9]` glob, wrapper_tests_e2e a `26_*` entry). The fluent-next additions to the testcafe and demo visual-test matrices stay.
The gate was red on the base branch and no workflow ran it. registries.json carried a drag-source sub-element the generator never produced, and the reachability run had 13 unreviewed scopes. The generator emits the sub-element now; twelve of the scopes are recorded as nested, each proven at runtime; the thirteenth was two actionSheet selectors that never matched an element, since the items live in the portalled popup wrapper and the state class lands on .dx-actionsheet-container.
…son + fallback-policy.test.ts) (DevExpress#35087)
8b39347 to
577ba30
Compare
9effde3 to
d68413c
Compare
17cde86 to
370c8f0
Compare
No description provided.