I'm working on my first proper Lightning Component project, and the experience has been both frustrating and pleasant. Pleasant in the sense that it reminds me of my days working with Flash and Actionscript, where you'd build movie clips (child components) with discrete animations or functionality, and they would dispatch events to listeners on the _root level/stage. (your parent, master component) The correlation is made all the more stronger since we're dealing with UI in both situations.

At any rate, this is a short post to talk about the Winter '17 lightning component, <lightning:icon />, and the recommended markup for UI components provided by the Lightning Design System (SLDS).

The SLDS makes use of a lot of svg icons, provided in a sprite sheet, but up until Winter '17 if you wanted to use those icons, you had to write your own custom helper component to render the icon.  In Winter '17 we got <lightning:icon />, which is basically Salesforce's officially supported version of that custom helper component.  For the most part it works ok, but there's a problem: the <lightning:icon /> writes its own CSS onto the <svg> element it generates, and there isn't an option (yet) for developers to set that themselves.  There is a class attribute for the component, but that only adds CSS to the container <span> that wraps the <svg> tag.

This is a problem because several of the SLDS examples require the ability to put CSS directly on the <svg> tag.  Additionally, <lightning:icon /> sets one problematic class on the <svg>, .slds-icon-text-default.  If you go into the SLDS CSS, that class is defined after a lot of other classes, and ends up overwriting the fill that is defined in classes like .slds-icon.

End result: the colours on your icons end up coming out all weird, and in some cases the position is all wrong.

That should be white. :P  It's really weird that this happened, it's like the team that made the component didn't talk to the team that made SLDS?  I dunno.

To get around this, you could:

• Keep using your own svg component: this gives you ultimate control, but it means you'll still have to use a static resource to hold the SLDS and hard code the paths to your icons.
• Use lightning:icon, but write CSS in your component to override the colours.

In the toast example above, that's what I did:

.THIS .slds-icon.slds-icon-text-default { fill:white; }

But with the section example, you're stuck, because you need to add some specific classes right onto the <svg>.

I don't want to get into CSS overriding hell and manually copy the styling down, so unfortunately in that particular case I'm going to keep using my custom svg icon handler so I have control. :/

Alas...