### Implementation The parsing of color chips should be strengthened. Take a look at suggestion 1. You can also review the suggestions in https://gitlab.com/gitlab-org/gitlab/-/issues/21821, but they mostly boil down to suggestion 1. The banzai/markdown filter is https://gitlab.com/gitlab-org/gitlab/blob/master/lib/banzai/filter/color_filter.rb, and the color parser is in https://gitlab.com/gitlab-org/gitlab/blob/master/lib/banzai/color_parser.rb You can ping @digitalmoksha for any questions. Overview -------- Gitlab Flavored Markdown's interpretation of "color chips" is prone to inappropriate activation. Example ------- Suppose you get a phone call. One of your users - Alice - has hit a snag, so she calls you to report it. You dutifully open Zoom, watch her demonstrate, take notes, and file an issue in Gitlab. ```plain Alice called at 3pm today. She's enabled the Gizmo component, but now she has a problem editing widgets. I watched this process on Zoom: 1. Search for gizmos. 2. Click on the third gizmo record (#79) 3. Open the widget tab 4. Click on the last widget #116 Note that it only crashes on widget #116. The other widgets on that screen are fine (eg #92 and #95 are ok). There's something weird about widget #116. ``` Of course, you made _Rookie Mistake #1_. This example would create a bunch of cross-references for unrelated issues:  This is not a big problem. It's well-known behavior. You goof up once, look for a mitigation, and carry-on. I'm a fan of the backtick - it works with most (all?) flavors of Markdown and most data/text. With backticks, the prose can safely include reference numbers (without spamming the world). Thus: ```plain Alice called at 3pm today. She's enabled the Gizmo component, but now she has a problem editing widgets. I watched this process on Zoom: 1. Search for gizmos. 2. Click on the third gizmo record (`#79`) 3. Open the widget tab 4. Click on widget `#116` Note that it only crashes on widget `#116`. The other widgets on that screen are fine (eg `#92` and `#95` are ok). There's something weird about widget `#116`. ``` Try `#1`, `#2`, `#3` -- that's fine. Try it on Gitlab, Github, Mattermost, mkdocs -- similar experience. Except... In Gitlab... some of the numbers get a mysterious black box:  Cause ----- My first reaction was: "Uhoh, there's a font problem." Well, no, it's not a font problem. (Yay!) It's a feature called a "Color Chip". The behavior is documented: * https://gitlab.com/gitlab-org/gitlab-foss/-/issues/24167 * [https://docs.gitlab.com/ee/user/markdown.html#colors](https://docs.gitlab.com/ee/user/markdown.html#colors) That sounds pretty neat... if you're a web-designer, who's day-to-day discussions involve color choices like `#a0a0ff` vs `#90b0ff`. (_Those are cool colors... which you can see... because Gitlab supports Color Chips..._) I can totally imagine how the feature would augment design conversations. But if you tend to talk about non-color things (eg database record#s), then you might feel more `#911` about boxes which randomly insert themselves. Suggestions ------------- 1. __Tighten up the parsing__. Only activate if there are _six_ hex digits. Anybody knowledgeable enough to write CSS color codes will know that the canonical form is six digits. Any image-editor/color-picker will output six digits. Going to six digits should reduce accidental activations. (FWIW, https://gitlab.com/gitlab-org/gitlab-foss/-/issues/24167 mentioned Github as a related example -- I tested, and they require all six digits.) 2. __Make the color chip more obvious__. If the user hovers/clicks on a chip `#116`, then give some feedback. Show a tooltip. Say it loud: "This is a color! This is `#111166`! This is `rgb(17,17,102)`!" Include a big swatch. Let the user soak-in the amazingness of that specific color.