[kupu-dev] Avoid filtering of HTML-comments

[Jon Stahl]

Duncan Booth wrote:
> <sean.upton at uniontrib.com> wrote:
>
>   
>> Having both behaviors regarding HTML comments be configurable within 
>>     
> the
>   
>> Plone Kupu setup seems like it would be a good idea.  
>>
>> Problem this has caused for media publishing applications I have
>> supported: authors comment out a piece of content with the intent of
>> possibly re-enabling it, and are surprised (to put it mildly) that it
>> vanishes.   Also, content imported from external systems generating 
>>     
> HTML
>   
>> often have HTML comments at the start of content.  
>>
>> These behaviors violate principle of least-surprise for many users;
>> configurability in a control panel for Plone integrators (along with
>> associated documentation/warning, GS extension profile example) would 
>>     
> be
>   
>> an ideal (I might be able to contribute time to coding this).
>>
>> Thoughts?
>>     
>
> My first reaction is that this sounds totally wrong: kupu is providing 
> wysiwyg editing, and expecting comments in the HTML source to remain 
> unsullied is completely outside the scope of a wysiwyg editor.
>
> If you want to make a change with a view to rolling it back later then 
> use CMFEditions to create a version. Don't rely on hacking the html.
>
> If you have content imported from an external system then you can surely 
> arrange to strip any leading comments. The comments aren't going to help 
> anyone doing wysiwyg editing, so if they are important you want wysiwyg 
> turned off anyway.
>
> And if you want to modify the behaviour in your system, then you can 
> customise the relevant javascript files.
>   
Duncan-

I think Sean's expectation is actually pretty reasonable.  WYSIWYG 
editors like Dreamweaver and FrontPage leave comments unmolested when 
you're editing graphically. 

If it's not difficult to support, I'd be +1.   Even though I agree that 
using comments for revision-management is asking for trouble.

best,
jon