Open
Conversation
Claude's explanation:
❯ How is it possible that you could simplify all those selectors so much without breaking anything or making them not specific enough so that they don't intefere with other page elements?
⏺ Great question. Let me show you exactly what happened with a concrete example. Take line 32 from the original file:
Before:
h1,.uk-h1,h2,.uk-h2,h3,.uk-h3,...,
.uk-section-primary:not(.uk-preserve-color) h1,
.uk-section-primary:not(.uk-preserve-color) .uk-h1,
.uk-section-secondary:not(.uk-preserve-color) h1,
.uk-tile-primary:not(.uk-preserve-color) h1,
.uk-card-primary.uk-card-body h1,
.uk-card-secondary.uk-card-body h1,
.uk-overlay-primary h1,
... {
color: var(--pw-text-color)
}
After:
h1,.uk-h1,h2,.uk-h2,h3,.uk-h3,... {
color: var(--pw-text-color)
}
The removed selectors were more specific versions of the base selectors, targeting elements inside containers like .uk-section-primary. For example, .uk-section-primary:not(.uk-preserve-color) h1 means "an h1
inside a .uk-section-primary element".
The key points:
1. Those container classes don't exist in the PW admin markup — no PHP template ever outputs class="uk-section-primary" or class="uk-tile-secondary" etc. So those selectors never matched anything.
2. The base selectors are preserved — h1, .uk-h1, a:hover, .uk-button, etc. all remain untouched. These are the ones that actually style the admin.
3. The properties are identical — the removed selectors applied the exact same CSS properties as the base selectors. They existed as UIkit's way of ensuring correct colors inside colored containers — a UIkit
feature the PW admin doesn't use.
4. No specificity change for real elements — since the removed selectors targeted elements inside non-existent containers, they were never winning any specificity battles. The base selectors were always the
ones doing the actual work.
So nothing got "simplified" in terms of what CSS actually applies — we just removed selectors that could never match any element in the admin.
Member
|
I think that a lot of those extra classes may be to fully support all uikit
features, as I know Diogo put a lot of work into that. It was because
Bernhard had concerns about it initially missing some uikit
features/styling that he was using in his modules, but the core wasn't
using. So the konkat guys went and added support for the whole uikit
library, as I understand it.
I had a similar thought this week that Claude would probably be great to
work in some of processwire's css and improve it. I'm sure there's room for
improvement in just about every css, scss and less file. For instance, it
might be a good opportunity to remove the dependency between the original
uikit theme and the new default one. It seems like there's good potential
for the admin.css to be self contained and not need to override original
theme styles. I also think that Diogo has started using Claude with the
admin.css now too. But they are still sending over tweaks and improvements
(some this week even) so probably should keep things they way they are now.
Longer term I think Claude is going to be very helpful in optimizing css
throughout the core.
…On Wed, Apr 1, 2026, 7:00 PM Adrian Jones ***@***.***> wrote:
Hey @ryancramerdesign <https://github.com/ryancramerdesign> - I think I
mentioned not long ago that I thought the admin.css file seemed
unnecessarily huge so I asked Claude to have go at removing redundant
classes and it literally halved its size. I know I saw a note somewhere in
your code about not minifying this file (although I'm not sure why), but at
least this should be a big improvement.
I haven't tested it thoroughly, but a quick look around the admin looks
good.
I asked Claude:
❯ How is it possible that you could simplify all those selectors so much
without breaking anything or making them not specific enough so that they
don't interfere with other page elements?
⏺ Great question. Let me show you exactly what happened with a concrete
example. Take line 32 from the original file:
Before:
h1,.uk-h1,h2,.uk-h2,h3,.uk-h3,...,
.uk-section-primary:not(.uk-preserve-color) h1,
.uk-section-primary:not(.uk-preserve-color) .uk-h1,
.uk-section-secondary:not(.uk-preserve-color) h1,
.uk-tile-primary:not(.uk-preserve-color) h1,
.uk-card-primary.uk-card-body h1,
.uk-card-secondary.uk-card-body h1,
.uk-overlay-primary h1,
... {
color: var(--pw-text-color)
}
After:
h1,.uk-h1,h2,.uk-h2,h3,.uk-h3,... {
color: var(--pw-text-color)
}
The removed selectors were more specific versions of the base selectors,
targeting elements inside containers like .uk-section-primary. For example,
.uk-section-primary:not(.uk-preserve-color) h1 means "an h1
inside a .uk-section-primary element".
The key points:
1. Those container classes don't exist in the PW admin markup — no PHP
template ever outputs class="uk-section-primary" or
class="uk-tile-secondary" etc. So those selectors never matched anything.
2. The base selectors are preserved — h1, .uk-h1, a:hover, .uk-button,
etc. all remain untouched. These are the ones that actually style the admin.
3. The properties are identical — the removed selectors applied the
exact same CSS properties as the base selectors. They existed as UIkit's
way of ensuring correct colors inside colored containers — a UIkit feature
the PW admin doesn't use.
4. No specificity change for real elements — since the removed
selectors targeted elements inside non-existent containers, they were never
winning any specificity battles. The base selectors were always the ones
doing the actual work.
So nothing got "simplified" in terms of what CSS actually applies — we
just removed selectors that could never match any element in the admin.
------------------------------
You can view, comment on, or merge this pull request online at:
#327
<#327?email_source=notifications&email_token=AACQEUDCSRKV3WS54YIYKYD4TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K24DSL5XXAZLOL5RWY2LDNM>
Commit Summary
- 4b66845
<4b66845?email_source=notifications&email_token=AACQEUHSC3IYH7CU4OR2LOD4TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K64DSL5RW63LNNF2F6Y3MNFRWW>
Cleanup unused container classes
File Changes
(1 file
<https://github.com/processwire/processwire/pull/327/files?email_source=notifications&email_token=AACQEUGBGYTIOAA7ELDCHDL4TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K44DSL5TGS3DFONPWG3DJMNVQ>
)
- *M* wire/modules/AdminTheme/AdminThemeUikit/themes/default/admin.css
<https://github.com/processwire/processwire/pull/327/files?email_source=notifications&email_token=AACQEUB3GOXPVNPEC6UNZJT4TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K24DSL5TGS3DFL5RWY2LDNM#diff-78c5ce6be34023628b36bf2bec795023e9765a23dd3a7299f1c5e57462beb20c>
(365)
Patch Links:
- https://github.com/processwire/processwire/pull/327.patch
<#327.patch?email_source=notifications&email_token=AACQEUFSISJQ22S7IVRJJLD4TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K44DSL5YGC5DDNBPWG3DJMNVQ>
- https://github.com/processwire/processwire/pull/327.diff
<#327.diff?email_source=notifications&email_token=AACQEUCHNEFHYYLSGEVCUQ34TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K24DSL5SGSZTGL5RWY2LDNM>
—
Reply to this email directly, view it on GitHub
<#327?email_source=notifications&email_token=AACQEUCGR2R2AXFO2DUAJFL4TWNSLA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTINZZGYZDIMJQGKTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACQEUACFM377CIPOMB4ZP34TWNSLAVCNFSM6AAAAACXJ2VFM6VHI2DSMVQWIX3LMV43ASLTON2WKOZUGE4TAMZYGQ2TEMA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Contributor
Author
|
Great point about supporting Uikit classes for third party modules. I wonder if there could be somehow be chunked out and only loaded if needed. I was curious what Claude thought was the bigger gain: ❯ Does removing all these extra selectors speed rendering up or just loading of the CSS file. ⏺ Both, but to different degrees: Loading — the bigger win. 122KB less to download, parse, and tokenize. CSS parsing is synchronous and render-blocking, so this directly reduces time-to-first-paint. Rendering — a real but smaller win. The browser builds a data structure (the style rule map) from all selectors and checks them during style recalculation. With ~2,000 fewer selectors, the browser has a The practical impact is mainly in the first category — less CSS to download and parse on every admin page load. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey @ryancramerdesign - I think I mentioned not long ago that I thought the admin.css file seemed unnecessarily huge so I asked Claude to have go at removing redundant classes and it literally halved its size. I know I saw a note somewhere in your code about not minifying this file (although I'm not sure why), but at least this should be a big improvement.
I haven't tested it thoroughly, but a quick look around the admin looks good.
I asked Claude:
❯ How is it possible that you could simplify all those selectors so much without breaking anything or making them not specific enough so that they don't interfere with other page elements?
⏺ Great question. Let me show you exactly what happened with a concrete example. Take line 32 from the original file:
Before:
h1,.uk-h1,h2,.uk-h2,h3,.uk-h3,...,
.uk-section-primary:not(.uk-preserve-color) h1,
.uk-section-primary:not(.uk-preserve-color) .uk-h1,
.uk-section-secondary:not(.uk-preserve-color) h1,
.uk-tile-primary:not(.uk-preserve-color) h1,
.uk-card-primary.uk-card-body h1,
.uk-card-secondary.uk-card-body h1,
.uk-overlay-primary h1,
... {
color: var(--pw-text-color)
}
After:
h1,.uk-h1,h2,.uk-h2,h3,.uk-h3,... {
color: var(--pw-text-color)
}
The removed selectors were more specific versions of the base selectors, targeting elements inside containers like .uk-section-primary. For example, .uk-section-primary:not(.uk-preserve-color) h1 means "an h1
inside a .uk-section-primary element".
The key points:
So nothing got "simplified" in terms of what CSS actually applies — we just removed selectors that could never match any element in the admin.