Any plan to improve the "Item Description" and "Profile" text editor?

Hi, there.

I am wondering what is preventing Envato from improving the (very) obsolete “Item Description” and “Profile” text editor. Or at least from extending the accepted HTML elements and attributes. Even just allowing the inline styling of elements (“style” attribute) would help us achieve much better and visually more compelling results for both the item descriptions and the profiles. Nowadays, we are bombarded with visually compelling content, even when receiving emails as every email client largely supports inline styling or even embedded CSS.

Considering that the reasons behind this long-overdue improvement cannot be technological since Envato can count on the one of the largest community of brilliant minds in the web development market, I am trying to figure out what the real reasons can be.

I came up with the following explanations but I would like to hear your opinion (and, hopefully, some insights from any Envato developers):

  • compatibility: with hundreds of thousands of item descriptions and profiles out there, Envato might be concerned about breaking any old content. But expanding the set of recognized HTML elements and attributes would certainly never break whatever was written for the current, more limited editor;
  • lack of interest: since this system has been working for many years, Envato may think that it is not worth it to improve it.
  • fairness: improving the editor could possibly be unfair toward the authors who have laboriously crafted their pages with a very limited toolset when new authors’ profiles and item descriptions could be visually more appealing with a fraction of the effort. Or, in any case, force the authors to revise all their pages, in some cases several hundreds of them.

Whatever is the reason holding back this much-needed update, I think you will agree with me that the following limits of the current editor are absurd and should be removed or greatly improved:

  • it is not possible to embed elements from other websites (e.g. YouTube, Vimeo, etc.). This seems to be unreasonable and forces us, authors, to work around this limitation with solutions that are overcomplicated and not as effective, especially considering how easy it is to get the embedding code for any major video content website;
  • stripping both the <center> tag and the style attribute from the allowed HTML elements, makes it basically impossible to center an element in the section. I have heard of people calculating the maximum width of the section and saving a picture with some transparent space on the sides in order to get a visually centered image… come on!!!
  • stripping the target attribute from the <a> tag makes it impossible to decide when an external link should open in a new tab or window (target="_blank").
  • it would be great to add a “Preview” button to check the appearance of the item description before committing the change. This would avoid dozens of description updates just because of a mishap in what we put in the description. In this regard, the Envatitor editor is not 100% accurate. For example, using the <center> tag perfectly works in Envatitor but the stripped code doesn’t in the Envato editor, resulting in a visible <center> tag and no center alignment.

I would love to hear your opinion about this matter.

All the best,
Luigi.

2 Likes

I never really thought about it, but I agree, it’d be nice to have an update to that. Though, like you said, it might cause compatibility issues, depending on what the upgrade includes.

A few years ago there was a bit of an uproar when they decided to change the background colour from light grey to white, which caused a lot of people to have to go through and fix all of their item and profile pages. So as long as the upgrade doesn’t break what people currently have, it should be fine.

Personally, I like to use Envatitor, which makes it all much easier, because then all you do is copy and paste the HTML into your description, but like you said, it’s not 100% accurate. Though things like embedded videos would be really nice to have, as well as not relying on tricks like oversized images to achieve simple things like alignment.

Hi, @XioxGraphix.

Thanks for your feedback. I get what you are saying even though a possible expansion of the HTML tag and attribute set that the editor is capable of interpreting would make what we write less problematic when Envato needs to update or change the general styling of the item or profile page. Furthermore, it definitely would not hurt what’s already in the system for the simple reason that the new HTML tag and attribute set would also include all the tags that have been used so far.

So, for example, giving us the possibility to write something like:

<div style="width: 50%; margin: 0 auto;"><img src="my-img-link.jpg" /></div>

will definitely not break any description where the following was used:

<div><img src="my-img-link.jpg" /></div>

It would simply allow us to write more impactful descriptions without making formatting acrobatics. :smiley:

That’s true. Perhaps it’s restrictive for simplicity’s sake? Though it would make more sense to allow for more advanced usage while keeping the ability for basic things.

Come to think of it, I somewhat recall seeing an official statement on something like this a long time ago. I think it had something to do with page structures and mobile compatibility. Have you tried contacting Envato Support about this? Even though it’s not technically an issue, you still might be able to get a real answer from someone directly involved with it.

Thanks for opening this @PerfectPeach. I’m a sucker for deep dives into this sort of thing so here goes :smiley:

