homepage Welcome to WebmasterWorld Guest from 54.204.68.109
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 93 message thread spans 4 pages: < < 93 ( 1 [2] 3 4 > >     
Are you AFRAID of Validation?
pageoneresults




msg:3832108
 10:07 am on Jan 22, 2009 (gmt 0)

Okay, what is it that deters you from validating your documents? Is it the fear of running that first validation routine and finding hundreds of errors? Ya, I'll agree, those validation reports can be rather daunting to the uninitiated.

I was just performing a quality check on recently changed pages and WHAM! 47 errors on a page. Yikes, where did that come from. To the untrained eye this would have been enough to make me hit the back button and just avoid the whole process altogether. The site works and looks just fine, I have no idea what those 47 errors were, are, will be. ;)

I check the first error in sequence and I left out a closing </p> element. Run validation again and tada, all is fine. Yes, one closing </p> element missing and it caused a cascade of 46 other errors. When I first started validating (a long, long time ago), I remember looking at those errors and gasping. Then I realized that if you take them one by one as they are presented, you'll find that many of the following errors are a cascade of the ones up top. Did that make sense?

I know we've had topics in the past on the most common validation errors and I think it is always good to refresh memories and alert new Webmasters that there is nothing to FEAR when validating documents. It may appear to be somewhat major at first but once you start addressing the errors in sequence, you may be able to go from 300+ to under 50 with just a few corrections in your HTML. The example I provided above with the closing </p> element is a primary error that many run into. Just one or two missing and/or incorrectly nested elements and validation is a mess.

Remember, take the errors one at a time and start at the very top of the validation report. Don't jump down to the middle of the report as that won't do you any good. You have to address the errors in sequence so that you don't end up "chasing the cascade".

W3C Markup Validation Service
[validator.w3.org...]

W3C CSS Validation Service
[jigsaw.w3.org...]

W3C RDF Validation Service
[w3.org...]

How many errors do you have on your home page this very moment? Let's get them corrected. No code dumps please. Just the first error in sequence and we can work from there. If you have hundreds, well, you'll probably need to follow along and work most of those out yourself. There will be many here who will most likely have upwards of 200, 300 and even 500+ errors. If you have errors in this number range, this is something that should be looked at soon as there are surely some in there that are potentially fatal in nature. I can understand a handful of common errors. But not a high number of uncommon errors, those could be trouble.

 

swa66




msg:3833539
 11:12 pm on Jan 23, 2009 (gmt 0)

If you don't value validation, what's there to help you make sure that your pages actually get interpreted like what you meant (since that what you send *is* unclear and open to interpretation).

Think what happens if your customer sees the website you made for him on something you have no chance of testing against (their new fridge with a built-in browser, the imode phone of their Japanese business contact while in Japan, ...)

To me the _only_ thing we have to make sure what you design has even a remote chance of being future proof and working on browsers you cannot test against is to make sure it validates. Sure MSFT's poor excuse for a browser needs special care, but that's easy enough to shield from the rest of the browsers.

"But GOOG doesn't validate": well GOOG has offices around the world, so they can get away with testing things that would be prohibitive costly for us (trip to Japan to buy a collection of imode phones to test it there on an imode capable network ?) and also they are more than big enough to get tested by those making the devices.

Bottom line for me: validation is critical.

From questions we see in e.g. the CSS forum it is also causing many problems with people's layout not obeying what they think they've written.

eg:

...
<p>
test
<ul>
<li>one
<li>two
</ul>
not obeying the "p" style
</p>

Guess what happens if the try to make a <p> be blue ? Well the browser will insert a virtual "missing" </p> before the <ul> ...

So is it CSS not working (what many a webmaster thinks) or if it that your code is basically nonsense and could be fixed easily...

The little logo's: I don't care much for them in general (like I said, web developer toolbar is easier) although -after seeing one of P1R's sites-: it can be done with style!

tedster




msg:3833543
 11:17 pm on Jan 23, 2009 (gmt 0)

That's got to be one of more unintuitive CSS situations - it really messed me up when I first began using CSS. Very often a list is, semantically, part of the paragraph!

mattur




msg:3833566
 11:54 pm on Jan 23, 2009 (gmt 0)

