Is there any reason the styles associated with the mdi
class need to be applied to the element itself rather than just the ::before
pseudo element? It would be better in terms of implementation if it was possible to just add class="mdi mdi-[icon-name]"
to any element you want to add an icon to rather than having to use something like the i
element (which is bad semantics).
It would mean <a href="#"><i class="mdi mdi-image"></i>Gallery</a>
is simplified to <a href="#" class="mdi mdi-image">Gallery</a>
which is much cleaner and more logical in my opinion. Better still would be <a href="#" data-icon="mdi-image">Gallery</a>
.
You can already add the class to any element. Also, usually I use a <span>
... seems ugly to use a <i>
element. If you need to customize it further please use the SCSS files and modify the _icons.scss
file and compile.
For now we're simply following Font Awesome's implementation to make migration easier for users.
Perhaps I wasn't clear. It's possible to add it to any element but it overrides the styles (font, display, transform) for that element. I don't see why the styles are added to the element itself rather than ::before
. These styles could just be added to .mdi::before
rather than the containing element.
Current implementation
.mdi {
display: inline-block;
font: normal normal normal 24px/1 "Material Design Icons";
font-size: inherit;
text-rendering: auto;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
transform: translate(0, 0);
}
Proposed implementation
.mdi::before {
display: inline-block;
font: normal normal normal 24px/1 "Material Design Icons";
font-size: inherit;
text-rendering: auto;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
transform: translate(0, 0);
}
https://github.com/FortAwesome/Font-Awesome/blob/master/css/font-awesome.css
Really following Font Awesome on that one. Kind of a large change to make.
.#{$mdi-css-prefix} {
becomes .#{$mdi-css-prefix}::before {
.
It's a one line adjustment that as far as I have tested has no effect on anything but allows the element that you add the .mdi
class to to have its own styles. The styles are just applied directly to the ::before
icon rather than inherited.
Edit: Would also require the same change to the definitions in _extras.scss
file.
Nah, I get it. The change definitely makes sense, but it goes against the current process of following Font Awesome. Really minor and I doubt anyone does it things like below are one minor use.
<span class="mdi"><span class="mdi-star"></span><span class="mdi-star"></span><span class="mdi-star"></span></span>
Damn. It's not actually stated on the FA examples so I doubt there are many people even aware they can do that. Could we add something like .mdi-set
that allows for that functionality and stray away from the font awesome method slightly? It would still be 99% compatible with FA. The addition of .mdi-ul
- which acts as mdi-set
but removes the bullet points - would also make sense to better follow FA.
Thinking this over for a bit more and this may not be a bad idea. Plus we have a month(s) until the next release for people to object. I really can't think of a reason to not implement this change.
So I made a new purposefully over exaggerated label that way people read this issue. I don't see anyone objecting, but lets see if anyone has any good points. I've googled a bit and there seem to be no downsides from an accessibility/browser standpoint.
Well it seems there are no objections. Can we add this to the next release? I'm assuming there is a release soon as there hasn't been one for a while and we've had quite a few icons added. I've just been assigned a new webdev project so this would be a really useful thing to have.
@JamesCoyle I already made the change for the next release. Just finalizing a few icons and some tweaks to the build system. Forgot to update the milestone for the issue.
Cooleo! (Remind me never to say that again...)
Would it be worth adding a note on the site on release just to let people know the functionality has changed? Might be a good idea to update the getting started page with new examples.
The getting started page takes pull requests.
https://materialdesignicons.com/getting-started click edit on github at the top right. The refresh button resyncs any changes. You have contributor access so you can edit from github without needing to do a pull request.
I'll add a quick example then. What version number will you be using for the next update? 1.7?
I see you linked the toolbar package I added MDI support to as well. :D I really need to figure out why my icon theme wouldn't add to the atom package repository and get that public. It replaces all the stock icons with material ones so everything can match the toolbar.
It will probably be 1.6.80 or something Not sure at the moment, adding random icons while fixing some of the build issues in the backend (and the "blank" icon isn't a real icon so it doesn't count toward the total count).
When you document it's a single :before
we still support IE8, because.
Could we bump it up a version number to 1.7? I can then say 'From version 1.7 you can...'. Did you also add the .mdi-set
feature? I could document some of the webfont features while I'm at it.
I don't actually version it, I simply take the icon count and turn it into a version number. So I would have to add 20 more icons to hit that, so for now we can just say v1.6.80+
.
.#{$mdi-css-prefix}:before,
.#{$mdi-css-prefix}-set {
...
How is that? There seems to be some margin/padding issues on h3
and h4
elements on that page though.
At the beach will fix it in an hour'ish. Most of that site's styles are very sloppy as it was a quickly skin of bootstrap 2 years ago.
Ah ok. Just needs a bit of margin or padding on the left side to bring them in line with the rest of the text.
I'll be fixing and releasing a new version this week. Was at a conference Mon-Wed this week and holding off the release until I had more time in case something went wrong. I'm just going to be adding 15 more icons currently at 1685 to make it a round v1.7.0 release.
Please preview here: https://cdn.materialdesignicons.com/1.7.12/
Let me know if you see any issues. This is not released to NPM/Bower until tomorrow.
I understand it's cool to do this on ::before but there is a very good reason font awesome does it like this.
If you have a paragraph with font-size: 10px the icon also has 10px so you get consistency a bit 'automatically' instead of having to define always the specific icon size. This is a great feature since most of the time you want the icon to match your text next to it.
By implementing this change that feature is now broken.
You can see what I mean here:
https://jsfiddle.net/mspaxhoj/1/ (new)
https://jsfiddle.net/g7dxufm5/1/ (old version)
You can see in lines 1-4 that the icon size is the same of the text next to it on old version, which is a great default. On new version icon size is always the default 24px. Tested on Chrome /win but it really is a CSS thing, not browser related.
The old version of material design icons I'm using is 1.2.64 since it's the one I have on my project and I couldn't figure out what was the immediately version before 1.7.12. Doing versions by icon count seems like a terrible idea, why not use standard software versions like semver or something incremental at least?
I vote to revert since:
a) font awesome does it like this
b) it seems it's a much better feature than saving up on a tag to explicitly insert an icon (which, by the way, I think it's the best way to do it in terms of HTML semantics than just piggybacking on an element)
c) can very possibly break compatibility if people were relying on this size assumption
If an icon is pure decoration (90% of the time it is) it is better to define it in CSS rather than defining it in the HTML as it has no semantic meaning. The idea of this change is to allow you to explicitly define an icon as before or apply it directly to an element giving you more flexibility without breaking anything.
I'll look into the size issue when I get a chance. It should be inherited from the parent.
Right, the issue is that @Templarian has omitted the line that sets the font size to be inherited. This needs to be fixed ASAP.
If you look at this fiddle you can see that with that style added it works as before.
I have to agree that the icon based versioning is weird. I'd prefer a system with the version as such: v[major version].[new feature].[bugfix].[number of icons added in release].
That fixes it and I withdraw my objections on using ::before. I don't agree with using it like that but it's not a problem to be flexible: this way can use it in both ways where previously only 1 way was possible so I think it's an improvement if it doesn't break anything.
That was a big breaking change for a minor release. Looking for the inherit fix soon anyway.
Will be fixing this very soon. Yea, not sure why I removed inherit. For now use v1.6.50. While walking in to work I was looking through the changes and realized that was probably causing all the issues you were seeing.
This has been fixed in v1.7.22
(not released into NPM/Bower yet).
https://cdn.materialdesignicons.com/1.7.22/
Will be doing a release tonight for v1.7.22
.
Deployed to NPM/Bower.
https://materialdesignicons.com/bootstrap was updated with the latest tweaks. It also includes more documentation.
For instance the ability to do things like:
<button class="mdi mdi-account">Hello!</button>
We'll probably want to update the getting started to explain things eventually.
Most helpful comment
Thinking this over for a bit more and this may not be a bad idea. Plus we have a month(s) until the next release for people to object. I really can't think of a reason to not implement this change.
So I made a new purposefully over exaggerated label that way people read this issue. I don't see anyone objecting, but lets see if anyone has any good points. I've googled a bit and there seem to be no downsides from an accessibility/browser standpoint.