Deprecated Elements
Hey Everybody,
I just wanted to open a discussion about depriciated elements in the html specification. I'm concerned that many of us might find serious trouble with our old pages when/if browsers ever decide to stop supporting those elements that have been deemed out of date by the w3c. First of all does anyone know where a complete list of depriciated elements can be found? I know they're listed in the specification but it would be nice to see a list of ONLY the depriciated ones, my brain might register it better. It just seems to me that HTML is being turned int CSS. If elements continue to be depricated and the browsers ever stop supporting them then HTML will be a fairly useless specification without the use of CSS, any thoughts/plans of action on this topic would be appreciated.
I just wanted to open a discussion about depriciated elements in the html specification. I'm concerned that many of us might find serious trouble with our old pages when/if browsers ever decide to stop supporting those elements that have been deemed out of date by the w3c. First of all does anyone know where a complete list of depriciated elements can be found? I know they're listed in the specification but it would be nice to see a list of ONLY the depriciated ones, my brain might register it better. It just seems to me that HTML is being turned int CSS. If elements continue to be depricated and the browsers ever stop supporting them then HTML will be a fairly useless specification without the use of CSS, any thoughts/plans of action on this topic would be appreciated.
ASKER
Thanks Jason, that's comforting.
I'm working on a VRML application, it's not so bad.
Expect massive points if you come up with that list :)
I'm working on a VRML application, it's not so bad.
Expect massive points if you come up with that list :)
I'm looking around for some more sources even now...
I liked VRML too, but it never seemed to catch on like people thought it would.
By the way, do you think we should ask community support to change the name to reflect deprecated correctly? Does EE weight the question title more than the responsed for search purposes?
I liked VRML too, but it never seemed to catch on like people thought it would.
By the way, do you think we should ask community support to change the name to reflect deprecated correctly? Does EE weight the question title more than the responsed for search purposes?
ASKER
Yea, probly. Spelling has never been my forte.
Mine either, but thank goodness Google knows how to correct me...
Jesse,
Working draft. I'm open to comments, corrects, suggestions.
http://jasonsinternet.net/deprecated.html
Working draft. I'm open to comments, corrects, suggestions.
http://jasonsinternet.net/deprecated.html
Hi jessegivy,
The W3C has created a number of different specifications for HTML, and for good reason.
Once you stick to a certain specification, e.g. HTML4.01, you're setting the page in stone and should code that page to that specification. Your work won't go out of date, but you must maintain the code to that specification.
Working with the different specifications, you'll come to see what's been dropped or not across the specifications, e.g. comparing XHTML1 Strict and XHTML1 Transitional. If you're working a lot with XHTML, why not start using an IDE that actually treats your HTML as XML and therefore highlight any missing or wrong elements in your markup. Some good IDEs with this in mind include XMLSpy (http://www.altova.com/) and TopStyle (http://www.bradsoft.com/)
Validate your markup often.
For a good site on the changes from HTML4 to XHTML1, check out the W3Schools (http://www.w3schools.com/tags/default.asp)
Hope that helps,
nD
The W3C has created a number of different specifications for HTML, and for good reason.
Once you stick to a certain specification, e.g. HTML4.01, you're setting the page in stone and should code that page to that specification. Your work won't go out of date, but you must maintain the code to that specification.
Working with the different specifications, you'll come to see what's been dropped or not across the specifications, e.g. comparing XHTML1 Strict and XHTML1 Transitional. If you're working a lot with XHTML, why not start using an IDE that actually treats your HTML as XML and therefore highlight any missing or wrong elements in your markup. Some good IDEs with this in mind include XMLSpy (http://www.altova.com/) and TopStyle (http://www.bradsoft.com/)
Validate your markup often.
For a good site on the changes from HTML4 to XHTML1, check out the W3Schools (http://www.w3schools.com/tags/default.asp)
Hope that helps,
nD
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>>blindly implement backward compatibility
I prefer, inclusivity to exclusivity. What's blind about removing elements I've been using for over a decade. While I'm excited about the new, more adaptive spec and presentation tecnology such as CSS XML and XSLT, I don't see why we should move away from some of the old conventions. Believe me when I say that there are some serious uses for things like tables. Is there some kind of conflicty between HTML and CSS? I find that the elements work well with styles and it still seems rather esoteric, the use of padding and other CSS elements.
I prefer, inclusivity to exclusivity. What's blind about removing elements I've been using for over a decade. While I'm excited about the new, more adaptive spec and presentation tecnology such as CSS XML and XSLT, I don't see why we should move away from some of the old conventions. Believe me when I say that there are some serious uses for things like tables. Is there some kind of conflicty between HTML and CSS? I find that the elements work well with styles and it still seems rather esoteric, the use of padding and other CSS elements.
>> Believe me when I say that there are some serious uses for things like tables.<<
Tables are not being deprecated. Tables are for tabular data. Given that 10 years ago there was no other way for layout, the web adopted tables for layout as a hack. Since CSS came along to deal with presentation and layout, we no longer need to hack webpages with tables; instead, we can go back to using tables for tabular data.
"Something that often seems to confuse people that are new to CSS-based layouts is the use of tables. I’ve seen plenty of cases where people interpret “avoid using tables for layout” as “don’t use tables at all”. It’s important to remember that tables are still perfectly fine to use – if used correctly."
- http://www.456bereastreet.com/archive/200410/bring_on_the_tables/
>>Is there some kind of conflicty between HTML and CSS?<<
Only between deprecated HTML and CSS, such as
<p align=justify></p>
(one hundred times in a lenghty page)
instead of:
p{ text-align:justify}
(only once on the styles sheet for the entire site)
Having it in the styles sheet also allows you to change it once for your entire site. So, in a 250 pages site that uses <p align=justify></p> Three thousand times, if you needed to change the alignment it would be a task worth of planning and projecting. On a site with CSS you just go to the styles sheet and change one word:
p{ text-align:left}
Tables are not being deprecated. Tables are for tabular data. Given that 10 years ago there was no other way for layout, the web adopted tables for layout as a hack. Since CSS came along to deal with presentation and layout, we no longer need to hack webpages with tables; instead, we can go back to using tables for tabular data.
"Something that often seems to confuse people that are new to CSS-based layouts is the use of tables. I’ve seen plenty of cases where people interpret “avoid using tables for layout” as “don’t use tables at all”. It’s important to remember that tables are still perfectly fine to use – if used correctly."
- http://www.456bereastreet.com/archive/200410/bring_on_the_tables/
>>Is there some kind of conflicty between HTML and CSS?<<
Only between deprecated HTML and CSS, such as
<p align=justify></p>
(one hundred times in a lenghty page)
instead of:
p{ text-align:justify}
(only once on the styles sheet for the entire site)
Having it in the styles sheet also allows you to change it once for your entire site. So, in a 250 pages site that uses <p align=justify></p> Three thousand times, if you needed to change the alignment it would be a task worth of planning and projecting. On a site with CSS you just go to the styles sheet and change one word:
p{ text-align:left}
> What's blind about removing elements I've been using for over a decade.
Nothing... what i mean when a standard evolves it EITHER must use some kind of deprecation mechanism OR blindly implement backward compatibility. It's much better to use deprecation and keep the specifications consistent.
All the deprecated elements and attributes are very easilly replaceable by their new equivalent.
Also, "HTML 4.0 Transitional" allows all the deprecated elements and attributes, so nothing is completely removed yet.
Nothing... what i mean when a standard evolves it EITHER must use some kind of deprecation mechanism OR blindly implement backward compatibility. It's much better to use deprecation and keep the specifications consistent.
All the deprecated elements and attributes are very easilly replaceable by their new equivalent.
Also, "HTML 4.0 Transitional" allows all the deprecated elements and attributes, so nothing is completely removed yet.
>>"HTML 4.0 Transitional" allows all the deprecated elements and attributes, so nothing is completely removed yet.<<
But they will be in xHTML 2.0. Deprecated elements are already gone in xHTML 1.1 but it is in no way about to become mainstream. But xHTML 2.0 will be the main thing in about 3 years.
But they will be in xHTML 2.0. Deprecated elements are already gone in xHTML 1.1 but it is in no way about to become mainstream. But xHTML 2.0 will be the main thing in about 3 years.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hello all. I'm a web developer just at the beginning of understanding the XHTML and CSS2 specs. A better description would be an IRATE web developer. I apologize in advance for the hijacking...my question at https://www.experts-exchange.com/questions/21734890/Tables-vs-CSS.html would probably be a better place to respond and discuss. In response to Esopo:
>>> Since CSS came along to deal with presentation and layout, we no longer need to hack webpages with tables;
Explain your position, please. I've been having this conversation for almost a week, and have come no closer to understanding how you can possibly rationalize using CSS2 over tables for layout. For the background on my issue, see Q_21734890, and the question that spawned that one.
I commonly hear CSS makes pages smaller. Granted, but that provides no basis for replacing the table elements. Instead of using <div>/<span> elements everywhere and formatting them to ACT as table elements, I can just put my style on the actual table elements and use the constructs EVERYONE knows and can deal with. In my very recent experiences, CSS does not behave, in EITHER FIREFOX OR IE, as implied in the actual recommendation. Given the same style applied, I don't see saving two letters (by using <DIV> instead of <TABLE>) as justifying the pain and anguish of dealing with the issues inherent in CSS.
I also hear CSS is more powerful than tables...more flexible, etc. So far, I find that to be untrue. In the example discussed in my other question, I had a working copy of that page, written using nested tables, that worked in both browsers. My question STARTED because of a common issue with formatting cells lower in the nest...this issue affected only Netscape. The only CSS example I saw that actually worked falls under duplicating the table elements using styles, and that did not work in IE.
If I were laying out a page full of static content and positioned elements, I could very easily see the benefits of using CSS2. However, start working with content where the sizes are not necessarily known ahead of time and things degrade to crap very quickly. Just a simple example:
<body>
<div style="width:80%; border:thin solid #ff0000">
<div style="width:100%; border:thin solid #0000ff">stuff</div></div>
The first div is 80% of the body. The second div will also be 80% of the body, NOT the width of the content. If I were to need a border around just that content, I would have to nest a <span> (or other inline-formatted element) inside with the border. How is that easier? I also can't set a static width because I don't know the width of the content. I can't set a percentage for the same reason. The same issue with tables:
<table><tr><td> </td>
The 1% flub causes the td to size itself only as large as necessary to display the data. The same trick will not work in CSS since CSS will render an actual 1% width and let the text bleed out of it. You can check it with a background-color attribute.
CSS also does not provide a method by which you can align block-level elements horizontally, outside of "display:table-cell". In effect, you would HAVE to duplicate the abilities of the table-related elements to get that kind of structure. What's the point?
I dunno...maybe I'm confusing my apples and guavas. But I have yet to see an example of why CSS2 styles should be used in favor of table elements. Thanks for your patience, and any responses are welcome and eagerly awaited. Now back to your regularly scheduled question...
>>> Since CSS came along to deal with presentation and layout, we no longer need to hack webpages with tables;
Explain your position, please. I've been having this conversation for almost a week, and have come no closer to understanding how you can possibly rationalize using CSS2 over tables for layout. For the background on my issue, see Q_21734890, and the question that spawned that one.
I commonly hear CSS makes pages smaller. Granted, but that provides no basis for replacing the table elements. Instead of using <div>/<span> elements everywhere and formatting them to ACT as table elements, I can just put my style on the actual table elements and use the constructs EVERYONE knows and can deal with. In my very recent experiences, CSS does not behave, in EITHER FIREFOX OR IE, as implied in the actual recommendation. Given the same style applied, I don't see saving two letters (by using <DIV> instead of <TABLE>) as justifying the pain and anguish of dealing with the issues inherent in CSS.
I also hear CSS is more powerful than tables...more flexible, etc. So far, I find that to be untrue. In the example discussed in my other question, I had a working copy of that page, written using nested tables, that worked in both browsers. My question STARTED because of a common issue with formatting cells lower in the nest...this issue affected only Netscape. The only CSS example I saw that actually worked falls under duplicating the table elements using styles, and that did not work in IE.
If I were laying out a page full of static content and positioned elements, I could very easily see the benefits of using CSS2. However, start working with content where the sizes are not necessarily known ahead of time and things degrade to crap very quickly. Just a simple example:
<body>
<div style="width:80%; border:thin solid #ff0000">
<div style="width:100%; border:thin solid #0000ff">stuff</div></div>
The first div is 80% of the body. The second div will also be 80% of the body, NOT the width of the content. If I were to need a border around just that content, I would have to nest a <span> (or other inline-formatted element) inside with the border. How is that easier? I also can't set a static width because I don't know the width of the content. I can't set a percentage for the same reason. The same issue with tables:
<table><tr><td> </td>
The 1% flub causes the td to size itself only as large as necessary to display the data. The same trick will not work in CSS since CSS will render an actual 1% width and let the text bleed out of it. You can check it with a background-color attribute.
CSS also does not provide a method by which you can align block-level elements horizontally, outside of "display:table-cell". In effect, you would HAVE to duplicate the abilities of the table-related elements to get that kind of structure. What's the point?
I dunno...maybe I'm confusing my apples and guavas. But I have yet to see an example of why CSS2 styles should be used in favor of table elements. Thanks for your patience, and any responses are welcome and eagerly awaited. Now back to your regularly scheduled question...
ASKER
Exactly my point routinet, keep up the good fight! I mean sure CSS has a TON of great things to offer, but I think it's just downright STUPID for those geeks at w3c to say, "okay, we've got something better, so let's go ahead and just trash the html specification that people have been working with for twenty years"
@Esopo,
>>Is there some kind of conflicty between HTML and CSS?<<
Only between deprecated HTML and CSS, such as
<p align=justify></p>
(one hundred times in a lenghty page)
instead of:
p{ text-align:justify}
(only once on the styles sheet for the entire site)
This DOES illustrate one of the more exciting and powerful uses of CSS, and the main reason for it's inception. It does NOT however show how there's some conflict between HTML and CSS, will the page with a hundred paragraph tags work? Is it a pain in the ass? Yes, but will it work? Of course it will. My main point is that it seems those making decisions that effect all programmers worldwide are being made too hastily. Just because you come up with a better system doesn't mean that it actually is better for all cases, and even if it is, there's no reason to just trash the old methods of doing things. Obviously with the incresed complexity on the web CSS was begging to be concieved, but for example, if you have a kid that's much more intelligent and better looking than you're other kid, do you just go ahead and shoot the ugly, stupid one in the head?
@Esopo,
>>Is there some kind of conflicty between HTML and CSS?<<
Only between deprecated HTML and CSS, such as
<p align=justify></p>
(one hundred times in a lenghty page)
instead of:
p{ text-align:justify}
(only once on the styles sheet for the entire site)
This DOES illustrate one of the more exciting and powerful uses of CSS, and the main reason for it's inception. It does NOT however show how there's some conflict between HTML and CSS, will the page with a hundred paragraph tags work? Is it a pain in the ass? Yes, but will it work? Of course it will. My main point is that it seems those making decisions that effect all programmers worldwide are being made too hastily. Just because you come up with a better system doesn't mean that it actually is better for all cases, and even if it is, there's no reason to just trash the old methods of doing things. Obviously with the incresed complexity on the web CSS was begging to be concieved, but for example, if you have a kid that's much more intelligent and better looking than you're other kid, do you just go ahead and shoot the ugly, stupid one in the head?
ASKER
...sorry for the rant, I just find HTML very comforting, and it seems like it's going down in flames.
And as far as simplicity goes:
<p align=justify></p>
(one hundred times in a lenghty page)
instead of:
p{ text-align:justify}
Only if you want all paragraphs justified. In reality, most of us will have to have three classes created, left, right, center.
So our pages are still <p class="left"> <p class="right"> <p class="center"> all over the place. CSS doesn't improve over HTML in this (admittedly simple) example.
I do grant that being able to globally specify everything in a single document has made life easier in some cases...
<p align=justify></p>
(one hundred times in a lenghty page)
instead of:
p{ text-align:justify}
Only if you want all paragraphs justified. In reality, most of us will have to have three classes created, left, right, center.
So our pages are still <p class="left"> <p class="right"> <p class="center"> all over the place. CSS doesn't improve over HTML in this (admittedly simple) example.
I do grant that being able to globally specify everything in a single document has made life easier in some cases...
> So our pages are still <p class="left"> <p class="right"> <p class="center"> all over the place.
That proves you still don't understand the concept of content/presentation separation and how CSS selectors should be used.
jessegivy, I guess you should carefully read the specications first... especially the WAI (http://www.w3.org/WAI/)
The specifications for HTML 4.0 and CSS 2 were published in 1998 and the WAI-WCAG were published in 2000... nothing new.
It's just that now, more people seem to be willing to use HTML/CSS properly.
That proves you still don't understand the concept of content/presentation separation and how CSS selectors should be used.
jessegivy, I guess you should carefully read the specications first... especially the WAI (http://www.w3.org/WAI/)
The specifications for HTML 4.0 and CSS 2 were published in 1998 and the WAI-WCAG were published in 2000... nothing new.
It's just that now, more people seem to be willing to use HTML/CSS properly.
>>> That proves you still don't understand the concept of content/presentation separation and how CSS selectors should be used.
You're right, I don't.
You're right, I don't.
Ok, let me try to address everything without extending too much (interesting challenge ;)
First of all:
>>Exactly my point routinet, keep up the good fight!<<
If the fight is supposed to involve me then let me assure you I’m a very peaceful creature. And if the fight is against the standards that dictate where the web is going, then it is quite a moot point.
So, to begin with, no fighting; it serves no purpose.
Routinet,
Your post encapsulates many of the common CSS newbie mistakes. The main one being:
>>Instead of using <div>/<span> elements everywhere and formatting them to ACT as table elements…<<
If it was like that then you would be right, but it is not. Tables were a hack. They mostly work as a grid, a skeleton to hold content. That is not CSS. CSS is about flow. Replacing <table>tags with DIVs and then TR and TD tags with even more DIVs would be worthy of psychological study under the obsessive/compulsive branch.
When thinking layout with CSS don’t think tables, don’t think the web as you know it. Think flow, think water. Picture Bruce Lee and learn from the great master:
“Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot it becomes the teapot. Now, water can flow or it can crash. Be water my friend.”
- Bruce Lee
Here is the thing. Setting aside the debate of whether CSS is a better layout and presentation tool than deprecated HTML (that it by far is), the web is no longer for the 800x600 screen, not even for the 1024x768 screen. On the desktop we are having a boom of panels in all shapes and sizes. A lot of wide screens in laptops as well. But that’s not the half of it. Now every cellphone is being made to browse the web. Every PDA has been able to browse it for the last couple of years. The web is no longer a place for fixed screens, it is now a “cup”, a “bottle” and a “teapot”, and your sites have to deal with that, be “water” for them.
Is it easy? Nope. It takes a while and some of the tools we need are not even here yet (CSS3 has a truck load of important features that are not out yet). The toughest part is resetting your mind from the table skeletons and thinking “flow”. The only thing I miss from tables is the equivalent to CSS: min-width that IE can’t handle without a hack, for everything else CSS is a far better call. But you have to know how to use it. Trying to use a bunch of DIVs as tables is just not going to cut it.
Jessegivy,
>>if you have a kid that's much more intelligent and better looking than you're other kid<<
These are not kids, these are tags. Bad tags to begin with. Transitional is still a valid DTD. Hell, 3.2 is still a valid DTD. If you want to use it, break a leg! But you are missing out on technology. If I see someone cutting down a tree with a pocket knife I may say something, but ultimately it is their choice to cut it down with that pocket knife if they want to.
How is CSS better? The answer is very simple and you learn it at the same time that you learn your technology. I assume that people who don’t see CSS as better simply have no training or outdated training in web technologies.
We can have all the discussions you guys want about CSS and deprecated tags, but nobody can teach you all you need to know to be informed about CSS through discussions.
The premise is simple: HTML Strict and CSS1+2 are the standard. They are better technologies. This is not open for discussion; it is just the way it is. It is not a philosophical thing nor an emotional thing (no sense in missing tags or trying to defend them or mourn them as lost offspring) it is a technical thing. If you want to know why, do your job as a developer and get on with the program.
Learning Strict HTML is a breeze. The easiest thing I ever did that involved something called a language. Yes, eating a donut is easier, but it doesn’t get called a language. CSS is a bit trickier, but is almost as easy. How about the next step, like server side technologies and DBs? I don’t want to be a jerk or point at people with my finger, but if anybody is so hung up on using markup technology that was dropped 10 years ago, how could they ever expect to keep up with serious stuff such as the change from PHP 4.3/4 to PHP5, ASP classic to .Net, etc? I mean, if anybody thinks CSS is a tough bone, they have a big wall coming when they start learning OOP.
And Jason,
>>So our pages are still <p class="left"> <p class="right"> <p class="center"> all over the place.<<
That is exactly the kind of code you are trying to avoid, because as you said it yourself, if you code it like that then it is pretty much the same thing as the deprecated code.
I’ll post an example for you in a minute.
First of all:
>>Exactly my point routinet, keep up the good fight!<<
If the fight is supposed to involve me then let me assure you I’m a very peaceful creature. And if the fight is against the standards that dictate where the web is going, then it is quite a moot point.
So, to begin with, no fighting; it serves no purpose.
Routinet,
Your post encapsulates many of the common CSS newbie mistakes. The main one being:
>>Instead of using <div>/<span> elements everywhere and formatting them to ACT as table elements…<<
If it was like that then you would be right, but it is not. Tables were a hack. They mostly work as a grid, a skeleton to hold content. That is not CSS. CSS is about flow. Replacing <table>tags with DIVs and then TR and TD tags with even more DIVs would be worthy of psychological study under the obsessive/compulsive branch.
When thinking layout with CSS don’t think tables, don’t think the web as you know it. Think flow, think water. Picture Bruce Lee and learn from the great master:
“Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot it becomes the teapot. Now, water can flow or it can crash. Be water my friend.”
- Bruce Lee
Here is the thing. Setting aside the debate of whether CSS is a better layout and presentation tool than deprecated HTML (that it by far is), the web is no longer for the 800x600 screen, not even for the 1024x768 screen. On the desktop we are having a boom of panels in all shapes and sizes. A lot of wide screens in laptops as well. But that’s not the half of it. Now every cellphone is being made to browse the web. Every PDA has been able to browse it for the last couple of years. The web is no longer a place for fixed screens, it is now a “cup”, a “bottle” and a “teapot”, and your sites have to deal with that, be “water” for them.
Is it easy? Nope. It takes a while and some of the tools we need are not even here yet (CSS3 has a truck load of important features that are not out yet). The toughest part is resetting your mind from the table skeletons and thinking “flow”. The only thing I miss from tables is the equivalent to CSS: min-width that IE can’t handle without a hack, for everything else CSS is a far better call. But you have to know how to use it. Trying to use a bunch of DIVs as tables is just not going to cut it.
Jessegivy,
>>if you have a kid that's much more intelligent and better looking than you're other kid<<
These are not kids, these are tags. Bad tags to begin with. Transitional is still a valid DTD. Hell, 3.2 is still a valid DTD. If you want to use it, break a leg! But you are missing out on technology. If I see someone cutting down a tree with a pocket knife I may say something, but ultimately it is their choice to cut it down with that pocket knife if they want to.
How is CSS better? The answer is very simple and you learn it at the same time that you learn your technology. I assume that people who don’t see CSS as better simply have no training or outdated training in web technologies.
We can have all the discussions you guys want about CSS and deprecated tags, but nobody can teach you all you need to know to be informed about CSS through discussions.
The premise is simple: HTML Strict and CSS1+2 are the standard. They are better technologies. This is not open for discussion; it is just the way it is. It is not a philosophical thing nor an emotional thing (no sense in missing tags or trying to defend them or mourn them as lost offspring) it is a technical thing. If you want to know why, do your job as a developer and get on with the program.
Learning Strict HTML is a breeze. The easiest thing I ever did that involved something called a language. Yes, eating a donut is easier, but it doesn’t get called a language. CSS is a bit trickier, but is almost as easy. How about the next step, like server side technologies and DBs? I don’t want to be a jerk or point at people with my finger, but if anybody is so hung up on using markup technology that was dropped 10 years ago, how could they ever expect to keep up with serious stuff such as the change from PHP 4.3/4 to PHP5, ASP classic to .Net, etc? I mean, if anybody thinks CSS is a tough bone, they have a big wall coming when they start learning OOP.
And Jason,
>>So our pages are still <p class="left"> <p class="right"> <p class="center"> all over the place.<<
That is exactly the kind of code you are trying to avoid, because as you said it yourself, if you code it like that then it is pretty much the same thing as the deprecated code.
I’ll post an example for you in a minute.
Most of the examples of bad CSS posted here are situation dependant.
To take Jason’s example (I’m hoping you don’t randomize your use of alignment just for the heck of it), I’m assuming that different blocks of text require different treatment.
Take this code:
************
<div id="header">
<h2>This is my header</h2>
<p>And this is the paragraph of the header that needs to be centered.</p>
</div>
<div id="content">
<h3>A subtitle</h3>
<p>This is a …</p>
<p>… 3-paragraph…</p>
<p>…article with full justification</p>
</div>
<div id="footer">
<p>Just saying goodbye</p>
</div>
************
What we have here is valid strict HTML. Run it like that and you’ll see your browser renders something that could very easily be used as-is.
And now, we style it. Say we want our header paragraph to be center aligned, our article paragraphs justified and the footer right aligned. And, of course, some action for the titles as well:
#header {text-align: center; border: 2px solid #FFE4B5}
#content p{text-align: justify}
#footer p{text-align: right; font-size: smaller}
h1,h2{color: #A0522D; background-color: #FFFFFF}
It is now a different document. Do you see how I didn’t have to touch the HTML? Can you imagine the advantage of using this even on a 5-pages site? If you want to change the color of the footer text, you just update the CSS file. Say you want to add a border to the footer, or make your titles larger or change the font face for the header, or have more spacing between the header and the content. You only update your styles sheet.
Now imagine this on a 50 pages site. Now imagine a 50,000 pages site. It works everywhere, and it works better. It is not just about less code (although it is considerably less code) it is about a page that is easier to parse by browsers, faster to load, easier to update and easier to code. It is just plain better.
Imagine how that would look with tables and <font> tags and what it would be to update the pages of your site every time you decide to change a color.
Of course, this is just sample code, but I’m hoping it illustrates the issues we are dealing with a bit better. For a more extreme example of CSS flexibility, check out the www.csszengarden.com
To take Jason’s example (I’m hoping you don’t randomize your use of alignment just for the heck of it), I’m assuming that different blocks of text require different treatment.
Take this code:
************
<div id="header">
<h2>This is my header</h2>
<p>And this is the paragraph of the header that needs to be centered.</p>
</div>
<div id="content">
<h3>A subtitle</h3>
<p>This is a …</p>
<p>… 3-paragraph…</p>
<p>…article with full justification</p>
</div>
<div id="footer">
<p>Just saying goodbye</p>
</div>
************
What we have here is valid strict HTML. Run it like that and you’ll see your browser renders something that could very easily be used as-is.
And now, we style it. Say we want our header paragraph to be center aligned, our article paragraphs justified and the footer right aligned. And, of course, some action for the titles as well:
#header {text-align: center; border: 2px solid #FFE4B5}
#content p{text-align: justify}
#footer p{text-align: right; font-size: smaller}
h1,h2{color: #A0522D; background-color: #FFFFFF}
It is now a different document. Do you see how I didn’t have to touch the HTML? Can you imagine the advantage of using this even on a 5-pages site? If you want to change the color of the footer text, you just update the CSS file. Say you want to add a border to the footer, or make your titles larger or change the font face for the header, or have more spacing between the header and the content. You only update your styles sheet.
Now imagine this on a 50 pages site. Now imagine a 50,000 pages site. It works everywhere, and it works better. It is not just about less code (although it is considerably less code) it is about a page that is easier to parse by browsers, faster to load, easier to update and easier to code. It is just plain better.
Imagine how that would look with tables and <font> tags and what it would be to update the pages of your site every time you decide to change a color.
Of course, this is just sample code, but I’m hoping it illustrates the issues we are dealing with a bit better. For a more extreme example of CSS flexibility, check out the www.csszengarden.com
ASKER
>>I assume that people who don’t see CSS as better simply have no training or outdated training in web technologies.
Wow now dude, I'm not in any way saying that CSS is bad or that we shouldn't use styles to present our data. My point is that MOST of the "great" new tecnology isn't really all that it's cracked up to be. I mean I'm sure that by the time I'm a whiz with CSS, XML, and XSLT, there's gonna be some completely new thing and by that time HTML will probly be considered about as advanced as a stone wheel. I also realize that it's part of the job (a pretty big part) to keep up with new tecnologies and not get left behind. Why do we have to change almost everything every five years or so? I mean damn, isn't this a cycle that people are recognizing? Can we come to some kind of solid spec for anything? It just seems so flip floppy and rediculous.
Just so you know, I graduated in June of 2004, so I'm not convinced that my education is completely out of date. They still had us writing tables. Are you down with OOP, yea you know me ;)
I mean damn! can we spend a few days just using the new tecnology, without having to go hit the books and figure out how they've rewritten the syntax, I'm done, I'm sure I sound like a little baby, anybody got a binky?
Wow now dude, I'm not in any way saying that CSS is bad or that we shouldn't use styles to present our data. My point is that MOST of the "great" new tecnology isn't really all that it's cracked up to be. I mean I'm sure that by the time I'm a whiz with CSS, XML, and XSLT, there's gonna be some completely new thing and by that time HTML will probly be considered about as advanced as a stone wheel. I also realize that it's part of the job (a pretty big part) to keep up with new tecnologies and not get left behind. Why do we have to change almost everything every five years or so? I mean damn, isn't this a cycle that people are recognizing? Can we come to some kind of solid spec for anything? It just seems so flip floppy and rediculous.
Just so you know, I graduated in June of 2004, so I'm not convinced that my education is completely out of date. They still had us writing tables. Are you down with OOP, yea you know me ;)
I mean damn! can we spend a few days just using the new tecnology, without having to go hit the books and figure out how they've rewritten the syntax, I'm done, I'm sure I sound like a little baby, anybody got a binky?
>>Why do we have to change almost everything every five years or so?<<
The web is in diapers and making its way into kindergarten. That is explanation #1. You can also try out these others for fit ;)
2. If you analyze Microsoft's model of releasing software (the leader software maker in the world) 5 years is a lot more time than the kind of run you can expect from software.
3. It has not been 5, it has been 10 and HTML 4.01 strict will likely be supported for another 10 years. So that is about 20, not 5.
>>I graduated in June of 2004, so I'm not convinced that my education is completely out of date.<<
I honestly don't mean to be disrespectful so please don't take this the bad way, but if your school taught you HTML after the year 2000 and you were not introduced to HTML Strict that dates back to at least 1997 (and even worse if they were teaching you to use tables for layout), you've been had. What else did they teach you, Fortran?
>>can we spend a few days just using the new tecnology...<<
Yes, you already wasted 10 years, you have 10 to go. My advise is that you look into xHTML (very similar to HTML Strict) as well, because it is right around the corner.
As I was saying above, I advocate the use of the recommend technology not out of zealot-ness. It truly is better and makes your job easier. I promise whatever time you spend looking into it won't be an effort to regret.
The web is in diapers and making its way into kindergarten. That is explanation #1. You can also try out these others for fit ;)
2. If you analyze Microsoft's model of releasing software (the leader software maker in the world) 5 years is a lot more time than the kind of run you can expect from software.
3. It has not been 5, it has been 10 and HTML 4.01 strict will likely be supported for another 10 years. So that is about 20, not 5.
>>I graduated in June of 2004, so I'm not convinced that my education is completely out of date.<<
I honestly don't mean to be disrespectful so please don't take this the bad way, but if your school taught you HTML after the year 2000 and you were not introduced to HTML Strict that dates back to at least 1997 (and even worse if they were teaching you to use tables for layout), you've been had. What else did they teach you, Fortran?
>>can we spend a few days just using the new tecnology...<<
Yes, you already wasted 10 years, you have 10 to go. My advise is that you look into xHTML (very similar to HTML Strict) as well, because it is right around the corner.
As I was saying above, I advocate the use of the recommend technology not out of zealot-ness. It truly is better and makes your job easier. I promise whatever time you spend looking into it won't be an effort to regret.
ASKER
>>What else did they teach you, Fortran?
lol, good one :) does C++ count?
>>As I was saying above, I advocate the use of the recommend technology not out of zealot-ness. It truly is better and makes your job easier. I promise whatever time you spend looking into it won't be an effort to regret.
Sounds like solid advice. I've already purchased the books, and haven't had the heart (or really motivation) to crack 'em open.
And it wasn't all crap at my school, they taught us how a computer works :/
I suppose there was ASP.NET
lol, good one :) does C++ count?
>>As I was saying above, I advocate the use of the recommend technology not out of zealot-ness. It truly is better and makes your job easier. I promise whatever time you spend looking into it won't be an effort to regret.
Sounds like solid advice. I've already purchased the books, and haven't had the heart (or really motivation) to crack 'em open.
And it wasn't all crap at my school, they taught us how a computer works :/
I suppose there was ASP.NET
I wish you luck jesse, I'm sure you'll get the hang of it pretty soon.
The toughest part as I said above is getting in the mind frame. But starting is easy. I would go for making sure your HTML is Strict, which only means you are limiting yourself to fewer tags. That is the easy part. Then comes trying to figure out a way to style things the way you want with CSS using the limited set of HTML tags. That is more about tricks than anything else.
After a while you just "get it". And then you'll be here helping the new ones start with CSS :)
The toughest part as I said above is getting in the mind frame. But starting is easy. I would go for making sure your HTML is Strict, which only means you are limiting yourself to fewer tags. That is the easy part. Then comes trying to figure out a way to style things the way you want with CSS using the limited set of HTML tags. That is more about tricks than anything else.
After a while you just "get it". And then you'll be here helping the new ones start with CSS :)
>> I honestly don't mean to be disrespectful so please don't take this the bad way, but if your school taught you HTML after the year 2000 and you were not introduced to HTML Strict that dates back to at least 1997 (and even worse if they were teaching you to use tables for layout), you've been had. <<
Should he go back and kick the instructor in the groin? (that was you who said that the other day, right Esopo?)
Folks,
I think this one may be getting to the "talked to death stage."
Should he go back and kick the instructor in the groin? (that was you who said that the other day, right Esopo?)
Folks,
I think this one may be getting to the "talked to death stage."
>>Should he go back and kick the instructor in the groin? <<
Yes, he should and I thought about mentioning it too ;)
>>I think this one may be getting to the "talked to death stage."<<
I don't think it is. I think it has advanced pretty well, and I hope that the example I gave sheds some light.
Yes, he should and I thought about mentioning it too ;)
>>I think this one may be getting to the "talked to death stage."<<
I don't think it is. I think it has advanced pretty well, and I hope that the example I gave sheds some light.
ASKER
Sorry folks, I thought you all deserved way more points, but couldn't figure how to increase, I'll figure it someday.
Thanks for a truely excellent discussion
You think you're gonna catch me there huh jason?
Thanks for a truely excellent discussion
You think you're gonna catch me there huh jason?
If I do, I'm pretty confident you won't stay caught for long.
Besides, I've got Son 1.0 due in April. My EE activities are going to be drastically curtailed when that happens.
Besides, I've got Son 1.0 due in April. My EE activities are going to be drastically curtailed when that happens.
ASKER
Congratulations!!!
Any plans for an updated version? I've got a five year old daughter myself, she's really great!
Good Luck!
Any plans for an updated version? I've got a five year old daughter myself, she's really great!
Good Luck!
Thank you!
No plans for an upgrade. It was hard enough to get this one out of alpha and into beta. My wife may change that thought process once we go into full production and the product is stable for a few years.
And I think we've beaten this metaphor into the ground now... :)
No plans for an upgrade. It was hard enough to get this one out of alpha and into beta. My wife may change that thought process once we go into full production and the product is stable for a few years.
And I think we've beaten this metaphor into the ground now... :)
>>And I think we've beaten this metaphor into the ground now... :)
Nice try, but not quite there ;)
https://www.experts-exchange.com/questions/21077089/EE-Bot.html#11680356
Nice try, but not quite there ;)
https://www.experts-exchange.com/questions/21077089/EE-Bot.html#11680356
LOL.
I can't believe people get points for that crap.
I can't believe people get points for that crap.
Yeah, about 5 points. And it is funny crap, well worth the points.
There is this:
http://www.w3.org/TR/REC-html40/index/attributes.html
which lists the deprecated elements with the D in the Depr column.
and this:
http://www.w3schools.com/tags/default.asp
Time permitting, I will turn these into a list of D only elements and post it on my personal page and link back here for all to enjoy.
What else should we be looking for? Does XML/XHTML have a deprecated list yet? Javascript, since it has basically become a part of web pages and we all have to deal with it to some extent?
--------------
More philosophically, I don't think you will ever see a complete lack of support for HTML elements by the major browsers, deprecated or not. Instead, I think you will see an evolution of the HTML/XML/CSS model into a whole new beast that will force the browser developers down a totally different path. Kind of like what we thought VRML might have been, but never was. In the meantime, quirks mode may become a user toggle instead of something triggered by the presence or absence of a doctype...
There is just too much information coded the old way to make a lack of support feasible. I don't think the web design industry is going to see something akin to the Y2K consulting boom with legions of developers being hired to re-code HTML pages into the next new markup langauge.
Others may feel differently. I'd be interested in the discussion, if nothing else.