[TYPO3-core] RFC #7984: Bug: stdWrap.crop now closes opened tags and counts chars correctly

[Steffen Kamper]

"Ernesto Baschny [cron IT]" <ernst at cron-it.de> schrieb im Newsbeitrag 
news:mailman.1.1207560427.2051.typo3-team-core at lists.netfielders.de...
> Martin Kutschker wrote: on 06.04.2008 14:53:
>
>>> There are two possible scenarios:
>>> 1) "blah <foobar> whatever" is parsed with parseFunc, then it will be
>>> counted as will be counted as "blah <foobar> whatever". The delivered
>>> HTML-code will be "blah &lt;foobar&gt; whatever" shown as "blah <foobar>
>>> whatever". That's what is espected.
>>> 2) "blah <foobar> whatever" is cropped as plain text. Then it  will be
>>> counted as "blah <foobar> whatever" (leaving aside the
>>> entities-discussion) delivered as "blah <foobar> whatever" and shown as
>>> "blah  whatever" (Firefox 2.0.0.13) or "blah whatever" (Safari 3.1) both
>>> ignoring the unknown tag "<foobar>". That's also what is expected.
>>>
>>> Can we hopefully close this part of the discussion? What do you mean?
>>
>> Besides that are obviously other other uses cases where the content is 
>> HTML but it is not processed by parseFunc etc
>>
>> Let's agree to disagree. IMHO changing a plain text crop to an 
>> auto-tag-closing, HTML-entitity-aware crop is a change of features and 
>> not a bug fix.
>>
>> We agree that it would be cool to have an auto-tag-closing, 
>> HTML-entitity-aware crop available in TYPO3 possibly but not limited to 
>> stdWrap.
>
> I agree with Masi here. This is a change of behaviour, as the "cropping" 
> was never documented as handling xml data and might have been used by 
> users with that in mind. The idea of having a switch to turn it on 
> (crop.html = 1) would be nice.
>
> Cheers,
> Ernesto

full ACK

i would like to handle this extra, so you have
stdWrap.crop
stdWrap.cropHTML

Having this as a new feature would be nice to have it in 4.3

vg  Steffen