Re: [Python-markdown-discuss] Escaping HTML instead of removing it ?

[Waylan L. <wa...@gm...>]

On 11/5/07, Yuri Takhteyev <qar...@gm...> wrote:
> > until just now (after committing my patch). One could already have
> > code that sets `HTML_REMOVED_TEXT` to an empty string so that all html
> > is stripped and replaced with nothing. Some may prefer such a
> > behavior. This makes that imposable to do. Is anyone doing this?
>
> This does seem like a reasonable thing to allow.  Why not use None
> instead of empty string as the code for escaping, testing for
> type(HTML_REMOVED_TEXT) == "string"?

After sending this message last night, I realized this isn't that big
of a problem. I'm currently testing by doing `if HTML_REMOVED_TEXT:`
so `False`, 0, an empty string, and `None` will all result in
escaping. What I missed last night is that a string containing one
space will equate to True and trigger replacing rather than escaping.
Seeing whitespace is a non-issue in html anyway, this seems like a
reasonable solution.

>
> > Another solution would be to change the expected values of the
> > `safe_mode` parameter for Markdown() to one of 'strip', 'escape', or
> > None rather than True/False. But that could get complicated/confusing.
>
> This is actually quote reasonable, except that we could make it more
> more backwards compatible by saying that safe_mode = None would turn
> it off, safe_mode = "escape" would escape the HTML, and "remove" or
> any other non-false value would replace HTML with the value of
> HTML_REMOVED_TEXT.  I think for the documentation we should tell
> people to put "replace", but the actual code should treat any true
> value other than "escape" as meaning "removed".

The more I think about it, the more I'm inclined to want a way to turn
escaping on as a parameter, so I think I'll leave things the way they
are, except that if safe_mode == "escape" we force escaping regardless
of the value of HTML_REMOVED_TEXT.

That seems to allow the most possabilites without extensions.

>
> > I should also mention that I also moved the code that does the
> > escaping/removing from the convert method to a text-post-processor. It
> > makes more sense there regardless of this change IMO and simplifies
> > the process of making your own extension to change the behavior.
> > Extensions would be another way to address the issues I mention above.
> > Perhaps we could just leave it at that.
>
> I am glad you did it, but it would be nice to have a simpler solution,
> that does not depend on groking extensions.
>
> Thanks for all the work!  When do you think we should make a release of 1.7?

I should update the escaping tonight from this discussion, and don't
have anything else for the immediate future, so whenever your ready.
I'll let you make those unicode changes that were discussed. You seem
to understand that better than me anyway. Or was that just a
documentation issue?

>
>   - yuri
>
> --
> Yuri Takhteyev
> Ph.D. Candidate, UC Berkeley School of Information
> http://takhteyev.org/, http://www.freewisdom.org/
>


-- 
----
Waylan Limberg
wa...@gm...