Loading Profile...
HTML tags are stripped from the Issue description field.
How can HTML markup, CSS, or code be included in the description field?
I’m frustrated
1
person likes this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has not planned to implement this.
The best point from the company
-
This is intentional. It's something we're thinking about, but the problem is that everyone wants something different. Some want Markdown, some want Textile, and some want to use HTML to markup their comments.
Others want the markup to be parsed and displayed as code. Of course, HTML, CSS, and JS aren't the only types of code, so we'd need to support a wide variety of code.
Unfortunately, there's no way to please everyone, and we didn't want to reinvent the wheel, so currently, our recommendation for sharing code is to use Pastie (http://pastie.org/) or Gist (http://gist.github.com) and share a link in the comment.
I’m confident but apologetic
The company thinks
this is one of the best points
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?This is intentional. It's something we're thinking about, but the problem is that everyone wants something different. Some want Markdown, some want Textile, and some want to use HTML to markup their comments.
Others want the markup to be parsed and displayed as code. Of course, HTML, CSS, and JS aren't the only types of code, so we'd need to support a wide variety of code.
Unfortunately, there's no way to please everyone, and we didn't want to reinvent the wheel, so currently, our recommendation for sharing code is to use Pastie (http://pastie.org/) or Gist (http://gist.github.com) and share a link in the comment.
I’m confident but apologetic
The company thinks
this is one of the best points
4 Comments Add a comment
This is one of the best points
-
I understand not wanting to allow people to 'markup' their issue descriptions with html, but why not escape the tags rather than strip them. We've posted an issue with an illustrative html snippet in it and the markup got stripped. I can see Pastie being useful, but it's overkill for a one line snippet. -
Honestly, I just don't think it makes sense to invest the time in building and maintaining the feature when significantly better options exist. Handling code formatting correctly and elegantly isn't a trivial task, and we just don't think it's worth it for the few edge cases.
There are countless other features that we need to work on where there isn't a valid or reasonable workaround. We hope to have more seamless integration in the future, but for now, we're focusing elsewhere. -
I don't need you to format the code, just display it as is. All that would be required is replacing any < with < in the input text.
-
Unfortunately, it's not that simple, and it's definitely not that simple to do elegantly. Sure it would *work*, but I wouldn't be comfortable with quality of that solution.
-
Inappropriate?What is wrong with simply replacing < with < and > with > with all input text
this allows people to post even a reference to an html tag and it wont just go away1 Comment Add a comment
This is one of the best points
-
Essentially, we'd have to do one of two things. The first option is that we assume that every < or > should be turned into an HTML entity. However, that's not a safe assumption, so we have decided against that.
The other alternative is to implement some parsing that would check for open and closing < and > characters and format accordingly. At this point, the time and effort to do that just isn't justifiable when Pastie and Gist accomplish the same thing and do it exponentially better than we would.
Nothing is ever as simple as it appears on the surface, and this is an excellent case of that. Instead of doing something halfway or wrong, we've decided it's best to not do anything at all. There are great workarounds that we're comfortable with. So, looking at things objectively and realistically, it's just not a high priority. -
Inappropriate?"This is intentional. It's something we're thinking about, but the problem is that everyone wants something different."
Just pick one. Right now you have nothing which is wayy worse than you picking one of the many solutions that I like slightly less than another solution.
As for regular users being inconvenienced by this feature... just make it default to off ... and require either the user to turn it on in their prefs or a better solution would be to enable/disable it per item.
There ... now go write the code.
I’m null
1 person thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
This is still a decision that we're perfectly happy with right now. We have some ideas on how to do this well, but they won't be easy.
Adding preferences might be a quick fix, but we feel very strongly that it's not the best solution. It's certainly not a good long-term solution as it would force us to make compromises and have to support it in the future.
I'm sorry if you're disappointed, but this simply isn't something that is a high priority for Sifter, right now.
EMPLOYEE