Well, 8 years ago I thought validation was the stupidest thing I'd ever heard - why validate to a spec that no browsers actually implement?

Nowadays validation is an essential part of my work flow. It's QA for HTML code. Indispensable. Still got 16 browsers installed for testing though ;)

g1smd




msg:3833579
 12:09 am on Jan 24, 2009 (gmt 0)

I think where the initial problem of "coding" comes from is the tool bar options in WYSIWYG editors.

With hindsight I might have expected the tools to be grouped with things I could do to headings, paragraphs, lists, tables, forms, images - the major block elements - but instead they were grouped in some other non-intuitive way that drove the user away from understanding the structure of the code they were creating.

pageoneresults




msg:3833806
 3:32 pm on Jan 24, 2009 (gmt 0)

The little logo's: I don't care much for them in general (like I said, web developer toolbar is easier) although -after seeing one of P1R's sites-: it can be done with style!

Thank you! Pssst, don't tell anyone that I do everything in FrontPage 2003 mostly. All ASP.NET I do in Expression Web. Blasphemy!

So, how many errors do you have on your home page now? That's a general question for everyone. I don't think I've seen any exact numbers yet from anyone participating. Of course I have 0 errors hence the reason I can get away with this topic and getting under people's skin. I came prepared to do battle. :)

victor




msg:3833931
 8:00 pm on Jan 24, 2009 (gmt 0)

I have zero errors (against Doctype 4.01 Strict).

That's true for the home page and all other pages.

I see no competitive advantage in writing code that is buggy or may be interpreted differently by different browsers.

Nor do I see any competitive advantage in tolerating HTML generating tools that are buggy. If they cannot produce syntactically correct HTML (their main mission!) why should I trust them at all?

Validated code is simply faster to produce (no need to extensively research HTML generators to find the one that produces the sort of errors you want; just go for one that works instead) and safer to run across a wider range of user devices.

poppyrich




msg:3833978
 10:11 pm on Jan 24, 2009 (gmt 0)

Call me grumpy, sneezy, sleepy, invalid, whatever.

All I'm saying is this:

If your page "validates" all it means is that it conforms to a set of rules put forth by an industry trade association.
They may be smart rules, they may be dumb rules, but that's all we're talking about.

I don't think that's worth anybody beating their chest about.

g1smd




msg:3833980
 10:27 pm on Jan 24, 2009 (gmt 0)

No. That's not "all" it means at all.

It means it has the best possible chance to work in current and future browsers.

lavazza




msg:3833982
 10:36 pm on Jan 24, 2009 (gmt 0)

They may be smart rules, they may be dumb rules, but that's all we're talking about.
If you were in the planning stages of developing a browser for your very own invention like iSunglasses or eSnickers, what set of rules do you think it might be worth adhering to?
willybfriendly




msg:3834114
 5:31 am on Jan 25, 2009 (gmt 0)

Home page validates on at least 4 sites. A fifth is a mess, but it is a work in progress, and the clients are demanding all kinds of eye candy that muddies up the waters, not to mention interferes with usability.

I figure when they get tired of 3 mouse clicks to log out they might give up the fance sliding JS menu. That will be more $$ for me, since they ignored my best advice.

Then I suspect the dropdown menu that obscures the sidebar menu everytime a pointer passes over it will go. More $$$.

It will, in time, validate;)

poppyrich




msg:3834269
 5:21 pm on Jan 25, 2009 (gmt 0)

@lavazza

The answer to your question would be, first, I would completely ignore the W3C spec and make sure the browser I was writing had a solid "Quirks" mode, as does every browser in mainstream use today. (IE, FF, Opera, Chrome, Safari - you name it.)

As far as "dumb" rules are concerned:

When theory precedes practice, as it does with the W3C specs which are, to a large extent, "best guesses" as to what authors will want and need, there is, first, a tendency to complexify and make the thing a wish list that just keeps getting longer and longer.
(Visual: I always stroke my beard when using the word 'complexify'. A global setting.)

See this post for an example:
[webmasterworld.com...]

phranque




msg:3834371
 10:48 pm on Jan 25, 2009 (gmt 0)

I would completely ignore the W3C spec and make sure the browser I was writing had a solid "Quirks" mode

how would you identify a "quirk" if you have completely ignored "normal"?

