comment previews should reflect markup accurately

Jun 05, 2010 18:15


Title
comment previews should reflect markup accurately

Short, concise description of the idea
Comment previews should render HTML in the comment as it is written, not silently correct it.

Full description of the ideaThe purpose of a preview is to see how something will look before it is submitted, so the user can make changes and correct errors. The ( Read more... )

html cleaner, comment viewing, comments, § no status, comment creation

Leave a comment

Comments 9

pinterface October 9 2010, 14:48:42 UTC
Comment/post previews not matching how comments/posts will look is inexcusable. All ya gotta do is run previews through the same codepath as the real thing!

Reply


cos October 9 2010, 15:51:32 UTC
It sounds like there's an inherent ambiguity: Different people will view the same post under different styles, so there's no one "real" style to pick. Perhaps it should default to the journal owner's default style, rather than the commenter's style, but that's still no guarantee.

Reply

fiddlingfrog October 9 2010, 16:41:34 UTC
That's not really the problem though. If the comment preview, which displays in the site scheme, silently corrects any HTML errors, then the user doesn't know that they might need to correct any problems with their HTML. Disabling the silent HTML correction, or better, highlighting the problem areas, will let the user correct their HTML so that the comment behaves as intended.

Reply

cos October 9 2010, 16:48:54 UTC
That's one instance of a more general problem, and the suggestion seems to be trying to address the more general problem (though it gives this instance as the main example). If some schemes correct this particular html problem and others don't, then it's possible to say "regardless of scheme, comment preview should never autocorrect this particular problem", but that's a different suggestion.

Reply

imc October 9 2010, 21:31:56 UTC
Comments always have their HTML cleaned whether it's in the preview or the main entry (and there are good reasons for this: the cleaner tries hard to stop any broken HTML in the comment from borking the rest of the page and to remove anything that might be dangerous. The cleaner is also responsible for turning LiveJournal-specific tags such as imc into the actual HTML which describes what imc looks like).

LiveJournal does in fact do pretty much exactly the same in comment previews as it does in the actual comments. The problem, as cos pointed out, is that it can depend on the style in which it's displayed.

In this particular case, when you write text more text the cleaner will change it into text more text. By default your browser will not decorate "more text" because it's not a hyperlink. However, the CSS of the particular journal to which this particular comment was posted contains an instruction which colours all elements green regardless of whether they are hyperlinks. So the posted comment looks different from the preview, but ( ... )

Reply


fiddlingfrog October 9 2010, 16:35:43 UTC
Makes sense to me.

For discussion, the mentioned support request: http://www.livejournal.com/support/see_request.bml?id=1107449

Reply


charliemc October 9 2010, 18:47:33 UTC
I had no clue this was happening! I've always assumed the preview was showing us exactly what would end up posting!

This is an obvious YES for me, as I frequently use HTML in comments -- and I do Preview to attempt to make sure it's going to post correctly.

+1

Reply


Yes rpkrajewski October 9 2010, 21:41:39 UTC
This really more of a bug fix than a new feature. For some reason, even with pretty vanilla LJ styles (which I think shouldn't matter, but maybe it does), not all tags are parsed or seem to "take."

Reply


Leave a comment

Up