[2.0/serendipity_event_freetag] use like categories
Re: [2.0/serendipity_event_freetag] use like categories
Wo genau ist das Problem mit den Unterkategorien? Die müssten meines Erachtens nur unter der Elterkategorie angezeigt und das Label mit einem Whitespace eingerückt werden.
Re: [2.0/serendipity_event_freetag] use like categories
English forum, remember?
The issue with subcategories is that there is no good way to layout this in a responsive context so that child categories align below their parent categories and save space at the same time.
About the only sane way to do this would be CSS3's multi-column layout, and that is not supported very well yet (IE8 and 9 don't support it at all, so we would need a fallback for that anyway – even more CSS needed). What's worse, it unfortunately doesn't work well with long category names.
With multi-column off the table, the remaing solution is floats (or inline-block, but that's harder to calculate and has the same issues as floats). If you float elements with the current markup, child categories align next to their parents, so parents and children would need to be grouped. If parents and children are grouped, you get large containers (parents with children) next to small containers (categories without children), resulting either in a very messy layout or in a layout that does not really save space (because it would clear the floats in order to get “true” rows and columns, which means there is whitespace below categories without children aligned next to categories with children).
There are jQuery plugins to solve this like Masonry, but I really don't want to add another jQuery plugin just for this.
YL
The issue with subcategories is that there is no good way to layout this in a responsive context so that child categories align below their parent categories and save space at the same time.
About the only sane way to do this would be CSS3's multi-column layout, and that is not supported very well yet (IE8 and 9 don't support it at all, so we would need a fallback for that anyway – even more CSS needed). What's worse, it unfortunately doesn't work well with long category names.
With multi-column off the table, the remaing solution is floats (or inline-block, but that's harder to calculate and has the same issues as floats). If you float elements with the current markup, child categories align next to their parents, so parents and children would need to be grouped. If parents and children are grouped, you get large containers (parents with children) next to small containers (categories without children), resulting either in a very messy layout or in a layout that does not really save space (because it would clear the floats in order to get “true” rows and columns, which means there is whitespace below categories without children aligned next to categories with children).
There are jQuery plugins to solve this like Masonry, but I really don't want to add another jQuery plugin just for this.
YL
Re: [2.0/serendipity_event_freetag] use like categories
So this is my current take on the tags overlay:
https://www.dropbox.com/s/rpcceawtk4atf ... 5.png?dl=0
What I did:
* input field first, then clickable tab list; move done button to upper right
* save space by dropping the A-Z indicators; frankly, I don't thing they really help scanning a cluttered tag list, but they waste some space
What I thought about but didn't opt for:
* put input field and tags list in tabs
* make the tags list collapsible
Both for the same reason: it's not really necessary. If users don't want or need the clickable tags list and would like a more “clean” overlay, they can just disable it in the plugin config. No need to have extra JS for this just because we can.
Frankly, I'm out of ideas here. Yeah, we could reduce the font-size in the tab list to save more space, but that's not really readable. Also, it's a stopgap solution – with a large enough list of tags and/or a small enough browser window, the overlay will still have to be scrolled to see all tags. (That being said, it will be possible using the backend's user stylesheet.)
Basically the only real solution to really limit the number of tags efficiently to avoid scrolling here would be to only emit the “most used” tags – I can't implement that, that's something for a plugin developer.
I've just committed the latest changes for this to core and additional_plugins and will consider this issue closed for the time being, at least concerning my ability to improve it. Sorry, but this will have to do for the time being.
YL
https://www.dropbox.com/s/rpcceawtk4atf ... 5.png?dl=0
What I did:
* input field first, then clickable tab list; move done button to upper right
* save space by dropping the A-Z indicators; frankly, I don't thing they really help scanning a cluttered tag list, but they waste some space
What I thought about but didn't opt for:
* put input field and tags list in tabs
* make the tags list collapsible
Both for the same reason: it's not really necessary. If users don't want or need the clickable tags list and would like a more “clean” overlay, they can just disable it in the plugin config. No need to have extra JS for this just because we can.
Frankly, I'm out of ideas here. Yeah, we could reduce the font-size in the tab list to save more space, but that's not really readable. Also, it's a stopgap solution – with a large enough list of tags and/or a small enough browser window, the overlay will still have to be scrolled to see all tags. (That being said, it will be possible using the backend's user stylesheet.)
Basically the only real solution to really limit the number of tags efficiently to avoid scrolling here would be to only emit the “most used” tags – I can't implement that, that's something for a plugin developer.
I've just committed the latest changes for this to core and additional_plugins and will consider this issue closed for the time being, at least concerning my ability to improve it. Sorry, but this will have to do for the time being.
YL