Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern 5 UI css development
giz wrote #338264:
Maybe I missed something in the thread, but I feel this unnecessarily complicates things.
Oleg already gave some response for the need by core Textpattern (and some benefits – icons set).
A basic set of --txp-- custom properties set in textpattern.css have an additional (assuming themes use them): as basic building blocks, plugin authors can build their little thing, using those bricks knowing that it will be integrated in the theme. And in that case, theme authors would not need to worry about a plugin clashing with their theme. Everyone in the community benefits in the end.
I was at first think about leaving the values blank, leaving it to the theme authors. I am not sure that wouldn’t cause problems. It does not take much to override to a theme author liking (I would do for sure, for everyone of those).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
Thanks Oleg & Philippe – that clarifies it for me; we’re on the same page.
How about we serve 3 separate css files:
- config with core :root variables
- base with generic styling, including base functional icons like resize grips, close etc
- theme styling, with decorative icons
I’ve been serving single-file stylesheets for so long I’d forgotten that the alternative has its advantages…
Offline
Re: Textpattern 5 UI css development
We currently use two style-sheets:
preview.csswith everything related to body/excerpt preview. This file is directly imported into shadow dom used for previewing, otherwise isolated from the ‘main’ document.textpattern.csswith few functional rules, core variables and (upcoming) jQuery UI icons.
Themes further add their own styling to the heap.
Technically, preview.css can be replaced by
@layer txp-preview {
/* rules shared with the whole page */
:host(#pane-preview) {
/* preview-only rules */
}
}in core or theme files, but some browsers do not (yet) handle this properly.
This suffices for the moment. Is a further splitting pertinent? Maybe, up to you UX gurus to argue.
Ideally (for me), core css might contain a minimal set that makes txp decently usable, without bells and whistles. And core itself should provide a minimal markup compatible with these rules.
Offline
Re: Textpattern 5 UI css development
giz wrote #338281:
Thanks Oleg & Philippe – that clarifies it for me; we’re on the same page.
I’ve been serving single-file stylesheets for so long I’d forgotten that the alternative has its advantages…
Excellent!
My idea is to start smallish for Textpattern 4.9, being late in the development cycle and not wanting to complicated things too much for various themes.
Hence the proposal to start with a basic set of custom properties as listed in the thread. This would be your #config block I think. If the suggested naming is OK, this can then be included in a core textpattern.css. I will have some set covering form controls ready tomorrow.
Then for Textpattern.next (5.0), with all the eventual reshuffles coming this can be reevaluated and improved.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
etc wrote #338282:
Ideally (for me), core css might contain a minimal set that makes txp decently usable, without bells and whistles. And core itself should provide a minimal markup compatible with these rules.
I’m in complete agreement!
The number of stylesheets we use won’t change how we structure the css, and its easy to reconfigure the scss side of things, so lets see what comes out in the wash…
Offline
Re: Textpattern 5 UI css development
phiw13 wrote #338283:
My idea is to start smallish for Textpattern 4.9, being late in the development cycle and not wanting to complicated things too much for various themes.
Then for Textpattern.next (5.0), with all the eventual reshuffles coming this can be reevaluated and improved.
My focus at the moment is a future scss subdirectory structure and naming convention for each partial, a mirror of the classes in the admin html.
To complement this, I’m preparing a dynamic TXP5 Style Guide in Textpattern so that its easier for us all to collaborate.
.
Is it necessary for us to use a txp- namespace in our core css variables? As Textpattern is the root, isn’t this implied? I’m asking as a self-taught coder ;-)
Offline
Re: Textpattern 5 UI css development
giz wrote #338292:
Is it necessary for us to use a
txp-namespace in our core css variables? As Textpattern is the root, isn’t this implied? I’m asking as a self-taught coder ;-)
Same reasoning as we have .txp- classes across the codebase. It is the reserved domain/namespace for Textpattern.
Practically, that makes it easy to recognise when studying someone else theme, etc.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
phiw13 wrote #338296:
Same reasoning as we have
.txp-classes across the codebase. It is the reserved domain/namespace for Textpattern.Practically, that makes it easy to recognise when studying someone else theme, etc.
I grok the rationale, but feel its overkill for core css variables.
Given that these are used extensively throughout the css, we’re lumping authors with a shitload more typing before their IDE triggers a relevant auto-complete. As Textpattern core is top-dog in the hierarchy, I’m hoping that it can enjoy the privilege of not requiring a name space; admin themes would build on this core and be required to use their own name space. A more subjective reason is that it’s ugly!
During this formative stage of design development I’m sticking to a simpler naming system, and will swap-in the namespace (or different variable names) when my codebase is mature :p
Offline
Re: Textpattern 5 UI css development
My in-progress TXP5 SASS Library is up. If it’s deemed useful, how should we go about giving developers access so we have a central resource? Note: I’ll need hand-holding for any git stuff…
Offline