Just how big is 1px anyway? There are a couple of things that affect it - the screen size and the screen resolution. With a really small screen set to a really high resolution 1px will be extremely small. With a really huge screen set to a low resolution 1px will be similarly huge.
By using px you lose all control over how big things are. While most people will have somewhere between 72 and 150 px to the inch there will be some who have really small high res screens with 500px to the inch and some with huge low res screens with 1/2px to the inch.
If you want any control over sizes at all then you should avoid using px as much as possible. The only place it really makes sense to use px is to set minimum width borders to 1px as that is literally the minimum width a border can have and still be visible.
Was thinking on it, and I really think that "blaze io" test is a bunch of horse manure... Really started to rub me the wrong way starting with this:
case in point:
Something a bit more realistic and non-mobile oriented dials it in better, though still not perfect.
For Example: http://www.site24x7.com/web-page-analyzer.html
gives for fueled:
DNS Time 8 ms
Connection Time 14 ms
First Byte Time 41 ms
Start Render 752 ms
Document Complete 1,489 ms
Total page loading time 1,490 ms
No. of Request 55
Total Objects 55
Images 41 (967.67 KB)
Java Scripts 4 (110.38 KB)
CSS 1 (6.41 KB)
Total page size 1272.86 KB
while for deathshadow.com
DNS Time 7 ms
Connection Time 359 ms
First Byte Time 435 ms
Start Render 588 ms
Document Complete 772 ms
Total page loading time 773 ms
No. of Request 13
Total Objects 13
Images 7 (27.21 KB)
Java Scripts 1 (3.52 KB)
CSS 4 (8.4 KB)
Total page size 44.22 KB
... and for mitica's page:
DNS Time 8 ms
Connection Time 1,014 ms
First Byte Time 1,395 ms
Start Render 1,400 ms
Document Complete 3,408 ms
Total page loading time 3,408 ms
No. of Request 4
Total Objects 4
Images 2 (161.39 KB)
Java Scripts 0 (0.0 KB)
CSS 1 (7.33 KB)
Total page size 172.71 KB
Numbers are more in-line with what I'd expect; though in the case of 'fueled' I find the total load time WAY too low since I'm looking at 5 seconds here -- though if you look at the chart they're allowing way more than 8 simultaneous connects per server. At 55 requests you limit that to 8 at a time with the sheer volume of the file sizes and ... well... anywhere from four to thirty seconds (depending on connection) seems more 'right'. (and consistent with Firebug or DragonFly's analysis)
Well, to compare, let's see what dragonfly says from here -- 22mbps time warner on my Core 2 lappy over 802.11n...
fueled: 4.8 seconds
deathshadow.com: 1.5 seconds
itmitica: 2.6 seconds
I'm usually a big advocate of the incorrectly named "CSS Sprites" -- but in this case the 160k file filled with whitespace is actually making the engine work harder to render -- notice that start render to end is so much higher. Since you can get 8 requests at a time you might actually get faster load times by NOT dumping everything into that one file... Empty/unused areas, redundant content and a larger decompressed 'raw' bitmap size to suck on RAM can have a massive impact on render time.
I encountered that on a site about six years ago -- we went overboard using "sprites", and it actually made the page slower... even on subpages once the image was loaded and rendered. Three of us were scratching our heads over that one until we noticed the memory thrashing from unpacking and blitting from the massive single file. Like everything else web related it's a balancing act -- file size vs. file count vs. script complexity vs. flashy stuff vs. uncompressed size... The last of which a LOT of people forget impacts both client and user side CPU time and memory use!
A bit like old school disk compression like SuperStor or Stacker -- where for high compression data (like plaintext) it actually made the hard disk faster at the cost of CPU, the total still being faster overall -- but on already compressed files like zip or rar, it sucked CPU for no noticeable size or speed savings... something reflected in mod_deflate today, where you don't bother doing it to jpeg, gif, png, zip, rar or anything else that has it's own compression.
That one sprite it's more like an experiment. It's a solution I find interesting and I'm proud of thinking it, but the rendering results aren't quite as good, I'll give you that.
The premise is wrong, those two big header graphics, will have to go. But they served for the experiment with taking advantage of them in forming three columns of graphics below them, allowing me to easily just align left, center or right those in background-position properties, and "profit" from the generously generated whitespace.
My logic was to classify the remaining graphics as left aligned, center aligned, right aligned, and to profit from those big headings to allow for the graphics below them enough whitespace to their right, left and right, and left, to keep them from showing up uninvited in another element's background.
My guess is I'll turn those columns into independent sprites. I'll dismantle the big header graphics into smaller pieces and I'll get rid of the redundant backgrounds in them.
As I said, I'm working on a new system for the back-end, but I'll revisit sprites and a few others in the front-end after I'm finished with that. Thanks for suggestions.
@Falgell: yes, even pixels are a relative measure. Will be interesting to see what future devices will do.
On the em/px issue another consideration: in some countries, if you build a website for certain institutions (government agencies, certain non-profits) you have to confirm to certain accessibility standards. Using px for any font-size is often not allowed in those standards.
(this is just a factual statement, everybody* is free to have his/her own opinion about this fact)
Should developers have that control?Quote:
Originally Posted by felgall
There isn't a unit that gives one absolute control over how big things are anyway. Px just makes issue for people using IE and text-enlarge, among other things.
Saw a guy on StackOverflow using a special Google font for Hebrew letters and everything set in px heights and absolutely positioned over backgrounds. His question on SO was "why does this look different in different OSes on FF, Chrome. IE?" and it did. Each OS showed these px fonts absolutely positioned over images... in slightly different places. I tested on Linux and it was also off... in a completely different way than his Mac/Windows screenshots.
Seriously, if it's saying 1.2 megabytes in 55 files is faster than 42k in 14 files, it's fiction... even accounting for rendering time.
Though in general that's something that annoys me about phones/tablets right now -- how they cheap out on the RAM when RAM is so cheap. These things came with 2 gigs of RAM we'd not see so many slowdowns and annoying behaviors. 512 megs? You're joking right? :D
It's why I'm thinking on making up some test pages of differing sizes and capabilities off one host -- eliminating differences in servers and providers from the numbers to dial it in better. HostGator, Pier 1 and... whatever Fueled is on likely all have different response times and server speeds -- which can have as big an effect on the result as the file sizes, file counts and render times.
Also you have to figure region into it -- Being in New Hampshire for example I get disastrously bad ping times (500ms or more) to anything south of Boston or east of Vermont -- because of this odd 'backbone divide' that results in all my requests being sent across the pond and back just to get to Chicagoland area servers... or up through Canada, across to Vancouver, down to Seattle and back for same... Which is why I'm such a stickler for total file requests and dislike pages with more than 16 of them. NOT talking just mobile, but talking general Internet use. As such many pages that people in metro areas get 2 second page loads, people in places like NH, VT, ME, the Dakotas, Utah, etc, are looking at ten to fifteen times that -- MOST of it due to latency and not pipe-width... which is why 50 or more separate files can have a disastrous effect on load times that again, people effectively sitting on a backbone would never see.
Like Jeff said, the mobile world is a different beast. Tests are tests, but testing for desktop is different from testing for mobile. (BTW, thanks for the links, I didn't know about blaze).
But I also believe it's a little arbitrary on the hosting server for tests, like Jason said. Not that much, though.
What I believe made the change for Jason's page it's probably the viewport meta. Setting it to device width probably helps a lot the speed render for Safari in iOS.
If not that, than it has something to do with some crazy bug in the elastic layout or in the markup Jason had before, that got fixed or removed. I'm more inclined to believe the later to be the real cause.
No offense intended, Jason, but you know it happens to every developer to discover strange things about its work. Like I discovered that "=>" in my markup, I never expected to, since most browsers knew how to deal with it, but Firefox Mobile. And I was so sure all was good, and then only by accident I stumbled upon it.
Make a diff between the old markup and the old css and the new ones, with some tool. What does it show?
Like I've said many times, there are many factors that affect performance. And now you're rejecting concrete evidence because it's forcing you to rethink everything you thought you knew.
If it's solid, Crusty will change his mind. He has been known to do that, just very slowly :)Quote:
Originally Posted by jeff
That the waterfall even seems incomplete and lacks anything resembling handshaking time (likely why it's numbers are so low) and allows more than 8 requests to run simultaneously really calls it into doubt as a legitimate source of information.
performance rules that we now take for granted. He's the best in this field, and it would be wise to give him the benefit of the doubt until you discover some overwhelmingly solid and contrary evidence.
record the waterfall data from an actual mobile device (which, ironically, is what the blaze test is doing already).
It ought to be up to you to perform this test, since you're the one who seems to think that the smartest people in the field got it wrong, but nevertheless, I went ahead and did it for you.
The number of downloads being processed at a time from a real life mobile device matches what we saw in the blaze test, which means blaze got it right.
As to connections -- so you're saying mobile devices, with their narrow pipes, crappy unreliable connections and spotty coverage often throttling down to dialup speeds...
... are allowed more simultaneous connections than a landlined desktop browser. WOW. Am I the only one who thinks that sounds like a REALLY bad idea? Given the limited RAM and barely passible multithreading, with dual core being a new concept to them -- it would explain why they are barely as capable as a comparably configured P2 desktop from a decade and a half ago... and why on most sites if you scroll more than two screen-worths in a row you end up sitting there waiting five seconds for it to catch up and render the new parts of the page to be shown..
Argh... let's just take all the lessons of the past three decades and pitch them in the trash -- that ALWAYS works.
Now it seems like you're deliberately trying to be irrational.
Comedy Central rags on it. ( >> to 2 minutes)
... while with Google, there's a reason many of us are abandoning ship for DuckDuckGo and other alternatives -- with their idiotically bloated and less useful than what they had a decade ago scripted asshattery, illegible color use and fixed metric fonts crapping all over their menu, and other bandwidth hogging nonsense that has quickly over the past year or two destroyed pretty much everything that made Google great, and made them THE place to go for search.
Instead they now seem bound and determined to follow Bing's suit, and add all the crap that flushed Ask Jeeves down the toilet during the dotcom bust! It's like all the things their competitors buried themselves by doing, they now want.
GREAT example 'source'. You'll excuse me if I don't consider working for Y! during the past decade when they lost all relevance and crapped out idiotic garbage like YUI, then working for Google with what they've been doing recently ... it doesn't exactly blow my skirt up.
And disagree with the general advice by others to avoid PX for font size.
If you want to use PX, go for it, there are no related accessibility issues anymore as others have said. On a device such as an iPad, you can't even change the font size independently of the web page, your only option is pinch and zoom. This is the way now with desktop browsers.
If any edge cases are out there that rely on ems, they're fixable. Edge cases should not be driving the frontend dev decisions such as px or em when the cost could mean more hassle and time wasted.
Enlarging text without other things on the page makes less sense. Often text is arranged in boxes and next to graphics that don't scale up as vector items, and the result can be a broken layout. Why would anyone choose a broken layout over a layout that maintains its structure during zooming?
In an ideal world, we'd all be using SVG graphics, and every image on every site would have near-infinite resolution where you could pinch and zoom down to the molecular level. In the real world, someone has just supplied you with a 512 x 288 jpeg which needs to go on the website ASAP. Don't forget to add the caption. Wait, that caption is too small, in the design it looks bigger. Developer scratches head as he wrestles with the inheritance nightmare before him - the result of previous developers CSS spaghetti across multiple files. Oh look, the master CSS file is common to multiple websites across the network, I can only touch the site specific CSS. In you go !important.... wait, have they set a default body size? What exactly is the em value I need to make important?
You get the idea.
PX fonts work. If you prefer an em strategy, go for it, and build that in from your foundations - design and coding and style guides all clearly specified and mapped out to avoid frontend problems down the road.
What I hate is people getting on their high horses saying we MUST use ems, or must do this or that... sorry, but those people usually are not the ones left to clean up the font size issues on the website at 5:25pm on a Friday.
PX is effectively a relative size when used for fonts. They maintain their vector nature when the page is enlarged on the client side. Further more, many websites use fixed pixel with containers for the layout. This is not a crime either due to the nature of the content inside those containers - often images and videos and assets whose nature is fixed pixel dimensions.
Even this website, as I write this comment on a wide screen in a textarea box whose width is "100%", my lines are way too long. Some people would call that a flawed design. I'll bet you the designer of this reply box did not mock up a form where text entry sentences extended this long. By liquifying and conforming to my 1920 display, I can tell you that you've done me no favours!
How's that for a first post rant? :-)
I choose this regularly. Like other users forced to do the same, reading large, sharp text with something blurry next to it makes me sick. It didn't used to when I was younger, but then I also used to be able to spin myself silly and ride roller coasters when I was younger as well. : (Quote:
Originally Posted by frypan
When I go somewhere to read something, I care utmost about "can I read the text", even over broken layouts. A little over half the sites I visit have something sitting over something else at my required font size, or popping out of a box, but most of the time this is only ugly.
Maybe it's because I'm not a designer that as a user, I care more about reading text than breaking a layout?
It would be interesting to have someone do a nice, big study with bad-eyesight users (regular internet/computer users) who need text-enlarge in one form or another and see if there's a trend of trying to keep the layout "pretty" or not.
But in any case, announcing that everyone can and should use zoom because it works for you and therefore px units should be used, is one of those statements that tells users like me, who don't do so well on zoom, that we should just pack up and leave the internets to the young people. Well, I ain't going anywhere so deal with me.
I remember how easily Chrome ignored all the users crying out for a return to "enlarge text only" feature that was removed. It was very easy for them: pretend they don't exist. Thanks, Chrome team, you rock! >:(
It could use some more vitriol and maybe some ***'s, and a bit more snark, but then I suppose I would hold those back on a first rant too.Quote:
Originally Posted by frypan
So, looking forward to more. We can get more colourful then.
In other words - simplified version - find some people who need assistive devices; lenses technologies, i.e. require glasses to read text on a screen. Then ask them if they would require text to be zoomed for readability if they were using naked eyeball.Quote:
Originally Posted by Poes needs feeding Chocolate now
The answer in my case; is "yes", I would have to enlarge the text without two bits of clear plastic. I wouldn't care about the page not being pixel perfect or slightly shifted as-long as I could clearly read the content.
But then, I often have that problem with websites that use %/em when the developer didn't take the time to understand how to use them too.
Though @frypan the 'use px' approach really pisses me off, because congratulations, you just turned me and a lot of other people into an instant bounce; at least so far as your flow content is concerned. Much like crappy fixed widths you're either sending me diving for the zoom, and frankly, if I have to zoom to use a page, I'll go find a page where I don't have to. If you design fluid or semi-fluid, don't even TRY to do the dipshit "but I can do it in photoshop" nonsense behind/around the text, there is NO excuse for pissing all over accessibility with px metric fonts on EVERYTHING.
My Desktop fonts are set pretty large, but I still have to zoom or text-enlarge on most sites anyways.Quote:
Originally Posted by crusty
Zeldman's is so far the only site I don't zoom on :) and everyone else pretty much says they have to zoom out.
Hi frypan. Welcome to the forums. :)
Out of the fire, into the frypan. :lol:Quote:
Originally Posted by frypan
You can make those boxes scale and arrange themselves nicely, though. That's the nature of the web. It's flexible and needs to adjust to different environments and states. It's not the same a print, and shouldn't be forced into the constraints of print. (It's also what makes web design fun. :) )Quote:
Originally Posted by frypan