Textpattern 5 UI css development

phiw13 · 2024-11-18 01:04:49

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).

giz · 2024-11-18 17:11:33

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…

etc · 2024-11-18 18:57:32

We currently use two style-sheets:

preview.css with everything related to body/excerpt preview. This file is directly imported into shadow dom used for previewing, otherwise isolated from the ‘main’ document.
textpattern.css with 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.

phiw13 · 2024-11-19 02:58:59

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.

giz · 2024-11-19 18:13:41

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…

giz · 2024-11-19 18:50:02

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 ;-)

phiw13 · 2024-11-20 00:16:48

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.

giz · 2024-11-20 17:29:10

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

giz · 2024-11-20 22:47:01

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…

etc · 2024-11-21 17:09:11

I’m experimenting with vanilla JS replacement for jQuery UI, please test.

Draggable Dialog (based on HTML draggable interface) feels much more reactive, but is less controllable than Movable Dialog. Note that the latter will not work in Safari, but this can be fixed.

giz · 2024-11-21 22:34:40

etc wrote #338310:

I’m experimenting with vanilla JS replacement for jQuery UI, please test.

Draggable Dialog (based on HTML draggable interface) feels much more reactive, but is less controllable than Movable Dialog. Note that the latter will not work in Safari, but this can be fixed.

Both dialogs work well for me (Chrome/FF).

In Safari, The Draggable dialog almost works, but has its own ideas about centering vertically. The Movable Dialog isn’t :)

phiw13 · 2024-11-22 00:34:23

etc wrote #338310:

I’m experimenting with vanilla JS replacement for jQuery UI, please test.

Draggable Dialog (based on HTML draggable interface) feels much more reactive, but is less controllable than Movable Dialog. Note that the latter will not work in Safari, but this can be fixed.

The draggable dialog works fine in Safari – same as Firefox at least. The movable one cannot be moved around, and the way you implemented it won’t ever work: position paper.

The luddite phone (Safari 15.7), although it supports basic dialogs, the scripting fails.

Textpattern CMS

Textpattern CMS support forum

#13 2024-11-18 01:04:49

Re: Textpattern 5 UI css development

giz wrote #338264:

#14 2024-11-18 17:11:33

Re: Textpattern 5 UI css development

#15 2024-11-18 18:57:32

Re: Textpattern 5 UI css development

#16 2024-11-19 02:58:59

Re: Textpattern 5 UI css development

giz wrote #338281:

#17 2024-11-19 18:13:41

Re: Textpattern 5 UI css development

etc wrote #338282:

#18 2024-11-19 18:50:02

Re: Textpattern 5 UI css development

phiw13 wrote #338283:

#19 2024-11-20 00:16:48

Re: Textpattern 5 UI css development

giz wrote #338292:

#20 2024-11-20 17:29:10

Re: Textpattern 5 UI css development

phiw13 wrote #338296:

#21 2024-11-20 22:47:01

Re: Textpattern 5 UI css development

#22 2024-11-21 17:09:11

Re: Textpattern 5 UI css development

#23 2024-11-21 22:34:40

Re: Textpattern 5 UI css development

etc wrote #338310:

#24 2024-11-22 00:34:23

Re: Textpattern 5 UI css development

etc wrote #338310:

Board footer