« JavaScriptEscape headaches
Icon alignment
Saving Bytes Every Page - Or, How I Learned To Stop Worrying… »

Nao

  • Dadman with a boy
  • Posts: 16,080
Icon alignment
« on March 12th, 2013, 01:13 PM »
I was looking into more layout-related code, and couldn't remember why .inline-block forces a vertical-align: middle.
Which got me into looking at inline blocks again... Been a very long time, really.

One of the things I never liked in my code, is that inline blocks are never properly aligned with any text content beside them.
It particularly shows in cat/title blocks, where I have to assign some kind of vertical-align hardcoded pixel value to align the icon next to the title, only the number differs on every browser... Originally I did all of my calculations on Opera, but now that I'm using Chrome on a daily basis, I keep seeing icons that are off by a pixel or two. Most people won't mind, but I do.

The thing with inline blocks, is that their height is the same as the text next to them. By default. So, I did a few tests and... It's really easy to align icons. Just remove any vertical-align crap, any hardcoded height, and then include the icon with background: url(...) no-repeat center. The 'center' is really what does it.

While there's a definite advantage to simplifying our icon code (and believe me, it will), there are also three drawbacks to this method, and this is why I'm not going to implement it without feedback.

1/ There are tons of icons, and it requires changing their HTML one by one, manually. It's okay... I can handle it. But it's not pretty.

2/ Sprited images.
- Obviously, can't set a 'center' on them, because they'll show something else on the side. So... Do we get rid of sprites for any icons that inherits .inline-block?
- Pete likes them (true enough, the sort.gif image is 90 bytes, as opposed to 146 bytes for sort_down+sort_up). However, the magic of gzip ensures that small images may sometimes compress very well through Wess. In this case, I tried doing the same code with the two separate images, and went from 29085 bytes to 29096... That's an extra 11 bytes. With a bit of CSS simplification, I went down to 29090. Only 5 more bytes... The 143 bytes in sort_down+sort_up are compressed to exactly 84 bytes, while the 90 bytes in sort.gif are compressed to 79. (And they said base64+gzip wasn't helpful to compress images... :P Well, that's probably due to the fact that there are other GIF files in our CSS, and they share similar, if not identical, headers and palettes.)

3/ If the icon is taller than the current text, it won't resize to fit. So, the icon will be partially hidden. I can't think of many situations where this is desirable.

So... What do you think..?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Icon alignment
« Reply #1, on March 12th, 2013, 03:31 PM »
Quote
That's an extra 11 bytes. With a bit of CSS simplification, I went down to 29090. Only 5 more bytes...
Ah, you're forgetting one thing about inlining something versus the HTTP request for it: the saving of that round trip. Sure, the DNS will be reused as will the HTTP connection (at least in theory), but the actual bandwidth of the request saved easily is more than 5 bytes. In fact it's probably into the hundreds of bytes I saved, while making it faster. If you look at a single page in isolation, sure, you'll see an increase - especially if it's a page without the sort image, but the incremental cost is lower on any pages that do use it.
Quote
Pete likes them (true enough, the sort.gif image is 90 bytes, as opposed to 146 bytes for sort_down+sort_up).
I don't really care much either way. The key thing is that I get to push things into the CSS that weren't in the CSS before and the easiest way I know of doing that is a sprite. I'm not fussed if you'd prefer me to keep individual images and use url-no-base64 instead to call them.
Quote
3/ If the icon is taller than the current text, it won't resize to fit. So, the icon will be partially hidden. I can't think of many situations where this is desirable.
Hmm. I'd be inclined to leave it as-is and change it on requirement.
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

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Icon alignment
« Reply #2, on March 12th, 2013, 03:58 PM »
Quote from Arantor on March 12th, 2013, 03:31 PM
Quote
That's an extra 11 bytes. With a bit of CSS simplification, I went down to 29090. Only 5 more bytes...
Ah, you're forgetting one thing about inlining something versus the HTTP request for it: the saving of that round trip. Sure, the DNS will be reused as will the HTTP connection (at least in theory), but the actual bandwidth of the request saved easily is more than 5 bytes. In fact it's probably into the hundreds of bytes I saved, while making it faster. If you look at a single page in isolation, sure, you'll see an increase - especially if it's a page without the sort image, but the incremental cost is lower on any pages that do use it.
Okay, I know you're only occasionally looking into Wess while it's one of my full-time jobs, so I just want to be sure... Can you re-read my post? As I said in it, you can perfectly embed both small files in the CSS, it doesn't have to be sprited... I feel like you've been mixing things up... :^^;:
These sort images are linked thematically so it's okay to sprite them (you can't change one without changing the other!), but theoretically there's no need to sprite them. Just embed them both. The only extra cost is the 5 bytes I mentioned. No round trips.
Quote
I don't really care much either way. The key thing is that I get to push things into the CSS that weren't in the CSS before and the easiest way I know of doing that is a sprite.
Then you probably missed something I guess... :^^;:
Quote
I'm not fussed if you'd prefer me to keep individual images and use url-no-base64 instead to call them.
url-no-base64() is only useful when you know the image is called in very few situations.
Quote
Quote
3/ If the icon is taller than the current text, it won't resize to fit. So, the icon will be partially hidden. I can't think of many situations where this is desirable.
Hmm. I'd be inclined to leave it as-is and change it on requirement.
On requirement..?
Leave what as is? All icons?
Then, I suppose, strip the vertical-align out of .inline-block and then fix stuff as I find them..?

