SitePoint Sponsor

User Tag List

Page 3 of 6 FirstFirst 123456 LastLast
Results 51 to 75 of 145
  1. #51
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 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?

    1. The Google home page is really simple HTML that is equally valid as HTML 2 as it is as HTML 4.01
    2. For HTML 2 the doctype was optional.
    3. That page is visited by so many people that adding a doctype would add significantly to the bandwidth requirements of the entire internet and slow everything down for everyone with the bandwidth needed to send billions of copies of the doctype between computers.
    4. Adding the doctype would break the page for people using a few really old and rare browsers that are only used by a small number of people where that number is small enough for most sites to ignore but which still represents thousands of daily visitors to Google even though there are only a few thousand people in the world still using those browsers.
    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="^$">

  2. #52
    SitePoint Guru glenngould's Avatar
    Join Date
    Nov 2005
    Posts
    661
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Stephen,
    Your points seem reasonable to me at first, but after reading this article SpacePhoenix mentioned, the bandwidth argument looks like a myth to me as well, if the test results here and here are correct (dated articles but probably still valid today):

    Quote Originally Posted by http://www.456bereastreet.com/archive/200608/google_valid_and_strict/
    Google’s invalid kinda-HTML 2.something very-loose is 4 944 bytes
    HTML 4.01 Strict file that is 3 902 bytes large
    Quote Originally Posted by http://blogoscoped.com/archive/2006-08-10-n50.html
    Google’s deprecated page (just the HTML, no JS): 3.08 K
    Strict page (HTML + CSS, no JS): 2.85 K
    Tweep List adds an avatar menu to Twitter (open source)
    Word Stats shows your most used words on Twitter

  3. #53
    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 SpacePhoenix View Post
    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.
    If browser documentation is to be believed it's the doctype that determines the rendering mode. If my memory serves me.
    Ed Seedhouse

  4. #54
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,014
    Mentioned
    103 Post(s)
    Tagged
    0 Thread(s)
    I do wonder when google is running its page rank algorithm whether it takes in account whether a site's mark-up validates.

    It would be an interesting experiment for someone to do a "save page as" on the google homepage twice to generate 2 copies then get one copy to validate. Then run a few tests on it to see which version loads quicker and which is the smallest in size.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  5. #55
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    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.
    Both of your examples and spelling mistakes will be visible errors. You omit that ending script tag, and guess what - you can CLEARLY see what's wrong. Oops! Now the rest of my page isn't rendering, right after the place I put that javascript, and I have a bunch of javascript errors... hmmm... What ever could that be?! You misspell the title with tilte and guess what - no visible title in the title bar of your browser! These are poor example choices, because these types of mistakes are never the real issues with validation.

    All the examples given thus far have been preposterous... Leaky faucets, bank failures, levees in Louisiana, printing books without even passing the content by an editor - these examples don't reflect the reality of HTML at all. The point is that the markup still gets displayed fine. That's right - no leaks, no catastrophic failures, and no glaring obvious mistakes. All silent, hidden, barely noticeable errors that people don't even know about or see at all unless they actually go through the trouble of running your markup through the validator.

    A much more accurate example would be a house that could use another coat of paint. Nothing's really wrong with it right now, but it could potentially become a problem down the road if it's not fixed (re-painted). The whole house isn't going to explode or collapse because it didn't get another coat of paint. Come on, guys... get real. The severity of this problem is blown way out of proportion.

    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.
    So you really think browser vendors would change the rendering rules to break 96&#37; of websites on the internet, just to cater to the 4% of websites that are valid? That's not even mentioning the fact that those pages are served as "text/html" anyway and NOT xml.

    So what do we do about minor validation errors? Fix what we can, and don't worry about the ones we can't (caused by clients, etc). Life's too short to worry about such non-issues. All we can do is wait for the new standard. It is supposed to clearly define browser behavior in all cases, even when there are errors. Pages with the new doctype will be handled accordingly and may not display with errors, and pages with the current doctypes will continue to be automatically fixed so they can be displayed for users no matter what. We can't break the web to force it to be valid. It has to happen slowly and gradually. A new standard and doctype is the perfect solution. Opt-in and use it if you want, use the old stuff if you don't. Everyone's happy, and it's a big win-win. But until that day comes, it's really not worth worrying about.

  6. #56
    SitePoint Guru glenngould's Avatar
    Join Date
    Nov 2005
    Posts
    661
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries
    Pages with the new doctype will be handled accordingly and may not display with errors, and pages with the current doctypes will continue to be automatically fixed so they can be displayed for users no matter what.
    XHTML is already not displayed with errors (if served properly) and other doctypes are already fixed automatically so they can be displayed, isn't it? So what are we expecting by waiting for a new standart actually?
    Tweep List adds an avatar menu to Twitter (open source)
    Word Stats shows your most used words on Twitter

  7. #57
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by glenngould View Post
    XHTML is already not displayed with errors (if served properly) and other doctypes are already fixed automatically so they can be displayed, isn't it? So what are we expecting by waiting for a new standart actually?
    Support from browsers, for one. XHTML isn't used in the wild due to lack of any support by IE (other than the limited HTML-compatible XHTML ending at version 1.0).

    Backwards and forwards compatibility is another. Try serving an old browser with XHTML 1.1 (or non-HTML-compatible 1.0 for that matter) and it won't even attempt to display it in the browser. HTML5 on the other hand takes a progressive enhancement approach to upgrading a standard. Even the oldest browser will at least treat it as HTML and get some meaning out of it.

    XHTML failed on the wider web because it broke forwards compatibility - it relied on the browsers adopting a new parsing model, which the most popular browser never did. HTML5 is completely the opposite - for the first time in an official standard, it specifies the parsing model that browsers actually use today. In my opinion this is a much better foundation on which to build a standard on something so set in its ways already as the world wide web.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog · Twitter · Contact me
    Neon Javascript Framework · Jokes · Android stuff

  8. #58
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    No matter which doctype and standard you follow it doesn't change some of the basic facts regarding validation and standards.

    The browsers are supposed to follow the standards which define how standard compliant code is supposed to be treated. In so far as HTML is concerned all the browsers do a pretty good job of following the standards in the way they process valid HTML. The standards don't say how a browser should treat invalid code and so it is left to the browsers to decide what they will do about invalid code. Treatment of invalid code does therefore differ between browsers (even though the differences between the way the major browsers treat non-standard code is relatively minor that may not be the case with some of the less popular browsers).

    In the case of XHTML (which 99.9&#37; of the different browsers by browser version support and 50% of browsers by visitor count support) the treatment of invalid code is also defined in the standards and al browsers treat it that way. As that 50% grows toward 90%+ then XHTML may become a practical alternative. Certainly anything would be better than the current proposal for HTML5.
    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="^$">

  9. #59
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ed Seedhouse View Post
    If browser documentation is to be believed it's the doctype that determines the rendering mode. If my memory serves me.
    You are correct.

  10. #60
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Ed Seedhouse View Post
    If browser documentation is to be believed it's the doctype that determines the rendering mode. If my memory serves me.
    That is not entirely correct as otherwise it would not be possible to have HTML pages using an XHTML doctype as is most commonly done for pages using that doctype where support for Internet Explorer is required.

    It is actually the MIME type that first determines which language the page is rendered as.

    text/html - render as HTML
    application/xhtml+xml - render as XHTML

    The doctype does affect rendering with a valid and complete doctype placing the browser into standards mode while a missing or incomplete doctype puts the browser into quirks mode but that only applies to HTML since XHTML doesn't have any modes other than standard. Browsers rendering the page as HTML do not actually use the doctype as it is supposed to be used - to define what is and isn't valid code.

    The doctype can also change where JScript (IE's equivalent to JavaScript) needs to look to retrieve some browser info with transitional doctypes populating fields in document.body and strict doctypes populating document.documentElement instead. Browsers that support JavaScript don't have that distinction as they store all that info in the window object instead.
    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="^$">

  11. #61
    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 r937 View Post
    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
    Rudy, you don't seem to have understood the purpose of a markup language (which, frankly, surprises me). You also seem to think of a web 'page' as something you're just supposed to look at, rather than a document conveying information. That point of view is fine if you're doing print design, but the web isn't print.
    Birnam wood is come to Dunsinane

  12. #62
    SitePoint Member biswa's Avatar
    Join Date
    Nov 2008
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, If you are targeting for good search engine rank ,you need to validate you code with w3c standard. If you see sitepoint home page it's perfectly validated. Look and feel doesn't matter .

  13. #63
    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 AutisticCuckoo
    Rudy, you don't seem to have understood the purpose of a markup language (which, frankly, surprises me). You also seem to think of a web 'page' as something you're just supposed to look at, rather than a document conveying information. That point of view is fine if you're doing print design, but the web isn't print.
    The web page has long stopped just being a text document. In many instances, a web page is merely a collection of user-interface components used to access back-end features of a web application. Cared to notice where the Web is headed with RIA and Adobe Air both of which use HTML to create user interface?

    A Web page has outgrown the W3C model that still treats it as a text document.

  14. #64
    SitePoint Addict
    Join Date
    Aug 2007
    Location
    St. Louis, MO.
    Posts
    206
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    We all know why we care if a site validates but why should a client or business owner care?

    That question was answered when I was given a broken page to fix. It was about 700 lines of nested tables. Not just nested tables but nested tables with inline style tags and procedural php. One of the table rows or cells had not been closed causing the page to render incorrectly.

    No problem, lets validate it and and find the problem. With over 200 errors on the page it was quicker for me to go cell by cell to find the problem. It took over an hour. Time is money and the client was charged for that time.

    If the page had validated or even only had a handful of errors I could of fixed the problem in less than 5 minutes.

    Like so many things in the world of web quality is usually measured by the ease of which the product can be maintained.

  15. #65
    SitePoint Wizard bronze trophy Kailash Badu's Avatar
    Join Date
    Nov 2005
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Apples and oranges again. The number of nested tables has nothing to do with validation. A web page can have the nesting twice deeper than that and still be valid. On the other hand, a web page with no tables at all might not validate. The deeply nested tables just lead to reduced maintainability and therefore are hard to fix (semantic issues aside). Just a <br> in place of <br /> can render a document invalid and the other way around.

  16. #66
    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 Kailash Badu View Post
    A Web page has outgrown the W3C model that still treats it as a text document.
    The W3C model doesn't treat it as any such thing.
    Ed Seedhouse

  17. #67
    SitePoint Zealot somecallmejosh's Avatar
    Join Date
    Sep 2006
    Location
    CT
    Posts
    153
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    We have a customer who's site was designed with tables and made up of almost 100 html files. Every time they needed a new page to be added they had to update every menu on almost EVERY page of the site. The weren't using includes. They didn't know better. For the most part, the site was almost valid (their were hints of coding to some standard), but their updates were costing them dearly. The website was truly a liability.

    The company hired us to install Google Analytics - which took forever, by the way. They were getting about 400 hits a month. The site viewed perfectly in all of the browsers that were accessing the site - we tested this. They were also getting referrals from qualified sources - direct search, and referring sites. Bounce rates were fairly low, too. The site was just a drain to maintain... (Hey, I like that for a tagline).

    Do you think converting to 100&#37; valid markup was the solution? Not at all. They were was getting qualified traffic and converting a small percentage (which is more of a design and marketing issue - something completely different). His maintenance fees outweighed his conversion, however. Validating the code was of secondary concern for them.

    We recoded his site... using the same exact design. The difference was that we installed a content management system. This is what he needed to make updates simple and efficient. Yes, we wrote the code to W3's standard but their site is a better tool for the business because it is more efficient to maintain - not because it is valid.

    The customer saves a few hundred dollars a month on website updates, and the changes happen immediately... this is the business benefit.
    Joshua K. Briley
    Website Design and Front End Development

  18. #68
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    A few things to think about regarding validation.

    1. The W3C validators do not test for everything. It is possible to have a page that passes the validator which contains invalid HTML (eg, a <button> outside of a <form>).

    2. The W3C standards are aimed primarily at the browser developers to tell them the standards that their browser should support. Appropriate standards for an easy to maintain web site will include a lot of other requirements not covered by the W3C.

    3. A web page needs to follow the standards at least as far as mandatory closing tags are concerned in order for the DOM to be constructed properly so as to allow the CSS and J(ava)Script to interact with it correctly. Without that minimum the page isn't going to display correctly in all browsers.

    4. If the browsers actually implemented the standards properly so that pages that didn't validate didn't render then it would be easier to tell if a page contains errors and fix them. We already have this with XHTML except that IE doesn't support XHTML making it useless for public web pages.

    5. There are times when it is necessary to break the rules (not oftem but on rare occasions). One example of this is Google having deliberately omitted the doctype from their home page.
    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="^$">

  19. #69
    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 felgall View Post
    5. There are times when it is necessary to break the rules (not oftem but on rare occasions). One example of this is Google having deliberately omitted the doctype from their home page.
    This is true of any art of course, but one must at least know the rules and understand the reasons for them first if one wants to break them successfully.
    Ed Seedhouse

  20. #70
    SitePoint Addict
    Join Date
    Aug 2007
    Location
    St. Louis, MO.
    Posts
    206
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Kailash Badu View Post
    Apples and oranges again. The number of nested tables has nothing to do with validation. A web page can have the nesting twice deeper than that and still be valid. On the other hand, a web page with no tables at all might not validate. The deeply nested tables just lead to reduced maintainability and therefore are hard to fix (semantic issues aside). Just a <br> in place of <br /> can render a document invalid and the other way around.
    I think you misunderstood me or I didn't explain it correctly. Yes I know table nesting has nothing to do with validation. What I was saying is that if it had at least been close to validating it would of been very easy to find where the tables were broken. Run it through a validation and you get at least close to where the problem is.

    But with a couple hundred random cascading errors you won't be able to find the problem through validation.

    Certainly don't want to turn this into a tables discussion
    Last edited by binarysys; Nov 15, 2008 at 18:44.

  21. #71
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    A basic first step in resolving where a page doesn't render correctly is to fix any validation errors. Most of the time one of the validation errors will be identifying the cause of the page failing to render correctly. Ensuring that the page validates (or at least comes close) will make the page easier to maintain in the future. Visitors to the page will not care whether it validates or not but the next person working on the page quite possibly will if there are any issues with it.
    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. #72
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    When I am given a page to fix, I check validation, like Stephen said. I would have to disagree about the second sentence though, while in spirit its correct, in totality its not. 100&#37; valid code will help it render correctly, it will not ensure it since people can do odd stuff still.
    Ryan B | My Blog | Twitter

  23. #73
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And valid markup is difficult enough to debug without having to fight errors in invalid markup. It's like a math forumula that gives you the right answer, once, but somewhere in that formula is an error. You are relying on the same circumstances to make that error work in your favor every time.

    Since when has coding for a computer ever been OK to allow errors? Computers don't allow errors. Only humans do. And anyone that thinks it's OK to allow such errors is not in control of what they are doing.

  24. #74
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by drhowarddrfine View Post
    Since when has coding for a computer ever been OK to allow errors? Computers don't allow errors. Only humans do. And anyone that thinks it's OK to allow such errors is not in control of what they are doing.
    If computers did not allow errors, browsers that were navigated to a poorly coded site would throw a nasty error. But humans code websites, humans code computers so computers allow some errors...
    Ryan B | My Blog | Twitter

  25. #75
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by rguy84 View Post
    When I am given a page to fix, I check validation, like Stephen said. I would have to disagree about the second sentence though, while in spirit its correct, in totality its not. 100% valid code will help it render correctly, it will not ensure it since people can do odd stuff still.
    You misread my second sentence. I said ensuring it validates will make it easier to maintain. Nothing to do with whether or not there are still browser quirks to cause it to render incorrectly. I agree with you that valid code doesn't guarantee correct rendering.
    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="^$">


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
  •