[fran.ha]

(Original post by jismith1989)
Actually, if you're just making a simple personal page, a plain old table -- even though it's no longer "the done thing" -- for layout can be simpler than adding class tags to divs and writing unnecessary lines of CSS to make it look as it should, so I don't think it's such a great crime, so long as you're aware that you're straying from the specification (after all, some of the most creative and efficient solutions inevitably break rules; I think it's wrong to say that there's a "wrong way"). The advantages that mfaxford outlines are all valid, but are really negligible for the average neo-Geocities site, as the OP seems to be creating, and may well be outweighed by the extra typing involved (and therefore slightly greater file size, which itself affects loading speed). That said, it probably is good, as a neophyte, to get into the habit of delegating presentation to CSS, but once you understand the orthodoxy, there's no need to be too dogmatic about it.

Simpler but wrong, not guaranteed to work, outdated. It's most definitely the wrong way to do it. Sorry. Look at any of the professional outlets...

It's wrong because it's no longer endorsed or considered correct by the bodies that control how web scripting is run and looked after in the future. That makes it wrong.

[Fallen]

(Original post by fran.ha)
Yeah that's fine. Sorry it's just a bit of a pet hate. I understand you're a programmer in other capacities but it gives people the impression that HTML&CSS are programming languages by saying you're a programmer, when in fact they're scripting languages.

They are not scripting languages at all... in fact scripting languages (such as PHP) are programming languages which can often be used to perform very complex and useful tasks.

HTML is simply a markup language, and while there is no real standard term for CSS, it is typically called a Style Sheet Language.

[faber niger]

(Original post by fran.ha)
Simpler but wrong, not guaranteed to work, outdated. It's most definitely the wrong way to do it. Sorry. Look at any of the professional outlets...

It's wrong because it's no longer endorsed or considered correct by the bodies that control how web scripting is run and looked after in the future. That makes it wrong.

Yes, I know that. However, when you consider that most, or at least very many, of the sites on the internet don't conform strictly to standards (I mean, you can get away with not including a doctype, for example; you're not "supposed" to, but it'll render perfectly well on virtually all browsers in use without one, so there are lots of sites out there that don't have one, and it doesn't seem to harm them), it's hardly the case that future browsers are going to interpret so strictly as to make all of those sites obsolete. Browsers have to ensure backward compatibility, so yes, you may be a dinosaur, but it's unlikely to cause many problems and, I insist, you won't be "wrong" (perhaps eccentric, but not wrong).

I agree that following the W3C standards is probably a good thing, but if a rough fix works for your purposes in almost all cases, is it a big deal if you use it? I don't think so. Languages, even programming/mark-up languages, evolve just as much from how they're in fact used as from central diktat (and standards only evolve once there's use, not before -- e.g. Microsoft introduced XMLHttpRequest support into IE, allowing for asynchronous communication and AJAX, and only then were standards written up, after sites were already online utilizing it); for example, if no one bothers to use the new header and footer tags, do you think they'll still be in HTML6?

[estel]

(Original post by jismith1989)
Sure, I'm not saying that it's the best way, just that it may still be a simple option that offers decent presentation across most browsers (and, unless you do a lot of work to create a properly responsive site, the same presentation issues you mention in mobile browsers can, and do, occur even when following HTML5/4 standards). I'm aware that that's heresy though. And, as I say, it's best to know the rules, if you're going to break them.

Also, even HTML5 isn't entirely semantic; the b tag is still supported and widely used, for example (even though the specification may prefer us to use silly tags like mark and strong, and then bugger about reinventing the wheel by having to set the font-weight of the tag ourselves in CSS).

The b and i tags are very specifically semantic in meaning: http://www.w3.org/International/ques...-b-and-i-tags/
As, indeed, are em and strong: http://html5doctor.com/i-b-em-strong-element/

[faber niger]

(Original post by estel)
The b and i tags are very specifically semantic in meaning: http://www.w3.org/International/ques...-b-and-i-tags/
As, indeed, are em and strong: http://html5doctor.com/i-b-em-strong-element/

Right, they're intended to be. That doesn't mean that they generally are in the minds of those who use them (which in any language, even a computationally compiled one that's a little stricter than natural language, is surely what counts); I certainly continue to use the b tag purely presentationally, despite that now being thoughtcrime, since I think that the advantage of ease (in not having to turn to a CSS file just to get a bloody bold font-weight) outweighs the disadvantage of breaking down the Berlin Wall separating presentation and content. And, really, what kind of brainless browser would render the b tag as anything but bold? But I sense that I'm probably getting needlessly "meta-" here.

Personally, whilst CSS obviously performs an invaluable function, I don't think that it's necessarily a good thing for HTML to be purely and entirely semantic (especially since it creates more potentially machine-readable information that in fact isn't read at all, and isn't likely to be -- what need, for example, is there for a separate header tag, and is that need so great that it's really worth further cluttering things up with these extra purely semantic tags?).

[Fallen]

(Original post by jismith1989)
Right, they're intended to be. That doesn't mean that they generally are in the minds of those who use them (which in any language, even a computationally compiled one that's a little stricter than natural language, is surely what counts); I certainly continue to use the b tag purely presentationally, despite that now being thoughtcrime, since I think that the advantage of ease (in not having to turn to a CSS file just to get a bloody bold font-weight) outweighs the disadvantage of breaking down the Berlin Wall separating presentation and content. And, really, what kind of brainless browser would render the b tag as anything but bold? But I sense that I'm probably getting needlessly "meta-" here.Personally, whilst CSS obviously performs an invaluable function, I don't think that it's necessarily a good thing for HTML to be purely and entirely semantic (especially since it creates more potentially machine-readable information that in fact isn't read at all, and isn't likely to be -- what need, for example, is there for a separate header tag, and is that need so great that it's really worth further cluttering things up with these extra purely semantic tags?).

You seem to separate the b tag from CSS, and I don't know why. The only reason you can use b without providing CSS is that you rely on the browsers default style sheet, which you can equally do with the more semantic strong tag. The default for b is the same as the default for strong, which is emboldening the text.