GitHub - adi1090x/polybar-themes: A huge collection of polybar themes with different styles, colors and variants.

A huge collection of polybar themes with different styles, colors and variants. - adi1090x/polybar-themes

GitHub

I've been feeling a bit weird using icon fonts lately, especially because of the accessibility concerns—and especially with the trend of using italic text to put in an icon!

Fortunately, this blog post linked to by the ForkAwesome repo (it's a now-defunct fork of FontAwesome) has some suggestions for alternatives. TL;DR: use SVGs directly 

https://www.irigoyen.dev/blog/2021/02/17/stop-using-icon-fonts/

#IconFonts #FontAwesome #SVGsAreTheFuture

Stop Using Icon Fonts by Michael Irigoyen

Icon fonts became popular over a decade ago. But their convenience comes at a high cost to your visitors.

Burned by My Own Hot Take – Tyler Sticka

It was 2015, and I was tired of losing arguments with customers about icon fonts. They were inaccessible, error-prone, and they looked worse…

I installed the #Landmarks add-on in #Firefox, and I was surprised #Mastodon doesn't have #a11y support. The only thing the default theme have is a generic “region”.

* Using semantic #HTML5 elements correctly = #accessibility support. (Image alt text is but one small thing.)

* Or, mark generic elements with #ARIA roles and labels.

* Stop using #IconFonts too.

As a11y has become a deeply personal thing for me (you won't understand its importance until you or a loved one needs it), I'm not only updating my own sites and practices, but I'm also checking existing platforms.

Having proper support in #Fediverse software/platforms can be a strong feature the network can add to the front / “marketing”.

I started to create a new #HTML5 and #CSS4 boilerplate, mainly for my personal use. I'm aiming for the following:

1. #A11y / #Accessibility support / #ARIA

Often forgotten. This time, it's deeply personal, it's now a must for me.

2. Avoid #IconFonts, use #SVG instead.

Same as the first item, but deserves to be mentioned separately.

3. #Microformats support

For #IndieWeb, #Webmention, #Fediverse, and related support.

4. Use the ‘rel’ attribute where appropriate

Same as those in the previous items.

5. Styling using style classes only. Not microformats classes, as those can be reused for other purposes.

I used to, and I also noticed others doing the same, use microformats classes for styling. And then just override it if the same microformat class is reused elsewhere. Makes everything confusing; and hard to track, especially if you're using someone else's theme/template/skin.

6. Avoid using advance CSS selectors as much as possible; without resorting to multiple styling classes.

Multiple classes, as well as, advance CSS selectors, can and do slow down rendering. It's easy to fall into this trap because it makes things easier. I'm guilty of it.

7. Drop deprecated stuff; and only use future-proof ones.

Like backwards compatibility with anything IE.

Also, many CSS resets are actually no longer needed.

8. Less JavaScript as possible.

If something can be done without scripts, use that method. Everything else is optional. The site should work with or without scripts.

Remember, we're creating a boilerplate that we can reuse. We build on top of it.

9. As semantic as possible.

For example, use “article”, “main”, “nav”, “aside”, “section”, where applicable, instead of “div” with a “role” and/or “id/class”.

We requested for those when HTML5 was being developed, but only few actually use it (especially blog templates).

10. BEM methodology

---

I hope those are everything worth applying in this journey.

Some notes:
* For #SchemaOrg, I prefer #JSON than embedding it in the HTML code through classes or itemprop.
* I understand there are a few with some of the goals I listed already implemented, but I prefer to learn along the way, not “how to use” this and that.

#YourOnlyOne

“Death To Icon Fonts” (2015)

https://www.youtube.com/watch?v=9xXBYcWgCHA

What's your opinion as a #WebDev today?

Did you find a way to address the issues presented while keeping #IconFonts?

Basically:
1. When our friends with #Dyslexia overrides your fonts, font icons turn into black boxes since the font they're using doesn't have support for those Unicode code blocks.

2. When screenreaders, or voice assistance, reads a site with icon fonts, they read the icon fonts really weird.

For No.2, a site with properly marked aria labels, or marked as hidden for assistive tech, is the solution I can think of.

However, for No.1, I can't think of a way since once the browser forces the user font, all fonts on the site will rely on the user's custom font.

The only other way I can think of is to provide an option to switch the site's font right from the website, so they don't have to override the site's font.

What's your solution?

#WebDeveloper #WebDevelopers #Coder #Programmer #Webmaster #A11Y #accessibility #assistive #Fonts

Seren Davies: Death to icon fonts - EpicFEL 2015

YouTube

Ok, I'm into #iconfonts these days. So here is a nice video explaining why setting-up a micro service for app #icons could be a good idea for large applications.

A #fosdem presentation by Ecaterina Moraru https://video.tedomum.net/videos/watch/970957fc-c742-4139-a458-be0dfe43bd32

FOSDEM18 - Icon Themes (Ecaterina Moraru)

PeerTube