Until now I thought justify meant that the text will start and end at the same pixel, but i was surprised a few hours ago, when I saw this:
I got similar results in 2 computers (win7+chrome, ubuntu+firefox), and not just at this place, there are more similar bugs on the same site.
After my second chec I thought this is general and I just haven't noticed yet, but other sites don't show this strange behaviour. Also refreshing the site and restarting the browser didn't solved it.
Has anybody else noticed this? What causes this?
Actually that could well be intended behaviour. As with kerning it's about the appearance, rather than being pixel perfect. With justification the appearance that's trying to be achieved is of a straight edge on both sides of the text column.
Letting a letterform with an uneven right edge like "k" stick out past the straight edge of a letter like "n" helps to give that appearance visually. This is because of Gestalt psychology, which deals with how we perceive shapes, and you can see it happening at the start of lines as well:
It wouldn't surprise me if Webkit handles the nuances of text reproduction like this better than IE's engine—it's a feature in desktop publishing software like Adobe InDesign.
It should be because of the character width is variable, a pixel is the smallest unit here, and fill the spaces, with, spaces can sometimes compute a float which is rounded.
Anyway, you should really not worry about this as the main reason would readability and not a design vagary.
The points previously made about this being a perceptual issue are valid, but also a bit accepting of a best-case scenario where the justification is being done right/well in the first place. It's worth nothing that proper text justification is actually rather hard, and the algorithms used by browsers just aren't that great. This Hacker News thread has a bunch of notes and links that should be of interest.
Related
This might be a poor question for this exchange but is it worth styling for zoomed out browsers? For instance, I can zoom chrome out to 25% and my navigation breaks, should I accommodate for this or will 99% of cases be fine without the extra effort in styling? What case would I run into problems like that?
25%? I wouldn't worry about it unless you have a use case for your page where your users will be that far out.
Now, 75%-125%, you might consider it. Usually your page will work fine at other zoom levels. If it doesn't, it's likely because you have hard-coded something you shouldn't have. (For instance, you might assume that text on a certain line will never wrap. That isn't a good assumption. Different devices use different fonts, which could cause text to wrap in some cases.) In those cases, make sure to only set the sizes to specific values when needed. Let the page flow as much as possible.
Probably not.
A good responsive design and sticky footer might work around this issue. That said, how many people zoom out this far?
See Marshall Roch's comment towards the bottom of that link - he says a small percentage have 1 zoom level off normal on facebook. So to zoom all the way to 25% seems quite extreme. I suspect any users who DID use that zoom level would be used to sites looking weird.
I'm writing a web app. It's only ever going to be used with IE8, so I'm not concerned with the behavior of any other browsers here.
So: I know how to custom-style a button using CSS properties e.g. background-color, border, and so on. However, when you apply styles that way, the resulting button looks like a blocky table cell, nothing like the nice, glassy-looking button that IE8 renders by default.
Is there some way to add a tint to the nice glass-looking button? I.e., it looks just like it normally does, but with a red outline instead of blue, and a red highlight on mouse-over?
Or is this something I'm going to have to do by hand with images? Again, IE8-specific methods are perfectly acceptable.
Thanks!
-dan
There isn't really a filter that will get you as close to the default in IE, though you can get pretty close using the button tag and standard css. It will not look the same in all versions of IE though.
Here's the filter reference though if you want to try other things.
Regardless of browser, one of the quickest, easiest, most widely tested methods for styling buttons via markup is Jquery UI's button It's a matter of adding a few tags to the class element, and you've got a button based on an link, button, or input field. For styling, you can handle styling via CSS, or via the very well done ThemeRoller option, where you can control everything from text size to background type via a simple gui interface--and you can change on the back end or even the user end on the blink of an eye, even via drop down.
One caveat, since IE is non-standards compliant, rounded buttons fail gracefully to square--with proper styling.
I realize that you have determined that you can use a proprietary solution for IE, and in your case it might be just fine over the long term. But in my experience, that's a really dangerous path to follow. What if the actual long term is longer than your anticipated "long term?" You're specifying that it's acceptable to be proprietary to a browser that's well behind the accepted standards, is already a version behind, and uses unsupported (by universal standards) solutions to solve problems. Conceivably, that version is going to get tougher and tougher to find, and if Microsoft holds true to their patterns, once you install IE9 it will effectively render your computer difficult of downgrading. And, I can't emphasize enough that IE's market share is dropping like a rock, which is scary considering basically 95% of the machines out there have it pre-installed. All it's going to take is one overzealous IT director with "security in mind" to render your programming efforts moot. Sorry for the rant, but IE proprietary code has bit me hard more than a few times...
I'd have to double-check, but you should be able to use a combination of a background color and use a transparent PNG or GIF as the "background image" to add the highlights.
All things being equal, I've rather embraced the flat, square button - finding ways to make it work well with the design - but then again I've always been a straight line, square edge kind of guy. :)
As others have mentioned, you do want to be mindful (within reason) of what you may have to handle. It's quite possible that before the next re-write you're going to have to deal with IE9 - writing code that works well in IE8 and IE9 would be the most prudent approach.
Have a look at http://www.webdesignerwall.com/demo/css-buttons.html and also http://css3pie.com/.
Combining those you can get nice looking buttons in IE as well..
In our current project, we have one particular page where, when viewed in IE7 or IE8, fonts seem .1 or .2 em larger than they should be. Having inspected the code and css, I cannot see where this is coming from. This issue affects ONLY ONE PAGE which is to all intents and purposes exactly the same as many others in the site, which display as expected.
Some things I have ruled out:
Text-size settings (it's not that, set to medium, and anyway if so why one page only)
DPI settings (same reason as above)
Browser zooming (it's set to 100% - the problem scales with the zoom setting, btw)
Browser-specific CSS (no browser specific rules are applied to the elements in question)
Stray font-size setting code in the markup (I've been through and eliminated this)
Voodoo (okay I haven't ruled this out - as my frustration increases I'm starting to think it might be this though)
The page displays as expected in Firefox. This is not a live site yet so unfortunately I can't point you at the URL.
Has anyone come across something similar and, if so, what was it?
Many thanks,
G
Without showing us or replicating it at least, asking is pretty much near useless but I suspect it's probably just a tag that wasn't closed on an element with an above average font size.
I'd recommend validating the HTML. If it's good, then it's hard to say without looking at the code/page.
Could you please show me a website (preferably, a forum) that has perfect liquid layout (that does not break at all if the browser window gets resized)? Would be nice to see...
Once again, where on the web can I see a website that doesn't become a mess when squeezed down and doesn't cap its own width when enlarged?
Have you ever been concerned about that? Or a fat lot you care? 'Cause I see that popular websites (even portals, I am not going to name any) have this problem (as I consider it to be).
Well, I'd like to see what your code would be for an avatar on the left and some user's info on the right. Please see this picture to figure out what I mean: savepic.ru/780576.png
The main reason why this is broken in many places is that it's broken at the fundamental level: CSS doesn't really support fluid layouts, there are still corner cases even when you start using tables for layout. On top of that, every browser and every version of every browser does CSS a little bit different.
The net result is that even highly paid web designers can't get it right (or someone would have come up with a solution by now and every would be using that).
The only hope is that browser developers finally agree to make their products compliant to the Acid3 test. But as I write this, my Firefox 3.5.1 gets only 92%. WebKit (Safari and Google Chrome) and Opera go the full 100% (see this article).
I personally have given up on this and I won't revisit this topic until IE 7 drops below 5% in the popular usage charts which will probably take five to ten years (IE 6 is dead as a log but still gets 12%).
Smashing Magazine have a couple of posts on fluid layouts. Try searching around there to find good examples and explanations.
One of my favourite from their examples is Vivabit.
Personally I haven't been to concerned about it yet, but I probably should, with the rise of netbooks and mobile browsers. I still believe you should serve a different layout to mobile browsers, though, but it's interesting to look at possibilities of serving the same to all browsers.
Well, Slashdot has a completely fluid middle column (down to some minimum which is pretty small) with fixed-width columns to left and right. As far as I can see it doesn't cap its width (tested on my 1900x1200 monitor).
It's not a forum on the main page, but the comments to articles are kind of like it. It doesn't have the avatar example you're looking for though :(
One of the pages on my website is pretty tall. It's under 200KB in size, but it's a series of tables that takes a lot of vertical space. After about 40 screenfuls (about 1/4 of the total scrolling height of the webpage), it just stops drawing: everything above that looks fine, and everything below that is plain white background -- except the footer (in a different div, I guess), which shows up fine at the very bottom.
I've asked around the office, and other people have seen this before, but don't know what causes it. We certainly have other pages here that are just as tall, and have no problem. I've seen pages render fine which are much longer. It's not a complex document at all -- some nested divs, some tables (4 or 5 columns, a couple hundred rows each), some CSS.
The page renders great in both IE7 and Chrome. Only Firefox 3 does this.
Any clues as to what's causing this? Or a workaround? I don't even know what to google for here.
EDIT: I've seen this on another, completely unrelated page. In both cases, it cuts off at about 33000 px from the top -- ha. I know FF3 can have divs and tables longer than that. Anybody know what they might be using a 16-bit size/coordinate for?
Sounds like this may be related to Firefox Bug 215055 or Firefox Bug 333994. Check these out. If it is indeed related, you can always attach your testcase to one of these bugs and add your comments to the bug.
I also recommend, like zodeus does, trying a nightly build or a beta of 3.1. If it's fixed there, that doesn't mean you force your customers to upgrade, but at least you know it's fixed in a future build and you can campaign for Mozilla.org to bring the fix back to a more current build where you might get people to upgrade.
Try downloading the Fire Fox 3.1 Beta or Nightly Build. They have reworked a lot of their internals. If it works there then I would say it's a reported and fixed FF3.0 bug.
This bug filed in Bugzilla may be related...