RFC: Textpattern 5 ideas & feature requests

giz · 2024-11-08 19:45:22

This release of Textpattern deserves an admin interface which is equally flexible and modernised.

Improve the css class naming system of many of the layout containers i.e. .txp-layout-4col-alt or .txp-layout-4col-3span to something more descriptive.
- Currently these selectors appear in different contexts with differing functions, meaning you have to resort to css selectors like .txp-layout:has(> .txp-layout-1col:first-child) to distinguish between general listing pages and say the edit_image tab. This would be a huge help in writing simpler, leaner, easier admin-theme css.
- I’d love to see admin-themes/themename/themename.php used to specify/append-to the classnames of many key elements in the interface (or a BEM-style the class naming system).
Use native html widgets eg. <details> instead of jqui widgets.
Refactor and simplify occurrences of jqui css; it’s from another era and is brittle. The icons alone account for a major chunk of the css payload, and many aren’t used.
Remove the Dark/Light mode widget, and leave the user to control their preferences via their device settings.
Improve the layout so that it is responsive to all viewport sizes — and more flexible so developers can add content anywhere without overt layout glitches.

Bloke · 2024-11-08 20:25:40

@giz. On board with all that. I’d love to dump jQuery and jQuery UI.

etc · 2024-11-09 09:18:24

Bloke wrote #338175:

@giz. On board with all that. I’d love to dump jQuery and jQuery UI.

I guess we all are. Now who has time/skills for such a massive refactoring? Any good will is more than welcome to submit prototypes.

We have already started some improvements: core css rules/variables, light-dark() colour schemes, etc. But many UX features currently are admin theme related, which makes difficult altering them in core without implying theme authors. For example, the Dark/Light widget is only present in Hive themes, core just tries to follow.

phiw13 · 2024-11-09 09:32:27

Bloke wrote #338175:

I’d love to dump jQuery and jQuery UI.

Yes, sure. That is lots of work for jQuery, including the menu system.

But jQuery UI for sure. Some small first step: remove the use of JQUI for the “format: textile” select widget on the Write panel, above the body/excerpt textarea. The styling already exists in the theme stylesheet, see the language selector at the top of the login panel.

html 
<p class="login-language txp-reduced-ui"><label for="lang">Language</label>
<select name="lang" id="lang" data-submit-on="change">
<option value="en-gb" dir="auto" selected="selected">English (British)</option>
<option value="es" dir="auto">Español</option>
<option value="fa" dir="auto">فارسی</option>
<option value="fr" dir="auto">Français</option>
<option value="ja" dir="auto">日本語</option>
</select>
</p>

I regularly see that widget jumping slightly on page load, waiting for jQUI to finish (there is lots of js at work on the panel)

phiw13 · 2024-11-09 09:40:12

giz wrote #338174:

This release of Textpattern deserves an admin interface which is equally flexible and modernised.

Got those txp-layout-** classes: perhaps it might make more sense to add some classes, for exampe, the large .txp-layout-4col-3span column containing the editing area on the Write, Forms, pages, … panels, one could add a class txp-editor-container.

The Edit Image panel should be change to adopt a layout similar to the Edit Plugins, or Forms, …) panels - the large editor column on the left.

The icons: plan is to move them to the new core textpattern/textpattern.css. The list could surely be pruned. If you feel like, suggestions welcome, I guess.

etc · 2024-11-09 10:23:04

phiw13 wrote #338177:

But jQuery UI for sure. Some small first step: remove the use of JQUI for the “format: textile” select widget on the Write panel, above the body/excerpt textarea. The styling already exists in the theme stylesheet, see the language selector at the top of the login panel.

Good idea, but how to style it so that it takes the width of the selected option?

giz · 2024-11-09 20:19:21

Happy to contribute :) Note: Textpattern is a black box for me, and I’m crap at javascript.

Initially as an excuse to learn more about demanding usage cases of css grid and subgrid, I’m working on a new admin theme, starting from scratch. My aim is to introduce a grid-based paradigm which plays well with the existing nomenclature, and allows for elements to be distributed according to the author’s whim.