poppyrich




msg:3834723
 2:40 pm on Jan 26, 2009 (gmt 0)

@phranque

Cute - there's gotta be a name for that particular kind of argument. I KNEW I shoulda gone on and taken Philosophy 102.
;)
Anyway, how did they do it before the official release of the final spec? Say 1997?
Yes, Quirks was named "Quirks" to differentiate it from "Standards" but that doesn't mean the kind of rendering described by the name didn't exist prior to our having given it a name. Quirks was an only child and then it's parents had another kid.

willybfriendly




msg:3834883
 5:42 pm on Jan 26, 2009 (gmt 0)

Quirks was an only child and then it's parents had another kid.

Nah, it was an orphan child, and then it got parents.

Ignore standards at your own peril...

pageoneresults




msg:3834908
 6:21 pm on Jan 26, 2009 (gmt 0)

Ignore standards at your own peril.

My question then becomes, what standards and/or model are you (not you specifically) using to construct your pages? You had to start somewhere right? So, you started with a broken model to being with huh? I know, that's a bummer. And you know what? It is an ongoing challenge for sure.

If the HTML specification states that a certain element be formatted a certain way, what is the major issue with this? I don't understand the constant bickering over standards. They've been there almost since the dawn of the Internet.

Dave Raggett's Introduction to HTML < Remember that guy?
[w3.org...]

I don't really see that much has changed since 1995 when it comes to HTML markup and its proper syntax. I've been through those documents many times and in reality, not much has changed with the HTML markup specification from a "basics" standpoint.

The Wiki has an excellent overview showing the transition of HTML from 1991 forward. Kudos to the Editor for that page...

HTML
[en.wikipedia.org...]

The first publicly available description of HTML was a document called HTML Tags, first mentioned on the Internet by Berners-Lee in late 1991.[2][3] It describes 22 elements comprising the initial, relatively simple design of HTML. Thirteen of these elements still exist in HTML 4.

Okay, I know, that only covers the barebone basics. But, you've got to start there, don't you? Now, where did all the errors come in since the specifications were established? People introduced them. The developers of software introduced them. There's this overall disregard for standards that permeates in the development communities because "they" keep breaking things. If the spec says to do it this way, well, how else can you do it without breaking something? I get really confused in this regard. You're forcefully breaking your HTML. That doesn't make sense to me. ;)

Hey, at least the President gets IT! [WhiteHouse.gov...] validates. Anytime we have these discussions, I'm pointing directly to the White House. They did it!

poppyrich




msg:3835273
 1:10 am on Jan 27, 2009 (gmt 0)

After this thread, I really AM afraid to validate!

swa66




msg:3835408
 8:39 am on Jan 27, 2009 (gmt 0)

Back in 1994 -when I learned HTML- , the common expression was that people producing HTML were to make sure it was valid/well structured; the User Agents' developers were to make sure to be liberal about interpreting if the HTML author messed up.

I think that liberal rendering is the root cause of invalid HTML out there: "This browser renders it, so there's no harm done". Till they then find a browser that doesn't render it properly and expect the browser to change instead of they cleaning up their mess themselves.

Steerpike




msg:3835416
 9:00 am on Jan 27, 2009 (gmt 0)


I believe very strongly in validation. Or at least I did (and still do where possible), but given most of my work currently involves heavy use of progressive enhancement to add relatively complex, unobtrusive javascript and I prefer to focus on accessibility; I've turned from validation towards implementing WAI-ARIA.

Given that aria isn't part of the specs of xhtml 1.0 or html 4 (or 5 that I can see - *sad*) it means making a depressing choice between that happy green tick and a hopefully improved experience for a generally overlooked segment of users in today's internet.

lavazza




msg:3835426
 9:17 am on Jan 27, 2009 (gmt 0)

add relatively complex, unobtrusive javascript and I prefer to focus on accessibility
The two are compatible?

Whatever...

I think that you'll find that scripts that are sourced externally (from the same or another domain)
e.g.
<script type="text/javascript" src="http://www.example.com/scripts/myUglyScript.js"></script>
or
<script type="text/javascript" src="../scripts/myUglyScript.js"></script>
are not parsed by the w3c and WDG [htmlhelp.com] validators

johnnie




