IMO a better solution would be to have an input for a snippet of text describing each article, limited to a certain volume of characters, restricted to text. This text could also be used as the meta description of the article. This would:
- Conform better to the standardized expectation for an HTML document
- Avoid all of the problems associated with [break] or with cutting at a certain character limit
- Be more foolproof, but also result in users creating more friendly documents, and using the snippet more effectively
Of course, the downside is that users would be more restricted in what they can use as the 'snippet'.
Other approaches (e.g. "perhaps modify the [break] to ...") are really striving towards validation of HTML in the code users enter, which is very difficult to achieve and very code heavy (I've tried it myself on other projects!)
Well, maybe not so difficult, to do... or code heavy...[edited] see next post [/edited]
As for a second input...
3 ways it's content has been used in cms's in the past, and now generally considered defunct...
1) a repeat of the first few lines of the main text, and ignored in full article display.
2) the first few lines of the original main, requiring user to ensure those lines are not in the main, else they will show up again, as the content is merged....
3) to provide a synopsis that is either displayed or not at the head of the article...
A second input may appear to make it easier, and in fact could be performed currently, by selecting text before [break], and displaying it in a leading box... then upon editing, enter it into the db with the [break] mark replacing it.... BUT, this is more coding, requires more discipline on user's part, and eventually, for some, becomes a right pain in the rear....
May as well look at making the current shortened output compliant, and maintaining a far more user friendly 'snippet' positioning method IMHO.