]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/patchqueue/calendar_--_archive_browsing_via_a_calendar_frontend.mdwn
response
[git.ikiwiki.info.git] / doc / patchqueue / calendar_--_archive_browsing_via_a_calendar_frontend.mdwn
index 9581ce40658cb3a170dbf81f830bd0b2b3eb0cdd..fe0dba1aaa7cca69e7896ca1cc8412035adf4c88 100644 (file)
@@ -593,16 +593,16 @@ I've been looking over the calendar plugin. Some items:
   that emitting the whole calendar in the preprocess hook would simplify
   things and you'd not need to save state about calendars.
 
-> A) I am scared of the html scrubber, and have never turned it on,
+> I am scared of the html scrubber, and have never turned it on,
 >        and did not look too deeply into what would be scrubbed out --ManojSrivastava
 >> Unless you're using javascript, a few annoyances link <blink>, or inline
 >> css, it's unlikly to object to any html you might write. The list of
 >> allowed tags and attributes is easy to find near the top of the plugin.
 
->     B) In case the option that gets the ctime of the pages from the
->        SCM itself, %IkiWiki::pagectime  is not populated that early,
->        is it? So I waited until the last possible moment to look at
->        the time information.
+> In case the option that gets the ctime of the pages from the
+> SCM itself, %IkiWiki::pagectime  is not populated that early,
+> is it? So I waited until the last possible moment to look at
+> the time information.
 >
 >> Actually, since my big rewrite of the rendering path a few months ago,
 >> ikiwiki scans and populates almost all page information before starting