Selecting an icon is somewhat clunky about simple-icons-font HOT 9 CLOSED

Another thing I really like to bring up when it's about icon fonts; accessibility 😌.
Since the ligatures are text, this can be searched for but most importantly it makes sense for visually handicapped people when they use screen readers (or the font fails to load). (There is a nice article about this here)

Personally, I'm not sure if I entirely agree with this. I find it quite weird that when I search for "simple-icons" my browser will select the simple-icons icon. As for the accessibility, first the article's main point seems to be that you shouldn't use icon fonts at all 😅 Second, generally speaking, for accessibility, regardless of how you use icons you should always put text next it. And if you don't you should use aria attributes to provide accessibility (aria-valuetext in this case), but unfortunately we can't enforce that.

The other arguments in the article hold regardless of whether you're using unicode characters or ligatures.

Don't get me wrong, generally speaking I'm/Simple-icons is in favor of adding accessibility by default as much as possible. In this case I'm just not entirely convinced this is best solved on our side 🤔

from simple-icons-font.

It's a mere example document allowing to test and look at the font.

Yes, the cumbersome selection is because of the use of ligatures and I considered using pointer-events: none before, however then the title attribute would be useless which I thought would be useful for checking what icon that is.

We could also improve the icon page similar to how the main simple-icons page looks (labels and whatnot) or even combine them by replacing the inline svg elements with the font?

from simple-icons-font.

I think we should also have it build a reference sheet (documentation, if you would like to call it that) for that manner, so people can look up how to use the symbols more easily (as a markdown document or even as a PDF or part of the PDF project maybe?)

from simple-icons-font.

Yes, the cumbersome selection is because of the use of ligatures

Did you test different ways of implementing it? As I said I'm not very familiar with icon-font-buildr, but I was personally expecting this would work the same as, say, FontAwesome, i.e. something like:

<i class="simpleicons simpleicons-500px"></i>

I considered using pointer-events: none before, however then the title attribute would be useless which I thought would be useful for checking what icon that is.

Good point, I agree that's not a good solution.

I think we should also have it build a reference sheet (documentation, if you would like to call it that) for that manner, so people can look up how to use the symbols more easily

Definitely, I would just put it in the README similar to how it's done in the main project. Also, this relates a bit to simple-icons/simple-icons#1362. UPDATE: see #5

or even as a PDF or part of the PDF project maybe?

Can you elaborate? The PDF project is intended for PDF versions of all icons

from simple-icons-font.

Did you test different ways of implementing it? As I said I'm not very familiar with icon-font-buildr, but I was personally expecting this would work the same as, say, FontAwesome, i.e. something like:

<i class="simpleicons simpleicons-500px"></i>

It's not a speciality to icon-font-buildr, ligatures are a basic font feature.
If we want CSS classes like in FontAwesome, we need to generate a stylesheet containing those then, analogous to how the test page is built.

It's basically this for every icon:

.simpleicons-github::before {
	content: 'github';
}

I will see for that right away, it's pretty simple 😄

or even as a PDF or part of the PDF project maybe?

Can you elaborate? The PDF project is intended for PDF versions of all icons

I mean that the reference sheet could optionally also be built as a PDF document to be supplied on the website for example.

from simple-icons-font.

It's not a speciality to icon-font-buildr, ligatures are a basic font feature.

I'm aware ligatures are a basic font feature. What I was trying to get at is that other font icons (like FontAwesome, but also fonts I've generated with gulp-iconfont in he past) seem to have each icon as a single character rather then a ligature, though I'm not sure about that.

If we want CSS classes like in FontAwesome, we need to generate a stylesheet containing those then, analogous to how the test page is built.
It's basically this for every icon:

.simpleicons-github::before {
	content: 'github';
}

I will see for that right away, it's pretty simple 😄

I feel like it wouldn't be a bad idea to just go with that if we can set it up, since that is how basically every other icon font does it (as far as I know).

I mean that the reference sheet could optionally also be built as a PDF document to be supplied on the website for example.

I see now, guess that is something we can discuss in #5. As for "advertising" this package on the website, I agree that it would be smart to start cataloging tools to use Simple Icons on the website, I will create an issue for that 👍 (EDIT: see simple-icons/simple-icons#1382)

from simple-icons-font.

[...] other fonts [...] seem to have each icon as a single character rather then a ligature, though I'm not sure about that.

This is perfectly possible and in fact the icons already each have one codepoint (character) starting at where unicode reserved space for custom symbols.
However, if we were to actually use them, we'd run into following problem:

If a new icon gets added, since it will just be shifted into that array of alphabetically sorted icons, it will take the codepoint of an icon that previously sat at its index, meaning if someone updated the package dependency and for some reason output the related codepoint themselves (custom CSS or whatever), then the icon would display as something else. (We could prevent that if we added some sort of fixed index attribute or a timestamp to newly added icons, but that sounds very troublesome).

In #6 I especially generate the CSS using the ligature instead of the codepoint an icon is assigned for this exact reason, even though one could argue that if they use this package and also the stylesheet that comes with it, they'd be safe from the problem described above, since the CSS would reflect he updated codepoint relations aswell.

Another thing I really like to bring up when it's about icon fonts; accessibility 😌.
Since the ligatures are text, this can be searched for but most importantly it makes sense for visually handicapped people when they use screen readers (or the font fails to load). (There is a nice article about this here)

tl;dr

Possible and already available, but probably not a good idea to use it here.

from simple-icons-font.

I'm not entirely sure, but this issue seems to be superseded by #39. Anyway, reading the discussion, I'm in favour of what have pointed @ericcornelissen here:

Don't get me wrong, generally speaking I'm/Simple-icons is in favor of adding accessibility by default as much as possible. In this case I'm just not entirely convinced this is best solved on our side 🤔

If is the case and there is no pending discussion, I would be inclined to close this issue.

from simple-icons-font.

@mondeja provided the CSS classes are used instead of the ligatures directly, yes this issue is solved (at least in the latest Chrome and Firefox). I think as long as we don't advocate using the ligatures directly we can mark this issue as closed 👍

from simple-icons-font.