Can we develop a better drop-down css in TW

#1

The class tc-drop-down is widely used in TW.
You encounter in the search, whenever you make a toolbar-dropdown …
This multiple usage sometimes causes design-issues.
To name the two that trouble me the most.

  • It is quite often off the screen.
  • The class contains also properties for the buttons within, like the width of 100% which makes it difficult to use buttons that fit the content.

I would like to collect the issues in this thread and rethink what is necessary for that class - or whether more classes are necessary for the various purposes. Perhaps we could even get a mobile-stylesheet

3 Likes
Advanced Search in Fields Plugin: New Updates
#2

I would add an easy to use drop down solution that can be cloned and reworked by users with a configurable filter, type ahead and keyboard selection would be a useful inclusion. One configuration of which could be used for a custom tags pill, or select values for a field or add remove tiddlers titles from a list would be very helpful. Such a generic solution could be designed with CSS customisation in mind, perhaps a cloneable stylesheet for the generic solution “instances”. ie not using tc-drop-down.

To me making the core CSS more usable is a herculean task, so why not provide a “drop down” solution independent of the core with its own friendly CSS.

In this package I make use of the tag dropdown to introduce features;
reimagin-tags.json (9.5 KB) just install and click on any tagpill; to see examples of what one can do with a nice drop down.

This example however does not try and fix or customise CSS because its difficult.

but one independent of the tag dropdown and search drop downs with sufficient documentation would be nice.

#3

Hi @TW_Tones thanks for your ideas. I’d like to see them at work in a demo.

For the dropdown I would like to have the properties devided into

  • one class that mainly does the positioning of the pop-up according to where on the screen it pops up and to the size of the screen
  • classes for the content that can be added to the pop-up. E.g. for the toolbar-buttons it would be nice if a second class could be added within a field.

BTW. : Tony, you were interested in the mod of a dynannotate-plugin with a viewtemplate for comments and annotations working out of the box. It is ready here … except for the styling of the dropdown.

1 Like
#4

@JanJo i may need to admit i have not found it easy to understand the dynanote thing at all. Its on my list of reseach subjects but i realy have no idea. I have gotton lost in a few attempts so far. I may be wrong but it seemed laced with jargon and prerequsit knowledge not documented.

#5

There are two parts that determine how the dropdown is displayed.

  • the class tc-drop-donw, as you say.
  • The reveal widget (where/what is the dropdown) with type popup and position with its value. The value used in position attribute is really important because it creates a inline style. The inline styles have higher specificity than other used styles (without !important)

For example in $:/core/ui/TagTemplate we have

<$reveal state=<<qualify "$:/state/popup/tag">> type="popup" position="below" animate="yes" class="tc-drop-down">
...
</$reveal>

it will be rendered as

<span class="tc-drop-down tc-reveal tc-popup" style="position: absolute; z-index: 1000; left: 0px; top: 19px;">
...
</span>

The CSS maybe need a rework for ease the customization. But the first is solving the issues from javascript of reveal widget to it work correctly with the class tc-drop-down and how to solve the position of the popup in the screen.

3 Likes
#6

Hi Alvaro,
thanks for the explanation, this is truely enlighteneing. :sun_with_face:
But in some cases like in the Editor-Toolbar-Dropdown you do not have the option to configure the dropdown that way because the structure is already given.

#7

I understand that is structure for you.

The difference between dropdown in editor toolbar and tiddler are tiddler toolbar is the content. In editor you have a button with image inside and a text (outside of button). In the tiddler toolbar are button with image and text inside.

Maybe I don’t expain correctly the following.

  • In $:/core/ui/TagTemplate, the reveal is the dropdown.
  • In $:/core/ui/Buttons/more-tiddler-actions, the reveal widget wraps the element with tc-drop-down class.
<$reveal state=<<qualify "$:/state/popup/more">> type="popup" position="belowleft" animate="yes">

<div class="tc-drop-down">
#8

Ciao Alvaro,
my problem is this:

.tc-drop-down a, .tc-drop-down button {
	display: block;
	padding: 0 14px 0 14px;
	width: 100%;
	text-align: left;
	color: <<colour foreground>>;
	line-height: 1.4;
}

and this

.tc-drop-down .tc-tab-buttons button {
	background-color: <<colour dropdown-tab-background>>;
}

which is in the standart stylesheet.

The editor-toolbar-button-dropdown is automatically build in this
$:/core/ui/EditTemplate/body/toolbar/button

#9

Why is it a problem for you?

Because I think your problem is similar/equal to one that @TW_Tones had with the buttons in toolbars. But it isn’t a problem with toolbars or dropdown, it is a problem with the specifity in styles in TW. Because to restyle a element you need have a selector with same or more specifity than the “original”.

#10

@Alvaro it seens to me its not nessasarily that we need to know selectors and specificity, altough we do. It is we need to know tiddlywikis css and html tags to identify how to be specific within tiddlywikis framework.

#11

Hello @Alvaro thanks, I will reread this.
But it would be nice if the classes were constructed in more modular way so that you did not have to escape unwanted properties.

#12

It would, that’s true. But the blame cannot be laid at TiddlyWiki’s door. The design of CSS itself is not very modular. Things might improve when we get what we’ve long been waiting for:

https://drafts.csswg.org/css-nesting/

#13

@TW_Tones , I agree. Because I said

it is a problem with the specifity in styles in TW

But until refactor of styles we will need to use the specifity to solve it.

#14

I think we do not need to nest classes, we could simply add the properties of two classes.

For the toolbar-dropdown we could add wikify/join together a class for the position of the popup which could be default together with a class transcluded from an a class field of the button for the content.

#15

Does the scoped attribute help you?

1 Like
#16

Thanks, I will give it a try, together with @Alvaro 's hint.

#17

A few thoughts:

  • The issue with the popups being offscreen is a JS issue, not CSS.
  • For backwards compatibility reasons we cannot realistically change the existing CSS classes.
  • The tc-drop-down class doesn’t really have anything to with positioning, only the appearance of the popup (width, borders etc). So where you have control over the $reveal widget you can just specify a different class name and style it yourself.
  • For situations like the editor toolbar button dropdowns:
    • the easiest option at present might be to wrap the contents of the dropdown in a DIV with a custom class like “janjo-drop-down”. Then use the selector .tc-drop-down .janjo-drop-down to scope the CSS for the links and buttons inside it.

In terms of core improvements, we should consider extending the editor toolbar button mechanism to support a dropdown-classes field that if present for a button tiddler, specifies the class name to use for the div inside the $reveal widget instead of tc-drop-down. Note that we already support a button-classes field.

1 Like
#18

That is extremely informative, I think!

I think, on this issue, which there has been a lot of sweat over, over a long time, it is actually very helpful to…

… better identify the base issues!

Hats Off!

Just a comment
TT

#19

Old reported issue of relevance to this.

1 Like
#20

https://daemonite.github.io/material/docs/4.0/components/dropdowns/

This is a design I would like, it automatically goes up if there is not enough space below.

1 Like