We'd need to either dynamically generate a CSS file containing the relevant styles, or would need to apply inline CSS to each label div.
If we inline'd the CSS, it'd make it harder for operators to override colouring for a specific label (at best, they'd need to use !important in their CSS), plus it'd cause headaches if there were ever a desire to serve GILS with a decent CSP (not that there aren't already headaches, but best not to add to them).
So, I think what we're looking at is generating an "external" CSS file containing the necessary colouring information.
Actually, in practice, it'll be an external CSS file per project - Gitlab's API doesn't let you fetch a global list. You can do per namespace/group, but that'll exclude any labels that have been created at the project level.
Currently a label looks a bit like this
<span class="label">Resolution::Won't Fix</span>
We'd need to expand the class to include an identifier for that specific label.
Whilst it'd perhaps be nice to use something unambiguous like label's ID for that, that information isn't currently available to us - the Issues API only returns the text of the label, no other information.
So, either we need to do it by label text (making sure to convert it to something CSS/markup safe) or we need to do a separate fetch to get all labels for the project and then attach the necessary information into the issue object.
That's not ideal, we'd have to refetch them when the user's browser requests the CSS file too (although Redis caching, if active would obviously mitigate this a bit).
What we might want to do then, is build the CSS when fetching the label and push it into a style header in <head>. It means a bit of overhead on any page carrying labels, and it'll need changing if we do want to tweak CSP related stuff later, but avoids the immediate request overhead.
This allows us to display a tooltip showing the label's description, but the real intent is as the first step toward being able to use the correct label colouring
Although it means some inline CSS, it's a trade-off: if we were to spin out an external css "file", we'd need one per-project, with each involving a second API call to Gitlab.
We only embed CSS for labels that are actually used on each page, so the markup overhead is minimised
Activity
23-Apr-22 10:12
marked this issue as related to #26
25-Apr-22 09:42
There are two sides to achieving this
Retrieving information about labels is pretty straightforward, we'd just need to call the labels API.
Applying that information though is dependant on us exposing the relevant bits of information.
We'd need to either dynamically generate a CSS file containing the relevant styles, or would need to apply inline CSS to each label div.
25-Apr-22 09:43
If we inline'd the CSS, it'd make it harder for operators to override colouring for a specific label (at best, they'd need to use
!importantin their CSS), plus it'd cause headaches if there were ever a desire to serve GILS with a decent CSP (not that there aren't already headaches, but best not to add to them).25-Apr-22 09:53
So, I think what we're looking at is generating an "external" CSS file containing the necessary colouring information.
Actually, in practice, it'll be an external CSS file per project - Gitlab's API doesn't let you fetch a global list. You can do per namespace/group, but that'll exclude any labels that have been created at the project level.
Currently a label looks a bit like this
We'd need to expand the class to include an identifier for that specific label.
Whilst it'd perhaps be nice to use something unambiguous like label's ID for that, that information isn't currently available to us - the Issues API only returns the text of the label, no other information.
So, either we need to do it by label text (making sure to convert it to something CSS/markup safe) or we need to do a separate fetch to get all labels for the project and then attach the necessary information into the issue object.
That's not ideal, we'd have to refetch them when the user's browser requests the CSS file too (although Redis caching, if active would obviously mitigate this a bit).
What we might want to do then, is build the CSS when fetching the label and push it into a
styleheader in<head>. It means a bit of overhead on any page carrying labels, and it'll need changing if we do want to tweak CSP related stuff later, but avoids the immediate request overhead.25-Apr-22 10:11
mentioned in commit 8fbb76ca47a3491ced8c12ac565d8358cd3b6f21
Commit: 8fbb76ca47a3491ced8c12ac565d8358cd3b6f21 Author: B Tasker Date: 2022-04-25T11:10:50.000+01:00Message
Fetch more detailed information on labels for issue pages (websites/Gitlab-Issue-Listing-Script#39)
This allows us to display a tooltip showing the label's description, but the real intent is as the first step toward being able to use the correct label colouring
25-Apr-22 10:42
mentioned in commit befae2ceb54a256bc25d30f4dec87424a57068a2
Commit: befae2ceb54a256bc25d30f4dec87424a57068a2 Author: B Tasker Date: 2022-04-25T11:41:17.000+01:00Message
Add CSS block to issue page to enable label colours (websites/Gitlab-Issue-Listing-Script#39)
Although it means some inline CSS, it's a trade-off: if we were to spin out an external css "file", we'd need one per-project, with each involving a second API call to Gitlab.
We only embed CSS for labels that are actually used on each page, so the markup overhead is minimised