[ ] let's show text as element inside the sidebar, but "ignore" it as an element at the design view. it can be edited but can never be selected directly.
[ ] for some reason, elements like bold or blockquote are not considered as text. question - how is the hovering mechanism works? is it bound to the rfrncs or is the type of elements that gets the underline are defined inside the function directly? please lmk before changing.
[ ] When adding a new text node it should become content-editable by default
[ ] while selecting text, if moving outside the text bounding box it then deselects the text and initiates element selection instead. need to isolate text editing as a "mode" at a deeper level.
[ ] if a text element is left empty of text, it will terminate itself. (and the fallback mechanism will auto-select something else according to the pattern, as mentioned at other issues). see figma for reference for terminated text
[ ] Implement "T" or Text editing mode
Imagine text editing is a "mode", which is initiated when :
double clicking on a :formatting and text" element type (instead of the redundant 2xdouble clicks in order to edit text).
once already in this mode, it is possible to simply click on other text elements and edit them freely (see figma).
it is also possible to hit T on the keyboard and initiate that mode.
for example, clicking on the h1 here would initiate the text editing mode and only then make the text as an active node.
motivation - we made the text a node and it is also more visible as an element which is great but since this isn't really an element we have to divide its functionality and the way it is treated. as a user you don't want to have a concern while editing text. it is different mental model than reordering elements. both can work together in harmony.
[ ] let's show text as element inside the sidebar, but "ignore" it as an element at the design view. it can be edited but can never be selected directly.
[ ] for some reason, elements like bold or blockquote are not considered as text. question - how is the hovering mechanism works? is it bound to the rfrncs or is the type of elements that gets the underline are defined inside the function directly? please lmk before changing.
[ ] When adding a new text node it should become content-editable by default
[ ] while selecting text, if moving outside the text bounding box it then deselects the text and initiates element selection instead. need to isolate text editing as a "mode" at a deeper level.
[ ] if a text element is left empty of text, it will terminate itself. (and the fallback mechanism will auto-select something else according to the pattern, as mentioned at other issues). see figma for reference for terminated text
for example, clicking on the h1 here would initiate the text editing mode and only then make the text as an active node.
motivation - we made the text a node and it is also more visible as an element which is great but since this isn't really an element we have to divide its functionality and the way it is treated. as a user you don't want to have a concern while editing text. it is different mental model than reordering elements. both can work together in harmony.