An initial prototype is 80% there¹, but I’m battling deeply nested divs which need to be coerced into acting as grid children i.e. copious display: contents; selectors. I don’t know of any other way around the issue without breaking compatibility :(

¹ 37kB nested output, uncompressed

I feel the best way forward is to prepare a document which identifies all the various nodes used throughout the interface, their classnames, ids and node ancestry. We need to identify patterns in the structure so the sass can follow suit. Does a document like this already exist?

Icons

How about using icomoon to generate a Textpattern icon font; I used it a while ago and found it removes much of the pain in dealing with icons. However we deal with them, I’m all for limiting the use of icons in the interface — particularly where they are redundant (appear together with a label); less is more :p

Ajax

The majority of issues I’ve had with client websites have occurred since AJAX saving was introduced (mostly write panel + bot_write_tab_customise glitches). The question needs to be asked: do we need it? It adds unnecessary complexity when most users wouldn’t notice the difference between an AJAX and full page refresh.

etc wrote #338179:

Good idea, but how to style it so that it takes the width of the selected option?

With a clean css slate, it can do this automatically.

Bloke · 2024-11-09 21:01:50

giz wrote #338180:

a document which identifies all the various nodes used throughout the interface, their classnames, ids and node ancestry.

I swear we (or maybe I) started one in the 4.3 era when were sanitising class names. But it’s probably been lost in the mists of time and various doc hosting moves.

etc · 2024-11-09 21:48:13

giz wrote #338180:

An initial prototype is 80% there^1^, but I’m battling deeply nested divs which need to be coerced into acting as grid children i.e. copious display: contents; selectors. I don’t know of any other way around the issue without breaking compatibility :(

It does not absolutely need to be bwc, we are on a txp5 thread here.

The majority of issues I’ve had with client websites have occurred since AJAX saving was introduced (mostly write panel + bot_write_tab_customise glitches). The question needs to be asked: do we need it? It adds unnecessary complexity when most users wouldn’t notice the difference between an AJAX and full page refresh.

AJAX preserves undo/redo history and cursor position, among other things. Sure, it also makes preserving js listeners and so on less trivial, but there should be a way.

With a clean css slate, it can do this automatically.

Curious to see it.

phiw13 · 2024-11-10 07:13:05

etc wrote #338179:

Good idea, but how to style it so that it takes the width of the selected option?

Asked like that, no, that won’t happen for now. The width of the default <select /> is always min-intrinsic based on the longest <options /> string unless constrained by the usual properties. In the future (probably TXP 5 timeframe) it might be possible.

The question is: does it matter?

etc · 2024-11-10 09:54:40

phiw13 wrote #338183:

The question is: does it matter?

I’d say yes, given how precisely spaces are defined in Sandspace theme :-) If we change this select box as you suggest, it will leave a large gap between the textfilter in Textile mode and the preview button in our current layout. That’s easy to fix with a bit of js, but it would be reinventing the jQuery UI wheel.

What I would like to avoid in a future layout, are these txp-layout-4col-3span classes, that almost imply how every theme should look like. Tough wish..

gaekwad · 2024-11-10 14:22:43

Bloke wrote #338181:

I swear we (or maybe I) started one in the 4.3 era when were sanitising class names. But it’s probably been lost in the mists of time and various doc hosting moves.

Tangentially-related:

github.com/textpattern/textpattern/issues/1711

Last edited by gaekwad (2024-11-10 14:22:54)

Textpattern CMS

Textpattern CMS support forum

#37 2024-11-08 19:45:22

Re: RFC: Textpattern 5 ideas & feature requests

#38 2024-11-08 20:25:40

Re: RFC: Textpattern 5 ideas & feature requests

#39 2024-11-09 09:18:24

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #338175:

#40 2024-11-09 09:32:27

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #338175:

#41 2024-11-09 09:40:12

Re: RFC: Textpattern 5 ideas & feature requests

giz wrote #338174:

#42 2024-11-09 10:23:04

Re: RFC: Textpattern 5 ideas & feature requests

phiw13 wrote #338177:

#43 2024-11-09 20:19:21

Re: RFC: Textpattern 5 ideas & feature requests

Icons

Ajax

etc wrote #338179:

#44 2024-11-09 21:01:50

Re: RFC: Textpattern 5 ideas & feature requests

giz wrote #338180:

#45 2024-11-09 21:48:13

Re: RFC: Textpattern 5 ideas & feature requests

giz wrote #338180:

#46 2024-11-10 07:13:05

Re: RFC: Textpattern 5 ideas & feature requests

etc wrote #338179:

#47 2024-11-10 09:54:40

Re: RFC: Textpattern 5 ideas & feature requests

phiw13 wrote #338183:

#48 2024-11-10 14:22:43

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #338181:

Board footer