From: john at keeping.me.uk (John Keeping)
Subject: [PATCH 2/2] ui-shared: emit root-desc-html and repo.desc-html after their text counterparts
Date: Sat, 23 Jun 2018 11:53:42 +0100 [thread overview]
Message-ID: <20180623105342.GF6584@john.keeping.me.uk> (raw)
On Sat, Jun 23, 2018 at 06:33:38PM +0800, Andy Green wrote:
> On 06/23/2018 06:28 PM, John Keeping wrote:
> > On Thu, Jun 21, 2018 at 02:46:47PM +0800, Andy Green wrote:
> >> Where root-desc and repo.desc are used in the header region, also
> >> emit their html counterparts afterwards if they are defined.
> >> Where root-desc are repo.desc are used outside the header,
> >> eg in the repo list, leave it as it is without adding any
> >> related html.
> >> Signed-off-by: Andy Green <andy at warmcat.com>
> >> ---
> > I think this should be squashed with the previous patch since it makes
> > it easier to see what's going on.
> > When I read your initial email on this, I thought we could introduce a
> > new HTML version of the description and use that *instead of* the plain
> > text one if the HTML variant is available.
> I actually first implemented just rendering what we have as raw html...
I don't think we can do that without introducing an HTML injection risk
in configurations that are currently safe.
> > Having looked at the current implementation of repo->desc, I think
> > that's desirable because the reason we don't have a null-check for that
> > in the context below is that it will be set to "[no description]" if no
> > other value is provided. If a user has set repo->desc_html, I don't
> > think we want to print "[no description]" before showing the HTML
> > description!
> I take the point, but it turned out there are two separate kinds of
> description here... the text-only, existing one that is used, eg, in the
> list of repos. And a "functional" HTML part that has buttons or
> whatever specific to the repo and used on the header part.
> With just treating them as one, the repo list gained meaningless HTML
> buttons or pictures or whatever decoration was put there. The repo list
> just wants a short textual description that already exists. So it
> arrived at this, leave that be, and add an optional HTML decoration part.
OK, that makes sense. Maybe we need the following check, but it is
if (ctx.repo->desc &&
(ctx.repo->desc != cgit_default_repo_desc ||
that is, show the plain text description only if it has been customised
or if there is no HTML description.
next prev parent reply other threads:[~2018-06-23 10:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 9:04 repo.desc as raw html? andy
2018-06-20 13:17 ` [PATCH] noheader: place branch combo on tabs if no header andy
2018-06-23 10:50 ` john
2018-06-21 6:46 ` [PATCH 1/2] config: add root-desc-html and repo.desc-html andy
2018-06-21 6:46 ` [PATCH 2/2] ui-shared: emit root-desc-html and repo.desc-html after their text counterparts andy
2018-06-23 10:28 ` john
2018-06-23 10:33 ` andy
2018-06-23 10:53 ` john [this message]
2018-06-23 11:08 ` andy
2018-06-23 16:33 ` john
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).