Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern 5 UI css development
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
:rootvariables.
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 applydisplay: 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">. Thesize="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.
Offline
Re: Textpattern 5 UI css development
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.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Textpattern 5 UI css development
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-detailsI’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-detailsScrolling wouldn’t be affected…
Offline
Re: Textpattern 5 UI css development
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern 5 UI css development
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.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Textpattern 5 UI css development
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.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
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.
Offline
Re: Textpattern 5 UI css development
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.
Offline
Re: Textpattern 5 UI css development
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’?
Offline
Re: Textpattern 5 UI css development
Bloke wrote #338759:
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.
Sounds intriguing; I’m looking forward to how this all develops…
Last edited by giz (Yesterday 16:49:32)
Offline
Re: Textpattern 5 UI css development
etc wrote #338766:
And if we manage to unify content types, txp code/interface will become less redundant.
Excellent! Will com_article_image remain as a plugin, or be rolled into core?
Offline
Re: Textpattern 5 UI css development
giz wrote #338781:
Sounds intriguing; I’m off to play with Pete’s demo site…
Note etc’s advisory here: forum.textpattern.com/viewtopic.php?pid=338777#p338777
Edit: but you’re always welcome at Casa de Demo Site, amigo!
Last edited by gaekwad (Yesterday 16:50:42)
Offline