Semantic Icons Proposal

[jpdevries]

View Markdown preview online

Voting

Only MODX Board Members may cast a vote. The Chief Architect and Chief Maintainer of the MODX Leadership are also granted one vote each. Votes may not be edited after they have been cast.

More info can be found in the voting protocol.

[OptimusCrime]

Good proposal. I was just wondering about the concept of splitting up the FontAwesome file and serve only the icons we use. First, MODX offers the feature to use the entire FontAwesome set for custom icons, this would then be impossible/limited to our subset. Second, would it not make sense to firstly rely on users cached version of the library? As FontAwesome is used on millions of pages already, it would make sense to request the CDN version first.

[jpdevries]

@OptimusCrime I like the idea of only including the icons we use especially since FontAwesome 5 is slated to have thousands of icons. Font Awesome 5 is moving towards an SVG approach, they aren't ditching the web font but they'll support an SVG sprite which is much better.

There's an example of using Grunt to create an SVG sprite from a folder of icons here:
https://markup.tips/projects/grunting-icons-into-svg-sprites.html#focus

It checks out FontAwesome using bower but also shows how you can include custom icons too.

Second, would it not make sense to firstly rely on users cached version of the library? As FontAwesome is used on millions of pages already, it would make sense to request the CDN version first.

I'm all for leveraging the browser cache. The best request is the one that isn't made. The only issue is, unlike with JavaScript, (and without JavaScript) you can't determine if the CSS file successfully loaded. Maybe we could use <noscript> to load a local copy and reach out for the CDN version, load the local if the request fails but I'm not sure if loading the entire icon set makes sense anyways. Especially since by the time we are breaking ground on the next Manager interface FontAwesome 5 might be out.

We could consider hosting our own custom iconset of just the ones we use on a CDN but another reason I'd lean towards loading them locally is offline support. Service workers can cache files in their scope for offline storage but I don't think you can do that for files coming from a CDN. It might be better to pay that one time load per MODX install for a local icon set, have the service worker cache it, and pull it from the cache from then on than to rely on the browser cache.

[jpdevries]

I've documented emoSVG, a JavaScript utility that will assist in progressively and freely enhancing emoji icons into SVG icons
https://github.com/jpdevries/emosvg#emosvg-

[OptimusCrime]

While the technology and the possibility to do this is cool, I am somewhat unsure if native Emojis can replace an icon set directly. Emojis were never meant, as far as I've understood, to be used in such a context. They are usually used as message smilies and emoticons found in chats, commit messages that is directly output from a user.

In the examples above the work, but in reality where we would need icons for folders, resources, weblinks, symlinks, snippets, plugins etc. It would be much harder to find anything suitable. Another problem is that fact that these Emojis can not be styled and live their "own" life separated from coloring scheme etc. What is the plan in terms of this? Just go with it, or is it possible to do anything wit this?

[jpdevries]

While the technology and the possibility to do this is cool, I am somewhat unsure if native Emojis can replace an icon set directly.

It's not meant to replace an icon set. It is meant to be progressively enhanced by one.

This is the loophole:
It is recommended that icons are delivered Emoji first when possible and otherwise or based on system settings use the SVG syntax with an optional PNG fallback as described in Grunt Icons into SVG Sprites Milestone 6.

So if there isn't an applicable Emoji, don't bother trying to progressively enhance from one.

They are usually used as message smilies and emoticons found in chats, commit messages that is directly output from a user.

Emoji is literally the fastest growing language of all time.

In the examples above the work, but in reality where we would need icons for folders, resources, weblinks, symlinks, snippets, plugins etc.

I've been working on a progressively enhanced proof of concept at http://m5bp.herokuapp.com

Here's what the folder icon looks like as Emoji:

Another problem is that fact that these Emojis can not be styled and live their "own" life separated from coloring scheme etc.

I probably didn't write enough on the difference between the interpretive nature of Emoji and declarative nature of art directed icon sets. The point is, what you point out isn't a problem at all. It is a strength. Emoji–first isn't just about the fact the art weights 0kB. For one reason or another, these icons may be more accessible and legible to users. The idea is they can set preferences indicating they prefer Emoji over something more declarative and art directed like a icon set such as font-awesome.

I did add a link to this Proof of Concept though, which has lots of info in the README
https://github.com/jpdevries/emosvg#emosvg-

What is the plan in terms of this? Just go with it, or is it possible to do anything wit this?

The goal is to be able to ship a configuration of the Manager that is unbelievable light. The Manager doesn't have to default to Emoji icons, but I think making it configurable will be a win for users trying to save data as well as ones who prefer the interpretive and responsive nature of using the icons already present on their device.

[jpdevries]

I've renamed this to "Semantic Icons Proposal", removed references to Emoji and bandwidth, and marked it ready for review. It now aims to just kill Icon Fonts.

[OptimusCrime]

Can this PR be closed or merged? It keeps appearing in my "Pull requests" overview, and I can not see any way of removing it myself. Thanks.