Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
phiw13 on Codeberg
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
phiw13 on Codeberg
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
Re: Textpattern 5 UI css development
Offline
Re: Textpattern 5 UI css development
etc wrote #338310:
I’m experimenting with vanilla JS replacement for jQuery UI, please test.
Draggable Dialog (based on HTML
draggableinterface) 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 :)
Offline
Re: Textpattern 5 UI css development
etc wrote #338310:
I’m experimenting with vanilla JS replacement for jQuery UI, please test.
Draggable Dialog (based on HTML
draggableinterface) 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.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Offline
Re: Textpattern 5 UI css development
etc wrote #338320:
Thank you. I have slightly reworked the Draggable one, it should be compatible with (some) touch devices now.1
1 Nota bene: jQuery UI does not seem to support touch-drag.
Safari (and console error below)
- dragging does not work (1px then another 1px then the drag movement selects text in the dialog and in the background)
- the movable dialog is present immediately under the draggable one
Firefox:
- draggable dialog seems to work
- movable dialog is present at top left of page
TypeError: $.plot is not a function. (In '$.plot($("#flot"), [{ color: "#942C1E", data: d}], { xaxis: { mode: "time", tickLength: 0, show: false}, yaxis: { show: false }, grid: {borderWidth: 0, hoverable: true, clickable: true } })', '$.plot' is undefined)
jquery.min.js:2:31678I dont’t think a draggable dialog makes much sense on a small-screen device. On a tablet like device that could sometimes be helpful, although iPadOS is definitely not geared towards that sort of actions.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: Textpattern 5 UI css development
phiw13 wrote #338322:
Safari (and console error below)
- dragging does not work (1px then another 1px then the drag movement selects text in the dialog and in the background)
- the movable dialog is present immediately under the draggable one
Yep, I see, thank you. It is related to this bug (?) and needs some refactoring.
I dont’t think a draggable dialog makes much sense on a small-screen device. On a tablet like device that could sometimes be helpful, although iPadOS is definitely not geared towards that sort of actions.
Anecdotically, it works quite well now on iOS and iPadOS I have tested, both with finger and pen.
Offline
Re: Textpattern 5 UI css development
etc wrote #338324:
Yep, I see, thank you. It is related to this bug (?) and needs some refactoring.
I see you have made some progress to have the dragging work on Safari, and Brave (Chromium). All 3 main desktop rendering engines now work.
Interesting tidbit: Safari and Firefox show the default cursor icon while dragging. Brave shows the copy cursor icon. All 3 show the move cursor icon before/after dragging when hovering over the header.
Note: could you remove that non-functional “Movable dialog” while testing? It is kinda confusing to have it there esp if you don’t plan to use it anyway
Anecdotically, it works quite well now on iOS and iPadOS I have tested, both with finger and pen.
Fine, thank you for testing those. I haven’t had time to do it. I still don’t see any point dragging the dialog around on small screen devices. On tables like devices, it certainly can be useful.
–^–
Where do you intent to use this? The preview dialog on the write panel, the tagbuider dialog on pages and forms.
For the inline help widget, the popover api (help example) might be interesting.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: Textpattern 5 UI css development
phiw13 wrote #338326:
I see you have made some progress to have the dragging work on Safari, and Brave (Chromium). All 3 main desktop rendering engines now work.
Took me 3 attempts. Browsers diversity is still fun.
Interesting tidbit: Safari and Firefox show the default cursor icon while dragging. Brave shows the copy cursor icon. All 3 show the move cursor icon before/after dragging when hovering over the header.
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.
Note: could you remove that non-functional “Movable dialog” while testing? It is kinda confusing to have it there esp if you don’t plan to use it anyway
It’s hidden now.
I still don’t see any point dragging the dialog around on small screen devices. On tables like devices, it certainly can be useful.
Yes, especially if they support css resize. Safari on iOS has some time to catch up before txp5 release.
Where do you intent to use this? The preview dialog on the write panel, the tagbuider dialog on pages and forms.
For the inline help widget, the popover api (help example) might be interesting.
Stef has written a nice txp UI library, but it needs to be completed with a bit of js to enhance the user interaction. jQuery UI looks outdated, the plan is to replace it with vanilla js. Preview, certainly. As for the tagbuilder, it needs to be refactored (if we decide to keep it). The current hard-coded implementation makes it outdated on each tag/attribute addition/removal. We need to find a way to register (core or plugin) tags with their attributes to automate the construction.
Offline
Re: Textpattern 5 UI css development
etc wrote #338328:
Stef has written a nice txp UI library, but it needs to be completed with a bit of js to enhance the user interaction.
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.
jQuery UI looks outdated, the plan is to replace it with vanilla js.
Yes yes yes.
As for the tagbuilder, it needs to be refactored (if we decide to keep it).
Yes, we should keep it. I was surprised at how many people actually use it. But it’s a royal pain to keep in sync with the real tags, so anything that can be done to reduce the load and have it grab attributes and implementation info from core code works for me.
As you say, 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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline