Open mardy opened 5 years ago
An invisible <span>
element is just plain wrong. I’m not really convinced why this is something that Nikola should do out of the box. Customizing themes for this is really simple, and are there really that many things that use that special markup? How would Nikola benefit from invisible <span>
s everywhere? Are you sure search engines are happy to see invisible <span>
s anywhere on a site?
Maybe we should treat the two issues separately: adding the data is one thing, adding the markup is another.
The addition of the authors data can be valuable: we can add their e-mail and photo in their index page, which I believe is not trivial to do with a theme customization (or then, why do we have the AUTHOR_PAGES_DESCRIPTIONS
variable?).
And a similar mechanism could then be used to set images on tags and categories, by the way.
It is fairly simple to add your author data to global_context
and modify the template that generates author pages to show it.
I'm working towards the goal of supporting webmention in my site. When I'm writing a post which is a reply to someone else's blog, and I send it as a webmention, I would like that — if my reply is accepted and shown in the original post — my name, avatar, homepage, and e-mail can be parsed by the webmention engine powering the target website and properly shown above my reply.
Most of the above actually happens only at the discretion of the target's website, but a precondition for that to be feasible is to have my microformats h-card embedded into my posts' h-entry. Posts generated by Nikola already have the proper
h-entry
markings, and with #3294 they will also have a basich-card
containing just the author's name. However, other fields are missing and it would be nice to get them in there too.For posts that don't have a specific author set, Nikola uses the default author from
conf.py
; there are already a few variables that could be presented in theh-card
:SITE_URL
BLOG_EMAIL
We just miss a
BLOG_AUTHOR_AVATAR
, but we could even use the image from theFAVICONS
variable or require that such additional fields be entered in theAUTHORS_DATA
dictionary I'm describing below (might be the best option, in fact).For other authors, a reasonable url is their automatically generated index page; however, e-mail and avatars are missing, so we could introduce an optional variable for them:
with all data being optional.
In the theme the new data can be shown as an invisible
<span>
element, how I'm doing here. But we might want to add a config variable likeSHOW_AUTHOR_AVATAR
; or we can also assume that, if an avatar is given, then it must always be shown (and those who don't want it — like me — can still go and modify their theme).