On 8. 9. 2026 20:13, C. Michael Pilato wrote:
So, perhaps `SVNIndexHeadInclude` (to indicate where this include is
getting injected), and yes I think it sufficient to just replicate the
option value inside the <head> element as-is. That, combined with the
aforementioned <div> wrapper and meaningful classes/ids, would let
someone source a CSS file or JS script or whatever, make stuff pretty,
futz with the DOM, etc.
As long as we add a big fat red flashing notice that all the bugs and
vulnerabilities arising from slurping JS into a plain ol' directory
listing are not our problem. I mean, it's a given that someone,
somewhere is going to inject supply-chained malware into their private
closed-source repo. Right?
-- Brane
On Thu, Jul 23, 2026 at 8:42 AM Daniel Sahlberg
<[email protected]> wrote:
Den tors 23 juli 2026 kl 13:56 skrev C. Michael Pilato
<[email protected]>:
On Thu, Jul 23, 2026 at 3:07 AM Daniel Sahlberg
<[email protected]> wrote:
Just from skimming through the docs it looks promising. If
you can make it work, I'd really love to put that into the
FAQ (and probably as a news item as well).
I still think we should at least entertain the most
low-hanging of the requested fruit. I mean, it would probably
take less time and effort than this conversation has to add
some decoration to mod_dav_svn's HTML output that would have
no effect on the visual representation of the directory
listing, but provide better "hooks" into the DOM for folks to
tap into. Consulting the list previously requested, these two
are the least disruptive in my opinion:
* class/id on list, class on list items preserving whether
item is dir/file/repository
* wrap list in div (would allow a flex layout without JS DOM
manipulation, easy to insert a sibling to the list using HTMX)
I again suggest that a simple SVNIndexCSS directive which
optionally injects a stylesheet reference to the <head> of the
output would be low-hanging enough to allow folks to make the
list prettier. But I'm also not particularly keen to add
esoteric features nobody has asked for. :-)
I agree, except that I'd prefer naming it SVNIndexInclude to allow
the end user to insert whatever they want (<script>, <meta>,
<style>, ...). SVNIndexCSS seems a bit too limited, especially if
it would only contain the name of the CSS file (much like to
SVNIndexXSLT) and just output the URL in a <style> element.
Is it enough to just dump the content of SVNIndexInclude into the
HTML output or do we also need the ability to load the content
from a file? That would make it an order of magnitude more
complicated though (and I'm not even suggesting being able to load
the content from a repository URL...).
Let's get 1.15.0 out of the box first and I can try to take a look.
Cheers,
Daniel
