Module chrome without card header - edit icon overlaps dropdown buttons and texts

[chmst]

What needs to be fixed

Impossible to open a submenu in this case:

If a module is displayed without title AND the user may edit, then the area for the edit button must have mor height

[richard67]

Oops.

[chmst]

I would prefer that the edit symbol is always visible , not only on hover.

[richard67]

Ping @infograf768 : Could you check @chmst 's previous comment?

[infograf768]

I am now preparing an eclipse project of this Cassiopea stuff.
I may look at things tomorrow.

[infograf768]

I don't remember if we had a discussion on this when it was implemented.
I sort of think that it should behave like the article or contact and be present when user can edit.
But, in some cases, it would break the display so much that I have mixed feelings.

the best solution may be to display the tooltip up, at the top limit of the module. Not sure we can. And, in any case not sure either our frontend tooltips are a11y.

[infograf768]

For now the tooltip placement is "auto"
If we modify to "top", we will get (mobile screencapture)

It's automatically contained in the window btw.

cassiopeia/build/media_source/legacy/js/frontediting.es5.js

Line 29 in 47b44d3

.tooltip({container: $('.jmodedit').parent(), html: true, placement: 'auto'});

[richard67]

As far as I understand, the problem is not the tool tip but the icon. It overlaps the metismenu toggle when using a metismenu in the sidebar, e.g. by moding the "Main Menu Blog" module to there.

[infograf768]

That's a totally other issue.

[infograf768]

I nevertheless suggest to change tip placement as the issue of the tip covering up the first link in other types of modules is present. (In 3.x it is set to top by default)
Also, we have a huge margin-left for the <ul> in the modules in general we should get rid of and I could not find where that comes from.

I could solve it by using (for LTR). But it has to be more specific as this mod-list is used in other modules and breaks them.

.mod-list {
    margin-left: -2rem;
}

To solve the overlap problem, some changes in the css will make it

.btn.jmodedit
{
  z-index: 1001;
  display: block;
  position: absolute;
  top: -1rem; // proposal
  right: -1rem; // proposal
}
html[dir=rtl] .btn.jmodedit
{
    right: auto;
    left: -1rem; //proposal
}

This gives (modified css a bit vs the animated gif below)

and use

I remark that the submenu is hardly differentiated from its parent.

Note

With metismenu we have lost the edit menu item possibility.

[chmst]

The edit buttons are added via frontendediting.js. This makes changes difficult. And in my opinion it is not userfreindly that the edit button is visible only with hover.

A good an simple and a11y solution could be (in core as this is rendering modules): If editing a module is possible: Add a new line on top of the module, containig the edit icon + edit label as in articles and contacts.

If this is not possible, adding some more padding-top to a metismenu in the sidebars could do it too.

[chmst]

Same issue here on small screen: It is not possible to open the menu - the edit button is nearyl invisible on the dark background.

[infograf768]

If this is not possible, adding some more padding-top to a metismenu in the sidebars could do it too.

I am afraid it is the only way to go. But it should be done only when frontendediting is set.
I saw no way for now to render an edit icon without the js. And no way to integrate menu item edit when using metismenu.

[infograf768]

@chmst
Only way I found is to totally get rid of the js, modifying the layout and also the chromes.

Proof of concept (did not correct all css)

[chmst]

If we add a div (100% width) bove the module content, it looks like this: