Personally, my HTML has gotten several orders of magnitude better since I started coding web pages in a text editor (Crimson Editor and ScITE are my favorites) than when I used Dreamweaver.
My rule of thumb: never let a program write your code.
Discussion on:
View:
Show:
When I am actively "programming", I write all of my code by hand, even when using what amounts to an advanced editor like Expression Web 2 (I use that because it's what I get for free). The editor is more of a collection of things like validators, file manager, etc. for me.
The second group is when I have my "casual content author" hat on... writing email, typing in a Web forum with one of those little HTML widgets, etc. In those cases, I reall don't care about the HTML quality, I just want to write the content and get done. In those circumstances, the tools do the work for me.
J.Ja
The second group is when I have my "casual content author" hat on... writing email, typing in a Web forum with one of those little HTML widgets, etc. In those cases, I reall don't care about the HTML quality, I just want to write the content and get done. In those circumstances, the tools do the work for me.
J.Ja
Frontpage is one of the worst as far as adding garbage... Dreamweaver is one of the better tools.
But, as you state... the best way to keep control and have the cleanest, and best validated code is to hand code it. (Dreamweaver WILL let you hand code it too.)
But, as you state... the best way to keep control and have the cleanest, and best validated code is to hand code it. (Dreamweaver WILL let you hand code it too.)
I used to use FrontPage, ages and ages and ages ago (as in, "FrontPage 98"), and dabbled with it occassionally since then. In general, if you use it simply as an HTML editor, it doesn't make bad HTML. Where it gets bad, is when you copy/paste from an Office app, and when you start using the controls that tie into the FrontPage extensions. Then it does some really odd things.
J.Ja
J.Ja
... all well and good talking esoteric stuff (well ... it is to me 
) BUT if a web site doesn't load properly in my browser of choice (Opera) then I simply move on to the next site. If it is a site that is trying to sell me something then you have failed in your job - I don't even look at what you're selling.
Unfortunately, as some posts above pointed out, most developers seem to think that IE is the be-all and end-all of browsers, and write code exclusively for that browser. If it works in Internet Explorer it must be right, yes? Wrong!
A classic example is the blocked mindset of the people who provide the internet banking software of the Credit Union I use. (By their own admission - it is optimised for IEx and usable in some other browsers - they quote Opera 5.x !!!)
Despite almost three years of trying to get them to make it work correctly in newer Opera versions, they simply ignore my emails. We are perfect - who are you to complain?
Therein lies another reason developers write bad code - they are too up themselves to take justified critism in the way it is provided - to IMPROVE their site so ALL can enjoy it.
So they keep cranking out the same old garbage.
Now if just ONE developer takes my message to heart and improves their coding for us long suffering web users, then the time taken to make this post won't have been wasted.
) BUT if a web site doesn't load properly in my browser of choice (Opera) then I simply move on to the next site. If it is a site that is trying to sell me something then you have failed in your job - I don't even look at what you're selling.Unfortunately, as some posts above pointed out, most developers seem to think that IE is the be-all and end-all of browsers, and write code exclusively for that browser. If it works in Internet Explorer it must be right, yes? Wrong!
A classic example is the blocked mindset of the people who provide the internet banking software of the Credit Union I use. (By their own admission - it is optimised for IEx and usable in some other browsers - they quote Opera 5.x !!!)
Despite almost three years of trying to get them to make it work correctly in newer Opera versions, they simply ignore my emails. We are perfect - who are you to complain?
Therein lies another reason developers write bad code - they are too up themselves to take justified critism in the way it is provided - to IMPROVE their site so ALL can enjoy it.
So they keep cranking out the same old garbage.
Now if just ONE developer takes my message to heart and improves their coding for us long suffering web users, then the time taken to make this post won't have been wasted.
HTML: you write some text and some program delivers it to the user. This is broken by design.
Compare to script languages: you write some text and some program delivers it to the CPU. This is OK since the program validates the text in the way.
HTTP servers should compile HTML before sending removing white space, redundant attributes and so on providing a bit better performance and VALIDATING THE INPUT CODE.
Without that HTML will be all junk forever.
Compare to script languages: you write some text and some program delivers it to the CPU. This is OK since the program validates the text in the way.
HTTP servers should compile HTML before sending removing white space, redundant attributes and so on providing a bit better performance and VALIDATING THE INPUT CODE.
Without that HTML will be all junk forever.
Don't go picking on Dreamweaver.
The preferred HTML tool for 9 out of 10 people creating web sites for Building Automation Systems.
Chuckle, actually, I'm one of those 1 out of 10 who don't use it.
However, the use of Dreamweaver for creating those Building Automation Web sites would not show up in the statistics that keep count of poorly coded HTML since its VERY unusual for those sites to allow public access. The IP's/URL's are kept closely guarded and security access codes are always required.
The preferred HTML tool for 9 out of 10 people creating web sites for Building Automation Systems.
Chuckle, actually, I'm one of those 1 out of 10 who don't use it.
However, the use of Dreamweaver for creating those Building Automation Web sites would not show up in the statistics that keep count of poorly coded HTML since its VERY unusual for those sites to allow public access. The IP's/URL's are kept closely guarded and security access codes are always required.
Just because its a product like dreamweaver doesnt mean to say that the output of code that is created is the cleanest it can be
I never even hinted at the idea that Dreamweaver produced clean, good code.
I've never seen an auto-code generator that produced good, clean code. At least, not unless your design, and your wants and needs was very simple and minimal, and you got everything laid out as you wanted it the first time around.
Most auto-code generators I've seen (actually ... ALL that I've seen) seem to get progressively worse in their outputs as you re-edit web pages/sites and change things around from the original. UNLESS ... you go in an do some manual editing to straighten things out from time to time.
My comment about Dreamweaver was tongue-in-cheek.
It is a favored tool of certain coders who have speed and ease in mind as versus optimized, good, clean code.
And they're not likely, the group(s) I speak of, to care whether or not their web pages and sites are standards compliant. The work they do is largely bid work, lowest bid gets the work.
So they just wish to put out the fastest piece of work they can, that meets their customer's wants and expectations ... at least well enough to get the customer to sign the check.
As far as to whether or not the web pages render properly in other Web browsers, not infrequently that is not one of the customer's criteria. For instance, I can not access my bank account over the Internet with anything other than Windows Internet Explorer, version 6 or better. Nor do they intend to change that fact.
Not unusual. In my Favorites folder, I have bookmarked literally dozens of large large businesses and government agencies that REQUIRE the use of IE if yah want to do anything other than simple browsing of their ads, brags, and other public data. Their secure areas require IE.
I'm not saying any of this is right. But it is a fact of life.
Personally, I use Firefox most of the time. But need to keep IE loaded and updated for accessing a fairly significant number of places which have secure connections.
I've never seen an auto-code generator that produced good, clean code. At least, not unless your design, and your wants and needs was very simple and minimal, and you got everything laid out as you wanted it the first time around.
Most auto-code generators I've seen (actually ... ALL that I've seen) seem to get progressively worse in their outputs as you re-edit web pages/sites and change things around from the original. UNLESS ... you go in an do some manual editing to straighten things out from time to time.
My comment about Dreamweaver was tongue-in-cheek.
It is a favored tool of certain coders who have speed and ease in mind as versus optimized, good, clean code.
And they're not likely, the group(s) I speak of, to care whether or not their web pages and sites are standards compliant. The work they do is largely bid work, lowest bid gets the work.
So they just wish to put out the fastest piece of work they can, that meets their customer's wants and expectations ... at least well enough to get the customer to sign the check.
As far as to whether or not the web pages render properly in other Web browsers, not infrequently that is not one of the customer's criteria. For instance, I can not access my bank account over the Internet with anything other than Windows Internet Explorer, version 6 or better. Nor do they intend to change that fact.
Not unusual. In my Favorites folder, I have bookmarked literally dozens of large large businesses and government agencies that REQUIRE the use of IE if yah want to do anything other than simple browsing of their ads, brags, and other public data. Their secure areas require IE.
I'm not saying any of this is right. But it is a fact of life.
Personally, I use Firefox most of the time. But need to keep IE loaded and updated for accessing a fairly significant number of places which have secure connections.
See http://www.phenoelit-us.org/dpl/dpl.html for an example. (the only sin, one row has about 10 extra columns in it; because someone generated this without looking). Warning... it takes F O R E V E R and a day to load...
Sample here (if it fits)
{TABLE FRAME=VOID CELLSPACING=0 COLS=47 RULES=NONE BORDER=0}
{COLGROUP}{COL WIDTH=177}{COL WIDTH=348}{COL WIDTH=472}{COL WIDTH=292}{COL WIDTH=150}{COL WIDTH=399}{COL WIDTH=429}{COL WIDTH=841}{COL WIDTH=34}{COL WIDTH=94}{COL WIDTH=66}{COL WIDTH=208}{COL WIDTH=48}{COL WIDTH=48}{COL WIDTH=45}{COL WIDTH=51}{COL WIDTH=86}{COL WIDTH=34}{COL WIDTH=79}{COL WIDTH=71}{COL WIDTH=208}{COL WIDTH=48}{COL WIDTH=41}{COL WIDTH=41}{COL WIDTH=40}{COL WIDTH=86}{COL WIDTH=34}{COL WIDTH=59}{COL WIDTH=66}{COL WIDTH=208}{COL WIDTH=48}{COL WIDTH=48}{COL WIDTH=65}{COL WIDTH=40}{COL WIDTH=86}{COL WIDTH=34}{COL WIDTH=74}{COL WIDTH=171}{COL WIDTH=86}{COL WIDTH=45}{COL WIDTH=48}{COL WIDTH=48}{COL WIDTH=51}{COL WIDTH=119}{COL WIDTH=28}{COL WIDTH=48}{COL WIDTH=71}{/COLGROUP}
{TBODY}
{TR}
{TD WIDTH=177 HEIGHT=17 ALIGN=LEFT}Vendor{/TD}
{TD WIDTH=348 ALIGN=LEFT}Model{/TD}
{TD WIDTH=472 ALIGN=LEFT}Version{/TD}
{TD WIDTH=292 ALIGN=LEFT}Access Type{/TD}
{TD WIDTH=150 ALIGN=LEFT}Username{/TD}
{TD WIDTH=399 ALIGN=LEFT}PASSWORD{/TD}
{TD WIDTH=429 ALIGN=LEFT}Privileges{/TD}
{TD WIDTH=841 ALIGN=LEFT}Notes{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=94 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=66 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=208 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=45 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=51 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=79 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=71 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=208 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=41 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=41 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=40 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=59 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=66 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=208 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=65 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=40 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=74 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=171 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=45 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=51 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=119 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=28 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=71 ALIGN=LEFT}{BR}{/TD}
{/TR}
Sample here (if it fits)
{TABLE FRAME=VOID CELLSPACING=0 COLS=47 RULES=NONE BORDER=0}
{COLGROUP}{COL WIDTH=177}{COL WIDTH=348}{COL WIDTH=472}{COL WIDTH=292}{COL WIDTH=150}{COL WIDTH=399}{COL WIDTH=429}{COL WIDTH=841}{COL WIDTH=34}{COL WIDTH=94}{COL WIDTH=66}{COL WIDTH=208}{COL WIDTH=48}{COL WIDTH=48}{COL WIDTH=45}{COL WIDTH=51}{COL WIDTH=86}{COL WIDTH=34}{COL WIDTH=79}{COL WIDTH=71}{COL WIDTH=208}{COL WIDTH=48}{COL WIDTH=41}{COL WIDTH=41}{COL WIDTH=40}{COL WIDTH=86}{COL WIDTH=34}{COL WIDTH=59}{COL WIDTH=66}{COL WIDTH=208}{COL WIDTH=48}{COL WIDTH=48}{COL WIDTH=65}{COL WIDTH=40}{COL WIDTH=86}{COL WIDTH=34}{COL WIDTH=74}{COL WIDTH=171}{COL WIDTH=86}{COL WIDTH=45}{COL WIDTH=48}{COL WIDTH=48}{COL WIDTH=51}{COL WIDTH=119}{COL WIDTH=28}{COL WIDTH=48}{COL WIDTH=71}{/COLGROUP}
{TBODY}
{TR}
{TD WIDTH=177 HEIGHT=17 ALIGN=LEFT}Vendor{/TD}
{TD WIDTH=348 ALIGN=LEFT}Model{/TD}
{TD WIDTH=472 ALIGN=LEFT}Version{/TD}
{TD WIDTH=292 ALIGN=LEFT}Access Type{/TD}
{TD WIDTH=150 ALIGN=LEFT}Username{/TD}
{TD WIDTH=399 ALIGN=LEFT}PASSWORD{/TD}
{TD WIDTH=429 ALIGN=LEFT}Privileges{/TD}
{TD WIDTH=841 ALIGN=LEFT}Notes{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=94 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=66 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=208 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=45 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=51 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=79 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=71 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=208 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=41 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=41 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=40 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=59 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=66 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=208 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=65 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=40 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=34 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=74 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=171 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=86 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=45 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=51 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=119 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=28 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=48 ALIGN=LEFT}{BR}{/TD}
{TD WIDTH=71 ALIGN=LEFT}{BR}{/TD}
{/TR}
I had to, at the time. My site's gone on past the 18,000 page mark, and the content is in a normalised database. I wrote it in such a way that it created a well formed xml document, and sent it out to disk.
When my hard disk crashed a year ago, I had to write the thing from the ground up. (Lost a few backups that I'd made, most recent was from 2005.)
Now I'm writing a new tool, but with the xml.net framework. I can tell they never, ever considered the idea that this might be used for an xhtml generator. It lacks the documentation for how to do the declartion tags properly.
I know my stuff puts out the odd bit of bad code. But I don't want to get caught out (like Bank of Ireland) with a website that crashes and leaves customers frustrated. All the time on BoI's site, I get weird error screens that don't reflect anything I'm doing. (And they really don't care either. I think that's a major cause of garbage code.)
When my hard disk crashed a year ago, I had to write the thing from the ground up. (Lost a few backups that I'd made, most recent was from 2005.)
Now I'm writing a new tool, but with the xml.net framework. I can tell they never, ever considered the idea that this might be used for an xhtml generator. It lacks the documentation for how to do the declartion tags properly.
I know my stuff puts out the odd bit of bad code. But I don't want to get caught out (like Bank of Ireland) with a website that crashes and leaves customers frustrated. All the time on BoI's site, I get weird error screens that don't reflect anything I'm doing. (And they really don't care either. I think that's a major cause of garbage code.)
Just out of curiosity I put the URL of this very page into the online W3C html validator (http://validator.w3.org) and the result?
409 Errors,
211 warning(s)
Preacher, Heal Thyself!
409 Errors,
211 warning(s)
Preacher, Heal Thyself!
I love it! I don't like people telling me what is garbage and what isn't. So it is nice to see the preacher caught under the ocvers with... well you fill in the blank.
The reason why we write non-compliant code is because the standard and the implementation of the standard demands that we write non-compliant code to get what we want to get done... done and done quickly.
This is business... success is the standard not adherence to an arbitrary set of rules or "best practices". You want to call my code junk because it doesn't validate by your validator... fine. But it renders and functions in all the browsers that my customers use and it looks darn good in all of them as well. And it was built FAST the way the boss wanted it done so that I could build even more good looking, functional, non-compliant, junk pages.
I susspose that's why many of us non-compliant junk developers continue to be employed and haven't been "globalized".
The reason why we write non-compliant code is because the standard and the implementation of the standard demands that we write non-compliant code to get what we want to get done... done and done quickly.
This is business... success is the standard not adherence to an arbitrary set of rules or "best practices". You want to call my code junk because it doesn't validate by your validator... fine. But it renders and functions in all the browsers that my customers use and it looks darn good in all of them as well. And it was built FAST the way the boss wanted it done so that I could build even more good looking, functional, non-compliant, junk pages.
I susspose that's why many of us non-compliant junk developers continue to be employed and haven't been "globalized".
Hi folks,
Though correct I see that Steve's and Bree's comments fall a bit short of being complete. There were hundreds of errors as Steve points out. Bree responds that this is business and the fact that the page displays in most browser nicely is what is relevant. Well, yes, results do count. Given that site content changes constantly you could argue that site content should not be held to the same standard as program code. On the other hand, site content can be archived for ten years or longer and represents the quality of a business' product which argues for quality and the point that it may not render correctly at a later time.
There has been more than one post on validator output in this "thread" so I decided to go look. The volume of error output and quantity of errors was large. I then grouped the output by type of error and spent several minutes examining the errors.
Fully half of the output is in reference to missing semicolons after the ampersand or the REFC error in other words. I do not know if this is even a XHTML requirement as of 2009.
Hundred of errors could be traced to the usage of the backslash and ampersand characters and resulting parsing confusion.
In addition, there were link and meta tags in the wrong locations which is actually a code / markup generator error not keeping track of header, body and footer sections. There were some missing attributes and a few other errors.
I would fix the REFC errors for the sole reason of cutting down the volume of output.
Normally I would spend a lot of time on this sort of thing but I will hazard a guess and say that about 20 QA tickets would be generated from this output most of which would be markup generator issues. I would welcome dissenting opinion on this as well as other perspectives and additional observations.
Regards, Dave Horsman
Though correct I see that Steve's and Bree's comments fall a bit short of being complete. There were hundreds of errors as Steve points out. Bree responds that this is business and the fact that the page displays in most browser nicely is what is relevant. Well, yes, results do count. Given that site content changes constantly you could argue that site content should not be held to the same standard as program code. On the other hand, site content can be archived for ten years or longer and represents the quality of a business' product which argues for quality and the point that it may not render correctly at a later time.
There has been more than one post on validator output in this "thread" so I decided to go look. The volume of error output and quantity of errors was large. I then grouped the output by type of error and spent several minutes examining the errors.
Fully half of the output is in reference to missing semicolons after the ampersand or the REFC error in other words. I do not know if this is even a XHTML requirement as of 2009.
Hundred of errors could be traced to the usage of the backslash and ampersand characters and resulting parsing confusion.
In addition, there were link and meta tags in the wrong locations which is actually a code / markup generator error not keeping track of header, body and footer sections. There were some missing attributes and a few other errors.
I would fix the REFC errors for the sole reason of cutting down the volume of output.
Normally I would spend a lot of time on this sort of thing but I will hazard a guess and say that about 20 QA tickets would be generated from this output most of which would be markup generator issues. I would welcome dissenting opinion on this as well as other perspectives and additional observations.
Regards, Dave Horsman
You can't blame Justin for all those errors. You can, however, blame:
<meta name="generator" content="WordPress 2.6.5" />
..and even that line is not in the section where it belongs. :-/
Many of the rest of the errors are for using HTML tag closing while using an XHTML doctype. In general, I also continually note that generated code is nearly always quite bad.
<meta name="generator" content="WordPress 2.6.5" />
..and even that line is not in the section where it belongs. :-/
Many of the rest of the errors are for using HTML tag closing while using an XHTML doctype. In general, I also continually note that generated code is nearly always quite bad.
Dayam! I forget you can't type less-thans in this place. The missing displayed code would be:
[meta name="generator" content="WordPress 2.6.5" /]
[meta name="generator" content="WordPress 2.6.5" /]
Hey, I would *love* to see the HTML on this site cleaned up. I have zero control over it. In fact, even on the content that I personally write, I do not personally enter it into WordPress, so even for that, I have zero control.
J.Ja
J.Ja
http://validator.w3.org/check?uri=http://blogs.techrepublic.com.com/programming-and-development/?p=896&tag=nl.e101
371 Errors, 205 warning(s)
maybe they're fixing it in embarassment
371 Errors, 205 warning(s)
maybe they're fixing it in embarassment
Two reasons:
1) BECAUSE THEY CAN: browsers allow it
2) BECAUSE IT WORKS: don't have no f'in time.
1) BECAUSE THEY CAN: browsers allow it
2) BECAUSE IT WORKS: don't have no f'in time.
I don't think you really explained clearly what you mean by garbage code.
Certainly code that has mismatched or missing tags could be considered garbage, but I don't know that I would include standards testing. If you write according to the W3 HTML standards, you won't get something that will run correctly on 75% of the browsers (IE6/7).
We use ASP.NET and Visual Studio, and that would be considered 'garbage code' by some. So what! It works, and our company standard is IE6.
Certainly code that has mismatched or missing tags could be considered garbage, but I don't know that I would include standards testing. If you write according to the W3 HTML standards, you won't get something that will run correctly on 75% of the browsers (IE6/7).
We use ASP.NET and Visual Studio, and that would be considered 'garbage code' by some. So what! It works, and our company standard is IE6.
but not always. It depends on how the browser interprets the page. However since browsers are generally trying to achive the standard, you can get ahead of the curve and just code to standard, and wait for the browsers to catch up
while waiting for the browsers to catch up, what looks correct in one browser, as it runs closer to w3c spec, is completely broken in another (IE), or works in IE and Opera, but is broken in in Firefox and Safari.
The more compliant the browser the better... the more the browser engines interpret a directive the same, the better.
The more code is expected to done fast, the more garbage tools will be used, or poor practices to get the desired results to make the "quota," time frame, etc.
The more compliant the browser the better... the more the browser engines interpret a directive the same, the better.
The more code is expected to done fast, the more garbage tools will be used, or poor practices to get the desired results to make the "quota," time frame, etc.
Development has become so complex as a result of constantly changing user requiremenst that aren't properly monitored, the many languages that have to be understood in order to complete an entire project, the security issues and standards that have to be met for web-sites that are publicly used; the list goes on.
Given all this, how does anyone expect individual developers to maintain qaulity code across the board? It simply can't be done.
HTML is a scripting langues that offers a lot of flexibility in the way you create a presentation. If your HTML is clean and legible and presents properly in the environment(s) you expect it to work than how can we worry about standards when there is so much else to do.
I don't like using CSS and rareley use it. Is this a crime? My reasoning for this is that I design many web pages from scratch without any over lying guidance in the look and feel. Thus it is easier to work dynamically as I design and code than begin adding CSS sheets that have to be constantly referred to when I am trying to concentrate on the interface.
Standards are supposed to be a guidepost for development not hard and fast rules. And that fact that so many web pages do not validate well against standards means that maybe the standards should catch up with the reality of everyday development and be more flexible in their validation processes...
Given all this, how does anyone expect individual developers to maintain qaulity code across the board? It simply can't be done.
HTML is a scripting langues that offers a lot of flexibility in the way you create a presentation. If your HTML is clean and legible and presents properly in the environment(s) you expect it to work than how can we worry about standards when there is so much else to do.
I don't like using CSS and rareley use it. Is this a crime? My reasoning for this is that I design many web pages from scratch without any over lying guidance in the look and feel. Thus it is easier to work dynamically as I design and code than begin adding CSS sheets that have to be constantly referred to when I am trying to concentrate on the interface.
Standards are supposed to be a guidepost for development not hard and fast rules. And that fact that so many web pages do not validate well against standards means that maybe the standards should catch up with the reality of everyday development and be more flexible in their validation processes...
Well if you want complete IE6 compatibility, then no. Because CSS doesn't work well with IE6. Otherwise I think it is unwise to not use CSS. It makes updating sites a lot easier and produces a better looking site. Also it eliminates the need for using tables as a layout scheme (which they were never designed to be).
...if you rely on others to maintain those pages. It's less of a crime if you maintain them yourself, but even then, it's still a misdemeanor. Start using CSS and you'll find yourself perhaps spending a little more time on development, but a lot less time on maintenance.
One of the problems with doing more up-front design such as with CSS is that in many commercial businesses you are never given the time to do quality development. And this is especially true in the financial industry in which I spent 20+ years.
In such places, technology is simply looked upon as a commodity in order to provide a service. Technical managers rarely care about the quality since they are often under pressure from high-stress user departments that want the work completed yesterday.
Up-front design techniques such as using CSS to develop uniform and coherent styles for interfaces is just not a luxury most commercial developers have in such organizations.
As far as doing my own web-development since I am the one who maintains my own work I simply don't see the need to design in CSS.
In addition, I don't like generic solutions which CSS tends to foster in that vein. Such solutions very often cause more problems than they are worth since the ripple-effects can wreak havoc...
In such places, technology is simply looked upon as a commodity in order to provide a service. Technical managers rarely care about the quality since they are often under pressure from high-stress user departments that want the work completed yesterday.
Up-front design techniques such as using CSS to develop uniform and coherent styles for interfaces is just not a luxury most commercial developers have in such organizations.
As far as doing my own web-development since I am the one who maintains my own work I simply don't see the need to design in CSS.
In addition, I don't like generic solutions which CSS tends to foster in that vein. Such solutions very often cause more problems than they are worth since the ripple-effects can wreak havoc...
the flip side of CSS is the ability to change everything on the entire site easily.
Say you decide after building "x" pages that you really want your [h1] tags to have a little letter spacing and a bottom border to make them look cooler/stand out/whatever.
with CSS you just do
h1{
letter-spacing:1px;
bottom-border:1px dotted #eeeeee;
}
and every single one is changed.
OR, if you just want h1s used in main content areas changed, you can do
#main-content h1{
}
(assuming you built it with CSS in mind)
with traditional HTML, you are hand changing every single one.
who's saving time now?
Say you decide after building "x" pages that you really want your [h1] tags to have a little letter spacing and a bottom border to make them look cooler/stand out/whatever.
with CSS you just do
h1{
letter-spacing:1px;
bottom-border:1px dotted #eeeeee;
}
and every single one is changed.
OR, if you just want h1s used in main content areas changed, you can do
#main-content h1{
}
(assuming you built it with CSS in mind)
with traditional HTML, you are hand changing every single one.
who's saving time now?
And if you want to change just one page you have to go back into CSS and create a new class for that page...
you can either run some inline styles
EG: [h1 style="font-size:500%; font-weight:bold;color:#ff0000;"]Hello world[/h1]
or you can just not connect the page to the main stylesheet and build it as a one off.
In which case you aren't any worse off than what you do now, but the other examples show how you're better off.
Keep in mind you can just do a little bit of CSS to cover the broad stuff (like centering your webpage in the broswer) or applying a background color or image to all pages or making all input elements gray with a 1px border and then do everything else custom.
There is not rule that says you MUST do all in CSS sheet or nothing.
mix it up a bit.
EG: [h1 style="font-size:500%; font-weight:bold;color:#ff0000;"]Hello world[/h1]
or you can just not connect the page to the main stylesheet and build it as a one off.
In which case you aren't any worse off than what you do now, but the other examples show how you're better off.
Keep in mind you can just do a little bit of CSS to cover the broad stuff (like centering your webpage in the broswer) or applying a background color or image to all pages or making all input elements gray with a 1px border and then do everything else custom.
There is not rule that says you MUST do all in CSS sheet or nothing.
mix it up a bit.
I agree with the immediate post above this one: if the web standards are being resisted in practice, for this long, it is an indication of a problem with the standards. This discussion reminds me of working with tools. Have you ever been told by some interfering know-it-all (or a lawsuit-deflecting safety label) that a flat-tipped screwdriver is not something for prying open a paint can? Or have you read on a label that you should not stand on the top two steps of a step-ladder? Such labels are for people too foolish to know their own limits or reasonably consider what is safe. I regularly ignore such instructions and substitute instead an accurate appreciation for my own abilities and the risks involved. Now, if it's a chainsaw or a lawnmower, I'm going to read the manual two or three times until I have it almost memorized before I try anything different, because the risk is greater. So, to me, a "TOOL", (like web standards) is a mental invention, not part of the natural world. It doesn't have genetic code, it has atoms and molecules (or bits + bytes) by which it interacts with whatever it touches. In other words, when considering using "the proper tool to get the job done" one must recognize that in some sense the tool which gets the job done IS A PROPER TOOL. There is a big difference between "safety" standards regarding SSL for example, vs. coding HTML with the FONT and BR tags. If professional programmers are allowed to control the future of the internet by shaping HTML to whatever they think it should be, what we will end up with is something as complex as a programming language. (Face it: they want not just certain HTML tags deprecated, they want HTML itself deprecated). Clearly, this is not what the majority of people want the internet to be, it has to be simple and allow users to accomplish directly what they want. If HTML browsers ever get away from their roots of using HTML for the practicality of displaying marked up text, you can expect the formation of yet another technological abstraction layer between the professionals and the people who use the internet to get things done, that is, relay information to each other. Progress in this mistaken direction would raise the barrier of entry, keeping more average joes out, and would eventually make it easier for politicians to end the free internet as we know it because eventually all the interests involved would be part of some commercialized model anyway. I think the standards (and future browsers) should remember the roots from whence they came. The original tags should not have been deprecated. CSS is great, but it's only another tool in the toolbox.
What works works. Leave it alone and leave us alone. If a browser won't decode it, fix the code. What some prima-donna thinks is beautiful code with everything all prissied up may not be what I want to do. We don't have to work in lock-step with self appointed gurus of code. Keep it simplel, let the unshaved ones be.
I'm a Systems Admin but I code websites in my spare time. I try to get my site to be W3 compliant, but its not always possible if I want the site to work right. But a lot of that comes down to IE6. If you took IE6 out of the picture then programming compliant code is much more doable. I personally don't program for IE6. I hate it and I'm not going to bend over backwards to accommodate it. As such I've put links on my site to Opera, IE7 and Firefox 3 and said that IE6 doesn't display correctly. It still works, it would just look funny.
... I've been able to get CSS sites to work right. In late 2000, I converted a site from HTML 3 to HTML 4 + CSS. It worked fine. It all depends on how far you try to reach. If you are doing a simple site design (which does not always mean "plain") without a lot of "tricks", the CSS needed will work fine in IE 6, and all modern browsers, and the differences will be minor if there are differences at all. That's one reason why I really like the Top Style tool, it makes it a lot easier to know what CSS works with what browsers, which helps keep me out of trouble.
J.Ja
J.Ja
Sometimes it's next to impossible for a developer to control the HTML. I suspect the vast majority of the pages that were tested in the Alexa test were generated by a CMS or by server-side rendering technology like ASP.NET. So maybe we should be asking why do those CMS's write garbage HTML? It's not just because of bad templates - the systems themselves inject HTML into the rendered output as well. Why does the ASP.NET framework write garbage HTML, with its reams and reams of unecessary embedded tables?
It's very true, many of the tools generate junk. I really hate ASP.Net's controls that crank out a zillion tables all over the place, for example. And, many CMS systems have hardcoded HTML in them that people have no control over. It's unfortunate. That's why I really like the MODx CMS, by the way... ultimate control over the HTML, even in the various plugins and such (they almost universally allow you to use templates with the plugins).
J.Ja
J.Ja
A lot of HTML rendering and site management tools inject junk into HTML pages. Many of the WYSIWYG editors, when you make later changes and modifications to a page inject those changes imperfectly and muddle up the code.
Not much you're gonna do about that. In many cases the web page author(s) are gonna use such tools, imperfect or not, for the sake of speed ... or because they do not know that much about hand coding.
Typically, if its an important (to me) web site, after using auto code generating tools I'll go back and utilize the old fashioned text mode code editing to clean things up.
Other times, I just leave it. If it works it works, close enough ... good enough.
This second case scenario happens routinely at work. Where we create and manage web sites for a number of customers. Some pay well, for the best they can get.
Others, want changes made on the cheap ... and quickly. You want it cheap? You get cheap. I'm not spending one minute more on such web site than I absolutely have to to produce a result acceptable to the customer.
For our larger, and better paying accounts, we go through considerable more effort. Sometimes giving them even more, and better than they ask. Because we LIKE their business and don't wish for them to be taking it elsewhere.
So sometimes, that "junk" website ... as you defined such in your original post ... is junk on purpose. Pay cheap ... get a cheap product. Turning out a better product takes more time, if that's what yah want you've got to pay for it.
Not much you're gonna do about that. In many cases the web page author(s) are gonna use such tools, imperfect or not, for the sake of speed ... or because they do not know that much about hand coding.
Typically, if its an important (to me) web site, after using auto code generating tools I'll go back and utilize the old fashioned text mode code editing to clean things up.
Other times, I just leave it. If it works it works, close enough ... good enough.
This second case scenario happens routinely at work. Where we create and manage web sites for a number of customers. Some pay well, for the best they can get.
Others, want changes made on the cheap ... and quickly. You want it cheap? You get cheap. I'm not spending one minute more on such web site than I absolutely have to to produce a result acceptable to the customer.
For our larger, and better paying accounts, we go through considerable more effort. Sometimes giving them even more, and better than they ask. Because we LIKE their business and don't wish for them to be taking it elsewhere.
So sometimes, that "junk" website ... as you defined such in your original post ... is junk on purpose. Pay cheap ... get a cheap product. Turning out a better product takes more time, if that's what yah want you've got to pay for it.
A "proof-by-example" that adhering to Web Standards/Recommendations is a "win-win" way to go can be found throughout Sonoff Consulting Services, Inc.'s (Scsi's) Productivity and Knowledge Transfer (P&KT) Web sites at URL addresses http://sonoffconsulting.com/ and http://sonoffconsulting.mobi/.
What do I mean by the above statement? First, use of "plain vanilla" HTML that validates contributes significantly to higher Search Engine Optimization (SEO) results and Web usability factors. Second, writing your HTML so that it also addresses Web Accessibility Initiative (WAI) and Web Content Accessibility Guidelines (WCAG) contributes to increasing Web accessibility.
I encourage anyone who wants to learn more of the details that support the above statements to pore over the Web pages for the above-cited domains and "put them through the testing wringer" to become convinced that such efforts truly do have a long-term payoff in both customer-centric focus and Web development/support areas.
Good luck and have fun!
Raymond Sonoff, President
Sonoff Consulting Services, Inc.
271 Saxony Drive
Crestview Hills, KY 41017-2294
Tel.: (859) 261-5908
e-mail: info@sonoffconsulting.com
What do I mean by the above statement? First, use of "plain vanilla" HTML that validates contributes significantly to higher Search Engine Optimization (SEO) results and Web usability factors. Second, writing your HTML so that it also addresses Web Accessibility Initiative (WAI) and Web Content Accessibility Guidelines (WCAG) contributes to increasing Web accessibility.
I encourage anyone who wants to learn more of the details that support the above statements to pore over the Web pages for the above-cited domains and "put them through the testing wringer" to become convinced that such efforts truly do have a long-term payoff in both customer-centric focus and Web development/support areas.
Good luck and have fun!
Raymond Sonoff, President
Sonoff Consulting Services, Inc.
271 Saxony Drive
Crestview Hills, KY 41017-2294
Tel.: (859) 261-5908
e-mail: info@sonoffconsulting.com
In the point "Developers who never updated their HTML skill sets:" you mention framesets, so what's so bad in using frameset to create independant page spaces for navigation, main window, etc.?
What would you recommend using in stead?
Roger R.
What would you recommend using in stead?
Roger R.
I would recommend using "include" files (along with CSS layout) instead of frames. Rather than listing all the reasons here, Google for "frames are evil". First hit:
http://www.html-faq.com/htmlframes/?framesareevil
Note the two main reasons why: bookmarking and search engines.
http://www.html-faq.com/htmlframes/?framesareevil
Note the two main reasons why: bookmarking and search engines.
who wants to be forced to a SITE's main page instead of bookmarking directly to the content you want? And what about printing content? You gotta jump through hoops depending upon the browser.
The only use I could think of might...might be a photo gallery.
Just use navigation.
The only use I could think of might...might be a photo gallery.
Just use navigation.
* Server side includes
* A templating engine or CMS
* The iframe element
J.Ja
* A templating engine or CMS
* The iframe element
J.Ja
The printing issue has been mentioned - the only browser which does a decent job seems to be IE.
The biggest issue would seem to be the difficulties of handling framesets with non-visual browsers - presumably the same issues faced when printing them. Not being visually impaired, I have difficulty grasping the issues. Few Web pages take "accessibility" issues into account, and this is one of those issues.
For alternatives to using framesets, examine the source of this very page. It's big, it's complex, and it has no frames.
The biggest issue would seem to be the difficulties of handling framesets with non-visual browsers - presumably the same issues faced when printing them. Not being visually impaired, I have difficulty grasping the issues. Few Web pages take "accessibility" issues into account, and this is one of those issues.
For alternatives to using framesets, examine the source of this very page. It's big, it's complex, and it has no frames.
I agree with the fact that framesets make a lot of scenarios better, particularly reducing the overhead of a lot of pages. Unfortunately, they are a usability nightmare. Bookmarking, printing, etc. That's why iframe exists. It retains much of the utility of framesets, without having the same problems (when used sanely, of course). I supposed someone can replicate framesets using a bunch of iframes, if they really wanted to...
J.Ja
J.Ja
Could you list or point us to resources that explain why we should bother, other than "you just should"?
NOTE: I DO try to be compliant and work hard to code "properly", I just think it would be a good addition to this discussion.
NOTE: I DO try to be compliant and work hard to code "properly", I just think it would be a good addition to this discussion.
* Accessibility - many aspects of the HTML standard (and not enough, according to many accessibility experts) are geared towards helping disabled users use the Web.
* Faster rendering - valid HTML is easier for the browser to parse.
* More accurate rendering - this is, unfortunately, not always true. Also keep in mind, many rendering discrepensies are at the CSS, not the HTML level.
Just a few, I am sure other folks can name some more!
J.Ja
* Faster rendering - valid HTML is easier for the browser to parse.
* More accurate rendering - this is, unfortunately, not always true. Also keep in mind, many rendering discrepensies are at the CSS, not the HTML level.
Just a few, I am sure other folks can name some more!
J.Ja
It's along run because of how long and how much crap is about. One of the reasons you don't see strict compliance browsers about is because 99% of web pages would be inaccessible.
Why will it save resources?
If you wanted to parse HTML, how much more does it cost in development, testing, maintenance and enhancement time.
To deal with say something as simple as a missing close tag?
At the moment making every web page in teh world valid in one go, would cost a wee bit more, that's absolutely no reason not to at least sort out pages your are devloping as you go along though.
If nothing eles they load faster, more to the point predicting how different browsers will render them is far simpler.
Just proper closure would make a huge difference.
Why will it save resources?
If you wanted to parse HTML, how much more does it cost in development, testing, maintenance and enhancement time.
To deal with say something as simple as a missing close tag?
At the moment making every web page in teh world valid in one go, would cost a wee bit more, that's absolutely no reason not to at least sort out pages your are devloping as you go along though.
If nothing eles they load faster, more to the point predicting how different browsers will render them is far simpler.
Just proper closure would make a huge difference.
I don't have an issue with server-side code. I prefer it. It may take a little more work to get it right but it's well worth the effort. Whether you use server-side includes, print statements, or pulling code from a database. Take time to get it right and then it will save a lot of time down the road.
just chop out anything that is repeated and away you go.
for the uninitiated it's something like this
...html code up here and stuff....
[php include header.inc.php]
..maybe some code...
[php include main-menu.inc.php]
...more html code here
[php include left-sidebar.inc.php]
...you content code....
[php include footer.inc.php]
Then when you want to make a change, you change one file, once.
for the uninitiated it's something like this
...html code up here and stuff....
[php include header.inc.php]
..maybe some code...
[php include main-menu.inc.php]
...more html code here
[php include left-sidebar.inc.php]
...you content code....
[php include footer.inc.php]
Then when you want to make a change, you change one file, once.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
