Add emoji names for Material and Fontawesome Icons

[facelessuser]

Provides a custom emoji index and generator for the Material theme that creates a copy of the Twemoji index and adds short names for all the icons included in Material (Material and Fontawesome).

Theoretically, if Octicons were added, it should see those and handle them as well.

Icons shortname are generated from their path. So if we had fontawesome/brands/github.svg, we could access it via :fontawesome-brands-github:. Same would work for Material etc.

It is assumed that all file names are [\+\-\w]. I'm pretty sure all the icons in the current sets follow this.

I have not rebuilt the styles yet. That needs to be done still.

[facelessuser]

I don't know what is up with the the CI failing 🤷‍♂.

[squidfunk]

Is it okay, if we postpone this after the release of v5? The release is packed with so many stuff, I would like to release this feature separately with 5.1.

[facelessuser]

I was thinking about this a bit more, and wondering if an alternative approach would make sense.

I have an extension called B64, and while I am not proposing to do something exactly like this, what if it was similar?

I'm thinking that maybe:

• It uses normal image syntax
• We could do it for all SVGs, or maybe we require something that triggers it, maybe two !!?
• It injects some element with a specific id and class.
• Then it generates an internal mapping. If it has already seen the SVG, we don't create duplicate copies.
• Post processing, we inject a style tag at the tail of the document with CSS variables for all the inlined SVG, and then injects styles to set the image as the background for the related id.
• If a user wants to set a specific size to a group of SVGs they can set additional classes with the attr_list extension and style accordingly, or set manual sizes with attr_list.

I imagine you could do something like:

![My SVG](path/icon.svg)

Set class;

![My SVG](path/icon.svg){: .icon}

Set size:

![My SVG](path/icon.svg){:. width="30px" height="30px"}

Or if we wanted an explicit inliner (same behavior as above applies):

!![My SVG](path/icon.svg)

Less emoji like, but we could adapt this to all images types really (though inlining for PNG, GIF, and JPEG would maybe just be base64.

Just a thought. Let me know what you think. I'd need to prototype this and everything, but in my head I think it would work. I'd have to prototype this up etc. Obviously I'm in no rush to do this for 5.0 release, but something to think about. It would mean that pymdownx would own this, and Material would not have to do anything or support it in its code base.

[facelessuser]

If you set as background you wouldn't be able to set height and width...you'd have to use some other syntax like background-size or whatever, but it would still kind of work...at least in my head.

[facelessuser]

Well, I guess material would still have to own it, as we'd need to expose assets...unless I could figure out a way around that. It would be a different approach though, and one that would allow you to not re-include duplicate assets potentially.

[facelessuser]

We could also keep it simple and just inline normal and not worry about injecting styles. In that way, it would be very much like the B64 extension. But you could just make inlines explicit with !!.

[squidfunk]

In general I prefer to trust your gut feeling regarding everything that is related to Markdown processing. The motivation for this feature was to make icons usable from within Markdown - if that's possible otherwise, it's cool. However, I'd say that it might be a good idea to start with inlining and then, probably later, improve on integration if we know more use cases and have some user experience available.

[facelessuser]

Sounds good, then post Material 5, I'll look into solutions more. The solution here will work, so if we want to do this we can.

I will probably also prototype kind of what I suggested above. It will be a simple image inlining extension. It will be a general purpose image inline extension meant to replace b64. It will base64 PNG, GIF, and JPEG, like B64 did, but also inline SVG. I think a manual inline syntax is the approach I will take with the ability to optionally inline everything if you are trying to produce a self contained document (something I do sometimes outside of Material and project documentation).

I'll keep it simple for now. We can always make it more "advanced" in the future if we feel it is necessary, or just leave it alone.

I may see if there is an easy way to create an option to find Python module paths. That would make it so Material wouldn't have to do anything, which I imagine is the ideal case.

[squidfunk]

Cool, let's to it like that!

[Andre601]

I personally think the emoji-like approach would be the best option as it feels more suited for what you do here.
I myself always see ![...](...) as integrating images, which break text in a way while I see :text: as intecrating icons in tex, which just sits there if you get what I mean.
Having it like !![text](path) seems unnatural in a way, while :text: is more logical in a way as it seems only natural to have it like that, since you can treat those icons like emojis too (Which are essentially icons too).

So tl;dr I personally would go with the emoji-like syntax and maybe have this image-like syntax as a separate thing somewhere.

[facelessuser]

We'll see how it goes. Technically they are images, but also icons 🤷‍♂ :. Regardless of whether I provide a way to inline SVGs, Material could always go the route suggested here.

[facelessuser]

Closing in favor of #1575