The points I have been making:
And even your own solution did not use any html5 specific elements which is what I am saying above should be the case. 
Do you know there’s a heck of a lot more to HTML5 than <header> <footer> <section> and <article> ?
Those are the least of HTML5 in my opinion.
and when it’s finished I’ll have a closer look at it for commercial use.
Before that, I’m not going to waste my time with it for the reasons I mentioned earlier. So in the mean time we can just agree to disagree on the merits of using it before it is finalised.
Guys guys, sorry for interrupting, but even from your arguing I learned a lot. So keep doing that 
To get to the point. Yes, I don’t know how I didn’t realized about the un-suportivness of the HTML5 tags in older IE browsers versions. Thanks for reminding me that. So my solution is, if the website’s visitors are going to be tech-savvy and modern, they are most most probably not going to have JS turned off. For that reason I would use a little JS help from modernizr to get my HTML5 tags working. However, if I develop a website for older and more inert people, and especially a website with tens of thousands of hits per day, I wouldn’t risk and layout it with HTML5, in case someone does not have JS enables. So it all comes down to the stats. Who know if HTML5 will be finally implemented in 2020? Why don’t we just start using it today, if it’s logical to do so, like I stated above.
One thing I still can’t quite get it is, how can you add a fixed padding (in this case 20px) if the DIV already has a relative width (in this case %)? I though that’s not possible, so I used one wrapper with particular width in percentage, and then use an inner div just to set the fixed padding. Thanks for providing me an alternative solution.
Post #10 is really helpful. Thanks for that too! Are there any layout tutorials that I can really understand not just how, but why it is done as it is done? Matthewjamestaylor gives some really cool starter layouts, but doesn’t give much explanation of what’s going on. Any other, more modern, layout solutions like that out there? I plan to develop my own set of starter layouts, some with fixed sidebars and flexible main column, while some even 3 column-based. That will help me with fast prototyping when starting new projects.
That’s where we differ. I don’t think it is logical to use html5 yet for the reasons I mentioned before.
If EVER… Even if it were supported, it does so much to set coding practices BACK a decade, there is NO benefit to migrating to it.
The only useful stuff in HTML 5 apart from ONE new form element all has NOTHING to do with markup (specifically CSS3 and the new JS stuff) – which I suspect is why it’s all been thrown under it’s banner; without them the emperor has no clothes.
ok fair enough.
My views are based solely on commercial use and after it’s finalised, or at least very close to finalised, I’ll have a closer look at it. But unless there is some sort of “road to Damascus” type change/improvement in html5 over html4 between now and then, I doubt very much I’ll be rushing to use html5 either. Basically: if it ain’t broken, don’t fix it
I wouldn’t rely on that. In my experience, non-tech-savvy visitors are less likely to have JavaScript turned off, simply because they don’t know how to do that.
Yeah, I was going to say that’s backwards too…
To get to the point. Yes, I don’t know how I didn’t realized about the un-suportivness of the HTML5 tags in older IE browsers versions. Thanks for reminding me that. So my solution is, if the website’s visitors are going to be tech-savvy and modern, they are most most probably not going to have JS turned off. For that reason I would use a little JS help from modernizr to get my HTML5 tags working. However, if I develop a website for older and more inert people, and especially a website with tens of thousands of hits per day, I wouldn’t risk and layout it with HTML5, in case someone does not have JS enables. So it all comes down to the stats. Who know if HTML5 will be finally implemented in 2020? Why don’t we just start using it today, if it’s logical to do so, like I stated above.
That seems like an ok approach to me, It depends on the app / website. Many applications don’t bother supporting non-js enabled browsers at all. You’ll see more of that in the future. I’ve done a u-turn myself on this issue and the web is really moving towards making js a required feature. Like it or lump it.
One thing I still can’t quite get it is, how can you add a fixed padding (in this case 20px) if the DIV already has a relative width (in this case %)? I though that’s not possible, so I used one wrapper with particular width in percentage, and then use an inner div just to set the fixed padding. Thanks for providing me an alternative solution.
Yes, an inner div is the simplest way to work with px/% widths + padding or border because by default the total width of an element is the width + padding + border.
There is a box-sizing property which will allow the padding & border not to add to the total width e.g.
#aside {
-webkit-box-sizing: border-box; /* Safari/Chrome, other WebKit */
-moz-box-sizing: border-box; /* Firefox, other Gecko */
box-sizing: border-box; /* Opera/IE 8+ */
padding: 20px;
width: 25%
}
But, IE6/7 won’t understand that yet, so until they are long gone I’m sticking with an inner div.
Post #10 is really helpful. Thanks for that too! Are there any layout tutorials that I can really understand not just how, but why it is done as it is done? Matthewjamestaylor gives some really cool starter layouts, but doesn’t give much explanation of what’s going on. Any other, more modern, layout solutions like that out there? I plan to develop my own set of starter layouts, some with fixed sidebars and flexible main column, while some even 3 column-based. That will help me with fast prototyping when starting new projects.
It’s a great way to learn. I’ve learnt just from playing with examples and asking questions like you are in this forum.
I also found the book ‘Bulletproof web design’ by Dan Cederholm an excellent beginner -> expert book.
Paul also has some great examples and explanations of layout on his site: http://pmob.co.uk/
All the best,
and is similar to the way I have been saying all along is the way it should be done, without having to use any elements from a currently half baked spec, namely html5…so it appears we are now in agreement on this
Another point:
Why put <!doctype html> on top of a document that doesn’t use any html5 specific elements?
It’s a bit like someone putting just <h1>Hello World…!!!</h1> inside a <body> and saying, “hey, look at my shiny new html5 code” 
Another point:
Why put <!doctype html> on top of a document that doesn’t use any html5 specific elements?
It’s easier to type and has no ill effect.
The difference between you and me is that I just don’t care about stuff that doesn’t matter.
I don’t bother typing the doc. type at all. It’s already at the top of my xhtml Strict document template.
That’s where we actually agree because I don’t care about html5 atm 
Other than making validation pointless/meaningless given 5’s structural rules that are so loose, a LA hooker looks like a nun by comparison.
Those users who disable JavaScript do so for a reason, such as disability, or have no control over the issue if e.g. they are using a business computer and company policy prevents the use of JavaScript. When these folk (1-2% of your visitors) reach your site, they’re not going to suddenly start employing JavaScript for your convenience - they’re going to go to another site. On top of the 1-2% of potential customers you’ve just lost there, you risk losing their friends and relations, too. Not because they’re going to say “Hey, example.com is a lousy site - it doesn’t work without JavaScript”, but because if they find your competitor’s site useful and accessible, they will say, “I use competitor.com and I’d recommend it if you want such-and-such.” Now, if you’re happy sending all that business to your competitors, by all means continue with your “JavaScript required” approach, but if not, then I suggest you have a rethink.
In the UK, it is a requirement that businesses provide equal access to services (not necessarily equal experience) for disabled people. I believe Australian law is similar. If your site is inaccessible to a disabled user, you could find yourself open to prosecution. In my experience, most disabled folk are too busy getting on with life to bother suing: they simply go elsewhere. But are you - or your clients - really prepared to take that risk?
I’ve always firmly been in the camp of making everything gracefully degrade without js.
such as disability
I don’t actually know if this is true for most people with a disability, There’s plently of js out there written to increase accessibility.
or have no control over the issue if e.g. they are using a business computer and company policy prevents the use of JavaScript
I’m not sure this is very prominent either, if it still is an issue I think it will become less and less of one in the future.
In the UK, it is a requirement that businesses provide equal access to services (not necessarily equal experience) for disabled people. I believe Australian law is similar. If your site is inaccessible to a disabled user, you could find yourself open to prosecution. In my experience, most disabled folk are too busy getting on with life to bother suing: they simply go elsewhere. But are you - or your clients - really prepared to take that risk?
Yes, in Australia there are anti-discrimination laws. I guess I just need to understand the case that makes all people with a disability have to use sites without javascript. To me, they are completely separate issues.
When these folk (1-2% of your visitors) reach your site, they’re not going to suddenly start employing JavaScript for your convenience - they’re going to go to another site. On top of the 1-2% of potential customers you’ve just lost there, you risk losing their friends and relations, too. Not because they’re going to say “Hey, example.com is a lousy site - it doesn’t work without JavaScript”, but because if they find your competitor’s site useful and accessible, they will say, “I use competitor.com and I’d recommend it if you want such-and-such.” Now, if you’re happy sending all that business to your competitors, by all means continue with your “JavaScript required” approach, but if not, then I suggest you have a rethink.
Now you’re talking about business value. For me and the types of applications I write it’s making less and less business sense to continue to support non-js enabled browsers. js makes some things far easier to build, a better experience for the users and happier clients. That sounds like a good sense in business to me.
obviously then, your clients are different to mine.
I haven’t had a client yet who was happy to lose any potential visitors/shoppers, with or without javascript, to their website.
There is a principle which is a bar against all information, which cannot fail to keep a man in everlasting ignorance — that principle is contempt prior to investigation.
All I can do is suggest you follow some industry leaders and Get Real about solving problems that matter.
@paul_irish @brucel @nimbuin @keithclarkcouk @thecssninja @leaverou
you’re entitled to your opinion, so we can agree to disagree
I don’t agree to that.