Textpattern 5 UI css development

phiw13 · 2024-11-24 12:05:57

etc wrote #338328:

Took me 3 attempts. Browsers diversity is still fun.

The header cursor is set via css, but browsers default behaviour on drag is not very uniform neither. I’m fine with it, adding an extra event listener might be bad for the fluidity.

cursor: grabbing would eventually be more appropriate (rather that copy); there is no dragging cursor. JQUI uses cursor:drag the whole time.

Yes, especially if they support css resize. Safari on iOS has some time to catch up before txp5 release.

that would lovely, one day in my next life, maybe.

phiw13 · 2024-11-24 12:10:37

Bloke wrote #338329:

This, +100. Anything you can do to make it more complete before 4.9 drops will be a boon, but if it has to wait till Txp 5 then so be it. There are definitely some gaps in the library.

At this point I think it would be better to wait for TXP 5. Unless you plan to wait another 6 month before release…

stylesheets might need updating, widget might need to testing, etc, etc, etc.

etc · 2024-11-24 12:30:46

Bloke wrote #338329:

retrofitting lAtts() (maybe?) with some kind of attribute registry …

looks tricky, since not all plugins are loaded on the admin side, and arbitrary forcing tags execution might be hazardous. I’d rather prefer registering tags/attributes on plugin install, by introducing some ‘register’ life cycle event. No clear idea atm.

phiw13 wrote #338330:

cursor: grabbing would eventually be more appropriate (rather that copy); there is no dragging cursor. JQUI uses cursor:drag the whole time.

Browsers reset it on every pointer move (or rather I don’t know how to prevent it). We’d need to register an ondrag listener (more or less like jQUI), but it might be expensive. We do it on touch devices (they don’t seem to support drag’n‘drop API), you can compare the mouse vs touch fluidity on a laptop with a touch screen.

At this point I think it would be better to wait for TXP 5. Unless you plan to wait another 6 month before release…

Agree. I would release 4.9 asap and turn the page.

etc · 2024-11-27 21:45:48

Bloke wrote #338329:

retrofitting lAtts() (maybe?) with some kind of attribute registry (or vice versa: build a registry and have the tags and builder read from it, though that could break encapsulation and means plugins need to catch up) would mean less code repetition and less chance of the tags and builder drifting out of sync.

Well, this was too tempting, so I’ve added getAtts() function to Registry:

<txp:php>
global $production_status;
// Silence warnings
$production_status = 'live';
$registry = Txp::get('\Textpattern\Tag\Registry');

foreach($registry->getRegistered() as $tag => $f) {
	echo "<h4>$tag</h4>";
	dmp($registry->getAtts($tag));
}
</txp:php>

Use with caution: if a (core or plugin) tag does not call lAtts() or calls it too late, its code will be executed.

jakob · 2024-11-29 22:32:37

etc wrote #338359:

Use with caution: if a (core or plugin) tag does not call lAtts() or calls it too late, its code will be executed.

I can see that would be the case with your code running every tag there, but are there general implications that plugin authors need to be aware of? And if so, what would I need to check in existing plugins? I can see you’ve implemented it on GitHub.

etc · 2024-11-29 23:26:00

jakob wrote #338377:

are there general implications that plugin authors need to be aware of? And if so, what would I need to check in existing plugins?

A typical tag looks like this:

function my_tag($atts, $thing = null)
{
    global $pretext; //for example

    extract(lAtts(array(
        'name'    => '',
        'value'    => '',
    ), $atts));

    /* plugin code */

    return $out;
}

As long as lAtts() is called before something risky is executed, it should be safe, because the function exits immediately (via an Exception) after lAtts(). Most plugins adhere to this workflow, but there is no guaranty.

giz · 2025-01-12 20:35:23

I’ve made progress in developing a css approach for the UI.

Core HTML nodes: Content: Write page is complete
Core SASS: Sets up the base styling with micro-layout only
Prototypes & Laboratory: Uses the Content: Write page as a guinea-pig for macro-layouts; various themes test the flexibility of the css. Twiddle sliders to boss around :root variables.

The css is flexible; developers and plugin authors can inject html virtually anywhere and be confident that it’ll fit / flow with its neighbours without breaking the layout.

Comments & suggestions, please.

Notes:

