Question about positioning for inline editor menu

[Lxstr]

Documentation Question

Hi DDG!

I am using the inline editor and I would like for the positioning on the sticky toolbar to push up neighbouring elements (the editable) when active. Current the position is over the elements.

So far I have tried a few different approaches including rearranging the components and height variables.

The closed I got was:

div.deckgo-tools-activated {
  --deckgo-inline-editor-position: static;
}

My code arrangement is

<div style={{ 'overflow-y': 'auto', 'height': '100%' }} contenteditable class=" ion-padding">
        <div id="output-text"></div>
      </div>,
      <deckgo-inline-editor
        containers="h1,h2,h3,h4,h5,h6,div"
        sticky-desktop="true"
        sticky-mobile="true"
        img-editable="true"
        font-size="true"
        background-color="true"
        class="hydrated"
      ></deckgo-inline-editor>

Is there any easy was to do this?

My current code:
https://www.robowrite.app/output

Affected documentation page: https://docs.deckdeckgo.com/?path=/docs/components-inline-editor--inline-editor

Thanks for this great WYSIWYG editor!
Cheers, Lex

[peterpeterparker]

Hi Lex,

Not sure I get what you mean. I tried https://www.robowrite.app/output but did not find the inline editor, therefore I am a bit confused about both the issue and the expectation.

Can you provide a screenshots / mockups or something?

That would help me gets the context, thx in adance.

[Lxstr]

I think I was hoping to have the sticky editor 'push up' (or down) the editable view rather than overlay itself. When you select text near the toolbar it often covers the text. Does that make sense?

[peterpeterparker]

Thank you for the screenshots.

1. About "sticky"

The sticky-desktop is indeed the property to be used to make the editor not overlay but, appear at the bottom. It can be displayed at the top but, only on iOS.

Therefore if you want it to be sticky and appear at the top, it would need an enhancement in the code.

Do I understand correctly that part?

Note: the inline editor is mostly though to work as an overlay editor and to be sticky on mobile devices. If you want something sticky all the time maybe other wysiwyg editor as https://www.tiny.cloud/ are more suited for your use case?

2. About "covers the text"

Regarding your statement "text near the toolbar it often covers the text", did you notice this in DeckDeckGo, our editor for presetations? Can you provide another screenshot example?

Not sure it can be solved in that form though, it's really trick to have both a floating wysiwyg editor in addition to the native wysiwyg options displayed by the os in addition to the keyboard/window size changing or not.

[Lxstr]

Hi David,

Thanks for the clarification. I'm having more of a play around with it the last few hours and I'm still getting to understanding it.

Definitely don't see any need for a sticky desktop editor. I was confusing there because I was testing on my browser, hence the screenshot of the sticky at the bottom and selecting sticky-desktop.

Haven't actually implemented any of the other WYSIWYGs (only researched them) but I quite like DDG editor because it only shows when text is selected.

Also, totally hear you regarding changing window sizing.

I think that way it works in ios DDG is great because it just covers the existing Nav bar, but currently it goes under my nav bar so I'll look into why that is.

I have a few other things floating around in my head as I've been playing with the code and I'll do a little more next week.

For example something different but related :

• Flex-wrap for narrow screens where the toolbar doesn't fit which I've coded but it because it goes two lines down would be more likely to cover high up text that a user has selected when in sticky mode.

[peterpeterparker]

Cool! If you play with the code let me know if you find any ways to simplify its code base. Kind of think it is over-complicated for what it does 🤷‍♂️. Really took me quite some time to implement, inputs really appreciated.

Regarding "flex-wrap", that would be a solution. Another one would maybe be to make the options smaller and therefore use less space?

If have to say we do not have that issue IRL in our editor because we reduced the amount of options. Less options, less space, problem solved 🤣.

I don't have currently much time to implement anything if you would discover any issues or else but for sure, really happy to hear all your suggestions and questions. Keep me posted!