Minor RSS output whitespace reduction#7969
Conversation
| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" | ||
| <?= $this->rss_base == '' ? '' : ' xml:base="' . $this->rss_base . '"' ?> | ||
| > | ||
| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" <?= |
There was a problem hiding this comment.
@aledeg I didn't expect this to come up so soon again. ;-D
There was a problem hiding this comment.
Maybe we could add a post-processor to remove all extra white spaces. I think it is hard to remember the use of each white space in the code base.
Unless you're coding in Whitespace (programming language) - Wikipedia
There was a problem hiding this comment.
Maybe we could add a post-processor to remove all extra white spaces
No, really, this would be more negative than positive in my opinion (dependency, footprint, reduced performances, barrier to entry, etc.). Furthermore, I believe (reasonable) whitespace and formatting of the outputs contribute to making the Web more accessible.
Nothing wrong here. Our RSS is valid and standard. This is just to accommodate (maybe) a buggy parser.
There was a problem hiding this comment.
Maybe this post-processor could be optional, handled by an extension. I think it's sensible to minimize the content. It's done for JS and CSS files through the web. Why not HTML files.
Anyway, the real issue is to remember why we have such white space patterns.
There was a problem hiding this comment.
It wouldn't have done anything about the recent discussion. The most it can do is to reduce all whitespace to a single space. Any potential whitespace issue is inherent to HTML, for better or worse.
I stand less negatively towards ob_start() etc. (to remove all whitespace at the start of a newline for example) than @Alkarex does but I don't see a clear added value either, nor any problem with the whitespace patterns. :-)
There was a problem hiding this comment.
A simple trim() or a regex would not be sufficient, as the processor would need to have some kind of understanding of HTML, where white-space does matter, for instance inside a <pre>. Parsing HTML would add a significant overhead.
Furthermore, the content is sent while being produced to reduce time to first byte, and even explicitly with flush() at strategic places, for instance to have some content and a spinner while waiting for articles of a slow SQL requests. I am worried a post-processor would make that quite more complicated and less efficient.
There was a problem hiding this comment.
Furthermore, the content is sent while being produced to reduce time to first byte
Yup, this is great. You're correct. :-)
fix #7968