| SitePoint Sponsor |
There is an article at snook.ca [link] about off-screen positioning versus clip (something which I've not tried). I'm using off-screen absolute positioning, though slightly different to the example in that article, but I can't replicate the page jump problem that this writer mentions. I have tried it in Firefox 3 (and latterly 8), Chrome, and Internet Explorer 8. So does this happen? Does it affect only browsers that I don't have, or what?
Wow, that's the dumbest article I've read in quite some time...
1) starts out with the massive text-indent; that's usually used for content cloaking or the 'broken' image replacement methods, and as such really shouldn't be used in the first place.
2) positioning off the top with apo? Off the LEFT... LEFT!!! Of course, if it has focusable content, what the blue blazes would you be hiding it for?!?
3) clip -- unreliable rubbish... I've never seen it work right in any browser.
position:absolute;
overflow:hidden;
top:0;
left:-999em;
width:1em;
height:2em;
End of problem. Width/height+overflow chops it off preventing height/width overflow issues, left positioning well off screen hides it...
Well, that's the thing. A lot of people seem to set top positioning, judging by what I've read, claiming that it avoids problems with right-to-left languages. I just used left positioning instead, because when am I ever going to write something in anything other than English, so maybe that's why I haven't seen this problem. My code is pretty similar to yours.
I couldn't get clip to work very well, either, when I tried it yesterday, but I didn't know why.
About focusable elements: I'm doing a new site at the moment, using Drupal, which involves the occasional use of focusable content being off-screen. That's the Drupal way anyway, but it does make sense in certain cases.
I'm not sure what the issue with clip is.
Admittedly I've only used it a few times when a client wanted an "animated gradual unveiling" of a vertical sub menu when its main menu item was moused over. It works fine in at least the major browsers.
I'm sorry... my deepest condolences.Originally Posted by adh32
Oh, yes, I forgot that you don't like any CMS!
Oh, yes, I forgot that you don't like any CMS!What's to like?Code:<body class="front not-logged-in page-home no-sidebars drupalorg-front drupalorg-site-main"> <div id="skip-links"> <a href="#content">Skip to main content</a> <a href="#search">Skip to search</a> </div> <div id="header" class="clear-block"> <div id="header-screen" class="clear-block"> <div id="header-inner" class="container-12 clear-block"> <div id="nav-header" class="grid-12">The chronic ineptitude of it's coders?
Yes, it's true that it suffers from what I understand is often called divitis. Like a lot of CMSs. But most of them can easily be removed from the templates and any others can usually be removed by writing functions. That can be difficult to figure out, and I've certainly had some headaches over it, but it's doable. I'm not making any excuses for the default output, though, some of which has really annoyed me. But Drupal has a lot in its favour and a lot to like.
Nobody can. And the comments where folks using RTL also solved the problems are also conveniently ignored.though slightly different to the example in that article, but I can't replicate the page jump problem that this writer mentions.
But then I disagree with Jonathan on lots of stuff. For example, he also advocates teh 62.5% font size crap on body elements. No thanks, I'm not getting my advice from this guy.
I continue to use the off-left positioning method. It works. Opera still has issues focussing on something pulled off-screen, and webkit still has its years-old bug of not moving focus to the fragment/destination, but those are not new.
The off-top positioning method had a few issues: Opera has not only a limit in width on pages, but that same limit seems to apply to heights too. So no setting something to top: -9999em in Opera (esp if the page has a main box with overflow: hidden).
Window-Eyes used to let users focus on something pulled off-screen to the top right on page load, rather than only when the user got to wherever the off-screen element actually was in the markup. No idea if that's still an issue.
Poes: A bit OT, but what font measure set up do you use in preference, and why? What is it about 62.5% that you dislike?
You know, I posted a bunch to someone with the same question on Linkedin... I wonder if I can just copy-paste that and translate to English...
Somewhere Crusty has an example page showing just how much smaller pages get (different per browser) when people use something that low. It's almost cutting someone's set font size down by half. I think Crusty didn't go down under 80%...I also use ems, but not microscopic sizes.
To avoid an IE bug, I use a % font setting on de body. But I use what the user has: 100%. People who need 20px fonts, 100% == 1em == 20px. For people with superman eyes and young hip age who have their machines set to 10px, 100% == 1em == 10px. But the user is deciding that. The Clagnut technique is all wrong (he did add a larger font later in the code, but most people imitating him leave that out and just keep the 62.5%, similar to people using Meyer's reset with outline: none and then no :focus styles added).
Web dev asks why he sees a difference with Georgia, 62.5% and Macs:
http://www.sitepoint.com/forums/css-...pc-752769.html
Font size on de body tag:
http://www.sitepoint.com/forums/web-...ag-731654.html
(read de comment from Jeff Croft): http://www.456bereastreet.com/archiv...ize_in_pixels/
(1st comment from Aaron Digulla): http://stackoverflow.com/questions/1...-font-size62-5
Browser default !=16px for everyone; that's why the numbers don't work. And if someone's bothered setting their default font sizes bigger, who am I to go make them smaller on him/her??
I sometimes hear bosses and designers say a font is too big. User complain when it's too small.
I thought that it was solely about making it easy to get all the em sizes worked out in any design that needs numerous different sizes.
In my case, I've found it useful for that, although I would leave it at 100% if I could find or come up with a better way because I've encountered some instances of CMS-generated text in divs (with no text elements around it, so they appear as 10px and I have to add another fontsize declaration) and some trouble with nested lists getting very oversized. When I started the design, it was hard to get the sizes that I wanted on things like headings when the starting point was bigger. 10 is such as easy number.
As an aside, rest assured that all my text is sized at effectively 16px and above (in most browsers, notwithstanding things that I can't control/predict, etc.). I can't read anything less than about 14-16px depending on the font.
Poes, that Stackoverflow link that you included.... That whole discussion seems to predicated on an assumption that the person who asked the question wouldn't then set fontsizes for text elements, e.g. p, li {font-size:1.6em} and h1 {...2.8em} and so on. Is that actually how most people do it? Leave most of the body text elements to inherit the 62.5%?! That would be nuts.
There's a way to hide things up with css font-size: 0px. However, it's not fully cross-browser - for instance still shows the text on iPad mobile Safari.
Yes, the original idea was, designers and CSSers were used to using pixels, but were being advised to use ems, and ems are a different mindset for pixel-wranglers. So with some clever math, someone thought they found a way for developers to use ems and know exactly how many pixels that would be. Since ems don't translate to pixels correctly cross browser/platform/hardware, it's folly.I thought that it was solely about making it easy to get all the em sizes worked out in any design that needs numerous different sizes.
But again, the Clagnut technique as originally explained, while an itty-bitty 62.5% is set on the body, there was a main-page wrapping div which had the font size set higher (so he could keep his 1em=10px thing but the page didn't actually set everything to 10px anymore) but the part everyone got was just the 62.5% part.
It's certainly what you'd see on many other pages displaying the technique, yeah. The original Clagnut page did not, but I think that wasn't highlighted enough.That whole discussion seems to predicated on an assumption that the person who asked the question wouldn't then set fontsizes for text elements, e.g. p, li {font-size:1.6em} and h1 {...2.8em} and so on. Is that actually how most people do it? Leave most of the body text elements to inherit the 62.5%?! That would be nuts.
If you're using the 62.5% technique but then being really picky on keeping font sizes pretty large, you're probably still okay. My issue is two-fold: most sites using it have text that's too small on my machines, and it's not true that you really get 1em=10px. I recommend people just dive into ems and get used to seeing how big they are (so, also container widths etc) when the body starts at system/browser default size (whatever that may be).
People going from px to ems also got bitten now and then by setting the font-sizes (in ems) on containers. That'll get you the nested-stuff problems. So for example, no setting of font-sizes on uls and ols. I set them on the lis if those are at the end of the DOM branch, or the anchors if there are anchors inside. Anyone I don't set an explicit font size on, is at least going to be naturally 1em, which will be... whatever the user has set.
You have to think roughly in terms of pixels, though, surely. Because if you ignore pixels, you have no reference point at all for what 1.6em may signify. I mean, pixels are the end result of whatever you do in your CSS and if you don't think in an em:pixel way, you might as well just not specify any font-sizes.
I see all my text at 16px or greater in the browsers that I can test, having chosen a starting point of 1.6em, and I can do little more than hope and assume that other people will see it at least as big as that.
Re: sizing on the lists: I had the font size on the list items but still had inheritance problems in sub lists because they're inside LIs.
I certainly started out thinking that way.Because if you ignore pixels, you have no reference point at all for what 1.6em may signify. I mean, pixels are the end result of whatever you do in your CSS and if you don't think in an em:pixel way, you might as well just not specify any font-sizes.
I really don't bother with thinking in pixels anymore really unless images are involved (or I'm working on a page where stuff is already set in px).
What does 1.6em signify? "160 bigger than default". I set something larger than 1 when I want something "bigger than" and smaller than 1 when I want something "smaller than". Ambiguous and ethereal, I know. But I'm okay thinking of things relatively on web pages for the most part (still bites me when I forget some browser sets some element to something other than 1em, like form inputs!).
Probably the reason I'm okay within thinking that way is because of how I've increasingly needed to increase sizes on web sites. Nobody is whatever the original pixel intention was on my screens anyway. Everyone's quite a bit bigger and I have no idea how many pixels bigger they are than they were on the original developer's screens.
The results are not the same cross-browser but they are the same ratio. Everyone's generally relative to each other in the same way regardless of scale.
For something like nested lists (where there are no anchors), let's say I have this:
<ul>
<li>main item one</li>
<li>main item two</li>
<li>main item three<li>
<li>main item four with components
<ul>
<li>sub item one</li>
<li>sub item two</li>
<li>sub item three</li>
</ul>
</li>
<li>main item vijf</li>
</ul>
If this list needs to be slightly smaller than default, then let's say I do
li {
font-size: .8em;
}
then yeah, the sub li's are 80% of 80%, which is smaller than 80% of the original 100%.
To keep the subs at the same level as the parents (80% rather than 80% of 80%) I set them to 1em.
li li {
font-size: 1em;
}
and I really do try to avoid 1.345em type settings because since I'm not thinking in pixels I know I'll have differing results per machine anyway so it's all not only relative, but approximate.
I dunno that I'd want to try to deal with ems in a CMS that's full of strange things, or px-sized boxes, or that mixes stuff horribly. But so far I've been lucky enough to be allowed to write HTML by hand.
Using em's on hand-written stuff is probably a lot easier, whereas using px on partially-machine-generated pages is probably easier. Certainly if I were stepping into someone else's page I'd be really careful using em for anything because being a relative unit, it'll die horribly if the other dev had set something weird somewhere else I haven't seen. Px settings always start from an absolute unit (even if that unit isn't exactly the same cross rez/browser/machine, as far as the browser is concerned it's some set amount) so nesting doesn't matter there.
You mean this?
http://battletech.hopto.org/html_tut.../template.html
Posting Permissions
Reply With Quote
Bookmarks