Re: Smileys are still gif. Why?
Reply #15 –
While we are talking about smiles and Spuds doesn't like the interface...what do you think about removing the sets? And keep "just" the option to add new/remove/manage smiley?
Re: Smileys are still gif. Why?
Reply #16 –
Well we should have one default set, IMO. I don't see any need to have several though (and TBH some of them aren't that great).
Re: Smileys are still gif. Why?
Reply #20 –
Back to this for a moment ....
I have the Fugue icons as PNG's (those are the ones we use on this site) and updated my local to PNG's, removed the old sets, updated a couple of areas to default to .png when you don't have smileys enable.
Now the questions of should we do some other things or not.
Smiley codes are tied to a filename and they are unique, such that each code points to a filename across sets, so changing to .png means we can't have another :-) code that is for a smile.gif in one set since our default is smile.png, .... all those :-) need to point to a smile.png in the sets.
So if you load another smiley set and they are all gifs, you will get the old does not exist notice, so if you really want to use that gif set with the :-) you can't until you unset it from smile.png ... I hope I have that right and it makes sense.
So
A) who cares, if they want gif for one of the default codes in our set they need to do some work. Meaning our default codes need to be the same filetype across all sets for the same code. ... Downside, lots of smiley sets will not work as they are gif
B) use the filename w/o extension to see if it exists, and based off the set chosen set a smiley_encode tag of png, gif, bmp, etc (based on the smile icon filename and assume all the defaults are of this type). This allows you to load smile sets of any type against the codes. Downside, you can't mix in a set, they are gif or png or etc
C) Same as b but only for the default codes, then any user defined ones are tied to the filename-type and that must be the same in all sets (assuming you want it to render n all sets). This allows for our default codes to be mixed type across sets and user defined codes be the same across sets.
D) Leave the default set as .gif, if someone wants a dark theme, they get the extra work.
thoughts?
Re: Smileys are still gif. Why?
Reply #21 –
mhh, to be honest: I'd go with c) until APNG is widely supported by all major browsers..
Re: Smileys are still gif. Why?
Reply #27 –
I'm missing something here. At the moment (SMF smiley stuff) you can set any file type for any smiley, and have different file types in the same set, and share smileys across sets or not, as you like. So, why does any of that need changing just because you want default smileys to be PNG? I don't get it.
Re: Smileys are still gif. Why?
Reply #29 –
Oh ok, well in that case I wouldn't think it's a problem. They can just use a custom code if they want to. The defaults will only be the basics, and should be non-animated anyway, so I can't see a problem with having default codes stuck to png suffix. Not really. It might mildly annoy a few people but they'll get over it.
Also, there's an old trick themers used to use when they wanted png images in 1.1.x and 2.0.x without hacking all the image calls in the templating. You just make your png and then rename it to a gif suffix. It works.
I haven't tried doing it the other way, but that might work too (IOW, make your animated gif and rename it to png).
ETA: Oh and regarding smiley sets, frankly I've never seen the point of them.