You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I assume because its a web edit, then you can parse the change on the server and detect the actual page size.
The big issue of course is that the left side only takes up one line and the right side takes up whatever the image height is. For now the only way is to add "padding" on the left side, until a true Designer system is done. The padding could be a Box with a big X. The actual markdown can be in the top left. of that Box, so you can still edit it. The Box could be a background SVG image so its resolution independent. The size of course of the SVG matches the size of the image ( on the right ). Now scrolling works again properly.
The same is true for all markdown really. The size on the left has no bearing with the size on the right. I could tell a markdown system that I want h1 and h2 to be huge when rendered.
The scrolling will get out of sync on the left and right side because of this.
another way to design editors
This might be annoying or useful. Dont know..
A real time designer using HTMX can literally edit the right pane, and as you go into each item and click you get a mini editor for that markdown type loaded in. You do not type markdown, but edit the markdown via the Designer that is specifically designed for that markdown type.
For text it's just text. For a list it's maybe a bit different. For an image its pretty easy, in that oyu want an image selector. All this is really the same design issues as what Google docs has.
Google docs has a menu on top. that another way, but its lots of mouse movements.
The clicks to the place you want to edit, is more mouse friendly and even keyboard friendly.
What can be useful though is a property tree on the right, so you can fast edit the properties of each markdown element too.
The other thing is thumbnail sliders on the left. Because markdown and browsers are "stack based", a page can go for ever. SO the thing not he left is more like a magnifier.
For non stack based systems ( think PowerPoints, where you have slides and a fixed size per page ), them you have many thumbnails of course. HTMX makes builds these system relatively easy. You just swapping out as we both know.
the trick is always "where does the source live". It can all live on the backend if xoyu can wear the speed costs. The "Designers" for each type though can be just html to a degree. each is a mini form.
Its a designer debate though.
You dont need the left pane ( the raw markdown ) unless you want it, which some users would
The markdown is sent to the backend, saved to disk and the mark down renderer renders the markdown on the disk, and then update the Front end. If you want you can use WASM on the frontend and do optimistic renders of the markdown to html too, but you still have to send the mark down to the backend.
Probably should update the demo to show off these.
The text was updated successfully, but these errors were encountered:
Hey @paganotoni
Its pretty robust thanks to the markdown package.
tables, and other things work.
When adding an image, the scrolling will not account for its height.
I assume because its a web edit, then you can parse the change on the server and detect the actual page size.
The big issue of course is that the left side only takes up one line and the right side takes up whatever the image height is. For now the only way is to add "padding" on the left side, until a true Designer system is done. The padding could be a Box with a big X. The actual markdown can be in the top left. of that Box, so you can still edit it. The Box could be a background SVG image so its resolution independent. The size of course of the SVG matches the size of the image ( on the right ). Now scrolling works again properly.
The same is true for all markdown really. The size on the left has no bearing with the size on the right. I could tell a markdown system that I want h1 and h2 to be huge when rendered.
The scrolling will get out of sync on the left and right side because of this.
another way to design editors
This might be annoying or useful. Dont know..
A real time designer using HTMX can literally edit the right pane, and as you go into each item and click you get a mini editor for that markdown type loaded in. You do not type markdown, but edit the markdown via the Designer that is specifically designed for that markdown type.
For text it's just text. For a list it's maybe a bit different. For an image its pretty easy, in that oyu want an image selector. All this is really the same design issues as what Google docs has.
Google docs has a menu on top. that another way, but its lots of mouse movements.
The clicks to the place you want to edit, is more mouse friendly and even keyboard friendly.
What can be useful though is a property tree on the right, so you can fast edit the properties of each markdown element too.
The other thing is thumbnail sliders on the left. Because markdown and browsers are "stack based", a page can go for ever. SO the thing not he left is more like a magnifier.
For non stack based systems ( think PowerPoints, where you have slides and a fixed size per page ), them you have many thumbnails of course. HTMX makes builds these system relatively easy. You just swapping out as we both know.
the trick is always "where does the source live". It can all live on the backend if xoyu can wear the speed costs. The "Designers" for each type though can be just html to a degree. each is a mini form.
Its a designer debate though.
You dont need the left pane ( the raw markdown ) unless you want it, which some users would
The markdown is sent to the backend, saved to disk and the mark down renderer renders the markdown on the disk, and then update the Front end. If you want you can use WASM on the frontend and do optimistic renders of the markdown to html too, but you still have to send the mark down to the backend.
Probably should update the demo to show off these.
The text was updated successfully, but these errors were encountered: