Partial fix Using button--icon--* CSS classes doesn't shown icons

[Kirby]

Affected version

2.3.0 Beta 1

The following codes show a button with an icon in XF 2.2 but not in XF 2.3

<xf:button href="https://..." class="button--link button--icon button--icon--hide">Test</xf:button>

<a class="button--link button--icon button--icon--hide button">
    <span class="button-text">
        Test
    </span>
</a>

The following code shows the icon in both versions, but switching the icon on click does not work in XF 2.3 although the CSS class is switched just like in XF 2.2

<xf:button href="https://..." class="button--link" icon="hide" onclick="this.classList.remove('button--icon--hide'); this.classList.add('button--icon--show'); return false;">Test</xf:button>

 

[Jeremy P]

The button icons in XF 2.3 are no longer CSS (class) based. I'll try to accommodate the first case, where we can process the class attribute into the new syntax. The others are not directly supported in the same sense that <i class="fa fa-eye-slash"></i> is not directly supported.

The second case can be updated to use <xf:fa>:

<a class="button--link button--icon button--icon--hide button">
    <xf:fa icon="fa-eye-slash" />

    <span class="button-text">
        Test
    </span>
</a>

The third case can be updated to use the icon module:

<xf:button href="https://..." class="button--link" icon="hide" onclick="this.querySelector('.fa--xf').replaceWith(XF.createElementFromString(XF.Icon.getIcon('default', 'eye'))); return false;">Test</xf:button>

While I can appreciate that BC breaks are not ideal, we aim to cover common/idiomatic usage and provide escape hashes for more niche situations.

 

[Kirby]

The others are not directly supported in the same sense that <i class="fa fa-eye-slash"></i> is not directly supported.

I am not sure what others think, but IMHO this is a major (usability) issue:

With XF 2.2 it was easily possible to add a FA icon pretty much anywhere HTML could be usesd by just using the CSS classes (eg. <i class="fa fa-eye-slash"></i> or rmth. similar).

This made it pretty easy for (unexperiencd) admins to add FA icons for public navigation for example.

I understand the challenges, but it would be really appreciated if this syntax could still be supported with XF 2.3 and beyond.

Regarding the last usecase:
This was actually a simplified standalone version to demonstrate the issue (of not being able to just switch classes to change the icon); the real usecase is XF.SwitchOverlayClick which (at least as far as I can see) cannot use the icon module.
So short of extending this handler (or entirely creating a new one) I don't see an easy alternative here?

 

[Jeremy P]

With XF 2.2 it was easily possible to add a FA icon pretty much anywhere HTML could be usesd by just using the CSS classes (eg. <i class="fa fa-eye-slash"></i> or rmth. similar).

This made it pretty easy for (unexperiencd) admins to add FA icons for public navigation for example.

The <xf:fa> tag was introduced in XF 2.1 over five years ago as a replacement for <i> and is similarly easy to use. While I understand it can't be used everywhere, we have also introduced first-class support for icons in phrases in XF 2.3. As the navigation items (and most similar things) are phrased, inexperienced admins can now use {icon::fa-eye-slash} to accomplish the same thing.

the real usecase is XF.SwitchOverlayClick which (at least as far as I can see) cannot use the icon module.

I'll mull this over, though support here was already fairly limited to the ~53 icons we previously had dedicated classes for. I'd personally rather add better support for icons here more generally.

 

[Kirby]

I'll mull this over, though support here was already fairly limited to the ~53 icons we previously had dedicated classes for.

Well ... adding new classes and using the existing machinery was easy, so practically there was no really sigificant limitation.

As the navigation items (and most similar things) are phrased, inexperienced admins can now use {icon::fa-eye-slash} to accomplish the same thing.

Granted, this does work for navigation - but there are like a gazillion places that do not use phrases and that do not support XF template syntax either.

• Node Descriptions
• BB Codes
• User Titles
• Notices
• Custom Fields Wrapper HTML
• Custom Fields Fields Value HTML
• ...

IMHO using FA icons should work everywhere (where HTML can be used) easily - this was possible with XF 2.2 and is no longer possible with XF 2.3.

 

[Jeremy P]

I don't disagree that icons should be straight-forward to use in nearly all places HTML can be used (though I would argue many of those really should be phrased anyway). It is still possible in XF 2.3 as it stands, albeit extremely cumbersome (requires manual <svg> and adding the icon to the extra icons option, or custom CSS).

I'll mull this over further, but having dedicated abstractions for icon rendering gives us a lot more flexibility going forward to do things like mix-and-match icon sets beyond FA so I'm not really sure class-based icons are the answer.

 

[Kirby]

It is still possible in XF 2.3 as it stands, albeit extremely cumbersome (requires manual <svg> and adding the icon to the extra icons option).

Really depends on the usecase. User titles set via usergroup for example have a limit of 100 characters (by default).

That is well enough for <i class="..."></i> and some text but squeezing smth. like <svg xmlns="http://www.w3.org/2000/svg" role="img"><use href="/data/local/icons/regular.svg?v=1711908652#question-circle"></use></svg> + text in there ... may be impossible.

(Of coure it is possible to get around that, I could create an Add-on to modify the schema and structure for the entity - the average admin can't. So the only realistic option (without an Add-on) here probably would then be to resort back to creating a dedicated CSS class and use that there.)

Really, there needs to be some easy, concise way to use FA icons basically everywhere that HTML can be used - even if only via JS (<i class="far fa-eye-slash" data-xf-init="icon"></i> or whatever)

 

[Jeremy P]

To be clear, we don't plan on removing the possibility of using CSS-based icons, we just want to use more dedicated abstractions (like the mixin). Something like this is still possible and supported:

<span class="ut-a">Admin</a>

.ut-a
{
    .m-faBefore(@fa-var-question-circle);
}

Though again I don't disagree that it could be less cumbersome (and equally using e.g. multiple icons here is still tricky if not impossible in XF 2.2), whether that means phrasing user titles properly or something else.

<i class="far fa-eye-slash" data-xf-init="icon"></i> or whatever

I'm certainly not opposed to this as it gives us what we fundamentally want: a more structured middle layer for icon rendering.

 

[Jeremy P]

A JS element handler for icons has been added in the next version:

<i class="fa--xf far fa-eye-slash" title="Some optional title" data-xf-init="icon" data-inline="false" data-lazy="false"><svg></svg></i>

The icons are inlined by default since we can't be sure they're sprited. They're also loaded/unloaded as they get closer to/further from the viewport, which can be toggled off with data-lazy="false". I'm not too pleased about (soft) requiring a nested empty <svg>, but it's necessary to prevent layout shifts with the way our icon CSS is currently set up.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.3.0 Beta 6).

Change log:

Improve support for processing button classes into icons

There may be a delay before changes are rolled out to the XenForo Community.