How to Make Square Corners with CSS
An epic journey of compassion and liberty that embodies the semantic markup movement in modern web design in an unprecedented paradigm shift to right angled HTML elements.
Finally! A solution for creating square corners on your website. You've probably read countless tutorials on how to make rounded corners, but a simple, elegant solution for creating square corners has yet to emerge.
Drivl to the rescue! Below is our coveted 84 step process for creating beautiful square corners. Follow our lead and you'll soon be basking in splendid perpendicular glory.
1. Compile Apache 2.24023 with mod_perl, mod_log_forensic, and mod_vhost_alias. Do not compile mod_perl as a DSO and keep apache in a chroot jail. Install Mysql 3.23 using yum, Perl 5.8, and /usr/bin/fortune. Set up load balancing and make sure mysql database connections are pooling properly. rm -f the main page for "ls" (usually stored in /usr/share/man). Create an alias in .bashrc that echos 'the fat man stands alone' every time you CD to a new directory.
2. With a yard stick, measure the approximate width and height of your computer monitor
3. Using a hot pink highlighter, draw a 4x scale outline of your computer monitor on a large sheet of butcher paper
4. Squeeze the drippings from an uncooked 12 oz porterhouse steak onto the butcher paper, smear the steak around until a greasy sheen is clearly visible
5. Place a housecat (latin: felis catus) in the center of the outline, if the cat leaves the boundaries of the monitor, squirt repeatedly with a water bottle (see: overflow: auto)
6. Walk along the edges of the outline and count the number of steps required to make a complete loop
7. Gently stroke the porterhouse-scented kitty
8. Multiply the number of steps taken in step 6 by everyone's favorite irrational algebraic number: 1.61803399 (phi)
9. Using the computed product, plot the approximate height and width of your target div using MS Paint. Export it as a 50 megabyte TIFF file and upload this to your webserver.
10. Open up your HTML file and create four divs: one above your bordered element, one below, and two floated to the side. Use the clearfix CSS hack and autoclear these elements using the :before and :after CSS selectors. (Warning: Not supported in 94.2% of all browsers). Make sure the top and bottom elements are display: block and your doctype is XHTML 1.0 Strict. Using prototype.js, call Element.hide(targetDiv) and Ajax.Request to a PHP script that calls getimagesize() on your previously uploaded TIFF. Apply these dimensions to your target element using $('targetDiv').style.height = 'x';
11. Huff a rag soaked in paint thinner
12 - 83: Once dementia has set in, enjoy a 13 hour parasailing excursion with imaginary cherub-beasts. Relax comfortably on the sands of space and time and sip mango mojitos. Do not listen to the golden pigs, they speak only lies and treachery.
84. When sobriety returns, add the following line to your CSS file:
p { border: 1px solid #000; }
That's it! Square corners are now yours for the taking.*
*Warning, this method may not be compatible with Firefox 1.5 on Windows XP build 902345, Firefox 2, FirePig 9, Pigs on Fire, IE6 with the Google Toolbar, Safari 1.2+, IE7 Build 908234, IE 5+, Netscape 4.8, Camino, Opera, Web TV, and any version of lynx ever made.
32 Comments
Wanna comment? Signup!
That's just typical... They're only quick and easy to use, instantly cross-browser compatible, reliable, intuitive, and make a whole lot more sense than spending an afternoon floating DIVs around a page.
Generic block-level containers? ..Semantic markup my ass
Tables have their problems, but they have their place too.
for marking up most everything else I'll take a div or anyother block element anyday. heck you can make any element block level if you like for example;
h1 { display: block; }
besides it's a lot more forward-maintainable to divorce content from presentation, not to mention that the majority of folks with horribly out of date browsers already know that they have a horribly out of date browser. have you seen usage stats lately? the majority of the web browsing public uses either IE 6+ or FF. IE's problems notwithstanding (and they are well documented and relatively easy to work around or avoid), the problem isn't the browsers anymore it's us folks who code and maintain sites.
- IE's problems notwithstanding (and they are well documented and relatively easy to work around or avoid)
But that's the entire point. You don't need to with tables. None of the leading browsers are fully compliant with css 2.0 standards, so why spend time working out what you can and can't use, what workarounds are needed for which browsers, when table layouts render pretty prefect not only on IE, FF and other PC desktop browsers, but Mac, Palm, PSP, Wii, etc...
I guess it all depends on if you feel like billing your client for another day or two's worth of work while you test all that or finish the project early and have an extended weekend spent in the pub.
- divorce content from presentation
CSS only goes part of the way to that goal, in the same way HTML did. Unless you enforce everyone to use XML/XSLT to generate all the content for their web pages and ban the use of presentation tags like <br/> that statement is never going to be true, even using a CSS div layout.
Yes tables aren't 'proper standards', but when no-ones playing by the full list of rules, a choice between the Netscape/IE days of seperate CSS sheets and fudges versus a table layout I know is going to work on every browser, I'll take the later.
Table layouts DO NOT render correctly on small screens. You shouldn't have to scroll sideways.
By using CSS you save your client money in the future by only requiring new stylesheets (as long as the HTML is truly semantic) and not changing those 15 nested tables you so elegantly crafted.
CSS totally separates content from presentation.
<br /> IS NOT presentation. It is content and denotes a line break. If you are using it for presentation then you are using it in a non semantic fashion.
Tables are infact "proper standards" ... for tabular data, not design. Oh the surprise!!!
As far as not playing by the rules... A crowd jumps off a cliff; Would you?
- You shouldn't have to scroll sideways.
Bad table and CSS layouts both cause this. Do it right and it'll shrink to the content, after that you'll be forced to scroll.
Bad table design however, doesn't deposit one layer on top of another on small screens, making even bad table layout more readable.
- By using CSS you save your client money in the future by only requiring new stylesheets
But you cost them more when developing. Either you have to fudge to work on all browsers, or you sacrifice like as is advised below to what you'll 'support'.
- <br /> IS NOT presentation. It is content and denotes a line break.
A line break already does a decent job of denoting a line break in textual content. BR just enforces a presentation action within HTML markup.. 'Do a line break here'. Oddly, other simliar tags have now all been abandoned B, I, Font....
- As far as not playing by the rules... A crowd jumps off a cliff; Would you?
No, no matter how hard they preach about CSS saving the web.
generally I have my clients sign off on a technical spec that includes supported browsers, if I browser is not on the list I don't bother testing for that browser. we (the client and myself) will arrive at a list of "supported" browsers based on current usage stats as well as an audit of 6-9 months of web server logs (assuming they already have a site...). as a result testing is assumed to be part of the development process.
>>None of the leading browsers are fully compliant with css 2.0 standards, so why spend time working out what you can and can't use, what workarounds are needed for which browsers
I don't, but lots of others out there have and do. a quick check of my favorite blogs or a google search is all I've ever needed to find the answer to a problem. I find that the more css I develop the less I need to research fixes. kind of reminds me of the old days of trying to find which nested table was broken.
Maybe you have a lot of technical customers, but in my experience client's don't care or know anything about cross-browser compatibility, technical specs, server logs, or anything of the kind - they want their site to look perfect all the time, everywhere.
It's naive of course, but that's why they're clients. I don't sit down with my plumber and discuss of how he's going to install my new shower - I don't care - I just want it to work, perfectly, all the time.
And ixulai, there's a difference between 15 nested tables and reasonable use of tables.
A bit like the way there's a difference between a reasonable use of style sheets, and a confused 50-sheet cascading nightmare.
The point is that there's no need to say "shudder" when someone mentions a table - nor is there any need to slavishly adhere to standards as if the entire web will sink beneath the waves if you don't. Standards evolve - surely one shouldn't assume any given version of a standard to define a perfect solution.
The two techniques are not mutually exclusive.
my clients are not technically savvy, it's up to me to educate them, more often than not they appreciate it. if they don't get it they end up working with someone else which is OK by me.
>>they want their site to look perfect all the time, everywhere. It's naive of course, but that's why they're clients.
not only is it naive, it's impossible. furthermore giving a client a promise that it would be so is negligent.
>>I don't sit down with my plumber and discuss of how he's going to install my new shower - I don't care - I just want it to work, perfectly, all the time.
so you allow your plumber to select the shower for you? presonally I, as the consumer, prefer to know up front what the options are so I can make an informed choice.
Also, I don't suggest it would be a good thing to mislead clients about how reliable a given system will be - but I also don't expect them to know, initally, what's possible and what isn't - and I certainly don't suggest involving them in the process of working out the details of delivering a system.
Clients pick things like colour, branding, maybe general layout, certainly content - a bit like the way I choose which shower I want, what colour it is, and which room it goes in - those are my options - I don't know, or need to know how it all works in the backgound.
I've worked for plenty of non-technical clients. I'm not suggesting that I involve them in every detail of development. But when I'm specing things out with a client I want to be sure that we're on the same page. How I arrive at a solution is my problem. It's more like deciding is it going to run on gas or diesel--the actual engine is up to me. I choose CSS because in my experience it's faster up front in terms of development and easier going forward in terms of maintanability. I don't expect my clients to know what CSS means, but they usually appreciate it when I speak to them about it in gerneral terms. They also tend to appreciate it when I site is almost done and we decide at the 11th hour to move page elements and it doesn't blow up our schedule. It used to drive me nuts when I would have to go back and rework a nested table just to move a logo or a nav bar. With css a couple of declaration edits and it's Miller time.
How does one make a mango mojito?
1 1/2 oz Cruzano mango rum
3 oz club soda
4 mint leaves
1 lime wedge
Muddle the mint leaves and lime wedge in the bottom of an old-fashioned glass. Add Cruzan mango rum and club soda as above or adjusted to taste. Add ice cubes, and serve.
Some people like to add sugar syrup, which a classic mojito would have - BUT others just add more mango rum, making this a 'diet mojito' as well as a headsmacker.
That has got to be the best Drivl yet!! LMAO!
(sorry to sound so net-lame)
Serious... I'm sitting in my corner using every ounce of energy to hold in the laughter.
Thanks... I really needed this.
