Ticket #192 (closed defect: wontfix)
No removing of breaks from inline HTML Elements
Reported by: | monkhorst | Owned by: | jf.hovinne |
---|---|---|---|
Priority: | minor | Milestone: | 0.5 |
Component: | editor | Version: | trunk |
Keywords: | inline elements breaks | Cc: | wouter@… |
Description
The function closeBlockTag() now has the functionality to remove breaks at the end from inline (CSS wise) HTML Elements like strong, em, a.
It causes this unwanted behavior: You type a line of text and mark the first few words as strong. Next, you want to add a break after the stronged text. Accidentally you place the cursor within the strong tag. You add the break. When you save the text the break will have disappeared!
It is totally compliant with the standards to have a break tag to end an inline element.
So I propose to exclude the inline elements by changing the function like this:
WYMeditor.XhtmlSaxListener.prototype.closeBlockTag = function(tag) {
switch (tag) {
case 'strong': case 'em': case 'sub': case 'sup': case 'a': case 'span':
break;
default:
this.output = this.output.replace(/<br \/>$/, );
}
this.output += this._getClosingTagContent('before', tag)+"</"+tag+">"+this._getClosingTagContent('after', tag);
};
Hope this helps.
I'm not sure what to do with this. The question is if this issue occur more often than unknowing users adding line breaks for no good reason. In the scenario you describe above it sounds like the emphasized ("stronged") text really should be a headline at some lower level anyway.
Back to the issue. Either all line breaks at the end of all elements should be removed - or only those at the end of block elements, leaving the inline elements untouched. This (the separation of block and inline elements) is an area where the parser implementation is a little bit off as well. It considers most elements to be block level elements and only self-closing elements to be inline...
I'm setting this as wontfix for now, as there's no solid solution that doesn't require massive amounts of work (I'd rather not touch the parser) and we need to get 0.5 out there. If you think I'm wrong feel free to reopen the ticket.