I’m experiencing a lot of weird behavior in the text editor when editing paragraphs.
To start with, it is incredibly slow. In fact, sometimes I can sit for a few seconds and watch the characters I have typed being entered slowly. Also, it is painfully trying to make a selection using double or triple clicks, plus drag selection is even harder.
But most disconcerting is the difference between what is entered in the editor and what is displayed in the browser. I find I have to enter multiple carriage returns to prevent all the text from appearing as one long paragraph.
Here is an example of what some text looks like entered in the editor.
Try entering <br> to get a new line instead of using returns.
I do agree it’s very unresponsive - maybe it’s processing on every character to update - might be better if that was done after a slight delay of no new text.
Yes, a break certainly works as intended when outputing the text, but it seems one should not be forced to do that in a WYSYWIG text editor as it clutters up the text in the editor.
For now I will use that till something better comes along.
I’ve experienced the slowness myself and will get it fixed up. I’ve also replicated the new line issue and will see what I can do there too.
Please only use <br> tags as a temporary fix if you absolutely have to. A better option might be to add multiple paragraphs to a flex which would allow you to easily control the spacing between lines.
Text editing is one area we know needs attention and have plans to greatly improve it, so bear with us.
Unless you’re a fan of writing in blocks (aka Notion and Craft) having to manually switch between sibling paragraph elements would get old really fast—it’s also a very unnatural way of writing text.
Ideally, Elements would have some way of helping users to work with sibling paragraphs of text as one cohesive element, rather than several disconnected elements. For instance, hitting return would begin a new paragraph (adding an additional <p> tag where necessary, but would still allow the user to navigate between blocks using the cursor, or make selections of text spanning paragraphs. So to the user there is one paragraph element in the page structure, but semantically there are as many <p> tags as hard returns in the text.
Having to manage paragraph spacing via a flex container gap property is very unintuitive, and something that would only be mildly obvious to a developer already familiar with how CSS (and Tailwind) work.
The whole user experience should be like a word processor app like Pages. Write some text. The default semantically creates <p> tags. If you want a headline, select it and change the style, now it’s a <h1>, if you need a sub head, select the style, it’s a <h2>, and so on.
Sorry, I didn’t mean that you should be using multiple paragraphs in a flex to separate lines all the time. It just looked like it might be a good way to get around the current limitations as you’re building a list, rather than inserting <br> tags.
Another way might be to use the data feature in a custom component, like how the FAQ component works, but that’s a little more complex.
Ultimately, you need to be able to do this within the text editor.
Given the range of formats that are used to create “text” content for browsers, I wonder if it is better that we have one editor/text Component or if there should be different Components for different formats (e.g. plain text, rich text, Markdown, etc.)?
Just like Elements, The inline text editor is unfinished and still in development. We know it needs more work, and we’ll be turning out attention back to it soon.
I have tried using a combination of headings and paragraphs, but this feels like the old days when you would end up with a lot of paragraphs.
All my current websites use Markdown for long-form text, as it is so much faster. I can write it in a dedicated Markdown editor and then paste it into the website builder.
When this came up, I tried doing that. I then converted all of the Markdown headings to heading components and most of the paragraphs to paragraph components.
This is what the hierarchy ended up looking like. I still had a bunch of paragraphs within some of these paragraphs, which is where the breaks were used.
All of the above could have been replaced with a single Markdown component.
I understand that the editor is a work in progress. I’m just trying to ensure that it is going in the right direction to enable easier text editing. There has still been no word on whether it will support Markdown or whether we will need to rely on a third-party solution?
yes that would be good because for the “upcoming” blog it will be the same. I like to prepare my texts in advance and to be able to copy and paste them with Markdown formatting.
In addition to website development tools, I also utilize external tools for my posting work. It would be advantageous if Elements supported the integration of tools such as MarsEdit, Drafts, and/or Notion for content creation and posting. However, the implementation of CMS components for Elements is a prerequisite for this functionality. It is hoped that the developers will consider these requirements while developing the CMS functionality.
Prior to the introduction of Foundation/TCMS and Foundry, I employed a stack that enabled me to extract blog posts from Blogger (despite my dislike for it, it was the most effective method at the time). I would greatly prefer the ability to create content offline and subsequently load it onto my website when I am prepared.
I often do a lot of my writing in various iA Writer folders synced via my iCloud Drive, and while it’s possible to copy/paste from iA Writer into a theoretical markdown element within Elements, it would be nice if we also have the option within Elements to say “these site articles (including front matter) are located at {/path/to/folder}”, so that if we had previously updated articles in iA Writer (or insert your favourite markdown editor here) then on republishing the site from Elements it would automatically pull and update those articles without the user having to copy/paste and manage all of those changes within Elements on their own.
This external markdown → Elements publishing workflow would also enable me to perform diffs, regex manipulations, etc on content using my existing tools, while being able to seamlessly integrate and publish the documents using Elements.
One other thing that would be extremely helpful is include local images and media (ie. ./ugly-cat.png or …/videos/ugly-cat.mp4 ) referenced in any markdown docs on publishing.
If you are a heavy user of automation (Shortcuts, AppleScript, javascript, Python) like me, then your external file access approach would make for very powerful workflows. Thank you for the suggestion. I hope the RM team can enable it!
I definitely agree with you that a solid, easy to use rich text editor - all WYSIWYG - is the essential text feature for Elements.
Personally, I think that the online editor that syncs back to Elements would be a great candidate for a 3rd party feature, but we all have our own priorities.
I used to think that markdown was a tech-geek/developer thing, but in recent years I’ve run into more and more ‘normal’ people working with it. And # while I * hate * _ formatting _ ![with] (it), it gets the job done.
well I know I shouldn’t but I’m being too teasing: we’re at the end of the first quarter of the 21 century, we’re talking about “no code” website creation, support by AI and native AI capabilities, we’re proposing that AI do it for us… in fact everything… but how I would like to be able to justify my paragraph without it ending up aligned to the left in this damn container that doesn’t want to take the maximum width of the screen and continues to limit itself to the width of the site I’m not even talking about adding an article to your blog without opening Elements Okay, I’m leaving
I’m not even talking about adding an article to your blog without opening Elements 
Okay, I’m leaving