Skip to main content
Topic: Data icons via CSS: no eye candy locked into sources. (Read 3318 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Data icons via CSS: no eye candy locked into sources.

Since the icons are pure presentation they really should not be locked into sources. They should be handled in the CSS. You can do this, y'know. It's not even difficult.

http://chipcullen.com/using-icons-from-icon-fonts-directly-in-css/
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Data icons via CSS: no eye candy locked into sources.

Reply #1

Which one are you talking about?
The one in the main menu?
I actually always wondered why they were in the menu array. Well, in 1.1 they have been "converted" to a name and used just to create a:
Code: [Select]
<i class="icon icon-menu icon-big i-' . $button['data-icon'] . '"></i>
so basically they are no more locked in source. ;D
Bugs creator.
Features destroyer.
Template killer.

Re: Data icons via CSS: no eye candy locked into sources.

Reply #2

Yeah, main menu. 1.1 sounds fine then. Except we aint got it yet. :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Data icons via CSS: no eye candy locked into sources.

Reply #3

Quote from: Antechinus – Yeah, main menu. 1.1 sounds fine then. Except we aint got it yet. :D
Thats due to all the bugs emanuele added :P  ... OK I may have added one or two dozen myself :P

Thats a very good read at the link , I did not know you could target like that, pretty cool really.

Re: Data icons via CSS: no eye candy locked into sources.

Reply #4

@Spuds Opera could already do that back in '02/'03 (well, excluding the web fonts and some of the newer selectors). Took the other browsers a while to catch up, but I think the whole shebang (generated content, selectors & web fonts) has been pretty mainstream since at least '09/'10-ish. ;)

That being said, classnames are much faster and might be useful for other purposes, so there's really nothing particularly wrong with the current approach as outlined by @emanuele besides that e.g. .icon and .icon-menu smell redundant. After all, you've already got #main_menu .icon or whatever, so yeah… heck, even just #main_menu li might do without any classnames depending on the specifics.

On the CSS side you'd have

Code: [Select]
.icon, .icon-big, .icon-lalala {shared junk}
.icon-big {non-shared junk}

But that's nitpicking and partially a matter of personal taste anyway.
Last Edit: June 14, 2016, 10:10:18 am by Frenzie

Re: Data icons via CSS: no eye candy locked into sources.

Reply #5

Must admit I did think class="icon icon-menu icon-big i-' . $button['data-icon'] . '" looked a bit over the top. One or two classes, sure. Four classes? Something looks wrong.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Data icons via CSS: no eye candy locked into sources.

Reply #6

The more the better!
Bugs creator.
Features destroyer.
Template killer.

Re: Data icons via CSS: no eye candy locked into sources.

Reply #7

 Antechinus kicks Ema
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Data icons via CSS: no eye candy locked into sources.

Reply #8

I spend all that effort clearing out css cruft and you nuts go straight to adding it back in again : p

Re: Data icons via CSS: no eye candy locked into sources.

Reply #9

He always does that. :P
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P