Serendipity Forums

Hi.

There is probably a simple solution to this, but I haven't been able to find it: How do I make Serendipity use the regular html-style <br> tag instead of the XHTML-style <br/> (i.e. with a slash) when displaying my entries?

Mikkel

Hi!

Why would you want to do that? HTML is deprecated for ages.

Regards,
Garvin

garvinhicking wrote:Why would you want to do that? HTML is deprecated for ages.

No it's not - it is still the most user-friendly and powerful tool for writing webpages. As long as the most widely used browsers still parse code as if it were HTML, there is little or no reason to start writing XHTML (see http://friendlybit.com/html/why-xhtml-is-a-bad-idea/).

I set up my website many years ago and wrote it in HTML 4.01 Transitional. So far, I have neither had the time nor any good reasons to convert it to XHTML, so for consistency I would like Serendipity to not use XML-style tags.

That does not mean that XHTML is a bad idea and that I will not change to XHTML at some point in the future, I just don't see any reason for doing it now - it will remain on my to-do list at least until IE supports XML parsing.

To re-iterate my initial question: Can Serendipity write <br> tags instead of <br/>?

Mikkel

Hi!

But <br /> is not invalid in HTML, it's backwards compatible. Changing it would invalid in XHTML - but not the other way round.

(see http://friendlybit.com/html/why-xhtml-is-a-bad-idea/).

I strongly disagree with that article. XHTML has plenty of semantic advantages that should be used for better accessible pages.

So far, I have neither had the time nor any good reasons to convert it to XHTML, so for consistency I would like Serendipity to not use XML-style tags.

Many parts of s9y use XHTML now, we have also deprecated the HTML option a year or so ago. Even though you might be able to fix your <br> issue, you would also have to create forks of dozens of other plugins, which would be quite a mess...

But most XHTML issues would not lead to invalid HTML, only the other way around. But you would certainly loose some XHTML features (like rel=nofollow or other attribute stuff)...

So the bottom line is: I strongly discourage patching XHTML stuff to output HTML format, this is not worth the effort.

To re-iterate my initial question: Can Serendipity write <br> tags instead of <br/>?

Yes, you would need to patch the nl2br PHP functionality for that and create your own markup plugin to use that instead of PHP's nl2br.

Best regards,
Garvin

garvinhicking wrote:But <br /> is not invalid in HTML, it's backwards compatible. Changing it would invalid in XHTML - but not the other way round.

I know.

I strongly disagree with that article. XHTML has plenty of semantic advantages that should be used for better accessible pages.

You are right - but it also has some major disadvantages. Another thing being that any site that relies on user input will have to implement some sort of syntax checking of that input, because malformed code will just make the XML parser abort.

Many parts of s9y use XHTML now, we have also deprecated the HTML option a year or so ago.

Okay - that is why I thought I had seen it somewhere!

To re-iterate my initial question: Can Serendipity write <br> tags instead of <br/>?

Yes, you would need to patch the nl2br PHP functionality for that and create your own markup plugin to use that instead of PHP's nl2br.

Maybe I'll just leave it Thanks for your reply.

Mikkel

Ho!

You are right - but it also has some major disadvantages.

I only see a disadvantage, when a XHTML mimetype is sent. Only this leads to parse errors that are conveyed to the client.

In all other cases, invalid XHTML is no more worse than HTML invalidity. I see no inherent disadvantege in XHTML markup, also I think it is even more logical to users than single-tag HTML variants.

(I hope you do see my point I'm making against HTML, I'm not trying to sound insulting to you )

Best regards,
Garvin

garvinhicking wrote:I only see a disadvantage, when a XHTML mimetype is sent. Only this leads to parse errors that are conveyed to the client.

But that sort of defies the purpose of writing XHTML, doesn't it? Why write XML-style code if it is not parsed as such?

One of the (future) major advantages of using XHTML is that you can do away with all the error handling functions that make today's browsers heavy. An XML parser (I am told) is very light, so you can fit it in many more places than a traditional browser.

But, as I said, then you must have complete control over your code, so you won't break the parser with invalid code.

In all other cases, invalid XHTML is no more worse than HTML invalidity. I see no inherent disadvantege in XHTML markup, also I think it is even more logical to users than single-tag HTML variants.

Agree and disagree. As long as the code is parsed as HTML there is no difference between the two, but again: Why use the XML-based variant when most browsers do not exploit the full potential of it?

(I hope you do see my point I'm making against HTML, I'm not trying to sound insulting to you )

I do see your point, and I don't feel insulted ! I am sure that when you work with a complex application such as Serendipity, XHTML has some concrete advantages over HTML, and I have no doubt that XHTML is the choice of the future. For my purposes, though, the advantages of shifting are not substantial enough yet - but I will eventually.

Mikkel

Hi!

But that sort of defies the purpose of writing XHTML, doesn't it? Why write XML-style code if it is not parsed as such?

XML can be properly parsed even without a XHTML mimetype; this just enforces that browser can render invalid XML just fine. Making browser fatally bail because of XHTML invalidation is a bad thing, but it is NOT a requirement. That's why s9y still uses XHTML 1.0 Transitional

Best regards,
Garvin