SitePoint Sponsor

User Tag List

Page 2 of 6 FirstFirst 123456 LastLast
Results 26 to 50 of 145
  1. #26
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    The website still works... in the small percentage of available user agents that you have tried it in, which do their best to fix dodgy code.

    If you don't validate it, it isn't an (x)html document. Simple as that. The answer to the question is 'never'.

  2. #27
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    It means the markup is of poor quality.
    I have to disagree. There may just be a slight mistake somewhere in your code.

    But an HTML slight mistake is not really a problem, no matter what you can hear. It's not like it will ruin a database or expose sensitive client data. I think people take it way too seriously ("I'm a good coder I have the little logo that proves it").

    I mean it's better if your code validates, but it's the last thing you should worry about (browser rendering is far more complex and has more than often not much to do with validation, how schocking!)(code generated by dreamweaver validates... have you tried your hands at such code? it's a hell...), and it shouldn't make you lose more than 0.01% of the time you took to build your website.

    I know I'm gonna get shot at for what I'm going to say, but in the end, no one really cares if your website does validate or not, except people who have time to waste, enough to validate your pages and scream, scream, scream when they realize they don't. No one but their neighbors hear them.

  3. #28
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    If you don't validate it, it isn't an (x)html document. Simple as that. The answer to the question is 'never'.
    There is no such thing as (x)html document

  4. #29
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    It's not a document? Funny, it has a DOM...

    I know I'm gonna get shot at for what I'm going to say, but in the end, no one really cares if your website does validate or not, except people who have time to waste, enough to validate your pages and scream, scream, scream when they realize they don't. No one but their neighbors hear them.
    Generally this is true. Customers do not check to see if a page is validated. They want it to work.
    And lots of stuff out there does, somehow by the grace of their gawds, work. Not sure how, and often need to get rewritten cause o noes, a new browser came out!! or something.

    I do check code. I don't run it through a validator, I just look at it. Lots of sloppy things I dislike are perfectly valid. But I will tell my boss, ok these people are total retards, dont hire them... THESE people seem to actually know what they're doing, they're ok... oh look, one of you competitors is high on teh Googles and has mostly valid (and otherwise well-written) markup, while this other one is using bad code and spammy garbage everywhere, making life a pain in the butt for customers in hopes of reaching more googliebots...

    I do notice people with invalid code often have MORE code (possibly to fix any errors coming from the invalid code?) so if invalid code is making you write MOAR CODEZ then obviously validating will help increase things like loading speeds etc as you slim your code down. They do say, code is most beautiful and works best when you can't remove anything more from it.
    But this is only a generalisation.
    Last edited by Paul O'B; Nov 14, 2008 at 05:51. Reason: mind your p's and q's

  5. #30
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok I re-read the first of my two posts, and I realized I wasn't really answering the thread owner's question.

    Page validation is never "not necessary". It should always validate. But when it does not, the world keeps on spinning, no matter what some may believe. Once again, a security flaw is a real problem, a "poor markup" is not a real problem, even if it would be better to have it......rich? It's just something you'll fix one of these days, when you'll have time. And write your own code, don't let a soft do it for you. 99% of your problems will be fixed.


  6. #31
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    It's not a document? Funny, it has a DOM...
    And yet it's possible it fails to validate as a valid document... and yet the browser displays it (even though it's not a document since the document itself failed to prove it is one). I'm getting lost

    Quote Originally Posted by Stomme poes View Post
    then obviously validating will help increase things like loading speeds etc as you slim your code down
    Caching techniques, database optimization, lazy include and instantiation, these are strategies that make your pages load quicker.

    But once again, I'm talking like I'm encouraging poor markup. All I'm saying is, this matter shouldn't be addressed with so much anxiety and purism.

    Also, I know that when you don't server-side code, it can be hard to find something that must look really important, like "the crucial point of one's discipline". The quality of a page mark-up is this thing as far as I have noticed for most HTML-only coders. It's just... I don't know... It's not that important in the end.

  7. #32
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One more thing you should really worry about: how does your code look before being processed by the server.

    Rendered HTML code may validate, but if you open the actual .php page, it could very well be a really really scary experience. Talking about "not rewriting code again and again", this is where I would start. Clean php, separation between business logic and presentation logic, these are things that really matter if you don't want to lose yourself in your application as it grows. Validation comes last.

  8. #33
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    That is more an issue of maintainability. The user doesn't care about that. The HTML that comes out the end is more important, it's what search engines see, what users see, what screen readers see etc. The code behind the back is entirely up to you... I agree it's a good idea to keep it neat, but it is less important.

  9. #34
    SitePoint Wizard bronze trophy Kailash Badu's Avatar
    Join Date
    Nov 2005
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have found that the standard compliant code is more maintainable and therefore easy to modify or work with. So I will generally try to make my code comply to standards as closely as possible. Having said that, I wouldn’t, however, be very adamant about the validation as to go to obscene lengths just to make sure that code is fully valid. Of course that is as long as it is not seriously malformed and displays well in all target user agents.

    The big companies don’t care about it because it doesn't hinder their business in any way. There are more important things to allocate resources to. Validity is pretty low on their priority list at the moment. pure business sense.

  10. #35
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,881
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Veus View Post
    Not really the same, as the website still works. There are no 'leaky parts'.
    Can you be sure about that? The website might look as though it works, you might have tested it in more than one browser, but that doesn't mean that it will work in all browsers on all systems.

    Yes, sometimes it's OK to let a known error go through, if you know exactly what has caused the error and what effect this will/won't have, and there is a good reason for needing the invalid markup.

  11. #36
    SitePoint Wizard bronze trophy Kailash Badu's Avatar
    Join Date
    Nov 2005
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D
    The website might look as though it works, you might have tested it in more than one browser, but that doesn't mean that it will work in all browsers on all systems.
    It doesn't need to.

  12. #37
    SitePoint Evangelist Ed Seedhouse's Avatar
    Join Date
    Aug 2006
    Location
    Victoria, B.C. Canada
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Many validation errors don't cause any customer unhappiness. Like, using <embed>, makes everyone happy and seems to work pretty well (I'm still not able to get <object>s to show their alternative children if the Flash doesn't load or the pathname is wrong in more than 3 browsers using Flash Satay...) so long as you have the plugin in the first place.
    That they may not cause problems now doesn't mean they won't later.

    Suppose IE37 suddenly starts to support real xml and real xhtml. And according to the standard they make invalid sites invisible. Now you have to scramble to recode all your invalid code perhaps years or decades after you've written it.

    If you have standards compliant code in the first place and some new browser fails to show it right you have a complaint, and you can report it as a bug. But if your code isn't compliant with the standard who do you complain to?

    Seems to me the very minor inconvenience of making your code validate now is cheap insurance well worth it to avoid the immense effort you may have to go through in the future when compliant browsers stop supporting your legacy code.

    The levees in Louisiana worked just fine until that darned hurricane came along...
    Ed Seedhouse

  13. #38
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Location
    Columbus, OH
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It doesn't need to (I no longer even bother checking for IE5 or NS compatibility, and I keep waiting for the last 6% of IE6 users to go away) but you want to hit the broadest possible audience with the least amount of effort, and valid code will get you 90% of the way there.

    That said, there is one major area (in my limited experience) where otherwise acceptable code does not validate, and it's probably an area where a bunch of these sites fall flat: custom attributes in form inputs. Programmers seem to find it a convenient way to pass proprietary values, particularly when implementing an AJAX-driven feature like "suggest" dropdowns. Browsers happily ignore values that do not apply to the input element, but validators will cry foul when they run into "action=suggest" or "autocomplete=on". I searched around for ways to get this to validate, but ultimately just took the code out because of the effort that seems to be required to work around this otherwise-harmless phenomenon.

    Another one I thought was strange was in a "script" element on our homepage. The script is wrapped in a comment declaration, and about halfway through the script is a FOR statement with the decrement operand "--". It causes the validator I use to think I am trying to close the comment and reads it as an error. It's one of the few remaining errors in a site that mostly validates in X1.0 Strict, but even these few errors I've been rubbing out don't even get noticed if you validate in Transitional.

    I retooled the site to validate in Strict as much as possible, and I've had to employ a few inelegant fixes by dropping "style" elements directly into the page until I can go back and clean it up, but that actually is sort of the point that I am laboriously trying to reach. Changing our code to Strict has forced me to write cleaner code that is actually easier to maintain. The only thing that's killing me is the loss of the "align" attribute, which renders so many things nicely in HTML, but is not always handled in the exact same way with the CSS properties "float" or "text-align". But I'm still learning as I go.

  14. #39
    SitePoint Enthusiast
    Join Date
    Jun 2008
    Location
    Ahmedabad India
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Take this advice.
    If you are not at all concerned about how Search engine crawls your site, you should not validate. If you are and you want to achieve success in SEO, you should immediately validate......This must be the simplest answer in this thread :-) ....

  15. #40
    SitePoint Evangelist Ed Seedhouse's Avatar
    Join Date
    Aug 2006
    Location
    Victoria, B.C. Canada
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Validation is easy and cheap, in fact it can be automated.

    Humans tend to underestimate the consequences of future risks, and it often comes back to bite them. AIG felt perfectly safe insuring these "deriviative" thingies. What could possibly go wrong?

    Oops! :-)
    Ed Seedhouse

  16. #41
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I'm less concerned about future versions of current browsers, than entirely new browsers/user agents/rendering engines.

    Yes, all browsers 'fix' code and make invalid code 'work', but what if a new user agent 'fixes' the code in a different way to everything else, and 'breaks' your site?

    If you don't code to standards, the behaviour of your site is undefined and ambiguous, and prone to break.

  17. #42
    SitePoint Evangelist tetsuo shima's Avatar
    Join Date
    Oct 2005
    Location
    Switzerland
    Posts
    597
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    If you don't code to standards, the behaviour of your site is undefined and ambiguous, and prone to break.
    I code to standards. My pages validate. Yet, something undefined and ambiguous persists: user agents' interpretation of this "valid" code. This is where the true ambiguity rests, not in your code.

    Your pages validating won't protect you against this problem. That's why it is so low in my agenda.

    If all browsers agree to display your pages the way you want, then you can consider your code to be valid. If it does actually "validate", it's a plus.

    As far as SEO is concerned, traffic and good content are the only efficient techniques which are really working. The rest is blah blah blah and prone not be working sooner or later.

    As far as loading speed is concerned, please... let's be serious. It's just HTML. It's insignificant. Plus, check it out: gimme the worst HTML page, let me apply some caching magic to it and...

    Where I work, the HTML coders are regarded as "frustrated extremists" (quoting a coworker). Even if I wouldn't say that, I know for sure that some of them wish that poor markup wasn't rendered at all, and that broken code was not fixed by browsers. Someone please explain this to me. Should we get rid of tidy while we're at it? Because I mean, after all, it does pretty much what a browser does in this situation.

    So in the end, even if your page does not validate, your browser makes it look like valid code.

    But as I said, I make sure my pages validate. I just do it because it's a professional standard. There is no other valid reason to it.
    The SEO Faq thread
    Dependency injection made easy: Phemto

  18. #43
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,000
    Mentioned
    101 Post(s)
    Tagged
    0 Thread(s)
    If a page does not validate it might get rendered in "quirks mode" which could (depending on the page's markup) alter how the page looks on screen.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  19. #44
    SitePoint Enthusiast
    Join Date
    Sep 2008
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    True, but that's just because of laziness. If you have user generated content, you'll need to provide a validator/clean-up utility for that content to ensure that the output is always valid. For (real) XHTML, of course, this is absolutely essential.


    No need to apologise for asking relevant questions! That's what forums like these are for. I'm the one who should apologise, for presuming you'd understand my jargon.

    Yes, you should put IE hacks in a separate CSS file. Then you link to that CSS file in a way that only IE understands but and this is important you do it using perfectly valid markup!

    Let's say your normal style sheet is called 'screen.css' and the one where you've put all the hacks for IE5 and IE6 is called 'screen_ie6.css'. Let's also say you've got a third one with hacks for IE7 called 'screen_ie7.css'. Then your head element could look like this,
    Code:
    <head>
      <meta http-equv="Content-Type" content="text/html; charset=utf-8">
      <title>Document Title</title>
      <link rel="stylesheet" type="text/css" href="screen.css" media="screen">
      <!--[if lte IE 6]>
      <link rel="stylesheet" type="text/css" href="screen_ie6.css" media="screen">
      <![endif]-->
      <!--[if IE 7]>
      <link rel="stylesheet" type="text/css" href="screen_ie7.css" media="screen">
      <![endif]-->
    </head>
    Notice the comments (highlighted in red and green). The first one applies for IE6 and older ('lte' stands for 'less than or equal to'). The second one applies for IE7 only. These are known as 'conditional comments' and are handled only by IE/Win. For every other browser they're just a normal comment, starting at the <!-- and ending at the -->.

    Wouldn't this need to be properly commented as CDATA if it were in an XHTMl doc?

  20. #45
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jjshell View Post
    I have to disagree. There may just be a slight mistake somewhere in your code.
    Well, I consider a published web document with mistakes in it to have sub-standard quality. If you don't, where do you draw the line between 'just a few mistakes' and 'poor quality'?

    Quote Originally Posted by jjshell View Post
    But an HTML slight mistake is not really a problem, no matter what you can hear.
    It depends on what the mistake is. Omitting a </script> tag is a slight mistake that will have rather dire consequences. Mis-spelling a title attribute as tilte is a slight mistake that will have very minor consequences. Using the same id value for multiple elements may not affect rendering, but could cause a script to stop working altogether.

    Quote Originally Posted by jjshell View Post
    I mean it's better if your code validates, but it's the last thing you should worry about
    I disagree. It's the first thing you should worry about. If something doesn't work as intended, the first step should be to validate the markup to make sure there are none of those 'slight mistakes'. Once you have assured the quality of the bottom layer – the markup – you can progress with your trouble-shooting to the other layers: presentation (CSS) and interaction (JavaScript).

    Quote Originally Posted by jjshell View Post
    (browser rendering is far more complex and has more than often not much to do with validation, how schocking!)
    No? Try omitting that </script> tag and fix the problem in your CSS style sheet.

    Quote Originally Posted by jjshell View Post
    no one really cares if your website does validate or not
    No, but a lot of people care whether the sites they visit work or not and whether they display properly or not. Certain types of invalid markup cause problems. Why spend hours tweaking your CSS or JavaScript when the HTML validator can tell you what's wrong in a couple of seconds?

    I'll return to my usual counter-question: would you bother to spell-check your manuscript before sending a book to the printers'? I mean, most people would (eventually) understand the text even if it was full of bad spelling and lousy grammar. Would you consider it a waste of time to correct those? If not, please explain the difference between that and validating your markup (which is essentially spell-checking your code).
    Birnam wood is come to Dunsinane

  21. #46
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,788
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by memco View Post
    Wouldn't this need to be properly commented as CDATA if it were in an XHTMl doc?
    You don't need the IE hacks at all if you are creating an XHTML document since IE9 and earlier do not support XHTML at all and will simply offer the page for download.

    If you make all your JavaScript unobtrusive and use external CSS files then you will not need the CDATA tag inside the script and style tags either (and it is only inside those tags where you'd need the CDATA tag in XHTML, not in comments).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  22. #47
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,217
    Mentioned
    58 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    ...please explain the difference between that and validating your markup (which is essentially spell-checking your code).
    oh, that's easy

    errors in a book are "in your face" because they are actually part of what the book's reader is reading

    whereas errors in your web page markup are hidden -- yes, they can be seen if the page visitor goes to the trouble of looking, but i daresay the number of page views compared to the number of times someone views source is like comparing an elephant to a flea ...

    ... or apples to oranges

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  23. #48
    SitePoint Guru glenngould's Avatar
    Join Date
    Nov 2005
    Posts
    661
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mmj View Post
    When is website validation not necessary?
    3) You are Google and you are making a search engine.
    I was just saying something similar.

    I always wonder what's wrong with at least declaring a doctype though.

    Any ideas on why Google (or similar websites) don't even bother the simplest validation rules?
    Tweep List adds an avatar menu to Twitter (open source)
    Word Stats shows your most used words on Twitter

  24. #49
    SitePoint Guru glenngould's Avatar
    Join Date
    Nov 2005
    Posts
    661
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by r937 View Post
    oh, that's easy

    errors in a book are "in your face" because they are actually part of what the book's reader is reading

    whereas errors in your web page markup are hidden -- yes, they can be seen if the page visitor goes to the trouble of looking, but i daresay the number of page views compared to the number of times someone views source is like comparing an elephant to a flea ...

    ... or apples to oranges

    Well, still not the perfect analogy but maybe we may better compare it to sending a manuscript to a publisher:

    -If you are a new writer you'd better check your spelling as much as possible.
    -But if you have a Nobel Prize in literature or a best-seller author (if you are Google) publishers would more likely tolerate your misspellings.
    Tweep List adds an avatar menu to Twitter (open source)
    Word Stats shows your most used words on Twitter

  25. #50
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,000
    Mentioned
    101 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by glenngould View Post
    I was just saying something similar.

    I always wonder what's wrong with at least declaring a doctype though.

    Any ideas on why Google (or similar websites) don't even bother the simplest validation rules?
    Glenngould, i came across this article when googling that.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •