aggregate: When a feed has an enclosure that is an image, audio, or video,
include the enclosure in the generated page.
The enclosure is hotlinked from the original feed, not copied.
My use case is to include a mastodon rss feed in amoung other rss feeds for
users who don't use mastodon. It could also be used to aggregate together
podcasts, etc.
Other enclosure types than image, audio, video, could be added, perhaps
a generic one? But these are the main ones.
The template uses 50% width for image and video, because often
attachments are in a high resolution, which will default to being
perhaps too wide for the page, or taking up a lot of vertical space. By
making it take up at most half the page width, that is avoided, while
also leaving room for any sidebar.
Sponsored-by: Shae Erisson on Patreon
Some of these might be relatively expensive to dereference or result
in messages being logged, and there's no reason why a search engine
should need to index them. (In particular, we'd probably prefer search
engines to index the rendered page, not its source code.)
This includes some CSS changes to names of elements.
Also, added Email login button (doesn't work yet of course),
and brought back the small openid login buttons. Demoted yahoo and verison
to small buttons. This makes the big buttons be the main login types, and
the small buttons be provider-specific helpers.
Mobile browsers typically assume that arbitrary web pages are
designed for a "desktop-sized" browser window (around 1000px)
and display that layout, zoomed out, in order to avoid breaking
naive designs that assume nobody will ever look at a website on
a phone or something. People who are actually doing "responsive
design" need to opt-in to mobile browsers rendering it at a
more normal size.
According to caniuse.com, a significant fraction of Web users are
still using Internet Explorer versions that do not support HTML5
sectioning elements. However, claiming we're XHTML 1.0 Strict
means we can't use features invented in the last 12 years, even if
they degrade gracefully in older browsers (like the role and placeholder
attributes).
This means our output is no longer valid according to any particular
DTD. Real browsers and other non-validator user-agents have never
cared about DTD compliance anyway, so I don't think this is a real loss.
The recent move of the post author to the author field is good, but with
it coming after the name of the feed, it is unlikely to be visible when
viewed in eg mutt. Move it to before the feed name.
While here, mollify http://validator.w3.org/feed/ and
s/dcterms:creator/dc:creator/g, which happens to make rss2email see
and do nice things with authors.
These all seem somewhat inappropriate (searchform and sidebar are
arguable either way). I've left actions and languages enabled, since
they seem more reasonable for CGI-generated pages.
Bug: http://ikiwiki.info/bugs/trail_shows_on_cgi_pages/
Signed-off-by: Simon McVittie <smcv@debian.org>
Simple podcast feeds didn't have content tags and I made sure to
keep it that way. This may be unnecessarily conservative. Changing
the behavior to include empty content tags might be fine, but I
don't want to think about it right now, I just want my tests to
keep passing!
The new fancy-podcast tests are copy-pasted-edited from the
simple-podcast tests. These tests shall be refactored.
Technically, when the user does this, a passwordless account is created
for them. The notify mails include a login url, and once logged in that
way, the user can enter a password to get a regular account (although
one with an annoying username).
This all requires the passwordauth plugin is enabled. A future enhancement
could be to split the passwordless user concept out into a separate plugin.
Joey Hess
Simon McVittie
sajolida
Joey Hess
Amitai Schlair
intrigeri
Antoine Beaupré