W3 Validation/Standars

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • ae3799t
    New Member
    • May 2012
    • 21
    • 4.2.x

    [Forum] W3 Validation/Standars

    Does vBulletin 4.2 Validate out of the box?

    After having a couple of issues, I ran our main forum page though the w3 validator and got 87 errors. Just wanted to know if we created all those, or if vBulletin comes stock with errors.

    If vBulletin is supposed validate on first install, what is the recommended way to get back and still keep the changes? Are there any?

    I created a new "No Parent" style and it gets the same errors, and the template do not show any changes. I guess the style is created from the templates that have been changed, which makes sense. Thanks
  • Mark.B
    vBulletin Support
    • Feb 2004
    • 24286
    • 6.0.X

    #2
    No it won't validate 100% out of the box but it is close enough for general purposes.

    The CSS in vBulletin 4 gives some validation errors because it needs to be compatible with IE6, 7 and 8 (although only IE8 is technically supported from 4.2 onwards, the decision was taken to leave older fixes in), also FireFox for some of their older versions.

    The errors are not that important in the scheme of things - you can fix them yourself if you want 100% validation but you will potentially cause problems, certainly for IE8 users which is still a widely used browser.

    The code in vB4 is valid CSS but it still using various tweaks in order to support some older browsers.

    My advice - don't worry too much about W3C validation, they aren't even always right about everything! Concentrate on testing your site in as many modern browsers as possible and make sure it renders ok in all of them.
    Last edited by Mark.B; Mon 26 Nov '12, 11:17am.
    MARK.B
    vBulletin Support
    ------------
    My Unofficial vBulletin 6.0.0 Demo: https://www.talknewsuk.com
    My Unofficial vBulletin Cloud Demo: https://www.adminammo.com

    Comment

    • Zachery
      Former vBulletin Support
      • Jul 2002
      • 59097

      #3
      To add to what mark says, being valid can be a good thing, however the validation parser catches things that are not always true, or is far too strict about. Its more important that the product works, esp when it comes to search engines being able to spider content and browsers showing things correctly.

      Comment

      • ae3799t
        New Member
        • May 2012
        • 21
        • 4.2.x

        #4
        I am not too concerned about the CSS. The search engines do NOT download the .CSS files and if there is a bug, it will only distort the presentation. Of course to validate is better than not to, for forward compatibility, if for no other reason. Not sure if the validated .CSS will load faster than the Non validated, like the html & xhtml can, if the browser is not forced into quirk mode by non validated code.

        So forgetting about the .CSS, it is the xhtml that gave me 87 errors on the form.php (actually high errors on all pages). And as I said, the problem is that we are having an issue.

        The bad part about not validating, is you have no real idea if the issue was with the original code, or a change that was made. Sure, you guys say your code is good, but lets face it, there is no one selling a product that does not make that same claim. And if you guys do any serious coding, you know very well that the code can have a problem that does not show up until a change is made, even when that change is valid. Besides, it is not the best of practices, to tell your users that they should test in all kind of browsers. After all, that is your job. Your selling a product and you owe it to your customers, as well as yourself to make that product as well as you possibly can.

        I agree that the W3 can be very strict, but good programmers all over the world, know how to keep their code clean. Or at least reasonably clean. If there are a few documented errors for backward compatibility, that is certainly understandable, but if it is an excuse for poor programming, then of course, it is not.

        I started in 2003 using FrontPage and it was full of deprecated tags and issues that would not validate. It still worked, but it also clouded the issues that needed to be corrected. I had to write our own DTD file to get rid of the non essential errors, just so I could make sure we corrected the needed errors.

        I would guess that most to of the errors are from changes we made, but it would be helpful to know what was there before we started to make changes. We should have validated before we started to make any changes. Thanks

        Comment

        • XiTCLUB
          Senior Member
          • Jan 2010
          • 190
          • 4.0.x

          #5
          I am agree with @ae3799t.

          as i validated my site i got 105 errors, some common errors was due to not adding "type" attribute to "<script>" tag. however its not necessary but it is a good programing practice to add it. as a Front-End UI developer i never missed these little things ever.

          and what do you mean by
          The errors are not that important in the scheme of things - you can fix them yourself if you want 100%
          its your responsibility to produce a product with no errors or at least less errors

          I know that fro a big product it difficult for 100% validation but it also cant be 100's

          Comment

          • Mark.B
            vBulletin Support
            • Feb 2004
            • 24286
            • 6.0.X

            #6
            Originally posted by XiTCLUB
            I am agree with @ae3799t.

            as i validated my site i got 105 errors, some common errors was due to not adding "type" attribute to "<script>" tag. however its not necessary but it is a good programing practice to add it. as a Front-End UI developer i never missed these little things ever.

            and what do you mean by

            its your responsibility to produce a product with no errors or at least less errors

            I know that fro a big product it difficult for 100% validation but it also cant be 100's
            See Zachery's post above. 100% W3C validation is not always a good thing, nor even desirable. And as I myself stated, they have been known to be wrong on more than one occasion.

            Have a read of THIS, among many other articles that deal with the problems of over-reliance on 100% validation.

            Also to achieve this validation all the legacy browser fixes would have to be removed from the code. You can't have 100% validation when you've catered for browsers that cannot render 100% validated code!
            MARK.B
            vBulletin Support
            ------------
            My Unofficial vBulletin 6.0.0 Demo: https://www.talknewsuk.com
            My Unofficial vBulletin Cloud Demo: https://www.adminammo.com

            Comment

            • ae3799t
              New Member
              • May 2012
              • 21
              • 4.2.x

              #7
              I do not think anyone is arguing for 100% validation, which seems to take the focus off the importance of validation. And speaking for myself, I do not care about CSS validation.

              What I want is code that validates the HTML/XHTML for all but a few issues and those issues should be documented, showing that there are valid reason for them.

              For example, Facebook and Twitter interfaces will generally not validate because they use OpenGraph, which will in general not validate to XHTML. In this case, it is generally better to allow the validation errors, then to beat yourself up in an attempt to get them to validate. I say generally because there are ways to get them both to validate. Still I do not think that validation is beneficial in this case. Another reason, might be that the validator is in error.

              The point is that these errors should be documented, so that the forum owners will know that they do not need to worry about those particular errors and can focus on the errors that do matter. This will also insure VBulletin mangers that coders are not using the lack of validation as an excuse for poor programming practices. It will also create live document list of all of the issues that need to be set aside, but should not be forgotten.

              As an example: Our forum has quite a few validation errors on non-escaped ampersands. i.e. Using "&", instead of "&amp;". Normally this error will not cause any problems, if it is understood why they are there in the first place. i.e.. Text in the document is one thing, but what if those validation errors are caused by VBulletin code and that code does not make sense? The cause of these errors on our main page is from variables written like the following. Specifically the 4 underlined variables.

              <a href="forumdisplay.php?do=markread&markreadhash=guest">Mark Forums Read</a>
              <a href="search.php?do=getdaily&contenttype=vBForum_Post">Today's Posts</a>


              It would seem that these variable should not be listed in the webpage, but instead the data contents of those variables should be written. So beside the fact that all of these generated errors can hide other more important errors, they make it difficult too determine whether we caused these by modifying the templates, or if they were errors in VBulletin's code from the start. This puts an added and unnecessary burden on us. Are we spinning our wheels by trying to correct these, or are these errors showing us a more pervasive errors, that are causing our issues with the hide tab, not working properly?

              ---

              Rather then point to 100s of articles showing the benefits of validating, I'll would like to comment on the article already pointed to.

              Although I think the writing is very good in the article "Problems with Using Website Validation Services", it was all over the place in it's efforts to reduce the importance of validation tools. Alexander clearly mixed apples and oranges by comparing html validators, with CSS validators, with screen readers, with language translators, which are NOT validators at all. The opening sentence set the stage for the idea that only beginners use the validators, which I find to be misleading. I understand the basic premise, which I agree with, that the validators are not the Golden fleece to end all web programming, However, the validator is an extremely important tool that should be used by all web designers. And weak articles like this one should never be used as an excuse to cover-up poor programming practices.

              The html/xhtml validator verifies syntax, not context, so Alexander's argument is weak. Comparing it to a language translator is almost ludicrous. Comparing it to the front end of a compiler would be much more appropriate. We may not think of a complier as a validator, but think about it... A compiler goes through the source code and checks for the syntax before trying to "translate" it into assembly language and finally compiling it into machine language. If the syntax (code) is written incorrectly, the complier indicates the issues. This is synonymous to what the validators do. They basically check the web page html/xhtml syntax. If an "if" statement does not have an "endif", the compiler indicates an error. If the "head" tag does not have an "end head" tag, the validator will indicate an error. Of course there is differences, but the comparison makes far more sense then to compare the validator with the screen language translator.

              The article compares the CSS validator, which is the closets comparison made. Still there is a significant difference. The CSS can be more easily checked by humans, as they look at the web page to see if everything looks in place. Humans do a very poor job of reading html/xhtml. Sure if there is a significant error and that particular browser cannot handle it by switching to quirks mode, the human can tell there is an issue. However if a table does not render right because of a CSS issue, the programmer knows exactly where to go to fix it. If the same table does not render right because of an html/xhtml error, it may be caused by incorrect html/xhtml syntax dozens of lines before the table, even if the table is coded correctly.

              The screen reader is NOT a validator, either, but I supposed it could be used to check a web page, but lets face it... Who uses a screen reader to check their web pages, but does not use a validator?
              Alexander made sever good points, and had the title been something like, "Life after the validator" and was written appropriately, the article would have been much more useful.

              Humans are very high prone to error. Statistically, humans are 3 sigma. On average they/we make about 45,000 errors in every 1 million opportunities to make those errors. Systems and machines are needed to help us get to 6 sigma (3.4 errors/million opportunities). In fairness to this article, validators are created by humans and humans make many mistakes, so the end result is that validators do indeed make mistakes, but lest face it, when it comes to html/xhtml, I would much rather have 3.4 errors per million, then 45,000. Wouldn't you?
              Last edited by ae3799t; Tue 4 Dec '12, 7:41pm.

              Comment

              • ae3799t
                New Member
                • May 2012
                • 21
                • 4.2.x

                #8
                Just wanted to update this thread with a conclusion. A bug report is being worked on now.

                The validation errors in VB4.2.0 caused by unescaped ampersands, will be fixed in the next release 4.2.1. Thanks to Zachery for pointing this out.

                Comment

                widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                Working...