SitePoint Sponsor

User Tag List

Page 7 of 7 FirstFirst ... 34567
Results 151 to 174 of 174
  1. #151
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by deathshadow60 View Post

    .. and I do that with an IBM model M keyboard how exactly?
    Option key on Mac is CTRL key on PC?

  2. #152
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  3. #153
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,121
    Mentioned
    448 Post(s)
    Tagged
    8 Thread(s)
    Off Topic:

    Quote Originally Posted by deathshadow60 View Post
    .. and I do that with an IBM model M keyboard how exactly? :P
    Last I heard, the developer kit was only available on Hackintosh, so I assumed you were using it that.
    Facebook | Google+ | Twitter | Web Design Tips | Free Contact Form

    Forum Usage: Tips on posting code samples, images and more

    Forrest Gump: "IE is like a box of chocolates: you never know what you're gonna get."

  4. #154
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    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:

    Quote Originally Posted by Jeff Mott View Post
    itmitică's snapshot inspired me to put a few websites through a mobile performance tester.

    I find it more than a little ironic that deathshadow will rant about page weight and performance until he foams at the mouth, yet his site is by far the slowest.
    1.2 megabytes in 55 files loading FASTER than 44k in 13 files? You can't tell me that's not fishy...

    case in point:

    Quote Originally Posted by itmitică View Post
    It improved your loading time as well:
    http://www.blaze.io/mobile/result/?t...3885f435617cba

    Code:
    Average Load Time 	Average Pagesize
    3.54s 	                42.55kb
    Markup grew two extra span, two more LINK, two more files, and it shaves 6 seconds off it? If that's not proof enough that said "test" appears to be a work of fiction... It's almost like it adds 6 seconds to any page that doesn't use a media query.

    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

    @mitica

    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.

  5. #155
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    @mitica

    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 [...] Empty/unused areas, redundant content and a larger decompressed 'raw' bitmap size to suck on RAM can have a massive impact on render time.
    Yeah, I was thinking the same thing, sort of.

    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.

  6. #156
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Netherlands
    Posts
    172
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    @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)

  7. #157
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    ...I really think that "blaze io" test is a bunch of horse manure...
    It's the performance tester of choice for the smartest people in the field. If you're going to disregard it, I'd hope you have a better reason than a poor result for your site.

    Quote Originally Posted by deathshadow60 View Post
    Markup grew two extra span, two more LINK, two more files, and it shaves 6 seconds off it? If that's not proof enough that said "test" appears to be a work of fiction... It's almost like it adds 6 seconds to any page that doesn't use a media query.
    Seems to me that the lesson you should take from this is that performance on mobile devices may not be as straight forward as you wish it were. There are factors that matter much more than k-weight. It's probably worthwhile to identify the exact change that so significantly affected your page's performance. And I mean that genuinely. I'm curious myself.

    Quote Originally Posted by deathshadow60 View Post
    ...in the case of 'fueled' I find the total load time WAY too low ... anywhere from four to thirty seconds seems more 'right'.
    Now you're ignoring your own performance results, and instead focusing on what would "seem" right to you.

    Quote Originally Posted by deathshadow60 View Post
    ...let's see what dragonfly says from here...
    Now, unfortunately, you've resorted to a test that none of us can exactly repeat. All I can say here is that I don't get the same numbers you do. For me, Fueled loads roughly twice as fast as your number.

  8. #158
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by felgall
    By using px you lose all control over how big things are.
    Should developers have that control?
    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.

  9. #159
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    It's the performance tester of choice for the smartest people in the field. If you're going to disregard it, I'd hope you have a better reason than a poor result for your site.
    Then how about the outlandish and nonsensical numbers for other sites?

    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.

    Quote Originally Posted by Jeff Mott View Post
    Seems to me that the lesson you should take from this is that performance on mobile devices may not be as straight forward as you wish it were. There are factors that matter much more than k-weight.
    Like file count, DOM complexity, total RAM usage for render and unpacking not just mod_deflate, but all the image formats encoding...

    Quote Originally Posted by Jeff Mott View Post
    It's probably worthwhile to identify the exact change that so significantly affected your page's performance. And I mean that genuinely. I'm curious myself.
    I'm thinking on building a few test pages just to see in a consistent manner what causes such MASSIVE changes -- a two-thirds reduction in delivery is gargantuan; I can't believe adding code could be the cause -- though I suspect stripping a lot of the CSS3 and backgrounds off it boosted the render time... Especially if they include gecko in their testing which is abysmally slow at doing anything like box-shadow, large images, text-shadow, etc... just as said effects suck down RAM on iOS devices meaning you scroll up and down twice in a row you get a blank page and half to wait 3 to 5 seconds for it to draw the new section.

    Off Topic:

    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?


    Quote Originally Posted by Jeff Mott View Post
    Now you're ignoring your own performance results, and instead focusing on what would "seem" right to you.
    Using the common sense of it -- 2 seconds render time + 200ms for each file past the first 8 as a lowball number, 5 seconds render time + 1000ms for each file past the first 8 as worst case; which is why across the street on my neightbors 768 DSL (which suffers massive routing penalties) 'fueled' takes around half a minute to finish loading... compared to 4.5 seconds here on my 22mbps cable connection (sad when cable has lower latency than DSL) or 2.8 seconds testing from my current server host via KVM.

    Quote Originally Posted by Jeff Mott View Post
    Now, unfortunately, you've resorted to a test that none of us can exactly repeat. All I can say here is that I don't get the same numbers you do. For me, Fueled loads roughly twice as fast as your number.
    Thing is, same connection same hardware the only differing factor would be the server, so do my site and itmitica's scale the same way on load times from dragonfly and/or firebug? They should... if you're seeing comparable numbers then something's gone south, or the difference in host could be the limiting factor. Oh, and be sure to disable cache (dragonfly it's under network options) so you get a true firstload.

    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.

  10. #160
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    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?

  11. #161
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Then how about the outlandish and nonsensical numbers for other sites?

    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.
    It's entirely possible that you have a cheap hosting service. Or if you're on a shared host, perhaps one of the websites you share with was consuming lots of resources at the time. Or perhaps something in your code was indeed degrading the mobile device performance.

    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.

  12. #162
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by jeff
    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 :)

  13. #163
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,809
    Mentioned
    73 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by felgall View Post
    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.
    How about using outline instead of border?

    Is outline OK to use on all SmartPhones?
    Last edited by John_Betong; Apr 3, 2012 at 17:24. Reason: correcting spasmodic keyboard characters.

  14. #164
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    \And now you're rejecting concrete evidence because it's forcing you to rethink everything you thought you knew.
    Sorry, but some automated tool I never heard of until linked in here, that seems to use a waterfall similar to firebug/dragonfly but has the number of simultaneous requests UNLOCKED doesn't exactly strike me as concrete evidence. In fact, I would suspect we have a different opinion of what the term "concrete" even means.

    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.

  15. #165
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Sorry, but some automated tool I never heard of until linked in here...
    The blaze mobile tester comes at the recommendation of Steve Souders, the chief performance officer of first Yahoo then Google, and whose research is the reason we have 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.

    Quote Originally Posted by deathshadow60 View Post
    ...but has the number of simultaneous requests UNLOCKED...
    You may not understand why that happens, but nonetheless, it happens. If you suspect it's wrong, then the rational and evidence-based way to test it would be to 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.

    http://pcapperf.appspot.com/view?has...ccb3051919ad91

    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.

  16. #166
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    The blaze mobile tester comes at the recommendation of Steve Souders, the chief performance officer of first Yahoo then Google, and whose research is the reason we have 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.
    So... the guy who ran Y! into the ground, and is probably why Google has been crapping itself for the past couple years in terms of usability and accessibility? WOW, great source.

    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.

  17. #167
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    So... the guy who ran Y! into the ground...
    No...

    Quote Originally Posted by deathshadow60 View Post
    [and] why Google has been crapping itself...
    Also no.

    Now it seems like you're deliberately trying to be irrational.

    Quote Originally Posted by deathshadow60 View Post
    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.
    I showed you a record of what's actually happening in the device. It's up to you whether you want to continue to be in denial.

  18. #168
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Now it seems like you're deliberately trying to be irrational.
    Calling it as I see it -- like Yahoo has even been RELEVANT for decade? It's a laughing stock; even 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.

  19. #169
    SitePoint Member
    Join Date
    May 2012
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    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.
    Strongly disagree.

    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? :-)

  20. #170
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by frypan
    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?
    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. : (

    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! >:(

    Quote Originally Posted by frypan
    How's that for a first post rant? :-)
    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.
    So, looking forward to more. We can get more colourful then.

  21. #171
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Poes needs feeding Chocolate now
    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.
    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.

    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.

  22. #172
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Maybe it's because I'm not a designer that as a user, I care more about reading text than breaking a layout?
    For me broken layouts usually means unreadable or at the very least annoying text -- from text blowing out of it's containers overlapping borders, to text overlapping other text elements, etc, etc...

    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.

  23. #173
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by crusty
    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.
    My Desktop fonts are set pretty large, but I still have to zoom or text-enlarge on most sites anyways.

    Zeldman's is so far the only site I don't zoom on :) and everyone else pretty much says they have to zoom out.

  24. #174
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,121
    Mentioned
    448 Post(s)
    Tagged
    8 Thread(s)
    Hi frypan. Welcome to the forums.

    Quote Originally Posted by frypan
    How's that for a first post rant? :-)
    Out of the fire, into the frypan.

    Quote Originally Posted by frypan
    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?
    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. )
    Facebook | Google+ | Twitter | Web Design Tips | Free Contact Form

    Forum Usage: Tips on posting code samples, images and more

    Forrest Gump: "IE is like a box of chocolates: you never know what you're gonna get."


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •