Javascript image changing stuff (upshrinks, etc).

Topic: Javascript image changing stuff (upshrinks, etc). (Read 7166 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Javascript image changing stuff (upshrinks, etc).

July 14, 2013, 06:50:31 am

Had an idea here too. At the moment we have the js swap images between the pointing up one and the ponting down one when an area is expanded or collapsed. It's not necessary.

I've been playing with coding for the quick edit and header collapse icons. In both cases, you have a button that contains a 16x16 image. That means the image has to be artificially enlarged to cover the whole button, so that the active target area is all of the button rather than just the small icon.

The way I've done it is to add padding to the image in the CSS, which acts like adding padding to any other html element: it makes it bigger. I gave them huge padding, and then used absolute positioning on the image, and hidden overflow on the button, to make it all behave. The result is that the whole button works like it should, and the icon stays where you want it at all times.

Code: [Select]

#collapse_button .linklevel1 {
	display: block;
	padding: 0 16px;
	border-radius: 2px;
	overflow: hidden;
	position: relative;
}
#upshrink {
	position: absolute;
	top: 50%;
	margin-top: -55px;
	left: 50%;
	margin-left: -58px;
	padding: 47px 50px;
}

So, I just had a brainwave. We can extend this to sprite the upshrink/upshrink2 images. Since they are already huge (like 116x110px in the above example, and more if text size is increased) adding a bit more on is no worries. So we just make a sprite (which will be mostly transparent pixels) and just use the js to change or append a class on click. That class is defined in the css, and shifts the image across like with any other sprite. This means instant results with no cache time stuff, and fewer images kicking around the installation.

Is good yes?

ETA: Eh. This would make a perfect candidate for spriting with the board icons (on/on2/0ff/redirect). Sizes are in the same sort of range. We could have one image doing all the board icons, and all upshrinks.

PHP conditionals would handle the board icons positioning aspect of it. JS class appending would handle the collapse/expand positioning. Easy.

Re: Javascript image changing stuff (upshrinks, etc).

Reply #1 – July 14, 2013, 07:57:54 am

Board icons are used only in BoardIndex, while collapse/expand are used potentially everywhere.

I would keep the two separated.

Re: Javascript image changing stuff (upshrinks, etc).

Reply #2 – July 14, 2013, 08:02:30 am

Why? There's no need to. Rolling them all into one is easy. I mean easy in code terms, not just in gfx terms.

Re: Javascript image changing stuff (upshrinks, etc).

Reply #3 – July 14, 2013, 08:19:00 am

Because they are really different things...

The quick edit could (and is already, no idea why it's not used) go with the sprite used for all the other buttons:
http://www.elkarte.net/themes/default/images/theme/quickbuttons.png
no idea what's the reason to have it with the board icons.

Then, sooner or later someone will want a way to have different icons for different boards, if you just have the board icons in one file you can easily expand it vertically without any risk to affect anything else (yes, I know you don't affect it even with the expand/collapse, but again I don't see any real correlation between expand/collapse and the board icons, they are just two different beasts).

It would be more logical (IMHO) to have the expand/collapse merged with the sort up/down:
http://www.elkarte.net/themes/default/images/sort_down.png
http://www.elkarte.net/themes/default/images/sort_up.png
and maybe the last post icon:
http://www.elkarte.net/themes/default/images/icons/last_post.png
that are barely similar at least.

Just thoughts.

Re: Javascript image changing stuff (upshrinks, etc).

Reply #4 – July 14, 2013, 09:54:48 am

It's not just to do with similarity in that sense. It's more to do with what goes together well for consolidating them into one image. What they look like and where you call them isn't really relevant.

Putting the quick edit icon into the quickbuttons sprite would be a bad idea. It'd be much easier to sprite it with the collapse/expand icons. These three are better suited to a horizontal sprite, not a vertical one like the quickbuttons. Same applies to the board icons. You'd be better off spriting them into a horizontal strip. This will let you use the result without adding extra elements to hold the new image (or more accurately, to only display the parts you want were you want them).

However, we probably should keep sprites simple, so on second thought I'd suggest doing the four board icons as one horizontal strip (on/on2/off/redirect) sized at 264x48. The three little ones (new_some, new_none, new_redirect) and the quick edit and the expand/collapse pair would make natural allies in another horizontal strip. That one would be sized at 192x24.

Obviously it'd be possible to extend spriting to other icons, but if just wanting to deal with those 10 that's how I'd do it. We only need one expand indicator and one collapse indicator. The current thing of having upshrink, upshrink2, expand and collapse png's is just pointless duplication.

If someone wants to expand stuff later they can still do that.

Re: Javascript image changing stuff (upshrinks, etc).

Reply #5 – July 14, 2013, 10:15:18 am

Like this (just as a example).

Re: Javascript image changing stuff (upshrinks, etc).

Reply #6 – July 14, 2013, 10:42:28 am

Quote from: Antechinus – July 14, 2013, 09:54:48 amPutting the quick edit icon into the quickbuttons sprite would be a bad idea. It'd be much easier to sprite it with the collapse/expand icons.

Genuine and curious question: why it is a bad idea?

Quote from: Antechinus – July 14, 2013, 09:54:48 amThese three are better suited to a horizontal sprite, not a vertical one like the quickbuttons.

emanuele thinks he asked a bad question

emanuele now is worried by the possible answer. lol

Re: Javascript image changing stuff (upshrinks, etc).

Reply #7 – July 14, 2013, 05:58:13 pm

Well having thought about it some more, quick edit could go in quickbuttons. I had forgotten about RTL.

Answer goes like this: the quick edit icon, and to a lesser extent the expand/collapse icons, needs to be artificially padded so that they cover the entire button even if someone is using maximum size text in their browser. This is why the quick edit one has 5em right padding on it. The padding scales with the text, and the whole width of the button stays an active target.

You also need sufficient vertical padding, but that has to be sized in pixels if you are going to sprite it vertically. Current css for quick edit is this:

Code: [Select]

.quickbuttons .quick_edit img {
	position: absolute;
	top: 50%;
	left: 0;
	margin-top: -48px;
	padding: 40px 5em 40px 4px;
}

Quickbuttons is based on a line of 24x24 units, so if adding it to quickbuttons you'd need to leave two units clear space above and below the quick edit icon. If someone added an extra icon within 48px of the quick edit one, it'd bork the display with large text sizes. So that wastes a bit of space, and is something else to go wrong (coz nobody willl think about this

).

So I was thinking having it in a horizontal sprite with other stuff would be better. That would use different spacings anyway, so probably (maybe) less chance of confusion.
Also, the quick edit one can be stuck at one end of it, which will save some blank pixels off the sprite.

For the collapse/expand ones, similar thinking applies. In practice they will need less width than height, so that means spriting them sideways is more economical. Ditto for the board icons.

Re: Javascript image changing stuff (upshrinks, etc).

Reply #8 – July 14, 2013, 06:06:27 pm

Come to think of it, having quick edit in quickbuttons would be fine if we made it the first one, and re-wrote all the positioning to take account of this. That's not hard to do, and it's probably a safe assumption that future additional icons will be addd last, at the bottom of the sprite, so it should be safe.

If quick edit goes first, it would only need the 48px clear space below it, because css padding can be used above it, so that save pixels too. Also, since it's symmetrical left to right, it works equally well for ltr or rtl languages.

Ok, so we should really do quick edit that way. The others are still better off in a separate sideways sprite though, IMO.