Forum Moderators: open
HTML4.01/XHTML1 Transitional: for making the transition from HTML3.2, they allow HTML3.2's presentational elements and attributes.
HTML4.01/XHTML1 Strict: for people who've made the transition to CSS, they disallow HTML3.2's presentational bits.
Presentational syntax is seen as a mistake in the development path of HTML, so the idea is to make those old features obsolete so people don't use them in future.
HTML5 only has one version <!DOCTYPE html>. The presentational bits from HTML3.2 and HTML4.01/XHTML1.0 transitional are removed for authors, but browsers are still required to support them.
[edited for clarity]
OTOH CSS is adding more and more features and support is getting better as older browsers die out, so you'll probably want to switch to CSS (and HTML5) at some point anyway, to use new functionality or to get other benefits. But there's no rush.
Anyway CSS really is the answer: it moves presentation out of the (x)html and into a separate (set of) files that control how it looks.
It means your code as a developer doesn't need to be intertwined with what the designer of the site needs to be done.
If well done it actually ultimately would make the two almost completely independent.
E.g. "strict" does not allow the use of "target" in hrefs, to open links in new windows.
Until browsers are sufficiently developed, and the audience/market sufficiently educated w.r.t. their usage, that sort of functionality impediment is enough to prevent me for one from adopting "strict".
Something similar is the matter with the use of objects. Objects do have their uses for structuring code contributions from several developers. But there are simpler ways to structure code, that can be much clearer in appropriate instances.
Code using objects is also slow, because there's a lot of needless code loaded every time.
Yes, objects can easily be reused. But if code doesn't change while reuse is important, you can also build a code generator. You get much faster code that way.
Which is why OOP is never really a waste of time.
I have knocked out apps in a day, with full OOP principles. Then 3 years down the road I find that I need something that does nearly the same thing again...and again.
Code using objects is also slow, because there's a lot of needless code loaded every time.
You separate content from presentation with a CMS or templating system, not with CSS. Presentation is always styling + structure, so why separate these? It just makes things less clear. This whole separating of styling from structure is, in my view, a flawed concept that the W3C has been pushing.
The idea of CSS is not necessarily to separate structure in addition to styling. As the name suggests, it is about styles, not structure per se. Having the style separate to the content and structure is beneficial, as it permits the client to either ignore the suggested styling, or apply an alternative, etc.
I have knocked out apps in a day, with full OOP principles. Then 3 years down the road I find that I need something that does nearly the same thing again...and again.
I still don't get this point. Define "needless code"?
Like I said, OOP is just a way to structure code. It works well in particular instances. But to use it in every single instance is to undeservedly idealize it.
Having the style separate to the content and structure is beneficial, as it permits the client to either ignore the suggested styling, or apply an alternative, etc.
If variations are needed, you might as well do that with server side scripting and simply change the template where the content is put into.
Reality is, that when the looks of a site are redesigned, structure changes as well, not just the CSS. And content usually also. There's no advantage to having separated things.
All this separation of various aspects of a site can sometimes make things clearer. But most of the time, it means that a lot of "looking up" needs to be done. Like, where, in which of the 3 CSS files, did that developer put the class "nothingbox"? Computers are extremely good at looking up. People with a dominant use of the left brain hemisphere do quite well with it (like the academic people in W3C). But it's a drag for more visually or intuitively oriented people, who use their right brain hemispheres more.
Or you do a copy and paste, and adapt the code.
Every line in an app should be typed out, and it's reason for being understood.
I'm sick of seeing c/p'd code, full of garbage dead weight. Variables that are set and never used. Methods that are never called. Etc, etc
The code to make your object universally useable, like all kinds of checks to see if the new developer is using constructor and methods correctly. The code for connecting objects together through inheritance. All this separating up of various functionality.
As for separating functionality, that should be done regardless of whether or not you are programming procedurally or with OOP.
All this separation of various aspects of a site can sometimes make things clearer. But most of the time, it means that a lot of "looking up" needs to be done. Like, where, in which of the 3 CSS files, did that developer put the class "nothingbox"? Computers are extremely good at looking up. People with a dominant use of the left brain hemisphere do quite well with it (like the academic people in W3C). But it's a drag for more visually or intuitively oriented people, who use their right brain hemispheres more.
Really, these arguments are rather weak.
I'd rather look through five well named files, each with a distinct purpose, than one file with 3000 lines of code.
Not to mention when I'm changing the structure of a site, I don't give a damn about it's styling. I don't want to have to mess around with that part of the code, I just want to be in a file, that alters the structure.
When I'm modifying the data retrieval, I don't care how it's displayed, where, what page, or any of that. Why would I want all that code mixed in? It just makes it harder to make changes and easier to introduce errors.