msg:3835446
 9:44 am on Jan 27, 2009 (gmt 0)

Pages that have hundreds of errors oftentimes have problems with closing a tag. Incorrectly escaping special characters in a URL is also a biggie.

Steerpike




msg:3835520
 11:30 am on Jan 27, 2009 (gmt 0)

The two are compatible?

Whatever...

I think that you'll find that scripts that are sourced externally (from the same or another domain)
e.g. <script type="text/javascript" src="http://www.example.com/scripts/myUglyScript.js"></script>
or <script type="text/javascript" src="../scripts/myUglyScript.js"></script>
are not parsed by the w3c and WDG validators

I'm not sure if you mean complex and unobtrusive are incompatible or if you mean javascript and accessiblity are incompatible?

Either way, they aren't. Complex scripts should be just as unobtrusive as simple ones and javascript, done right, should offer little issues in terms of accessibility.

Sourcing a script externally has nothing to do with validating accessible WAI-ARIA compliant markup as aria specs revolve around roles and attributes that don't exist in xhtml1.0 (the 'role' attribute exists in xhtml1.1) or current html specifications.

Frankly I support wai-aria over validation because it increases usability for a specific group of users who are most at risk of being marginalised by current web trends. I also believe that a little lack of validation now will be made up in the future when aria *does* validate because then I will have validation and my users will have the benefit of more usable applications without having to wait for years.

[edited by: Steerpike at 11:40 am (utc) on Jan. 27, 2009]

pageoneresults




msg:3835523
 11:38 am on Jan 27, 2009 (gmt 0)

Pages that have hundreds of errors oftentimes have problems with closing a tag.

That is probably one of the most common errors. It occurs quite a bit when things are nested incorrectly and you end up with missing closing elements in the nesting process usually through a WYSIWYG interface. I'm going to guess that a majority of the errors are being caused by WYSIWYG too. In fact, I know they are. After working with various editors over the years, I've seen the code they produce and I know where the errors are going to creep in if the program is not used correctly.

Keep in mind that when you are validating a document, one error at the top of the html may cause an untold number of errors below it, in the cascade. So, fix the ones at top first and there is a good chance that a majority of the cascading errors are going to go away.

Semantic Data Extractor
[w3.org...]

Ever use the above tool? It's a nice little quality check after all is said and done with to see how well you've marked up your document semantically. While not 100% foolproof, it does give you a good overall feel for what that document might look like from a semantic standpoint.

So, what stops you from validating again? I know, it is just not worth the time and effort. But, what if Google made an announcement tomorrow that it is now using semantics in its algo and those documents that are semantically correct will score higher overall? Would you change your mind about validation then? Do we need something in writing from the search engines that say poorly written code may cause improper indexing and your document may not perform as it should? Well, don't hold your breath just yet waiting for that announcement. You'll have to read between the lines for now. ;)

Yes, I know, semantics and validation are two different things. From my perspective, they work hand in hand. If the HTML is borken somewhere, hopefully the indexer can interpret the remaining parts of the document and extract the correct semantics.

httpwebwitch




msg:3835594
 1:11 pm on Jan 27, 2009 (gmt 0)

Not everything I do is valid.
Well-formed: definitely
Strict XHTML: predominantly
semantically sensible: usually
# of Javascript errors tolerated: zero
rendered properly by IE,FF,OP and GC: always

If the pages end up being valid, it's a sign I didn't screw up. I'd guess most of my pages do validate, especially since I stopped using the @target attribute. But I rarely check. When I do, I'll accept a few warnings, but no errors.

I should admit, I am also turned off by W3C "I'm valid!" chicklets. They remind me of the "Best viewed in Netscape" chicklets we used in the late 90s. It's not like excelling at sports and winning a trophy. It's like going to a trophy shop and buying one, having it engraved with your name and bringing it to school to show your friends how much of a git you are. One of my employees put them on one of our sites the other day... He's proud that the entire site validates 100% clean. I'll let him keep the chicklets on there for a while... then he's fired.

(I am kidding D, you are not fired)

gdjones83




msg:3835597
 1:19 pm on Jan 27, 2009 (gmt 0)

I validate every page after I update or create, I just think its good practice to have valid code and makes it easier for the crawlers. I just use the link in the web developer toolbar for firefox (obviously then check everything in IE6 or 7 again before deeming it complete)