Hmm...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Icon alignment
« Reply #3, on March 12th, 2013, 04:07 PM »
Quote
Can you re-read my post? As I said in it, you can perfectly embed both small files in the CSS, it doesn't have to be sprited... I feel like you've been mixing things up...
I'm not mixing anything up. Inlining, whether or not you sprite, means you don't make HTTP roundtrips. That's a bandwidth saving of a surprising magnitude - anything between 100 and 1500 bytes per request, or more in some particularly vile cases.

There are two separate issues here and I think you missed what my commit actually did to a point ;)
Quote
These sort images are linked thematically so it's okay to sprite them (you can't change one without changing the other!), but theoretically there's no need to sprite them. Just embed them both. The only extra cost is the 5 bytes I mentioned. No round trips.
I'm well aware that I didn't need to sprite them. However, the byte saving seemed worth it to me ;)
Quote
Then you probably missed something I guess... :^^;:
Or I didn't explain it very well, more likely. Yes, I'm well aware I can embed individual images one at a time. There's plenty of places this is done. And it would make for easier CSS not to have to make sprites, but it would tend to make larger CSS if you have a bunch of images with common palette.

But if you have a group of images that naturally fit together, there is no good reason not to make a sprite out of them. It keeps the filesize down on disk, it keeps the CSS smaller in most cases from what I've seen and if you're going to modify it, you're going to modify at least substantial parts of a given sprite anyway.
Quote
On requirement..?
Leave what as is? All icons?
Then, I suppose, strip the vertical-align out of .inline-block and then fix stuff as I find them..?
I don't know, didn't sleep well, feel like crap and I need to hike out in a bit to get more bread and stuff - in the several inches of snow we had yesterday.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Icon alignment
« Reply #4, on March 12th, 2013, 07:06 PM »
Quote from Arantor on March 12th, 2013, 04:07 PM
I'm not mixing anything up.
Well, I'm not the one who mentioned going back to a non-embedded solution for sort_down/sort_up... :^^;: I was always going to keep them embedded.
Quote
Inlining, whether or not you sprite, means you don't make HTTP roundtrips.
I wrote the feature, I know that... :niark:
Quote
That's a bandwidth saving of a surprising magnitude - anything between 100 and 1500 bytes per request, or more in some particularly vile cases.
Large cookies FTW.
Quote
There are two separate issues here and I think you missed what my commit actually did to a point ;)
You wanted to embed sort_down/sort_up to save bandwidth. I understand that. These files aren't used on every page, but it's all right. I don't see the other issue.
Quote
I'm well aware that I didn't need to sprite them. However, the byte saving seemed worth it to me ;)
Did you try without spriting..?

I should say -- there are a few icons (can't remember which) that I wanted to sprite, then I tested the results and was surprised to see that the sprite file was making the CSS file bigger after gzipping, and there was no way around it. So I'd personally try to avoid spriting anything without some serious tests.
Again, sort.gif is a perfect candidate for spriting because both files are a variation on each other.
Quote
And it would make for easier CSS not to have to make sprites, but it would tend to make larger CSS if you have a bunch of images with common palette.
Not always... Again: 5 bytes, is it worth the hassle? In this case, probably, but in other situations, we'll always need to compare file sizes.
Quote
I don't know, didn't sleep well, feel like crap and I need to hike out in a bit to get more bread and stuff - in the several inches of snow we had yesterday.
Oh, so that annoying snow came from your place eh? Here in Paris, it's been snowing since last night, no end in sight. Between last Saturday (right when I came back from vacation) and today, the temperature dropped by 18°C. I think the C stands for "Come on?!"

More seriously, it's still something I want to explore, although I have to admit it won't be interesting to a lot of people...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Icon alignment
« Reply #5, on March 12th, 2013, 07:12 PM »
Quote
Large cookies FTW.
It's not just large cookies, or the rest of the HTTP header crap, it's also the TCP/IP packet itself ;)
Quote
You wanted to embed sort_down/sort_up to save bandwidth. I understand that. These files aren't used on every page, but it's all right. I don't see the other issue.
Actually, I wanted to just make it controllable from the CSS rather than inline images. Everything else is just a byproduct of that fact.
Quote
Did you try without spriting..?
I didn't, no, but given the fact it went from 146 bytes to 90 for the pair, I didn't think it was worth the effort in spending much time on it. That could probably be shrunk even more if I really wanted to, e.g. making sure to only use the minimum number of colours possible (which is 3)
Quote
I should say -- there are a few icons (can't remember which) that I wanted to sprite, then I tested the results and was surprised to see that the sprite file was making the CSS file bigger after gzipping
That implies a non-common palette.
Quote
Oh, so that annoying snow came from your place eh?
It stopped snowing some hours ago, but yes, probably was our fault.
Quote
More seriously, it's still something I want to explore, although I have to admit it won't be interesting to a lot of people...
I think it will likely confuse more people than it would help. I actually think defaulting inline-block to vertical-align: baseline would probably be better than vertical align to middle, but try it.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Icon alignment
« Reply #6, on March 15th, 2013, 12:33 AM »
Just this...: is it really worth defaulting vertical-align to anything at all..? Why not just set inline-block and be done with?

Oh, I think I already removed it in an earlier commit, so it means we'd have to remove it from sort_down as well...
I'm getting a bit lot in my refactoring process... ;)
« JavaScriptEscape headaches
Saving Bytes Every Page - Or, How I Learned To Stop Worrying… »