For those of you who have been working with CSS for quite some time, this is no news at all, however for the newbies and those with little inclination or interest to learn the various ins and outs of CSS, here's a "tool" that will make your life easier. It's called the YUI Reset CSS brought to you by Yahoo! http://developer.yahoo.com/yui/reset/ I promise, if you take care of your HTML, this will solve most of the problems associated with cross-browser CSS related issues. Enjoy!
Ah yes, that stupid nonsense again. I love how it's completely broken in IE/Opera with large fonts/120dpi on because they are STILL convinced everyone is only running 96 dpi... pretty much making their entire font.css moot... how the 'reset' only resets elements to the same if you want them at the 'default' - making it useless if you don't want the default appearance... pretty much making the entire base.css worthless... and forget not all that wasted code in reset.css resetting elements that frankly you should a> not be setting all the same, and B> should be setting manually in your own code in the first place. (see all that font-size bull on the various headers) Of course, given the total shit that Yahoo churns out for code, going to them for coding advice, ESPECIALLY when it comes to CSS... well, it's a bit like taking your fuel injected car in for service at a 1950's lawnmower repair shop. What a bunch of rubbish.
Hi deathshadow, "they" = me. I'm Nate Koechley. I'm the author of Yahoo!'s YUI CSS Foundation. I would appreciate your help and input if you're interested. It sounds like you have some good stuff to contribute. In particular, I'd like to know in what way "it's completely broken in IE/Opera with large fonts/120dpi?" I'm not aware of what's broken. In fact I put significant effort into those two specific situations, so I'm actually quite curious what your experience is. (I don't mean to take this thread off-topic, but your post was pretty short on specifics.) At the tactical level the best way for us to collaborate is with bug reports, test cases, and feature requests via our publicly read/writable tracker on Sourceforge: http://sourceforge.net/tracker/?func=add&group_id=165715&atid=836476 Discussion is vibrant on the public mailing list -- http://tech.groups.yahoo.com/group/ydn-javascript/ -- where you can find the entire YUI team active. About Reset.css I'll say just one thing: The purpose is not that you "want the default appearance," but rather that implementers want a dependable, consistent, normalized foundation upon which to build safely and predictably. For instance, without Reset.css in place the margins of H2 elements vary slightly between browsers and platforms. If an implementer sets h2 {margin-bottom:20%;} the computed/rendered value would vary across browser. With Reset.css's normalization applied upstream of implementation-specific CSS, 20% will be identical across browser. So the purpose is to provide a stable foundation, not to enforce a particular visualization. Finally, I'll risk a short reply to your bait, your "given the total shit that Yahoo churns out for code" bit While it's certainly true that there are significant sections of our vast global network that don't reflect our best practices, I challenge you to look at our good stuff. YUI's Menu control is the most accessible that I'm aware of, and is built with semantic markup, advanced WAI-ARIA support, and a progressive-enhancement approach that makes it useful from Lynx, to Netscape 4, to Firefox 3, and everything in between, with or without JS or CSS. That's pretty good in my book. One might retort that Menu is library code and not live Yahoo code "in the wild". My reply: Yahoo! Search's results page is semantically sound: take a look at this example, build with semantic markup, CSS, unobtrusive JavaScript, and effective accessibility accommodations: http://search.yahoo.com/search;_ylt=A0oGkwmAFDFHFzcAGgGl87UF?p=Web%20Standards%20and%20The%20New%20Professionalism&ei=utf-8&iscqry=&fr=sfp Like most, we're not perfect. But I believe that an honest, open-minded, and unbiased review of our modern work will leave all but the most demanding pleasantly surprised. Here are a few places to look: http://local.yahoo.com/ http://pets.yahoo.com/ http://eurosport.yahoo.com/ http://widgets.yahoo.com/ http://www.kelkoo.co.uk/ http://tech.yahoo.com/pc/1991465629,1991474228,1994767591,1994701827?full=yes#ytprodspecdiv http://uk.tv.yahoo.com/ Me taking your bait aside, I'm primarily interested in your help with the YUI CSS Foundation that I author. Thanks, Nate Nate Koechley natek a/t yahoo-inc d/ot com YUI Team, Yahoo! Inc.
Then why set everything to defaults on elements the end user for any layout should probably be setting themselves in the first place? Sure... where is it? - you certainly didn't link to any. I'll try to be constructive - but the pages you linked to as examples of good are... well, look like examples of script kiddies gone wild. Let's take that search page for example: Inlined CSS - waste of bandwidth across multiple pages. Being a SEARCH the moment someone goes to a second page, that's 30 or so lines of code that could have been cached. empty script tag in the header. Nonsensical indenting and formatting. If you're not going to include proper formatting, don't include ANY formatting and save the bandwidth - don't just add tabs for no apparant reason - and don't give me that 'oh, that's because it's the formatting for the CGI' rubbish - after thirty years of coding I know that's a load of malarkey. inlined hack CSS that likely isn't even needed - ALL of it presentational. onload on the body init method... endless overblown case of classitus and unneccessary wrappers on a layout that doesn't need about 80% of the HTML used. Hordes of javascripting DHTML data that should likely just be inlined as regular HTML THEN manipulated. Hey look, content after HTML is closed and 96 validation errors. 37k of HTML for 3.7k of actual content - there's no excuse for that whole page to take more than 10k (good thing you are serving it packed) - on TOP of the inlined script you've also got 90k of javascript that from where I'm sitting seems to add little functionality. You've got a 154k page that from what I'm seeing in functionality should be 30k... MAYBE 50k TOPS. It's an EXCELLENT example of what I mean by 'vomiting up code' as it seems to be overburdened with scripting on the 'isn't it cool' factor instead of enhancing the browsing experience. It looks like the type of DHTML script kiddie nonsense I'd expect to find on Dynamic Drive - Not the code I'd expect people claiming to be promoting web standards and giving advice on site design to deploy. The only good thing I can say is at least it only uses two images under 6k total, making excellent use of sliding an image around in the CSS. Let's try Local.yahoo.com - hey, is that second box below the area with the H1 supposed to be greyed out like that with no indication of how/why? Let's see if that's an opera specific bug and try FF and IE - ooh look, three different browsers, three radically different page layouts! Oh yeah, THAT's efficient/desirable. Hey, 43 Validation errors - Let's take a look at the source: Again, inlined CSS... Here's a great indicator of making something too complex for it's own damned good: http://l.yimg.com/us.yimg.com/lib/ls/css2/yls-combo-home_200712181800.css If you don't know what's wrong there, back away from the keyboard please. I realize that's probably a result of load balancing across servers - at which point you are probably introducing more overhead than if you just served it directly. Body - unique to the page - if you need BOTH and ID and a Class, you are probably doing something wrong. Cryptic class names - if you are working with multiple coders naming everything gibberish abbreviations is just asking for people to toss even MORE classes on there. Again, if you are holding up: <body id="yls-hm" class="yls-gl-bd"> <div id="yls-gl-pg"> <div id="doc" class="yui-t7"> <div id="ygma"> <div id="ygmacx"> <div id="ygmatop"> <ul id="ygnav"> Code (markup): as an example of good coding, /FAIL/ hard. REALLY hard... and this is based on a framework you are trying to promote for beginners? What, beginners that have been knee deep in bash scripting and esoteric illegible C++ for a decade or more? Fixed width non-adaptive layout, no major complicated stylings, and yet it's nested five div's deep before the top inlined menu even shows up... Classitus at it's worst on what should be a relatively simple page. Of course if more time was spent actually optimizing the pages you'd not need to waste time putting all that ajax and javascript 'loading' nonsense in there, because it would load fast enough NOT TO NEED IT. Wow, look at this - two javascripts that could be combined into one, and a noscript of content AFTER the HTML is closed... and that wonderful comment. I could go on and on about ALL of those sites you linked to - they are all EXTREMELY poorly coded, and it shows. That's what graceful degredation and semantic markup is for... and sometime you have to say 'look, we can't continue to support full functionality/appearance on a decade old pre-web standards pre-css browser anymore'. If you are still worrying about Nyetscape 4, then you truly are still stuck in 1997 as I don't think ANYONE else gives a flying fig anymore about it... (you're using a 286? Don't make me laugh, your windows boots up in what, a day and a half?) - given that NS4 users would now be 0.00000000001% of the browsing public, I think it's safe to say "Get a browser made in THIS millenium" - I wouldn't expect anyone to still molly-coddle a NS4 user anymore than I'd expect your site to render fully functional with graphics via Telnet on my Trash-80 model 4P. (I say, I say, that's a joke son.) As to my advice on the foundations - don't use them. Instead of trying to reset everything to a baseline that doesn't actually FIX any of the REAL problems cross browser (Firefox background jog, IE 3 pixel jog, IE double margins, etc, etc) anyone writing a page should learn those problems then write clean minimalist semantic markup, then bend it to their will via CSS. Frankly, all that font nonsense is exactly that - nonsense. In Opera it prevents one of the major points of using %/em from even working (which I consider 'broken' as a matter of principal), adjusting to the system metric... while in IE it still enlarges breaking layouts written that assume you're % to px conversions are always going to be true. Here on my machine (which runs 120dpi/large fonts, AND under linux has X11 set to 100dpi instead of 75) guess what - all the text is STILL 25% larger in IE... (and KHTML under Ubuntu...) - to which I say GOOD. Yahoo in general fails MISERABLY on usability BECAUSE the fonts don't adjust to the system metric in my browser of choice, AND is designed to use fonts well below the '12px' minimum that I am personally comfortable with... All combines into another reason the only thing I use Y! for is a throwaway e-mail. When I have to dive for the zoom control and enlarge 20-50% just to get the text usable, I'll go somewhere else. Pretty much the only 'foundation' you need to work cross browser WELL is to understand what %/em is, that an OS system metric can change their meaning, understand what haslayout is, and use a valid doctype and one of the simpler reset methods... hell, for 99.99% of the pages I write the ONLY 'reset' I need is: * { margin:0; padding:0; } and I'm getting to the point where I'm finding it easier to style forms WITH that reset than without. Once you understand that IE on inputs treats line-height as height, and that fieldsets SUCK (so don't use them for styling) - end of problem. Really, the only 'reset and baseline' I need or would suggest to anyone is: * { margin:0; padding:0; } img { border:0; } body { text-align:center; /* remove for full width fluid */ } #container { /* remove next three lines for full fluid width */ width:768px; text-align:left; margin:0 auto; } Code (markup): with the matching default template: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <link type="text/css" rel="stylesheet" href="screen.css" media="screen,projection" /> <title>Template</title> </head><body> <div id="container"> </div> </body></html> Code (markup): Anything more than that as a starting point - well, would make a good half hour show of Penn and Teller. I'm going to download the entire YUI to review it properly, I'll post that review here... Hey, did you know the redirect to sourceforge doesn't work in Firefox?
html{color:#000;background:#FFF;} Because NOBODY would actually set those in their design. body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,form,fieldset,legend,input,textarea,p,blockquote,th,td{margin:0;padding:0;} I can KIND of accept the idea of this, but frankly it's too much code - AND you are targeting ul, ol, li, inputs AND fieldsets - elements people SPECIFICALLY have problems with when reset. At that point just use the bloody universal. table{border-collapse:collapse;border-spacing:0;} given the problems styling all sides of TD's, and that this means little or no styling allowed on TR's, this makes styling tables a pain in the ass UNLESS you are doing this JUST so you can use tables for layout. While I'm not a anti-table nazi like some folks, wasting the time setting this on all pages is just, well... fieldset,img{border:0;} Ok, THIS I agree with. address,caption,cite,code,dfn,em,strong,th,var{font-style:normal;font-weight:normal;} Oh yes, overriding the default behaviors of EM, STRONG and table headers is SO desirable. There's NOTHING inconsistant cross-browser about these that I've ever seen, and when it IS an issue I'd probably be setting the full font line (condensed) ANYWAYS. li{list-style:none;} On ALL LI? First, I'd probably set that on UL, not LI, second I wouldn't set it on all - only as needed. caption,th { text-align:left;} Just... why? h1,h2,h3,h4,h5,h6{font-size:100%;font-weight:normal;} Again, WHY? This one makes even LESS sense. NOTHING wrong with the default sizes, and if the coder CARES that they be a size other than default, I guarantee they won't be setting all of them to 100% - just plain waste of code. Of course THEN you set them AGAIN in base.css - and most of the examples call both files - BRILLIANT. q:before,q:after{content:'';} again, not a bad idea - that's a keeper when using shortquotes - which is what, once every hundred pages? Good to know how to do - NOT something I'd include as a starting point. abbr,acronym {border:0;font-variant:normal;} Again - WHY? /* to preserve line-height and selector appearance */ sup {vertical-align:text-top;} sub {vertical-align:text-bottom;} Cute, but me, I just specify a line-height that's tall enough in the first place... actually reminds me, nowhere do I see line-heights explicitly declared... being the specification says 'anywhere from 1.1 to 1.2' and that gecko seems to determine line height almost at random... input,textarea,select{font-family:inherit;font-size:inherit;font-weight:inherit;} I would suggest instead of actually explicitly declaring them at a smaller size than the nearby text and setting the line-height the same as the font-size of the local text - but that's why I don't have problems doing a universal reset. /*because legend doesn't inherit in IE */ legend{color:#000;} and setting it to black is different from default how exactly? Reset, reset-fonts, reset-fonts-grid - these are all different from each-other HOW exactly? Of course, the lions share of the YUI kit is javascripts - 7 MEGS of javascripts. Let's take a quick look at what should be a simple one - the animation... Multi-timer, object heavy, chews cpu like crazy (sorry, but when it chews up 10% cpu when running of a Q6600, that's fat .js) all for a library that frankly, shouldn't even need more than 8-10k of code to implement. The most complex thing is the curved paths, and that can be 'faked' easier than the complex spline being used there. (velocity next point faking - appears almost identical, uses simpler math) - and I'm not 100% sure, but it looks like it has problems handling more than one item animated at once. THEN you have the really ugly stuff - like that fat bloated calendar rubbish - NOT ONLY should that sort of thing REALLY be generated client side - but it's 80k as the condensed 'minimal' - for something that if you got rid of the bloated objects, USED the existing DOM tree and generated via innerHTML could probably be done with comments for less than 30k. Though at least this javascript is a step up from the half-assed attempts are stealing other people's code and malifing up the simplest of functionality you see from the likes of dynamic drive. Going to bed now - If I have time tomorrow I'll keep going.
I'm on the bedside laptop with insomnia (go figure) - I was taking a look at the grid builder when my 'real' problem with these types of frameworks occurred to me. The approach is backwards from what I consider the golden rule of site building - markup first. Instead of writing minimalist markup that's clean and easy to read, we are talking about slapping in presentational classes to try and shoehorn existing CSS into the layout we want. The grid builder is a great example of this - set it for 160px sidebar, two columns in the content area, 750px width, and you get this jumble of code: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>YUI Base Page</title> <link rel="stylesheet" href="http://yui.yahooapis.com/2.4.1/build/reset-fonts-grids/reset-fonts-grids.css" type="text/css"> </head> <body> <div id="doc" class="yui-t1"> <div id="hd"><h1>YUI: CSS Grid Builder</h1></div> <div id="bd"> <div id="yui-main"> <div class="yui-b"><div class="yui-g"> <div class="yui-u first"> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas sit amet metus. Nunc quam elit, posuere nec, auctor in, rhoncus quis, dui. Aliquam erat volutpat. Ut dignissim, massa sit amet dignissim cursus, quam lacus feugiat. </div> <div class="yui-u"> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas sit amet metus. Nunc quam elit, posuere nec, auctor in, rhoncus quis, dui. Aliquam erat volutpat. Ut dignissim, massa sit amet dignissim cursus, quam lacus feugiat. </div> </div> </div> </div> <div class="yui-b">Navigation Pane</div> </div> <div id="ft">Footer is here.</div> </div> </body> </html> Code (markup): coming in at 1,145 bytes... Cryptic classnames which if you can decipher appear to be presentational in nature - indentation of code that is borderline non-existant and where it does exist, makes no sense. If this is supposed to help a developer make a page some comments, at least for example purposes to show where in this jumbled mess the more 'major' sections open and close would go a long ways towards being 'useful' instead of a tinkertoy. I mean, I have to ask - do you guys HAVE a style guide? Maybe it's the two decades of Wirth style languages being my bread and butter -Maybe it was my early programming days having a nun rack me on the knuckles with the metal edge of a ruler screaming "INDENT" and "DEINDENT" in my ear... but DAMN. Especially since that DIV around the H1 serves no purpose, (rarely does in any layout), the BD and yui-main div's aren't doing anything useful, and I think you have a class that's completely unneeded in the form of first (though that could be useful for future stylings) Seriously, it would go a LONG ways towards my taking your 'framework' more seriously if you cleaned up the output to something like this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head> <title>Simplified Grid Example</title> <link rel="stylesheet" href="screen.css" type="text/css" media="screen, projection" /> </head><body> <div id="container"> <h1>Grid Builder? NOT.</h1> <div id="contentWrapper"><div id="content"> <div class="halfwidth"> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas sit amet metus. Nunc quam elit, posuere nec, auctor in, rhoncus quis, dui. Aliquam erat volutpat. Ut dignissim, massa sit amet dignissim cursus, quam lacus feugiat. </div> <div class="halfwidth"> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas sit amet metus. Nunc quam elit, posuere nec, auctor in, rhoncus quis, dui. Aliquam erat volutpat. Ut dignissim, massa sit amet dignissim cursus, quam lacus feugiat. </div> <!-- #content, #contentWrapper --></div></div> <div class="sideBar"> Navigation Pane </div> <div id="footer">Footer is here.</div> <!-- #container --></div> </body></html> Code (markup): and instead of shoe-horning the wrong CSS into working had it generate clean CSS for the layout. The laugh is that this is all the HTML that layout needs, but is about the same filesize WITH the full formatting (about four times the tabs and carriage returns), verbose classnames, AND comments explaining the longer 'stretches'. (honestly, #contentWrapper isn't NECESSARY on fixed width - I include it because I usually code dynamic) Oh, and apologies for the multiposts, but I was hitting up against the post length limits... and don't take my comments TOO personally - I have the same criticisms of my own code from two years ago... and two years ago I had this opinion of my own code from four years ago... and four years ago... you get the idea (going back three decades now)
Hey again, Thanks for all that. Some good stuff. Just a short note now to let you know that I'm drafting a reply, and though I need to leave the house for most of the midday I'll get back to you this evening. In the meantime, we're hiring, do you want a job? Thanks, Nate
You wouldn't be able to control him. Trust me (and for the record, deathshadow and I are pretty much on the same page when it comes to this stuff).
Depends - as Dan's aware I make a bad line coder, as I'm more of a project leader - For example if I was brought in, my first act would be demanding that in the background we would be recoding EVERY page for a complete relaunch of EVERYTHING inside a year. Semantic markup, minimal markup, with a STYLE GUIDE. There is NO reason for HTML to not validate - with the exception of flash embeds (I'll look the other way on those), and only a handful of acceptable reasons for CSS not to. (zoom for haslayout, hacking for FF 1px jog, -moz properties for CSS2 properties gecko STILL doesn't support or the occasional odd CSS3 everyone else does, IE filters... and... uhm, I think that's it) I also am a New Englander - we are NOT, a friendly people. I was taught that in business when you think something sucks, you come right out and tell someone it sucks - no matter who they are... and to HELL with people's feelings. It's called business after all not 'back slapping fanboy fun'. Usually this results in your namby pamby west coast limp wristed tofu loving millivegan John Tesh fan eurotrash metrosexual wannabes getting their panties in a twist every time I open my mouth, just because I didn't give them a smile and a pat on the back. Hmm. Maybe Dan's right It's why I RAN my own company (I'm technically retired) instead of being just another drone. I just take on the odd web design job now and again for extra pocket change. (and I don't come cheap either)
Oops, past the edit limit. My bad, that should say 'server side'. Ok, continuing through the YUI library, let's talk about the menu object - first off, what's with all the bloated objects? User objects in javascript generally are twice as slow as objects already in the DOM, and a a ****load more code than needed - all because it's a piss poor clone of the piss poor object model from C++. (again, I'm a Wirth programmer - Dr. Nick got it right with Modula, everything since has been either a cheap copy or just plain rubbish) - second, one look at the HTML in the basic example shows a CLASSIC case of classitus. <div id="basicmenu" class="yuimenu"> <div class="bd"> <ul class="first-of-type"> <li class="yuimenuitem"> <a class="yuimenuitemlabel" href="http://mail.yahoo.com"> Yahoo! Mail </a> </li> <li class="yuimenuitem"> <a class="yuimenuitemlabel" href="http://addressbook.yahoo.com"> Yahoo! Address Book </a> </li> <li class="yuimenuitem"> <a class="yuimenuitemlabel" href="http://calendar.yahoo.com"> Yahoo! Calendar </a> </li> <li class="yuimenuitem"> <a class="yuimenuitemlabel" href="http://notepad.yahoo.com"> Yahoo! Notepad </a> </li> </ul> </div> </div> Code (markup): Two div's around the the topmost UL I assume are for the shadows (here's a hint though, shadows both left and right don't look right!) in which case you only need ONE of them. You've got a perfctly good class around the anchors on the LI, so the anchors DO NOT NEED A CLASS... you've got a perfectly good class on the UL, so the LI DO NOT NEED A CLASS, you've got a perfectly good class on the wrapping DIV, so the UL do NOT NEED A CLASS... Shall I go on? <div class="psnMenu"> <ul> <li> <a href="http://mail.yahoo.com"> Yahoo! Mail </a> </li><li> <a href="http://addressbook.yahoo.com"> Yahoo! Address Book </a> </li><li> <a href="http://calendar.yahoo.com"> Yahoo! Calendar </a> </li><li> <a href="http://notepad.yahoo.com"> Yahoo! Notepad </a> </li> </ul> </div> Code (markup): Should be ALL the code that is needed for that menu. (you might still want the ID for absolute positioning as per the example)... It's half the code and can be functionally identical. The classitus is so bad on a lot of these pages I'd half suspect crap like Dreamweaver being involved somewhere here. in the CSS, you just change: ".first-of-type" to ".psnMenu ul" ".yuimenuitem" to ".psnMenu li" ".yuimenuitemlabel" to ".psnMenu a" There is NO REASON to have all those subclasses. Complete and total waste of code - in the HTML, an item that does NOT hit the cache as often as the CSS does. The extra div can be lost, I'd hang the right shadow on the remaining DIV, the bottom shadow on the UL and lose the left shadow (which makes no sense) - THEORETICALLY we could reduce it even further by losing the div and hanging the bottom shadow on the last LI by giving it a class (.last sounds good) - could even give it rounded corners by adding the bottom to the UL, the sides to the .li, a negative margin on .last, and adding a class to .first... hell with a little care and planning you could likely axe the DIV AND uniquely style ALL of them - and do it from a single image to boot! - classes are good for UNIQUE stylings - if you are using the same class ten times in a row with no variation, and it's the only element type under the parent tag - you shouldn't be hanging a class on everything in the first place. oh, and some word separators - camelbacks or underscores would go a LONG ways towards cleaning things up. I've recently switched to camelbacks (from underscores) because it's the method used in javascript variable names (making things consistant across all my code) and does not involve extra characters. That the next example is pure .js menu - the pinnacle of accessability failures... well... Not good. Instead of having that I'd probably have a section advising people NOT to use javascript for menus, and instead to take the time to use a SSI/CGI/SGC/PaFNA like Perl, PHP, ASP or even SHTML, even if it's just enough of it to do <?php include('headers/header.inc.php'); ?> or <!--#include virtual="headers/header.inc.html" --> since a purely javascripted menu is ALWAYS a miserable /FAIL/
The day I met D was the day I admired his intelligence (IM IN LOVE "AHEM" I MEAN he helped me fixed my problems in CSS) and if your the same as D then welcome to my LOVE BOAT my friend D's the man cause he has high class when it comes to CSS. Give me a decade maybe 2 and I will be the one speaking like him OK P.S MERRRY CHRISTMAS EVERYONE. AFTER CHRISTMAS, PLEASE BE SOBER WHEN YOU COME TO THE FORUM OK HAHAHA CHEERS
Heh, I've known deathshadow for about 5 years now. We actually have a lot in common, save for the fact that I tend to be more diplomatic. But I can be just as ruthless when I feel I have to be.
Its getting better by the day, I just realized that your user name first name starts with a 'D' and that Ive been calling deathshadow "D". I will start naming every ones name correctly from now on in respect to your user name. CHEERS
Interesting find. There are so many potential issues for problems though...that it seems viable that it won't be able to solve them all. I'll look at using it in the future though.