Improving how smileys are managed

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Improving how smileys are managed
« Reply #15, on January 16th, 2013, 05:56 PM »
Quote from Arantor on January 16th, 2013, 05:24 PM
Bump for Nao: what are your thoughts about storing the smileys in the DB and having them inserted in to the CSS from there? (I'm trying to avoid the need to push files to the file system unless necessary)
Can CSS handle animated gifs?
The way it's meant to be

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #16, on January 16th, 2013, 06:05 PM »
Um, yes, yes it can. I mean it works currently, right? Yup, they're embedded as data URLs directly into the CSS file already ;)

The difference I'm proposing is to effectively change where this information is coming from - instead of getting them from the physical files as it does currently, get them from a database table.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Improving how smileys are managed
« Reply #17, on January 16th, 2013, 06:08 PM »
Quote from Arantor on January 16th, 2013, 06:05 PM
Um, yes, yes it can. I mean it works currently, right? Yup, they're embedded as data URLs directly into the CSS file already ;)

The difference I'm proposing is to effectively change where this information is coming from - instead of getting them from the physical files as it does currently, get them from a database table.
Oh yes, sorry, didn't realise that. I understood the difference, it should drastically reduce the number of GET requests when compared to SMF that are performed on a page, but it can make the initial load heavy for the smiley CSS file if there are a crapload of smileys on a site (which is like 50% of sites out there).

EDIT: I know I'm arguing against an implemented feature, just wanted to share what I felt. Although in either case loading from DB seems like a better idea.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #18, on January 16th, 2013, 06:15 PM »
I'm still not making myself clear, I can see this.

Smileys are ALREADY loaded into the main CSS file, automatically. It's been that way for months. Seriously, check the code for any smiley on the site thus far. ;)

Code: [Select]
<i class="smiley wink_png">;)</i>

But it relies on having physical files coming into the system to read, encode and store in the CSS. I'm proposing changing *this* part of the process and only this part of the process, to be able to streamline smileys being added, ideally without having to have write access anywhere that is currently needing write access.
Posted: January 16th, 2013, 06:11 PM

Though it just occurred to me that it might cause IE to poop itself as it doesn't like overly long data URLs.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Improving how smileys are managed
« Reply #19, on January 16th, 2013, 07:11 PM »
Sorry, missed that topic... You should nudge me by PM for any topic you haven't seen me comment on and you need feedback on ;)

I'm not against the idea, I'm against not having a UI for that later... (BBCode :P)
But yep, older versions of IE either don't support data-URIs at all (Wedge redirects IE6 and IE7 to the physical files), while IE8 (or was it IE7? Probably IE7) has support for them, but no more than X bytes, probably 4K I think. Most smileys are under that range. Wedge accounts for this anyway by, IIRC, automatically redirecting to the physical file is the smiley is very large -- because the advantages of having an overall single file for smileys are totally destroyed by having a LARGE file. ;)

So, yeah, it's unlikely that your suggestion would be good in the long run. I can live with knowing that IE6 won't see any smileys at all (what did they do to deserve them anyway? :P), but I can't live knowing that people will have to download a 2MB smiley file because the admin decided to post a lot of animated lulcatz as smileys.

:edit: I'm not sure Wedge also sorts out the smileys that are 'hidden' by default. It would be smart not to include them in the smiley file, I'm guessing, because most likely they won't be used a lot...

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Improving how smileys are managed
« Reply #20, on January 16th, 2013, 07:21 PM »Last edited on January 16th, 2013, 07:40 PM
Quote from Arantor on January 16th, 2013, 06:15 PM
I'm still not making myself clear, I can see this.

Smileys are ALREADY loaded into the main CSS file, automatically. It's been that way for months. Seriously, check the code for any smiley on the site thus far. ;)

Code: [Select]
<i class="smiley wink_png">;)</i>

But it relies on having physical files coming into the system to read, encode and store in the CSS. I'm proposing changing *this* part of the process and only this part of the process, to be able to streamline smileys being added, ideally without having to have write access anywhere that is currently needing write access.
Posted: January 16th, 2013, 06:11 PM

Though it just occurred to me that it might cause IE to poop itself as it doesn't like overly long data URLs.
No, that's not what I meant. I realised that this is already implemented in Wedge, but what I was asking was what happens when there are a lot of smileys? A lot of forums have huge smiley packs and many of them are animated, that makes for a few MBs of smileys in a CSS file which will be loaded at once, it'll probably cross a few browser's cache limits as well (especially on mobile, iOS doesn't even cache permanently and ANdroid can have a few MBs of cache depending upon the device but it can still be an ugly ride).
Posted: January 16th, 2013, 07:16 PM

Okay, reading the source it seems it won't embed smileys beyond 4KB, that'll probably help quite a bit. But perhaps it should limit the CSS file beyond a limit?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #21, on January 16th, 2013, 07:23 PM »
@Dragooon: Yeah, now I see where you're coming from. Right now there's nothing to cope with that. I don't even know if the customised smiley stuff even works properly any more or whether it's reliant on hardcoding.

Need to think about how that's going to work, too.


@Nao: Heh, I should remember that but I'm sort of conditioned not to PM people to bump topics. I find it rude when people do it to me, so I don't like doing it to others.

I wasn't sure what the behaviour was for IE, I just knew it pooped itself with bigger data URLs. But if redirection to physical files already occurs... then that's how it's got to be anyway, which takes this fancy stuff off the table (which is fine, keeps it simpler) and just enforces using S/FTP, fine by me.

Hidden only means not shown in the post form, but I know on my own sites I use hidden all the time. Also note that :edit: is a hidden smiley ;)

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Improving how smileys are managed
« Reply #22, on January 16th, 2013, 07:43 PM »
Hidden from the post page *and* the smiley popup as well. I usually use hidden smileys to represent elements that are either not interesting to my users (for instance I have both [nobbc]:mdr: and :lol:[/bbcode] smileys, which mean the same in French, so one is 'hidden' because it's only for me -- I don't use it much though), or to add smileys that are too big to fit in the popup, and thus I'd logically rather avoid having them in the CSS file as well.

I don't know, I think it makes sense...

It doesn't prevent you from using the smiley -- it just forces users to an extra HTTP request for them.

Perhaps we could add some UI to ask admins if they want to cache all smileys, or post+popup, or just post smileys...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #23, on January 16th, 2013, 07:46 PM »
In which case, let's just not cache them into the CSS and just leave them as regular HTTP requests - they're not that common (you have to know that they're there to use them)

I don't think users need to be given that detail to be honest; there is such a thing as too much choice.