i’m not saying you should generate websites the way that i generate websites, but whenever i look at how other people generate websites i am very unimpressed
is
<element name="h1" namespace="&xhtml;">
<value-of select="atom:title"/>
</element>
really better than
<h1>{{ post.title }}</h1>
?? no. but also yes
@Lady do you personally prefer using XSLT or using string templating languages? I have some mild fondness for each, myself
@jamey well, i prefer XSLT if the data source is XML. if the data source isn’t XML then you might have issues
@jamey unrelatedly, you know a lot about Atom feeds! i currently keep the full text of my blogposts in my Atom feed, which is good, but i worry it will result in a Quite Large filesize over time. i know i can use RFC5005 to paginate the feed, but do you have any thoughts on this besides? how big is too big for Atom feeds, or is size not really a practical concern?
@Lady oh sure! I wouldn't say I'm an expert on what limits exist in deployed feed readers by any means, but I have looked for answers to this question before. I remember reading that the Windows RSS client library (everyone is surprised that this is a thing) had a file size limit, but I can't find the limit now. I also see various people talking about FeedBurner being limited to half or one megabyte, and I've heard iTunes limits podcast file sizes. In general my impression is that 0.5-1MB is probably safe for most readers but larger sizes might break some.
Separately, there are of course implications for your web host's bandwidth limits if you serve a large feed. Several popular feed readers fail to correctly implement HTTP cache validation, so they'll pull down the entire file regularly even when it hasn't changed. But even correctly implemented clients generally have to download the entire file even if only 1% of it has changed, so allowing the feed to grow unbounded can multiply your bandwidth usage by a lot.
As far as I know those are the only important considerations about feed size!