Phrasal elements are allowed *anywhere* text is valid. This can be validated with the w3c validator using <code> within an <h3>.
Also in RSS readers, HTML tags in titles/subjects are not supported.
Yes, hence the need for a plain-text version of the title used for links, rdf, and anywhere else that won't render xhtml. And then an xhtml "pretty title" for display in places that will render xhtml, like the title that gets displayed.
You did already patch up your own code to support that, right? Did you already check how things are working with that?
So far I've just comment out that offending call. I did get started a coding a perm solution, but work interrupted. I will supply a patch when all is done for review. Things seem to work OK, but urls for reading the story have the tag minus <> in them, that will have to be repaired.
I have now committed a patch to Serendipity 1.1 (SVN Trunk) that creates a new variable $entry['html_title'] that holds the un-htmlspecialchar'd content of an entry, which you can use via {$entry.html_title} in your custom template. Then you don't need to hack the s9y code anymore, you just need to create your custom template.
html_title will work for advanced users--we just have to take care of our own tags and entities. But I don't see any reason that we can't allow for using xhtml phrasal elements and entities in rendered and substituted form.
For the general user, I am still very convinced that allowing this functionality would create confusion and BC breaks, leaving people wondering. For specific users like you, I think the way above should be in order. Or maybe you have a better idea/option?
The "config option" might be workable, but because of the <h3> tag issues above, I think it should more be a template issue than a global config issue. I'd also like to keep configuration value cluttering as low as possible.
I'm all for BC, let's just not cripple the present and the future at the same time. We should be able to do both.
BC is very vital to Serendipity, so I hope you can understand my reasoning. But I still agree that users like you want to have an accomodation to the problem. So I hope we can figure out something that works for both of us.
Are you a bit skilled with PHP and could flesh out a small algorithm for the replacement rules you'd like to have? If you have no PHP knowledge, maybe a verbose english description of what needs to be replaced how could help me. I find \< escaping quite strange and have never yet seen this somewhere for <> characters...I don't know if people would know that this was possible?
\ is the standard perl escape character, also used by many other systems, including PHP in preg_*. While you don't *need* to escape <> in preg_*, it will nonetheless work. Truthfully, the escape character could be anything, but I think we should stick with one that a) some already know, and b) if they learn it for the first time, it will apply to other things. We will have to tell them somewhere that if they want a title like:
"Proper use the <code> tag in XHTML 1.1" that they will have to write that as \<code\>
In reply to Carl, I submit that making <code> (an inline element) display as block globally in a style sheet is a bad idea. This would fail with a sentence like: This brief howto will cover my use of <code>rsync</code> to backup the critical data on my home network. <code> is the proper semantic markup here.
I submit that anyone smart enough to put in a <code> tag is (or ought to be) smart enough to make it a <code style="display: block;"> or perhaps <code class="block">.[/quote]
I'll keep hacking on a patch.
Regards,
Mark