[Request] Make a way for tokens to be clickable or add token data to every highlight...

Is your request related to a specific problem you’re having? A way to add a clickable link on each word or token.

The solution you’d prefer / feature you’d like to see added… A way to add a function to each highlight HTML element that can be called when it is clicked on. I would like to add at least one value to it and that is the type of entity it is.

Any alternative solutions you considered… I could add a click event on the container and then check the current target but that doesn’t give me the token type. If the highlight HTML elements could have data added to them then that would work. If you had a “div” tag that was highlighted it could be something like:

<span token-info="type:'tagname', name:'div'">div</span>

Additional context… Consider the following un-highlighted raw HTML code before it is highlighted:

<div id="div50">
	<span>Hello world</span>
</div>

What I would like is to be able to add a click handler for everything. The code after highlighting would look roughly like this:

<span onclick="hook('div', 'tagname')">div</span> <span onclick="hook('id', 'attribute')">id</span>="div50">
    <span onclick="hook('span', 'tagname')">span</span>Hello world
<span onclick="hook('div', 'tagname')">div</span>

[joshgoebel]

The way I see it, the syntax highlighter parses the code, marks each fragment with a class definition.

You’re still imagining a full parser I think… we only tag/highlight what we find interesting - what we think MOST people would want to colorize, sometimes this might only be 5-10% of files total content. It’s not our job to classify every single item. True, we do more than we used to (see #2500). Yet over 10 years of highlighting CSS and no-one has asked for values to be highlighted - include yourself - you’re only asking as a round-about way to achieve some other end.

Also:

• Other highlighters ignore values (GitHub, Prism, etc)

So I feel we’re in pretty good standing with our current behavior. That said, I did open an issue for this discussion - and we’ll see where that goes. And you’re welcome to comment on that thread.

[joshgoebel]

Looking at it, highlighting the color names doesn’t seem too difficult at this point but originally I was attempting to enclose the CSS property value so I could make it clickable.

Yes, and I believe you’ve already seen how if you customize the grammar (for your own personal uses) you might achieve this result - however that is not something we care about in the core library. I’m not even yet convinced that all values should be highlighted. Highlighting a thing well is as much about what one chooses to highlight as what one does not.

In rethinking this just now I’m not sure we should even add colors - unless we first think whether the plan is to include a list of ALL discrete values. I think before we go down that road I’d want to know how large a size change this is… would the CSS grammar going to be 10% larger or 200%?

Hint at valid CSS and valid CSS properties and values

We’re not interested in what is “invalid” as this is very hard to do with pattern matching across ALL grammars - and we desire consistency in features we add to the library. If adding invalid to all grammars would be difficult, we’re not interested in adding it to only a few (just because they are easy).

Check if the property name exists in CSS … Check if the property value is a valid value for that property

This is WAY out of scope. We are not a language parser. We are a sophisticated pattern matcher. You may want some type of CSS parser instead.