I am looking at blueprint styles, and there is font-size declared on html element (100.01%) and also on body (75%). Other text elements have their font size set using em’s.
Why declare font size on html and body as well?
Why use percent on html/body and em’s on others?
I thought I can just use font-size: 1em on body and go from there… using only em’s, why is there need for % on body element, and also why is font-size used on html?
One more question about line height. Should it be declared as number withou em’s, line-height: 1.5 ?
Yeah, there’s no reason to do it on body – unless you don’t understand %/em – the 100.1% is really weird, and probably indicates a bit of #DDD programming… though that’s a given whenever you get into idiotic bloated train wrecks – the types of things that have words like “framework” or “blueprint” on them, which on the whole saddle you with presentational markup, bloated markup, and in general defeats the entire POINT of using CSS in the first place… hence the slapping values on everything before you even start to have a layout, and presence of idiotically meaninglessly vague classes like “span-1, span-2”, and outdated half-assed rubbish like clearfix… to go hand in hand with the fat bloated BS ‘reset’ that’s more framework than reset – hence it being three times what I’d ever consider using for such.
Which is why I’d advise NOT taking sleazy half-assed rubbish shortcuts like “blueprint”. All it does is make a giant mess out of something simple. Same goes for YUI, jQuery, LESS, and any of the other ‘layers of abstraction’ that as a rule piss all over any project they are involved in.
I’ve got a shocking memory, but I remember it being discussed as a workaround for some old browser that had problems otherwise. I’m sure it’s long out of date now.
I can’t figure out from that link the issue with line-height. Can you or anyone else discuss more about the possible drawbacks (browser/device inconsistency) of using line height without unit declared? Thanks.
I’ve repeatedly seen it broken in Opera across platforms pretty much from the first time I encountered it – though it it’s consistent in cropping up. It often becomes like people who declare %/em font sizes without redeclaring the line-heights, or using the named sizes, and the net result is all the lines overlapping.
There was an example of the behavior (from a similar cause) I pointed out in a recent thread in regard to Neilsen’s websites. My desktop and laptop are both high res (1920x1200 and 1680x1050 respectively), both run large fonts/120 dpi, both running the same versions of Opera… but when I visit their site it’s fine on my desktop, but my laptop gives me this:
Back when M$ first announced their new “artist formerly known as frontpage” rubbish, the website for it at that time used the no-metric line-height along with fixed-height containers (the latter being REALLY stupid), resulting in this on all my systems:
… and I’ve been seeing sites broken like that more and more as people omit their line-height when they change the font size – it’s why I have the rule ‘if you change the font-size, change the line height’ – at which point it ends up just as many characters in most cases as just redeclaring the entire shorthand FONT property – which is why I just do that.
It’s one of those stupid little things people do to allegedly ‘save time’ or ‘save a few bytes’, where to be frank much like whitespace stripping its typically a band-aid on a knife wound, you might hide that it’s there but it doesn’t fix a deeper rooted problem… or the comments between sibling elements bugs which is SO easy to rectify – put the comment after a open tag or before a closing tag, not the other way around… I repeatedly have seen people diving for vague hacks and bloated CSS when the only thing wrong was doing something like </div><!-- end section –>
Leaving off the unit is unreliable and unpredictable cross browser, at MOST it’s two extra bytes to NEVER have it EVER cause a problem… That there are people even arguing in favor of something so silly is almost as mind-numbingly astounding as the people who actually defend the use of HTML 5.
Opera on Linux doesn’t do it, but I’ve seen plenty enough bugs that hit either Linux Opera but now WinOpera, and vice versa, so it could be more to do with his Windows system. My Applications fonts are set large, but I don’t get line-overlap (I do sometimes in Chrome but that’s a butt-browser anyway).
How does making one property accept no metric when EVERY other property does make any sense whatsoever. 1 what? 1.5 what? The only time not having a metric makes any sense is zero, since zero is always zero. (unless zero is first in a series, and that’s really rare).
Though that article from Meyer, much like his idiotic bloated resets, I’m shocked anyone sees anything of value. There’s nothing in there even resembling a coherent thought, and to be frank, anyone who would declare a line-height of 1/1em/100% needs a good swift kick in the junk for making an illegible page.
That inheritance they claim – of it always recalculating, is total ******** and as I said above does NOT occur across all browsers on all systems all the time. It’s a sleazy shortcut at best, how to completely throw a website in the trash at worst!
Kind of like “reset reloaded”, or style/scripting frameworks.
Seriously, how the blue blazes did Meyer become a name in this industry? To be frank, I have never seen so much misinformation and piss poor coding advice from any other source. People are dumber for having read anything he’s done! Honestly he’s as much to blame for broken bloated websites and people coming to sites like this one asking “why” as WYSIWYG editors!
There are no drawbacks to using unitless line-heights only benefits.
Jason and I had a long discussion about this in this thread and despite Jason’s best attempts he could provide no proof that there were any drawbacks or bugs at all. The only drawback is that people don’t understand how unitless line heights differ from line-heights with units.
When you use a unitless line-height you pass a “scaling factor” to the child so if the child has a smaller font-size then it automatically gets a line-height to suit its new font-size. On the other hand when you use ems or % then the line height that gets passed down to the child is a fixed pixel unit. For example if the line-height is 1.5em and the font size of a parent is say 20px the line-height will be 30px. Now if you have nested element with a font-size of 10px the line height will still be 30px and look silly. If you used unitless line-heights then the parents line-height would still be 30px but the childs line-height would inherit the “scaling factor” of 1.5 and thus the line-height for the child would be 15px. A perfect match for the parent and the child. No drawback’s at all and I have yet to see proof of any bugs although I don’t doubt there are still a few bugs around as with nearly every property.
I’m surprised Jason didn’t know about the old Opera bug which is where the 100.1% body height comes in. Opera would get it wrong when 100% was used but not if 100.1% was used.
Apart from the links to two screencaps of sites that were broken because of it… apart from most every site that uses it ending up with overlapping lines on my laptop…
But sure, no bugs at all.
Opera 6? To be honest I really didn’t give a flying fig about how Opera handled websites until version 7… actually to be fair I really didn’t “care” until 8.5 – Prior to that it made IE 5 look good.
That would be because of bad design and nothing to do with unitless line-height as such.
Lines don’t overlap because you use unitless line-height they overlap because the line height is too small the same as if you give a small line-height in pixels. Nothing you have said or provided proves that there is a problem with unitless line-height although perhaps it does show that people don’t understand how to use it (which of course may be a drawback). There well may be odd bugs and situations where things go awry but the same can be said for most other properties as I mentioned before and is not a reason to discount using them. I was quite prepared to accept that there was a problem but after our recent discussion it has only enforced my belief that there is nothing wrong as the process stood up to all your tests.
Opera 6? To be honest I really didn’t give a flying fig about how Opera handled websites until version 7… actually to be fair I really didn’t “care” until 8.5 – Prior to that it made IE 5 look good.
I only meant as an Opera fan I thought you would have encountered that bug. I remember it well and indeed is one of the things that put me off Opera from the start (and the fact that it mimicked ie’s broken box model in quirks mode). I agree that from about 8.5 Opera did improve a lot.