However I have to say its certainly not the be all and end all for me as the minute I insert an swf or flv I've automatically got 8+ errors, I've tried in the past to find a ways to avoid these but have just learnt to ignore them nowadays.

Steerpike




msg:3835617
 1:37 pm on Jan 27, 2009 (gmt 0)


However I have to say its certainly not the be all and end all for me as the minute I insert an swf or flv I've automatically got 8+ errors, I've tried in the past to find a ways to avoid these but have just learnt to ignore them nowadays.

You may find this unobtrusive swfobject [code.google.com] useful if you haven't already discovered it.

gdjones83




msg:3835662
 2:26 pm on Jan 27, 2009 (gmt 0)

Cool, I'll definitely take a look into it, I've tried others that say they're valid html but still throw up errors. I'll report back on whether it works for me.

ergophobe




msg:3835776
 4:57 pm on Jan 27, 2009 (gmt 0)

How about this for a why I don't validate - if I have any affiliate links from Amazon, Commission Junction, etc, the html generated by their code doesn't validate and one single affiliate link can generate 20 errors. Put a couple on a page and you're hosed.

How do you deal with that? Pick better affiliate networks perhaps?

pageoneresults




msg:3835777
 5:01 pm on Jan 27, 2009 (gmt 0)

How do you deal with that? Pick better affiliate networks perhaps.

I've actually gone to my affiliations and have told them that if they could not provide valid affiliate code, I would not sell their product. Believe it or not, both that I've gone to in the years have fixed their code to be valid.

If you've got third party feeds coming in and they are not valid, talk to the feed providers. Most will listen to the valid complaints and fix the issues. They can easily update their code to be "clean" and someone just needs to let them know.

ergophobe




msg:3835789
 5:18 pm on Jan 27, 2009 (gmt 0)

I'm sure I'm too small for CJ to care about, but it's a good point.

As for feeds, if they were predictable, but non-validating, I could of course parse them myself. The problem is those damn javascript and iframe links where I don't have control of what gets generated.

@poppyrich. I don't think this assertion was really answered:


If your page "validates" all it means is that it conforms to a set of rules put forth by an industry trade association.

Yes, a set of rules known as a Document Type Definition. AFAIK, all SGML documents should have a DTD and that was true long before anyone thought up HTML. It means that you follow a spec, perhaps arbitrary, perhaps stupid, but if you don't like the rule, invent your own spec, with your own DTD and validate to that. The document would then still be valid and if your Doctype takes off, browser manufacturers will know what spec they should accomodate.

Yes, browsers run in quirks mode, but that's because they follow the Prime Directive of Software Development: Be Strict in What You Produce and Tolerant in What You Accept.

Browser developers try to accept everything they possibly can, following the latter half of the Prime Directive. Ideally, content producers would be as strict as possible in what they produce. And web developers need to follow both parts (for God's sake, enough of rejecting my phone number because you expect dashes in certain places in the US and . in other places in France). Everything works better that way.

Alcoholico




msg:3835851
 6:23 pm on Jan 27, 2009 (gmt 0)

In regards to this topic, a bare bones, straight out-of-the-box install, of a SharePoint site, before adding any content or modifying any of the templates generates;
308 Errors, 95 warning(s)

Why did you go that far? Have you tried to validate THIS page? Not that bad though validator reports 43 errors and 4 warnings

Trace




msg:3835875
 6:39 pm on Jan 27, 2009 (gmt 0)

Why did you go that far? Have you tried to validate THIS page? Not that bad though validator reports 43 errors and 4 warnings

...because it's the framework I'm forced to work, hence why none of my sites will ever validate.

I've actually gone to my affiliations and have told them that if they could not provide valid affiliate code, I would not sell their product. Believe it or not, both that I've gone to in the years have fixed their code to be valid.

This statement, makes no sense to me at all.

How could you threaten to not sell their products? That would just mean it's money out of your pocket, for what? What difference would it make if they make their code valid? Obviously they code the already had worked, else no one would use. If they change it to valid code, it will look the same, will act the same and will sell the same amount of product as it did.

This 93 message thread spans 4 pages: < < 93 ( 1 [2] 3 4 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved