Textpattern 5 UI css development

giz · 2024-11-16 18:20:17

This thread continues from RFC: Textpattern 5 ideas & feature requests

giz · 2024-11-16 18:54:37

jakob wrote #338234:

If it’s any help, I made a start at this as a basis for making another admin theme:

https://github.com/jools-r/hive-revo

Unlike your approach, it doesn’t start from scratch but is more of a conversion of Hive v4.9 to use css variables for font sizes and layout parameters as well as logical properties. I also switched from 13pt to 16pt as the base unit. I was tinkering for my own purposes and didn’t use Phil’s build setup or the flat hive variant. Instead it uses parceljs so that you can use state-of-the-art CSS and have it transpiled back for old browsers (parcel uses lightningccs from the same author for this).

I had hoped that by using logical properties (block & inline rather than top, left, bottom, right) it would be possible to dispense with a lot of the LTR / RTL code. However, as yet the browsersl.ist settings seem to insist of transpiling back to language-specific settings rather than leaving the logical properties CSS as is, so the compiled CSS is not markedly smaller (see also this discussion). An update of parceljs with many fixes came out a couple of days ago, which I’ve yet to try.

As such, it’s a work in progress and not directly usable as a theme. I got ahead of myself with the more opinionated theme I was developing and haven’t backported later solutions into this version. But maybe it is of some help all the same.

Thanks!

Talking of old browsers, is there an agreed minimum spec?

In the interests of keeping the css lean, I strongly prefer coding the core css for modern browsers only. Legacy browsers can be catered for via a ‘Legacy browsers’ admin theme (or an extra css file). For the most part I find that legacy browsers deal reasonably well with grid and subgrid etc; the layout doesn’t break, the page just gets longer!

Major simplifications can be made to accommodate LTR / RTL (margin-inline-etc to the rescue). The number of colour variables can also be reduced (particularly the doubling-up for Light / Dark mode):

html {
	--clr-text: var(--black);
	--clr-bg: var(--white);

	color: var(--clr-text);
	background-color: var(--clr-bg);

	@media (prefers-color-scheme: dark) {
		--clr-text: var(--white);
		--clr-bg: var(--black);
	}
}

giz · 2024-11-16 19:26:55

etc wrote #338239:

We won’t have time to change it in 4.9 anyway, but for 5.0, is wrapping content partials in div.txp-layout-4col-3span etc really necessary? Might something like grid-area be more flexible? Currently, content and markup are mixed a bit too much in core, imo.

Suggestions welcome.

From a purely css-grid perspective, key elements want to be direct children of the grid eg.

body.main-grid-class
- header
- .messagepane
- .txp-heading
- .title
- .author
- body
- excerpt
- .txp-save-zone
- etc

or maybe with a couple of container divs if some grouping is preferred:

body.main-grid-class
- header
- .messagepane
- .txp-main
  - .txp-heading
  - .title
  - .author
  - body
  - excerpt
- .txp-sub
  - .txp-save-zone
  - etc

That said, using the current divitus markup is not a big problem (we can use a single _u_explode.scss partial where relevant divs are targeted to use display: contents) — it also allows older admin themes to be used, and maybe also plugins targeting a specific div#name container.

Last edited by giz (2024-11-16 19:28:51)

etc · 2024-11-16 20:09:38

giz wrote #338246:

That said, using the current divitus markup is not a big problem (we can use a single _u_explode.scss partial where relevant divs are targeted to use display: contents) — it also allows older admin themes to be used, and maybe also plugins targeting a specific div#name container.

Oh yeah, display: contents is a mighty flattener! Still, grids seem to make any other grouping than semantic unnecessary? Or do we still need containers to style an entire grid area (say, draw a border)? Sorry for amateurish questions.

giz · 2024-11-16 21:07:11

Mostly, yes you can.

If its a div like .txp-sub in my example above and it has display: contents; then you can’t without using ‘hacks’ like :before and :after to fabricate the borders as grid children.

Last edited by giz (2024-11-16 21:07:57)

phiw13 · 2024-11-17 00:52:16

Or do we still need containers to style an entire grid area

Containers (such as .txp-layout-4col-3span) are still use full for grouping and styling purposes…

(on the use of display:contents, opinions are divided, I personally deeply dislike it, along with things like contain: size etc.).

phiw13 · 2024-11-17 00:54:16

What do others think about having a basic set of core @custom-properties) that themes and plugins can rely on?

As documented in this thread.

Bloke · 2024-11-17 07:51:20

I love css-grid and flexbox, depending on the effect I’m after. Being able to shunt content around into different areas as the viewport changes is brilliant. But it does bring into question the semantic use of things like .txp-layout-4col-3span because at different widths it might not occupy 4 columns or span 3 or whatever.

So if we go grid we should definitely review our container naming conventions. They’re of an era where frameworks like bootstrap were trying to do stuff that CSS grid now does natively (and better).

etc · 2024-11-17 09:05:14

Grid or not (up to theme authors to decide), I do not like using markup for purely styling tasks, it feels like a css failure. So yes, let us try to go more semantic in txp 5.

giz · 2024-11-17 19:16:49

phiw13 wrote #338252:

What do others think about having a basic set of core @custom-properties) that themes and plugins can rely on?

Maybe I missed something in the thread, but I feel this unnecessarily complicates things.

Admin core doesn’t need to know about colours and icons and variations in layout; admin-theme stylesheets should be built around a reduced set of core variables, and then extended further as the theme author sees fit. Plugin authors need only write unclassed semantic html, and shouldn’t need to refer to any variables unless they require a specific override, in which case they can add --clr-text: pink; etc. in the style node of their component.

Regarding the preview panel and its styling, I feel this too belongs as part of the selected admin theme. Older admin themes would still work, albeit without syntax colouring.

If our required reduced set of core variables is overly specific and in two locations, we’re doing it the wrong way; theme authors would need to add many lines of css to cancel them out, meaning we’re downloading more css for zero gain.

giz · 2024-11-17 19:43:24

phiw13 wrote #338251:

Containers (such as .txp-layout-4col-3span) are still use full for grouping and styling purposes…

(on the use of display:contents, opinions are divided, I personally deeply dislike it, along with things like contain: size etc.).

display:contents is just another property in a large arsenal of css properties. It does what it says on the tin; what’s not to like?

Interestingly, it arrived at roughly the same time as css grid; I suspect it was introduced as a way of promoting nodes to be direct children of a grid node.

The alternative is to use something like:

.txp-main {
  display: grid;
  grid-template-columns: subgrid;
  grid-template-rows: subgrid; // likely required depending on context
  grid-column-start: n;
  grid-column-end: -n;
  grid-row: span n; // likely required depending on context
}

when this does the same job:

node1, node2 {
  display: contents;
}

etc · 2024-11-17 22:56:09

giz wrote #338264:

Admin core doesn’t need to know about colours and icons and variations in layout;

Colours I’m not sure, but icons are used by JQuery UI, with its proper markup. Currently every theme author has to style a bunch of .ui-icons. This set is repeated in each of three themes shipped with txp by default. Putting them in a core style-sheet would save few kB and theme authors work. And once we get rid of jQuery UI, we will simply remove these icons from core, rather than asking every theme author.

Regarding the preview panel and its styling, I feel this too belongs as part of the selected admin theme. Older admin themes would still work, albeit without syntax colouring.

Some rules (max-width etc) are reasonably shared by all themes. Preview colours take less than 10 lines of css.

If our required reduced set of core variables is overly specific and in two locations, we’re doing it the wrong way; theme authors would need to add many lines of css to cancel them out, meaning we’re downloading more css for zero gain.

The aim is to outline a common set of rules, necessary for txp functioning and potentially valid for every theme. Whence this discussion.

Also, when we change/add a feature (like previews in shadow dom), a minimal styling is required to make it work. It is much easier to do it in core before themes catch up.

Textpattern CMS

Textpattern CMS support forum

#1 2024-11-16 18:20:17