This is a big one. We use the same functionality (with different text converters) across the application. If you’re entering text into a comment field, it is using the same functionality that is also rendering the item description. Unknown to most people, Envato Market doesn’t use a standard text conversion framework. It’s a homegrown solution that is a mix of BBcode, textile and HTML. The reasoning for this is pretty straight forward; Envato Market was around before there was any front runner in this space. Making changes to these classes is a very delicate process despite the size of our existing test suite. Whenever improvements are made, we need to analyse it against hundreds of thousands of variants and build out extensive test cases for each. It’s no small task by any measure. In an ideal world, we’d replace this whole system with a more standardised approach (such as Markdown using the commonmark specification)

I wouldn’t say lack of interest but instead, it’s not something that has made the top of the priority list. Feedback like this helps us to shape those roadmaps so consider your vote placed!

If there was a migration of any type, we would aim to automated as much of it as possible to avoid unnecessary work for authors. I suppose you’re right in that it would be a bit of work for some authors. No thoughts from me at the moment on how we could fix that but I’m sure we could come up with something to help out there.

This is somewhat by design but also accidental in other aspects. We take performance very seriously and many other providers simply don’t when it comes to a third party (ad trackers, video hosts, image hosts, etc). We’ve made alot of effort to provide a fast and secure user experience and allowing some third parties like this degrade the experience. Not only that, there are some customers who have a very low network capacity meaning that if we’re loading videos or super high resolution images, they are likely to bail out because of their slow connection. This isn’t something anyone wants as it’s a crap experience for everyone involved.

On top of performance, we now have alot more privacy concerns to contend with. Opening up access to third party cookies and trackers is something we’re actively avoiding.

This is probably more of a two part thing. Design + security. The design aspect is pretty straight forward; we have designers who spent lots of time putting together the ideal experience and we wouldn’t want someone outside of the team to be able to alter the way that the page is rendered. At the end of the day, the item description is intended to provide an overview and feature listing of your item. It’s not intended as a web page editor :slight_smile: There are a multitude of ways that we could change this but none really line up with what it’s current aim is. I touched on it briefly but, security is also a concern here. Parsing broken HTML (bbcode and textile too) is really dangerous. Any markup that has a trailing tag (center is one <center></center>) is susceptible to this because if you don’t close the tag, everything rendered after it has it applied. There are mitigations for this but at the same time, it’s a bit of a game of whack-a-mole until you start locking down elements.

This is a more recent thing but again, it’s security related. Check out the Google Developers article on this. I suspect this was removed prior to having suitable mitigations available and it was never added back in.

I agree! This would be a nice to have. I’ll pass it along to the product folks who can take a look at it.

4 Likes

Hi, @jacobbednarz,

I must admit I was hoping for an answer from someone involved in the development team but I would have never expected such an extensive and detailed reply. Kudos to you!

Every aspect you mentioned totally makes sense and I can easily imagine how many concerns are involved in the maintenance of a community of more than 10 million users.

That is absolutely understandable. Nevertheless, this also applies to <p> and <div> tags that are already supported by the current editor. So, the addition of <center> would not make much more harm than what the other tags already can do in this specific regard.

Geat! I am glad I was able to share my feedback with you!
If I can take advantage of your patience, I added another topic, few months back, in regards to the Tsunami player in AudioJungle. You can give it a look here. Any feedback on that would be awesome!

Thanks again for kindly taking the time to reply to my post!

Best,
Luigi.

1 Like

Hi @PerfectPeach, thanks a lot for putting this together. Always good to hear feedback from the community, and I agree, this is something that could in fact need an update.

I think @jacobbednarz covered a lot of points already, but I can add one thing:

We’re currently investigating how can we improve this on my team. We don’t know exactly what areas we can touch yet, and which will be too delicate per Jacobs point. I can say though, we are at least expecting to add a preview option.

To be completely clear: It’s not 100% sure this is happening, and it wouldn’t be in the next few months but it’s on our roadmap. It’s an area we are going to improve!

Thanks again for your feedback.

3 Likes

Hi, @davidbjornbograd,

Thank you for your comment on this. I truly appreciate your effort in reassuring us that our inputs are heard and taken into consideration.

Well, even without being 100% confirmed, this is definitely great news!

As I did with @jacobbednarz, I invite you as well to give a look at my other post about adding active markers to the Tsunami player.

Thanks again for your update!
Luigi.

1 Like

The player idea is awesome!! I’ve shared it with the people working on that part of the product, and one of them is already excited about it. :smile:

They usually have a very busy roadmap, but I’ll put it as a suggestion for one of the new things to look into. Hopefully, it will end up on their roadmap.

If you have anything else feel free to reach out.

2 Likes

Wow! That was fast! :smiley:
Let me know if they want to analyze the script I wrote and feel free to put any of them in touch with me in case they want to brainstorm that idea a little more!

All the best.