search

modxcms / revolution

MODX Revolution - Content Management Framework
https://modx.com/
GNU General Public License v2.0
1.35k stars 528 forks source link

Death to Icon-Fonts? (@fontface) #12771

Open jpdevries opened 8 years ago

jpdevries commented 8 years ago

Roadmap wise (and i'm not sure how this fits in with semver) I think it is worth considering doing away with icon fonts. They simply aren't accessible. https://github.com/FortAwesome/Font-Awesome/issues/6133

Let's say Font-Awesome 5.0 addresses issue 6133 along withe the other a11y concerns. Still not really accessible: https://speakerdeck.com/ninjanails/death-to-icon-fonts

I've been using a Grunt based workflow lately that allows you to use font-awesome as an svg implementation rather than a fontface implementation.

Here's roughly what it does:

<svg class="icon">
  <use xlink:href="assets/img/icons.svg#icon-heart"></use>
</svg>

If you'd like an icon to be read aloud by a screen reader:

<svg class="icon">
  <title>Globe</title>
  <use xlink:href="assets/img/icons.svg#icon-globe"></use>
</svg>

Just like with icon fonts, you can easily color the svg icons.

svg.icon {
  fill:currentColor;
}

The only downside I'm aware of to using <use> with <svg> is that your sprite can't be loaded from a CDN (or any other domain) regardless of CORS. This is apparently being worked on though.

While the death to icon fonts to a great job of explaining why @fontface shouldn't be used for icons because users can change the fonts used on a web page for legibility (to say maybe OpenDyslexic) I do think that one possible work around is to add settings to your experience that allow the font to be changed for everything except your icons. For example:

jpdevries commented 8 years ago

Did a little more research and realized I suppose you could say there is another downside to an SVG based icon system than a font icon one. AFAIK you cannot draw icons using pseudo elements without an icon font. For example, in Revolution currently we can do:

.tree-new-weblink > em > button:before {
  //@include icon($link);
  @extend %pseudo-font;
  content:$fa-var-link;
}

Which is a nice way to add an icon without having to put anything in the markup at all.

Update

Ok maybe I lied. This actually could be accomplished with SVG if you embed the SVG in the stylesheet using base64 encoding.

gadgetto commented 8 years ago

I always hide font-icons from screen readers and provide text alternatives. So no a11y problem in my opinion.

jpdevries commented 8 years ago

I always hide font-icons from screen readers and provide text alternatives. So no a11y problem in my opinion.

This isn't really about screen readers. You can make an icon font read by one, or not read by one as you mentioned using ARIA roles. SVG icons will only be read aloud if you include a title so you have control there too.

It's about what happens when users override your fonts. Notice if users change the fontface of a webpage (using a browser plugin or preference) so they can read it better icon fonts break

That is the a11y problem.

Also let's not forget that over 300 million users use modern devices that don't support fontface at all.

gadgetto commented 8 years ago

From this perspective you are right. But then we need to discuss web-fonts in general. Because if a user changes the font face it could also break a11y.

jpdevries commented 8 years ago

Certainly one of those times I wish I was wrong. It was a significant effort to get font awesome into Revolution, so it would be kind of a bummer to pull it out but the research does speak for itself. Maybe this is more something we just keep in mind and plan for MODX Next.

OptimusCrime commented 8 years ago

I can't see any way this can be done before 3.x.

alroniks commented 8 years ago

I agree with that using font for icons is a crutch. That have done when not existed other solutions. But now we have SVG, and svg allow to create icons with many colors for example (font allow only one color for whole symbol). It would be good use svg for icons in new versions of MODX or just in new manager panel.

jpdevries commented 8 years ago

I can't see any way this can be done before 3.x.

Me niether. I think this probably should target "MODX Next".

I don't know much about MODX Next but I hope out of productive conversations like this we can formulate some sort of 'guidelines", almost a spec if you will, of how we agree solutions should best be approached when creating a Manager interface. Not only would this help ensure the default MODX Next theme is solid, but I think it also could help people create their own themes of the same caliber.

For example, I would love it if the MODX Next API was framework agnostic, meaning it doesn't exactly "replace ExtJS" with something like React or AngularJS but is built with web standards allowing theme developers to extend upon with the framework(s) of their choice.

dubrod commented 8 years ago

There is no need to remove Font Awesome. The big scary "300 million users" fact is about browsers not users. If Opera Mini chooses not to have that support thats on them. There is always going to be a case where a browser doesn't support something.

What we need to do is change the markup of UI element.

For example, already working in the a11y project. The Content Toggle Arrow... https://github.com/modxcms/a11y/issues/55

we added an ARIA label and a hidden DOM element.

jpdevries commented 8 years ago

There is no need to remove Font Awesome.

I'm not suggesting we remove Font Awesome. It is a great icon set. I'm suggesting an SVG implementation over a fontface one, maybe just on the roadmap for MODX Next because I think switching to an SVG implementation in Revo would be a lot of work.

Fontface has 92.87% global browser support and really has no polyfill. So, there's at least 7.13% of the web of a reason to remove the webfont implementation currently being used.

SVG support is trickier to measure. That said SVG has a global browser support of 96.39% and can fall back semantically to PNG graphics. Whoot.

Two really great articles on the subject (one is a rebuttal to the other) http://blog.cloudfour.com/seriously-dont-use-icon-fonts/ http://benfrain.com/seriously-use-icon-fonts/

One of the points the author makes in the pro-icon-fonts article is that they only use them in non-critical situations (like where there is an icon and text inside a button) but in Revo we use them critically all over the place.

The big scary "300 million users" fact is about browsers not users.

Incorrect. Users configure their browsers with plugins and settings. It's about the users and how they browse, not the browsers themselves. For example, iOS 9 introduce Content Blockers allowing apps like Focus by Mozilla to allow users to do things like block web fonts entirely.

Focus has nothing to do with the Safari browser itself and everything to do with how the user opted into browsing the web. In this case the choice to block web fonts is made by the user not the browser.

We also saw in in the speakerdeck that there are plugins that do things like overwrite all fonts on a page to something like OpenDyslexic which of course breaks any web font icon implementation. Here is Github with the OpenDyslexic plugin enabled:

dubrod commented 8 years ago

Roadmap wise (and i'm not sure how this fits in with semver) I think it is worth considering doing away with icon fonts. They simply aren't accessible.

I'm not suggesting we remove Font Awesome.

Sorry I misunderstood

Also let's not forget that over 300 million users use modern devices that don't support fontface at all.

In my opinion your using this statement to justify your request to use SVG while this 300 million users is a mute point, it even says on your slide "P.S. - Help us find more accurate data", and not relevant to the point about providing clear text in a situation where font-face is not supported

Incorrect. Users configure their browsers with plugins and settings. It's about the users and how they browse

Notice if users change the fontface of a webpage (using a browser plugin or preference) so they can read it better icon fonts break

So you want to list every combination of plugins and settings and make sure we cover them all?

That's a never ending battle

I actually have added the Dyslexia font example in the a11y manager so I know how to make 2 fonts co-exist in MODX. I built it as an option to turn on and off instead of relying on the user to override it.

If you go down this path of what a user can and cannot create we are going to be spending more time here in Issues than coding.

jpdevries commented 8 years ago

In my opinion your using this statement to justify your request to use SVG while this 300 million users is a mute point, it even says on your slide "P.S. - Help us find more accurate data", and not relevant to the point about providing clear text in a situation where font-face is not supported

I think about the 1 user that can't access something because they are:

It is going to be increasingly difficult to find accurate data on users that browse without icon font support. The AppStore doesn't publish download numbers, so we have no idea how many people are downloading and using Focus.

It doesn't matter if it is 300,000,000 or 1 to an HTML designer because they design a web for everyone.

That's a never ending battle

No it isn't.

If you go down this path of what a user can and cannot create we are going to be spending more time here in Issues than coding.

Concerning to hear this.

OptimusCrime commented 8 years ago

I think trying to have this in the manager is a good thing, but by far not a critical aspect of it.

I mean, there are billions of webpages that don't do anything about this. Try to check the wordpress interface. I bet it has the same limitations too. There is a reason these fonts are popular, it's because they are fast, well developed, and does a good job. Simply removing it will not work, and the good alternatives are hard to find.

OpenDyslexic is one thing, but the other things on the list can easily be excused by 'the manager was never intended for such displays'. Opera Mini is a handheld micro browser, until every recently the manager did not function at all on mobile devices. So I suggest trying to work this into the a11y-project and focus on things that does not require a HUGE work around in the default theme.

jpdevries commented 8 years ago

I think trying to have this in the manager is a good thing, but by far not a critical aspect of it.

It is critical for a certain group of users as long as webfonts are used critically as they are in 2.x. That is without question. I think the question at hand is are we going to design interfaces for every user or continue to make exceptions?

Try to check the wordpress interface. I bet it has the same limitations too.

Here is the Wordpress Admin with web fonts disabled:

And that is from Wordpress 3.3.1 released Jan 3, 2012. The current version supports no-webfont as well.

There is a reason these fonts are popular, it's because they are fast, well developed, and does a good job

They are no faster and do no better a job than SVG sprites with the exception that SVG <use> doesn't loading from a CDN yet. I also think SVG sprites offer a much better workflow. Imagine being able to plop a bunch of SVGs in a folder and use a Grunt or Gulp workflow to create a sprite. This sprite could even have icons from a variety of different sets with no issue.

'the manager was never intended for such displays'

The 2.x Manager wasn't designed for a11y either and frankly making it fully accessible is impossible as long as ExtJS or any other HTML–last approach is being used.

To compare again with Wordpress again, try using the admin with JavaScript disabled. Pretty much everything works as expected. They are still working on some accessibility improvements for Wordpress 5 but even Wordpress 4 is way ahead of us in this area.

So I suggest trying to work this into the a11y-project and focus on things that does not require a HUGE work around in the default theme.

I agree. I think we should focus on conversations like these though for future versions (MODX Next) but I thought it was worth discussing for the Revo roadmap as well especially with all the a11y stuff going on.

OptimusCrime commented 8 years ago

Is it possible to use fontawesome with svg like you explain? I mean, MODX really needs a HUGE icon set to function properly. Are there any so popular projects for svg?

jpdevries commented 8 years ago

@OptimusCrime See https://github.com/modxcms/revolution/issues/12771#issue-118004063

The workflow I'm proposes makes use of the full font-awesome library and automates the switch to SVG <use> support but what I'd really point out is that you could also throw any other SVG icons in that folder and those would get included in the sprite too.

You plop your SVGs in a folder or let the script check out the latest version of font-awesome and plop them there for you. Run one grunt command and you have an SVG sprite with icons referenced by ids keyed off their filename. You also have fallback PNGs automatically generated and a polyfill for no-svg browsers. Completely accessible. Full browser support. Full user support.

Really the only downside IMO is you can't load your sprite from a CDN yet but I think it is safe to assume that by the time "MODX Next" breaks ground :crystal_ball: that will be worked out. For sites I've tested, it's still faster to load a local SVG sprite than fontawesome from a CDN because the script will only put icon art (and there are no weird CSS classes) in the sprite that are used in the templates, so it might be only a few dozen icons.

I also don't think the icons "block" pageload as bad with an SVG implementation yet but I haven't done any real research or testing on that.

There is a reason these fonts are popular…

Webfont based icon sets were created out of a necessity that is no longer present. Just like Flash. I wouldn't be surprised if fontawesome 6 switches to an SVG sprite implementation so maybe this issue will be a non–starter. I bet the only thing they are waiting on is CDN support.

jpdevries commented 8 years ago

This entire issue could be summed up in less than 140 characters.

“the whole idea of using a font to display icons is as much a hack as tables for layout were.”
– tweet by @SaraSoueidan

rthrash commented 8 years ago

Key UI elements should not rely solely on an icon for many reasons, a11y included. Fortunately there are straightforward ways to address that. An SVG-approach sounds like a great idea to explore; there probably should be a similar issue raised for Revo 3 (and absolutely for MODX “Next” when that surfaces on Github).

I'm not sure if removing FA icons from 2.x would represent a breaking change because site builders and developers might use them for CRCs. My gut says it probably would violate the “no breaking changes” rule, though… if not it'd be really awesome to see a prototype demo of how it would work in the current major version.

Further, I concur we probably won't reach full perfection on the accessibility front for 2.x. But that doesn't mean it's not worthwhile, and it definitely is not an issue that merits derailing or deriding the effort. It absolutely is a valid discussion, however!

To me at least, it seems like a making it available as a theme for users to download and install on "pre-a11y" versions of Revo—and hopefully with it fully distributed with the core for an upcoming minor version of 2.x—is a very positive step in the right direction.

jpdevries commented 8 years ago

Further, I concur we probably won't reach full perfection on the accessibility front for 2.x.

Agreed. Working with ExtJS and having no HTML layer that is progressively enhanced it would be arguably impossible to achieve "full accessibility".

Fortunately there are straightforward ways to address that.

Regarding the OpenDyslexic stuff it already has been addressed in the a11y theme so I think you are off the hook there.

there probably should be a similar issue raised for Revo 3 (and absolutely for MODX “Next” when that surfaces on Github).

Any idea when we might see that happen? Even if it is just a blank repo where issues like this can be posted? I'm sure there are others in the community that would be anxious to pitch in working on MODX Next even while others are working on 2.x and 3.x.

jpdevries commented 8 years ago

I'll be the first to admit, this is pretty great. Long Live Icon Fonts demonstrates how ligatures can be used for a pretty bullet proof and accessible webfont implementation. Ligatures does allow for "cleaner" markup than the SVG <use> approach.

I spent a while trying to de–bunk it and couldn't. The only potential valid concern I can come up with involves i18n support. Would you need a separate font file with different ligatures for each language?

At 81.27% browser support is not fantastic, but that is ok because it falls back naturally to text. Use something like Focus to disable webfonts? Doesn't matter, text will display.

webfonts enabled

webfonts disabled

SaraSoueidan commented 8 years ago

@jpdevries I’m a bit tired of the whole icon fonts vs SVG debate because SVG is clearly superior, and icon fonts have always been a hack and now that we have a "native" option to display icons we should embrace it instead of favouring our own convenience as devs (I know many devs prefer icon fonts because it's easier and faster to implement); but this is just my opinion. I have yet to find one relevant or compelling icon font argument that is about the user, not about the dev workflow.

But regarding your last comment, see Zach Leatherman’s replies to the writer of the Icon fonts and ligatures idea: https://twitter.com/zachleat/status/676073390365511680 — there is a timeout problem esp. in Safari that makes this idea not as bulletproof as it might seem at first. It requires a workaround which brings us back to the whole "icon fonts are a hack" idea.

Please do feel free to ignore my comment. I only commented because I was mentioned and have no intention to get into the svg vs icon fonts debate here as well.

jpdevries commented 8 years ago

@SaraSoueidan I'm sorry didn't mean to drag you into an old debate in yet another project ;)

I agree with you that SVG is clearly superior. I really appreciate all the research on SVG you've shared as it has helped me come to such a conclusion.

Another thing I wonder about with the ligature idea is how does it work with i18n? Would you have to have a different font file for each language set?

Thanks for chiming in.

jpdevries commented 8 years ago

Is it possible to use fontawesome with svg like you explain?

@OptimusCrime This Thinkful Project takes you through switching from an iconfont implementation FontAwesome to an SVG sprite implementation. By following along and then inlining the SVG Sprite (and nothing else) I improved the mobile PageSpeed Insights score of markup.tips from 75 to 99. Just like that. https://www.thinkful.com/projects/grunting-icons-into-svg-sprites-573

This is a similar article as well http://blog.cloudfour.com/our-svg-icon-process/

I think it is clear that this "switch" wouldn't likely be considered until a MODX Next, so this issue should probably get moved to that repo when appropriate.

jpdevries commented 8 years ago

GitHub switched to SVG icons yesterday and shared a great write up on it :+1:

“By switching from icon fonts, we can serve our icons more easily, more quickly, and more accessibly. And they look better.” https://github.com/blog/2112-delivering-octicons-with-svg

Next time around, we should definitely make sure to route all the calls to icons to one Chunk or something so it only has to be changed once. I recently went through the pain of having to update icon syntax all over the place, not fun: https://github.com/blog/2112-delivering-octicons-with-svg#how

SVG Icons can be filled with multiple colors, giving them more creative freedom than icon fonts. They are very MODX! :lollipop:

rthrash commented 8 years ago

Great call JP. Thanks for sharing the most recent example and experience. Do you think kit would make sense to consider for Revo 3?

jpdevries commented 8 years ago

@rthrash I do think it would be worth considering mostly so that we could update the Manager theming API to be more accessible to how people create and use icons. For example, it is a lot simpler to say "add this SVG code and then use an icon anywhere like this" than it is to document or support creating custom icon fonts.

With SVG icons it wouldn't just be "you can use font awesome icons in MODX easily" it would more be "you can use any vector icons, and we've already got the font awesome ones bundled for use".

As part of the effort, I would suggest abstracting all the calls for icons to one function/Chunk/whatever for future updates to icon syntax.

I've got the Grunt stuff done for the workflow but things that would be left that I can think of would be to

One thing I kind of like about our 2.x implementation is it allowed us to aadd font-awesome icons with no markup. Essentially, we can "paint them" with CSS using our utility. Might also need to look into how to work around that as well.

Ruslan-Aleev commented 5 years ago

@Alroniks Is this discussion still relevant?

JoshuaLuckers commented 5 years ago

I think @jpdevries has a good point. We should leave the discussion open and get back to it once 3.x is released.

alroniks commented 3 years ago

Yep, I am going to convert it to format Proposal, which can be targeted later to a specific version.