Yeah, I meant header -- I don't use it so I rarely remember which one it's called. It's stupid/pointless either way. Ok, found the page you were ACTUALLY referring to (I'm assuming): http://thenashvillewebdesigner.com/demos/demo04-allsemantic.php BODY is unreliable cross browser for restricting width, you're getting needlessly complex in the CSS from using FAR more elements than you need, the only reason you need ANY of those wrappers is for presentation not semantics. You've got no media targets on your STYLE or LINK, no TYPE on your LINK, vertical-break characters doing border's job, some paragraphs for what should probably be part of the heading, the steaming pile of ASIDE (I'll cover that in a moment), nonsensical/gibberish/unnavigable use of headings thanks to HTML 5's new ****tard rules for using them, paragraphs around non-flow paragraph content, garbage redundant and pointless use of the TITLE attribute, inclusion of attributes (like TARGET) that have ZERO MALFING BUSINESS ON ANY WEBSITE WRITTEN AFTER 1997!... and unless in framesets had zero business being used before that either, hence WHY it was deprecated in STRICT! Don't strip choice away from the user! Much less the lack of actually using the CODE tag inside your PRE. That's just a minor nitpick... Just joshing you. It also appears to me that you are using HEADING, SECTION and FOOTER to cover up for not grasping why you'd have a wrapping DIV in the first place -- PARTICULARLY since you are applying style with them, NOT meaning. Don't even want to think about the headach of turning that mess responsive. Of course, the lack of the double wrapper around the main content column means you can't do a PROPER semi-fluid fully adjustable elastic layout... which is why your sidebar is completely broken here in three browsers (Opera, Chrome and Safari) For all that, it's not BAD -- certainly far better than anything I'm used to seeing out of the HTML 5 crowd -- but is it any better than a DIV based layout?!? Not really. If anything the HTML 5 pissing on the semantics and accessibility makes it not worth the dozen or so bytes you MAY have saved. (Not that with all those "extra wrappers for nothing" I'm convinced you saved a blasted thing!) I mean, how is it a serious improvement on, for example, my EWI website: http://www.ewiusb.com Yes, it's DIV and class heavy -- but those DIV exist JUST for presentational/non-semantic reasons. I don't want nor would I use semantic tags to do ANY of that -- because they are NOT there for that reason. They are hooks to which I apply layout, and that's IT... and layout is NOT meaning, it's presentation. Hence why the concept of a sidebar in something like 'aside' has NO MALFING BUSINESS in the markup -- since it might not even be PRESENTED as a sidebar in all media targets! Is it still 'aside' when it's not even a separate column on mobile thanks to your media queries? The only meaning of aside that would make any sense for a semantic tag would be a literary aside, where a character breaks the fourth wall talking to the audience. (Think Ferris Beuller ... a more direct version of a soliloquy.) -- rendering the tag so useless it might as well be ADDRESS. Any other use of it, and well... to be brutally frank, what makes "aside" for sidebars any different than using the CENTER tag? The answer? NOTHING! I think there's a philisophical difference in building sites some people never grasp -- and that's the content FIRST, layout SECOND approach. If I was writing the same page as your demo, I would first have taken the content, or a reasonable facsimile, and marked it up semantically with ZERO concern for layout... Doing so it becomes readily apparent why those extra tags are pointless crap if you bother using numbered headings properly. <h1> Semantic Layout </h1> <ul id="mainMenu"> <li><a href="#">Link 1</a></li> <li><a href="#">Link 2</a></li> <li><a href="#">Link 3</a></li> <li>Element used: LI</li> </ul> <h2>Main content</h2> <p> The main content is an article element. The aside used for the sidebar and the article element are nested within a section. Depending on the content of the page, it may be more semantic to nest sections rather than use an article element. </p><p> Interestingly, if you are viewing this page in Firefox or IE10, you will see a box shadow around the whole content. That is actually applied to the body element in the CSS. Unfortunately, Chrome does not render it. </p><p> So, how much code is on this page? Hardly any. The structural elements within the body are just the few lines below: </p> <pre><code>Insert Final Markup Here</code></pre> <p> So close as to make no never-mind! </p><p> Here is all the CSS I have used on this page: </p> <pre><code>Insert Final CSS Here</code></pre> <p> While it is true that this page looks pretty plain, a wide variety of designs can grow out of this simple base. Perhaps someday I will pretty up a version to show how these simple elements can bear the weight of an intricate design. Even serving up faux columns for the main content and sidebar area would be quite straightforward, but I have not bothered to do that here. </p> <h2>Extra Content</h2> <p> One point of this exercise is that coders frequently use elements unnecessarily. </p><p> We imagine that the only way to center a page is to wrap everything in a containing div—but it's actually not true... although you may have to a couple extra tricks for older versions of Internet Explorer. BUT because the code is well-structured, older versions will still get something usable, even if the page looks different. That's more than can be said for coding by trickery a lot of the time. </p> <hr /> <div><!-- using a div as this is not a content paragraph --> This demo courtesy of <a href="#">someone</a>, <a href="#">somewhere/a> </div> Code (markup): The ONLY legitimate reason from a usability and professional writing standpoint standpoint to add more markup to that is for presentational hooks, NOT semantics... That only leaves the data-scraping ***tards as the audience for those tags, a group most people actively try to FIGHT so you don't end up having content stolen/easily duplicated/extracted. (not that not using those tags would stop them, but why make it easier for them?). Again, it's the same garbage as that microformats idiocy from a few years ago. Particularly once you start using responsive layout and media targets, and those 'sections' may no longer even be separate... or could be re-organized... or your sidebar is no longer a sidebar because the screen is too narrow... or your sidebar gets split into multiple sidebars to better use the screen space... In other words, ZERO legitimate benefits from HEADING, NAV, FOOTER, SECTION, ARTICLE, and more than anything else, the idiotic halfwit PRESENTATIONAL ASIDE. Or as I've come to call ASIDE, "CENTER 2.0"
Actually, I forgot one legitimate reason for using those tags -- the whole "Let's make this as needlessly complex as possible" thing that's really popular right now, hence all the idiotic crap like jQuery, LESS, SASS, Blueprint, Bootstrap, OOCSS, etc, etc... HTML 5 fits in just great with that garbage.
See, we're fundamentally disagreed on what semantic code looks like. You think semantic code means having a bunch of intrinsically unsemantic elements in your code, and you style those. I believe semantic code means you only have semantic elements in your code, and you style those. FWIW, I've never used that layout on a live site, as I haven't done enough testing. I see now what you're talking about with Chrome (couldn't really care less about Opera anymore; at this point, the only people using it are devs checking their sites, frankly), and it has nothing to do with the HTML. Apparently Chrome doesn't compute percentages on padding properly. That's not very difficult to fix. I frankly have NO idea what you're talking about when you say it would be a nightmare to make responsive. It already is responsive; just needs media queries to let the sidebar know when to tuck underneath when things are getting too squished. Frankly, making page structure per se responsive is pretty easy. It's images that complicate things more than anything.
The thing is, those extra allegedly semantic elements you are adding for NOTHING are redundant -- how is that making things any better? It's already divided into obvious sections thanks to the use of headings and HR, why would you add more tags for NOTHING. Wrapping more semantics (SECTION, NAV, HEADER, FOOTER) around already semantic elements (H1..H6, P, PRE, CODE, LABEL, UL, OL) is NOT good semantics or good coding, it's just redundant crap. Having multiple tags for redundancies is better than a single easy to remember tag how exactly?!? Hell, that's WHY the real HTML 4 deprecated MENU and DIR as redundant to UL, ISINDEX was dumped for INPUT, STRIKE and S were redundant to DEL (which shockingly most devs STILL don't seem to realize even exists), APPLET was dumped as redundant to OBJECT ... and why EMBED wasn't officially adopted. Now not only are they introducing pointless redundant structural tags, MENU is back for *** knows what in forms, EMBED is official and they added the idiotically redundant AUDIO and VIDEO tags (instead of riding Microsoft's ass about their idiotic implementation of OBJECT)... and these are improvements HOW EXACTLY?!? Hell, even IMG was on the chopping block for the original HTML 5, before that was dropped like a sack of wet trout for the pointless garbage the WhatTFWG came up with. ... and those of us who find all the things it does out of box actually far, far more useful than the pathetic attempts at replicating the functionality with 'extensions'. Opera is my primary browser for a LOT of reasons -- obeying the system metric so I'm not digging through settings when I change the OS settings, rocker navigation, portrait mode tabs, an actually USEFUL notes (that you can cut/paste to/from as a glorified clipboard organizer), password manager, in-built mail client, favicon launchers, custom user buttons, trash can for tabs, turbo for crappy connections, in-built USER.CSS and USER.JS, pre-defined accessibility .js to override crappy layouts, an actually USEFUL zoom, etc, etc... Which of course is why Opera 15 can go plow itself, as it seems to have NONE of these things. I was hoping for Opera around the Blink engine, NOT the pathetically useless crippleware known as Chrome with the Opera logo slapped on it. (Seriously, Opera 15 is a shamefully bad release, and even 16 "next" and 17 dailies seem to be doing jack to address this) You have no double-wrapper, so you're stuck with either non-elastic inaccessible broken crap, or trying to use garbage hacks 'holy grail' style... or a fixed width layout. Worse you're declaring widths and padding on the same element, which is pretty much shooting yourself in the foot which is why it's broken here in IE too. (Large font/120dpi user checking in). Particulary with % padding based on font-size and % width based on width of the parent, you've shot yourself in the foot and made it too fragile for practical deployment. That's why you double wrap the content, set the outer wrapper to float and width:100%, pad or margin one side of the content to make room for the sidebar, then float the sidebar the same direction as the outer wrapper (which should be it's sibling) and use a negative margin to slide it over. % widths with opposite direction floats, particularly when mixed with padding, is unreliable broken rubbish -- always has been, and there's unlikely to be anything to change that so long as padding % and width % are not based on the same numbers! -- edit -- NOT entirely true. "box-sizing" from CSS3 letting you make elements use the 'broken' IE quirks mode box model (border-box) instead of the standards one (content-box) would do what you are trying to do -- but that's heavy duty 'draft' land and not real world deployable yet... sad since it was proposed for 2.1 and rough implementation began back on pre-FF gecko, IE8 and Opera 7. -- end edit -- Re-arranging the menu so those vertical breaks don't look like arse would be a start to the issues, the header dropping down next to the menu for *** knows what reason, the footer gaining oddball behaviors below certain widths thanks to FOOTER being a ridiculously flaky element layout-wise (sometimes it's as bad in FF as LI are in IE8 or comments are in IE7- and FF 13-) Repeatedly I've found the HTML 5 elements actually interfere with making a responsive layout! (I have this funny quirk of not badmouthing something until after I've tried it REPEATEDLY) Good trick for that? img {max-width:98%;} Works wonders. OH noes, it gets a forced resize to the screen size once you go single column, not that! Similarly, keep word-wrap:break-word; in mind when you have misbehaving text elements -- Wonderful old "Microsoft proprietary" property dating back to IE 5.5 that was FINALLY adopted into CSS3 -- though that's CSS3 in a nutshell, replicating all the cool stuff IE 5.5 could do, just doing it it's own way or claiming to have come up with it since anything M$ is "evil". Nothing like "new" CSS3 properties that works all the way back to IE 5.x, right webfonts?
First, let me say that it's a nice looking site, and the use of divs is not much different than I've done in the past. But let's be serious. You ask how my example page is a serious improvement on that (and of course I presume you mean, semantically). Really? Here again is the entire structural code (and by "structural code," I mean the tags that would be there if we removed the content) for the whole page: <body> <header></header> <nav></nav> <section> <article></article> <aside></aside> </section> <footer></footer> </body> Code (markup): That's it. In comparison, underneath your navigation, you start off with four levels of divs before even hitting any content whatsoever. And even after that, we get one h2 and then immediately two more div tags? Naw. You have a mountain of unsemantic tags cluttering up the HTML precisely for presentational purposes.
Tell me, what IE are you using? As I note very clearly, this is a "workshop," not a production page. I have zero shims or conditional commented CSS for older IE. It's a no-brainer that older versions of IE are going to require a bit of attention if you want to support them for a production site. I'm certainly not going to waste my time doing that on a page like this. What I *can* tell you is that I can zoom to 200% in IE10 and break absolutely nothing. There's no trick at all. Specifying percentages is easy. But specifying max-width doesn't mean mobile phones aren't downloading your big file. Perhaps I shouldn't have called that "responsive" so much as "responsibly responsive." (And yes, I have solutions for that too, but it's still more involved than keeping the structure itself intact.)
... and how would you implement that WITHOUT those extra DIV? Even using those allegedly structural 5 tags to do what I'm doing there for layout I'd STILL need the extra DIV to reliably have 100% min-height, semi-fluid elastic layout, RELIABLE content-first elastic columns (something yours will NEVER do without an extra DIV), reliable float containing... Much less your example is unfair because you have no real content, meaning you'd want an ID on NAV in case you had other NAV (If you're going to use it how the spec says), a ID on FOOTER and HEADER since ARTICLE is supposed to have those :/ , etc, etc... If I was to gut mine down to your 'example' style, but accounting for FULL layout elements <body> <div#wrapper> <h1></h1> <ul#mainMenu></ul> <div#columnWrapper> <div#contentWrapper><div#content> <div#subSection> <h2></h2> <div#subSectionContent> <p></p> </div> </div> </div></div> <div id="extras"> <div#subSection> <h2></h2> <div#subSectionContent> <p></p> </div> </div> <div#subSection> <h2></h2> <div#subSectionContent> <p></p> </div> </div> <div#subSection> <h2></h2> <div#subSectionContent> <p></p> </div> </div> </div> </div> </div> <div id="footer"></div> </body> Code (markup): Of course, #columnWrapper is only really there to wrap both columns height-wise not just for easier float clearing, but to force some proper behavior in the media queries thanks to Safari iOS being a ***tard, and to make legacy IE behave properly with the 100% min-height layout. ... something else not having a wrapping DIV can't do. Good luck putting your FOOTER tag AFTER </body>, much less that for min-height body has to be height:100% so you can do the margin ride-up. Of course, to drag yours kicking and screaming into what I'm doing for layout it's gonna gain a few div -- or are you going to abuse section for that? Much less for a true apples to apples it would help to show the H1 and UL equivalents (and even WITH NAV you should still have a UL -- even the 5 spec agrees with that BTW as evident in their examples -- kind of like how the idiotic ***Tard PLACEHOLDER is NOT a replacement for LABEL?) alongside adding ID's since you might actually want to *shock* use article more than once inside your content (as you yourself said), have multiple subsections, etc, etc... <body> <div#wrapper> <header#pageHeader> <h1></h1> </header> <nav> <ul#mainMenu></ul> </nav> <div#columnWrapper> <div#contentWrapper><section#content> <article> <h1></h1> <div#subSectionContent> <p></p> </div> </article> </section></div> <section#extras"> <article> <h1></h1> <div#subSectionContent> <p></p> </div> </article> <article> <h1></h1> <div#subSectionContent> <p></p> </div> </article> <article> <h1></h1> <div#subSectionContent> <p></p> </div> </article> </div> </div> </div> <footer#pagefooter></footer> </body> Code (markup): That's about all HTML 5 would 'offer' for improvement if you were attempting to do the same exact layout -- net chnage ZERO. That's why those extra tags don't do jack **** of value! You'd still put ID on them since ARTICLE can/should have it's own HEADER and FOOTER (all part of pissing on numbered headings use/meanings), pissing on accessibility by making every heading a top-level heading (***tard bs that probably came from the SEO scam artists), etc, etc... IT's why that page and your example aren't a good apples to apples compare. Gimme a few and I'll toss up a 1:1 equivalent of how I'd do the same page.
Just in case we've not threadjacked enough (hope the OP doesn't mind - it's good to hear both sides of this argument) IE10, forced to 100% zoom so it doesn't dick with images, set to 20px instead of 16px default so it behaves like a 120dpi system SHOULD. (as opposed to it's 'normal' behavior of turning the system metric into zoom -- one of the things that has pissed me off IE8+, NOT that I use 8 regularly, I just don't understand why they pissed on it's accessibility with 8/newer -- probably related to why JAWS doesn't like it either) While I wouldn't call it a waste of time, but then I design with that in mind for pretty much everything I write. Following some simple rules and avoiding some common pitfalls isn't more work once you get used to it. Resetting 10 to it's default behavior here, and it breaks at 120% or more. (big shock) -- you talking win7 or 8? (no joke, they act different -- kind of like FF on Winblows vs. Quack vs. Linsux) If the file is big enough for that to be a concern, and it's not the ONLY content (as in downloading direct instead of being in a IMG tag) -- then the website is trash. Admittedly I know I'm in the minority on this opinion with the absolute dipshit "has no **** business on a website" javascripted asshattery like sliding animated banners and their ilk -- but really if that's a concern, ... besides given the half a meg or more of ***Tard scripts people sleaze onto their sites, one or two big images should be a non-issue with most mobiles having at least half a gig of RAM, with an unencoded 1600x1200 32 bit image (only five times the upper pixel limit I'd allow on anything in a IMG tag) coming to only 7.6 megabytes is this REALLY a problem? (especially since anything that big should be encoded) -- that's one of those time-wasters I see people fretting over when generally speaking anyone that gives a hoot in hell about it would probably have images blocked anyways! (I know I do when using my mobile plan!)
Hey, why isn't your box-shadow showing? Oh wait, box-shadow doesn't work on BODY -- inset or out! Another strike against sizing with body -- a LOT of my layouts end up having to have an extra DIV of 100% min-height wrapping so I can add a inset box-shadow. Pisses me off, but again body is NOT a valid target for box-shadow. Though good news, you don't have to say -moz anymore... and the only reason to say -webkit is for Safari. When Google split off Blink from Webkit, they followed mozilla's suit and said "**** vendor prefixes".... and there was much rejoicing.
... and here's how I'd write that same thing without 5 for a better comparison -- though it's column layout is rock solid, it has media queries, hover states and anchors, etc, etc... We're mostly talking markup, not style. http://www.cutcodedown.com/for_others/timGallant/simpleLayout/template.html Which 'stripped' is: <body> <div#pageWrapper> <h1></h1> <ul#mainMenu></ul> <div#contentWrapper><div#content></div></div> <div#extras</div> <hr /> <div#footer></div> </div> </body> Code (markup): Though again you have that same H1... I just don't waste time wrapping it in some stupid extra HEADER tag and bother using logical heading orders in the rest of the document instead of the halfwit "H1 everywhere" In any case those DIV are only in there as hooks for the presentation without applying semantics. I see no reason to use allegedly semantic tags in place of DIV there... apart from adding elements you don't need (HEADER and NAV), or that are just redundant (HEADER, SECTION, ARTICLE, FOOTER) ... sad part is it took ten times as long writing it's new content and testing across browsers than it did slapping such a simple layout together; though really that's the point either way.
deathshadow, as I noted right on the page, Webkit doesn't apply box-shadow to body. Firefox and IE10 do. That's a big reason why I probably wouldn't do this workshop 100% in real life. Most of my designs I want a box shadow around the container. As for claims about me needing a whole bunch more hooks. Not many. I would not need to put an ID on the nav, for instance. A lot of the key to writing clean HTML is using the CSS cascade and leaving the markup clean. It's easy to offer different rules to header nav and footer nav, for example (or whatever). I'll also admit that I don't often worry about equal height columns (overused, in my opinion), but when I do, it's a no-brainer to it faux (and even easier now, with CSS3's multiple background images and CSS gradients). The bottom line is that a lot of bloated HTML is due to not making full use of CSS. So you brought it up—let's take your present EWI page for an example. At this stage of my understanding of HTML5 semantics, I would probably code it something like this: <header> </header> <section class="main"> (Main content) </section> <section class="main"> (So where do I get one? area) </section> <section class="sidebar"> <nav> </nav> <nav> </nav> <nav> </nav> </section> <section class="sidebar"> <aside> </aside> <aside> </aside> </section> <footer> </footer> Code (markup): I'm not saying that's the ultimate semantic way; I might change a couple details if I further studied the purpose of various elements of your page. And admittedly, this is not as tidy as my much simpler page, but still reasonable. Eleven total tags (including nesting). As far as hooks, I may be missing something, but as far as I can tell, the only thing I'm uncertain I would be able to achieve without extra containers is your doubled border on your boxes and at the same time having both inner and outer shadows. I'll admit I haven't figured out a way to do that. (I've managed 3 out of 4, but not four. Not saying there's not a way, but I haven't found it yet.) I'm not afraid of adding IDs, but as far as I can see they're not all that necessary apart from the fact that I see you're supporting anchors with them for screenreaders (kudos to you for that). Now, of course, there's an important qualification. I would need more than the above markup if I thought it was important that pre-HTML5-compliant browsers had identical rendering to modern browsers, but I don't. My view is that IE8 should be fully usable and have an attractive rendering. Anything earlier just needs to be served the content, period. The other thing for me is that working this way keeps the HTML manageable, and if your HTML is manageable, your CSS is also more manageable. It's a lot easier to see what's what than if you have a whole bunch of wrappers all over the place. What I've found since I've started using HTML5 is that I have to comment my code a lot less frequently. It's a lot easier to see what that closing tag belongs to; no need to comment it.
This is practically becoming a chat session. I got distracted with the shadows and borders on your boxes, and in my playing around just realized the way to create a vignette around the body. Very cool.
Your code in that last post I'm not really following -- but then I don't tend to make layout code until AFTER I have semantic code; I'm unable to figure out what parts of content would go in which of your HTML 5 tags. How would you do the 100% min-height for the footer given that APO is unreliable off the bottom? You need a master wrapper as a SIBLING to the footer to ride it up OVER. (just as you would pad the bottom of your column wrapper to make room for it) -- that's why I added DIV AFTER semantics. Let's just concentrate on one small section, an average .subsection from either column.... When I wrote the semantics of the content, I ended up with: <h2>Subsection</h2> <img src="images/test.png" alt="test image" class="trailingPlate" /> <p> Just a test trailing image plate and some simple content. </p> Code (markup): As that's ALL the semantics it needs. The H2 says it's a subsection, anything after it is related content. By the time it gets styling I added the DIV into it: <div class="subSection"> <h2>Subsection</h2> <div class="subSectionContent"> <img src="images/test.png" alt="test image" class="trailingPlate" /> <p> Just a test trailing image plate and some simple content. </p> <!-- .subSectionContent --></div> <!-- .subSection --></div> Code (markup): The outer DIV for putting a border, box-shadow and background on it, the inner DIV for the inset box-shadow on the content (so it's top actually lines up with the bottom of the h2 instead of going under it!). NEITHER exists for semantic reasons, I just added them as needed style hooks I could not apply to either. I could buy using SECTION for the outer one, but how about DIV.subSectionContent? It's JUST there for style, otherwise it serves no legitimate purpose. IF you used SECTION both would need classes, (unless you are 100% sure the content won't have SECTIONS either)... I would hesitate to call it an ARTICLE since this format is used for multiple content areas (relegating ARTICLE to the same functionality as CODE inside PRE); but here's the kicker -- EITHER WAY, you need all those block-level containers to apply the style I'm applying, regardless of what tag is being used! You'll find that across the entire page -- you could swap SOME tags, but to achieve that same appearance you're gonna use the same number of block level containers, there are no extras that could be condensed onto others style-wise. That's why we HAVE DIV and SPAN -- semantically neutral containers for the application of style, in which you group the existing semantic tags. You use them once you've exhausted the existing semantic tags. Which is why as a rule of thumb I HATE seeing UL wrapped in DIV#menu when nothing is being done that couldn't be applied to the UL itself... which seems to be the REAL reason for NAV to exist, since again the reason they use in the specification is redundant to heading navigation if anyone bothered understanding how to use numbered headings. But of course, that's why they shrugged their shoulders, said "eh, whatever" and loosened the structural rules to let you sleaze out nothing but H1 any old way. Of course, without extra wrappers I also fail to see how you would make the columns reliably. Again, opposed floats are unreliable BS -- how would you stop the first two sections from stacking -- or worse the latter smaller column sections from not stacking across the bottom if the content is short? (though in a way, that might be cool...). You are going to need AT LEAST two more DIV (or section, though section of sections seems really stupid when they're kin-level by heading) - one around the first two sections, the rest around the latter -- to even come CLOSE to a reliable columnar content-first layout cross-browser. Oh, and the accesskeys menu isn't just for screenreaders -- it's also for Opera... or was. Not so much anymore with Opera 15 pissing away all the accessibility aids that were one of the main reasons to use Opera as opposed to anything else. Open in Opera 12, hit shift-esc.... and marvel at the glory. (heck, try it on these forums!) Like everything else that made Opera's UI a million times more useful than pathetically crippled trips in the wayback machine to Mosaic's user interface like Safari and Chrome, it's just plain GONE in 15+... since Opera 15+ is just Chrome with a Opera logo slapped on it. I know, I know... let it go... wait, then what the *** am I supposed to use? Five years from now still trying to use Opera 12 since even with extensions NOTHING even comes CLOSE to being as useful!?!
I take it back. Figured out how to create double borders and outer and inner box shadows without a containing element.
It's amazing what can be done layering box-shadows over each-other. You can use border for a center (and pre-css3), and non-blurred inset and outset to add two or three or even a dozen more inner and outer ones.
Just had to throw up that demo. That was fun: http://thenashvillewebdesigner.com/demos/demo05-bordersandshadows.php
I generally don't use generated content for the outer shadow because it only works as 'fixed' to the layout -- it won't scroll with it. THAT takes an extra wrapper set to 100% min-height around everything with setting HTML and BODY to height:100%; -- usually handy anyways though since if you're already making a 100% min-height layout you'd need that extra DIV anyways. One big thing I'm noticing is you have a second generated content on your 'section' -- you don't need to do that as you can stack all those values on the single SECTION (or in my case DIV) tag. The stack order is LIFO -- last in, first out in terms of the painters stack. section { position:relative; margin:20px 0; padding:50px 40px; background:#CFC6BA; border:3px solid #000; border-radius:50px; box-shadow: inset 0 0 15px #000, 0 0 25px #000, 0 0 0 3px #FFF; } Code (markup): Would be functionally identical to what you did with the generated content... Though I'm wondering if you really meant for the larger shadow to go over the 3px one. Try switching the order of the two outset box-shadows to see what I mean. First one you call ends up on 'top' of the latter ones. You can stack box-shadow values as a comma delimited list to... well, I don't know how many times actually. I've never hit up against any limit. Couple other things: When it's zero you don't need to say 'of what'; zero is zero. It's also 'bad form' to use lower case for HEX values, as that implies BASE 64. So you're aware no browser obeys any box-shadow value greater than 256px -- and did you REALLY mean to declare border twice? http://www.cutcodedown.com/for_others/timGallant/multiborders/template.html Is my own approach to the same problem -- since so far as I'm concerned in this case the H1, P, PRE, CODE and HR provide ALL the semantics a page like this needs... and I wouldn't even use a P on the footer since it's not flow content, it's incidental text. But then I use the LITERARY meaning of paragraph, NOT the typographical one. (which is why you'll see Gary "kk5st" Turner and I going around in circles over putting a lone IMG tag in a P -- which I'd never do as what the *** makes a image a paragraph?) I'm also going to take this to PM -- I've got some questions about some rather... questionable choices in your demonstration.css
By the way, deathshadow's "fun" page works better than tim's (performance-wise). For some reason, tim's slows down my computer.
Yeah, I realized later that I could have done everything without generated content. I thought I could, but being late I forgot how I needed to specify the order and the widths. xtmx, which specific page are you referring to, and what do you mean? What browser/OS are you viewing with?
Oh, forgot to note: I very well understand that 0 is 0. But some browsers a few years back didn't like it if you mixed a specified unit with plain old 0 in the same declaration. I suspect it's long been a non-issue, but I still do it out of habit.