My attempts use <details> tags in place of the original <section>s in the sidebar. While this has advantages, I discovered that you can’t apply display: grid; to details tags — and can’t do interesting stuff like this. In my next attempt I’ll revert back.
I wanted to hide much of the sidebar contents behind a toggle for small screens, but needed a title for the sidebar for this to be effective (an icon alone wouldn’t do alone as the toggle). I’m requesting a new text string in core language tables as a title for the sidebar. ‘Article details’, ‘Details’ or ‘Organisation’? The title is hidden at larger sizes.
In each of my layouts, one snippet of html was a constant headache: <input name="Title" type="text" id="title" size="64" maxlength="255" placeholder="Required" value="" required="" spellcheck="true">. The size="64" is too long to fit in small screens or containers, and so needs cajoling via css to fit. Can we lower the size or drop all sizing attributes on inputs and textareas, leaving this to the css?

I used com_article_image to generate the content of Article Image in the sidebar (styling is handled via core.css).

Both Five and Jekkyl are hampered by Article Image being located in the sidebar; at larger sizes I want this to ‘break-out’ from the sidebar so it can be independently located at large screen sizes.

How does everybody feel about allowing Article Image and Custom Fields to break out of the sidebar? They are more ‘content’ than ‘organisational’… The obvious downside is that this would likely break older admin themes :(

The only alternative I can think of is using an admin-theme supplied javascript to move the nodes if required.

colak · 2025-01-13 14:55:35

giz wrote #338754:

How does everybody feel about allowing Article Image and Custom Fields to break out of the sidebar? They are more ‘content’ than ‘organisational’… :(

There are sites that would not work efficiently as a continues up and down scroll may be needed to insert the content. Also, custom fields can also be organisational in article custom lists. ie in most simple terms think of the apples, oranges, pears lists, which define which articles appear on a particular page and which do not.

giz · 2025-01-13 16:37:05

colak wrote #338757:

There are sites that would not work efficiently as a continues up and down scroll may be needed to insert the content.

We currently have:

div.txp-layout-4col-alt
  div#txp-article-actions.txp-save-zone
  div#supporting_content
    p.txp-actions
    section#txp-write-sort-group.txp-details
    section#txp-dates-group.txp-details
    section#txp-categories-group..txp-details
    section#txp-meta-group.txp-details
    section#txp-image-group.txp-details
    section#txp-custom-field-group.txp-details
    section#txp-recent-group.txp-details

I’m on the fence about suggesting:

div.txp-layout-4col-alt
  div#txp-article-actions.txp-save-zone
  div#supporting_content
    p.txp-actions
    section#txp-write-sort-group.txp-details
    section#txp-dates-group.txp-details
    section#txp-categories-group..txp-details
    section#txp-meta-group.txp-details
    section#txp-recent-group.txp-details
  section#txp-image-group.txp-details
  section#txp-custom-field-group.txp-details

Scrolling wouldn’t be affected…

Bloke · 2025-01-13 17:04:17

giz wrote #338754:

How does everybody feel about allowing Article Image and Custom Fields to break out of the sidebar?

For sure, but it should be application dependent. And this is one reason I do not want to tie custom fields to sections by default.

For starters (at present) only articles have sections so it wastes storage space to store it for all other content types.

Perhaps if we unify content types somehow (and Oleg has ideas about how to achieve this) then tying fields to sections is more doable. But if we’re going to do that, I would prefer a dedicated column for it.

I have a dirty plugin that adjusts the available fields on the fly when you change section. All it does is hide the ones that don’t match the section name. But there’s the question mark over what we do with data that’s not in scope. Currently it’s still “on the page” hidden so gets stored, which is mildly irritating, especially when it comes to outputting it and iterating over fields with data in them.

Why do I mention all this? Because, at the moment, we have implemented a “family” column which is an optional, freeform field that you can use for grouping content however you like. Core does not wire this up in any way.

With my article field=>section mapping plugin enabled, the family column is wired as mentioned above on the Write panel. Fields appear in the panel only if the section matches one of the comma-separated family entries for that field. This feature is unused on the other panels at present, but it could be used to group them into dedicated areas on the Images or Files panel, for example.

Now, if giz wants to move the article image and some custom fields out of the Custom Fields twisty area, he could specify the family as, I dunno, main and then write a ten-line plugin to intercept the rendering of the fields to divert anything with family=main into the main content column.

The point? The family is your tool to do whatever you or the community wants with it, combined with plugins to deliver custom content capture/display across content types.

If we hardcode one application (e.g. section mapping), then we can’t use it for something else.

There’s nothing to stop you doing both of course. Say you named your custom fields according to a convention and added a suffix with the section name (e.g. location_forsale). You could write a plugin that checked the name of each field and only showed fields that match the suffix of the currently selected section. Then you have the family field available to determine which column it goes in.

Or you could name your fields like location_forsale_main and code your plugin to interpret that convention as fieldname_section_column. That frees up the family column for something else entirely, maybe to group the fields into their own twisty areas on the panel.

The point is, by not hardcoding this field, everyone benefits from (ab)using the field names and family to achieve complex layouts and business logic.

jakob · 2025-01-13 22:14:38

Congratulations on the progress you’ve made. Fascinating to see your different layout and skinning variants.

BTW: any chance of perusing the scss via GitHub? Just find it easier to view in combination in a text editor, rather than clicking on each page.

Regarding content vs. organisation, I also shift custom fields and images around, but more depending on the priority I think they should have for a particular site (or site’s users) than any semantic principle.

phiw13 · 2025-01-14 00:49:24

giz wrote #338754:

How does everybody feel about allowing Article Image and Custom Fields to break out of the sidebar? They are more ‘content’ than ‘organisational’… The obvious downside is that this would likely break older admin themes :(

The distinction I see is strictly data “content” – article body, article excerpt – and “meta data” – dates, custom field, description, author and custom fields – and then “organisational & presentational” data – categories, sort and display. The latter two groups fit well in a side column.

Article image does not fit in that second group as it is more of a content type.

–^–

PS I hope it is not your idea to make your stylesheet work build-in into Core; I see very little to nothing I could use. Make it available as a theme is OK, just like there are core themes now.

etc · 2025-01-14 10:58:59

Bloke wrote #338759:

Perhaps if we unify content types somehow (and Oleg has ideas about how to achieve this) then tying fields to sections is more doable. But if we’re going to do that, I would prefer a dedicated column for it.

I have more wishes than ideas, but abstracting the notion of content looks natural. Why the images deserve a special treatment, but not the audio, say? Why a physical image needs a caption? It’s just a set of pixels per se. A picture of two persons can represent ‘me and my father’ in some article, and ‘me and my son’ in another one.

And if we manage to unify content types, txp code/interface will become less redundant.

giz · 2025-01-14 16:19:21

jakob wrote #338762:

BTW: any chance of perusing the scss via GitHub? Just find it easier to view in combination in a text editor, rather than clicking on each page.

Will do. I first need to change my directory structure, which has been ad-hoc.

giz · 2025-01-14 16:34:35

phiw13 wrote #338763:

PS I hope it is not your idea to make your stylesheet work build-in into Core; I see very little to nothing I could use. Make it available as a theme is OK, just like there are core themes now.

I didn’t realise there was a boss-level when contributing to Textpattern. Why on earth would I go to so much effort for ‘another theme’?

Textpattern CMS support forum

#31 2024-11-24 12:05:57

Re: Textpattern 5 UI css development

etc wrote #338328:

#32 2024-11-24 12:10:37

Re: Textpattern 5 UI css development

Bloke wrote #338329:

#33 2024-11-24 12:30:46

Re: Textpattern 5 UI css development

Bloke wrote #338329:

phiw13 wrote #338330:

#34 2024-11-27 21:45:48

Re: Textpattern 5 UI css development

Bloke wrote #338329:

#35 2024-11-29 22:32:37

Re: Textpattern 5 UI css development

etc wrote #338359:

#36 2024-11-29 23:26:00

Re: Textpattern 5 UI css development

jakob wrote #338377:

#37 2025-01-12 20:35:23

Re: Textpattern 5 UI css development

#38 2025-01-13 14:55:35

Re: Textpattern 5 UI css development

giz wrote #338754:

#39 2025-01-13 16:37:05

Re: Textpattern 5 UI css development

colak wrote #338757:

#40 2025-01-13 17:04:17

Re: Textpattern 5 UI css development

giz wrote #338754:

#41 2025-01-13 22:14:38

Re: Textpattern 5 UI css development

#42 2025-01-14 00:49:24

Re: Textpattern 5 UI css development

giz wrote #338754:

#43 2025-01-14 10:58:59

Re: Textpattern 5 UI css development

Bloke wrote #338759:

#44 2025-01-14 16:19:21

Re: Textpattern 5 UI css development

jakob wrote #338762:

#45 2025-01-14 16:34:35

Re: Textpattern 5 UI css development

phiw13 wrote #338763:

Board footer