SitePoint Sponsor

User Tag List

Page 4 of 6 FirstFirst 123456 LastLast
Results 76 to 100 of 145
  1. #76
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,869
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by rguy84 View Post
    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...
    Yes but the errors that the browsers are supposed to allow are written into the standards - such as some end tags being optional and the head, body, and tbody tags also being optional. Leaving them out is asking for trouble but browsers are supposed to allow for people making those errors.
    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. #77
    SitePoint Enthusiast
    Join Date
    Feb 2008
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When will you validate your website? the answer is ALL THE TIME.

  3. #78
    SitePoint Enthusiast WebDesignHome's Avatar
    Join Date
    Nov 2008
    Location
    Sheffield
    Posts
    70
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Plus it also makes you look more respectable by passing validation
    Web Design Sheffield
    For all your web design needs. Bargain prices
    Style Model Agency

  4. #79
    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
    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'?
    Quite simply, I don't draw it. As soon as the document gets rendered the way I want, I'm happy. The day I have time left, I check if it validates. I type my code. No rubbish software code added. I consider my code rather clean. That's maybe why I don't panic if a <img> tag does not close itself.

    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.
    But you notice it if you test your app correctly. And you fix it. Now, a "fixed" app may still not render valid pages. I don't worry about it, unless I have free time. The point is: the application is doing fine.

    Quote Originally Posted by AutisticCuckoo View Post
    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).
    Once again, it's the best way to proceed. But if you don't do it like that, you won't expose yourself to major catastrophe that you won't notice while testing your app. Plus, a page validating does prevent troubleshooting. My point again is: a page validating is a very low priority.

    Quote Originally Posted by AutisticCuckoo View Post
    No? Try omitting that </script> tag and fix the problem in your CSS style sheet.
    And you notice it's a problem without having to validate your pages

    Quote Originally Posted by AutisticCuckoo View Post
    No, but a lot of people care whether the sites they visit work or not and whether they display properly or not.
    Aside from webdesigners or computer geeks? Nobody really does I think. Webdesigners wish it was otherwise, but it's not. And once again, a site can work properly yet won't pass validation. Tell amazon and google about it.

    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?
    99&#37; percent of the time the validator tells me rubbish and plays the HTML hero, warning me about this and that. It's never proved to be of any help with the problems I've encountered. Browsers interpretation has always been. That's why I regard it as nice addition to my projects, like the last polish ("last" being the keywrod here). But since it's personal history, I guess that yes, it's fair enough to validate you page when you can't solve your issue and see if it helps. I did, it didn't work.

    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).
    I think your comparison is irrelevant. I'm not sure who's the editor in your comparison, the user or the browser? If it's the browser, well, we're dealing with an editor who either fixes the mistakes, or add some. If the editor is the user, mispellings in your code don't matter as long as the content is accessible, as that's what they're interested in.

    And when you've handled all the steps of releasing a website (including accessibility), if you're not too tired, you make sure that your code isn't mispelled. And don't tell me an accessible website is only a validating one.


  5. #80
    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 Kailash Badu View Post
    The web page has long stopped just being a text document.
    Who said anything about documents containing only text? Please don't put words in my mouth. I said a web 'page' is really a document conveying information, not just something that's pretty to look at. Information can be text, still 2D images, moving 2D images, sounds or tactile feedback. In the not-too-distant future we'll probably have 3D images and video (it can be faked already), olfactory feedback, etc.

    Quote Originally Posted by Kailash Badu View Post
    In many instances, a web page is merely a collection of user-interface components used to access back-end features of a web application.
    In other words, information that the web application needs to convey.

    Quote Originally Posted by Kailash Badu View Post
    A Web page has outgrown the W3C model that still treats it as a text document.
    You're putting words in other people's mouths again. Please point out where W3C has stated that a web document can only contain text. Or, if you can't, stop spreading FUD.

    Quote Originally Posted by felgall View Post
    It is possible to have a page that passes the validator which contains invalid HTML (eg, a <button> outside of a <form>).
    That's not invalid, only unsemantic.

    Quote Originally Posted by felgall View Post
    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.
    Indeed, but it would also make web publishing insurmountably hard for 90% of the people who can now express themselves on the web. Alternatively, it'd take publishing software that are several orders of magnitude better than the ones we have today. Think Dreamweaver 78.0.

    Quote Originally Posted by felgall View Post
    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.
    A doctype declaration isn't meant to be necessary for browsers. It's only for validators. Browsers don't care about HTML versions; if they support <font> they'll handle those tags properly even if the doctype declaration claims HTML 4.01 Strict or XHTML 1.1.

    The only reason we need to include doctype declarations in our markup is because they are now abused for presentational purposes; something for which they were never indended.
    Birnam wood is come to Dunsinane

  6. #81
    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
    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.
    I'm sorry to go after you like that Tommy (I mean I'm a big time user of your reference and I really like your articles), but I find you're being too picky about your area of work and you're pushing theory too far. Even though theoretically you're right, you obviously can't deny that 99.9&#37; of the web users have the same relationship with a webpage than they do with print. It's just printed on the screen. And when it comes to print, people wouldn't worry if the big printing machine isn't setup correctly, as long as nothing messes their newspaper. And if one day it does (because, say, the paper-makers decide that it's time paper messes up print job if the machine isn't setp up correctly), the printer will fix it. No catastrophe. I know it's hard to admit, but HTML isn't such an important matter compared to other areas.

  7. #82
    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 jjshell View Post
    Plus, a page validating does prevent troubleshooting.
    Lapsus... is it not?
    The SEO Faq thread
    Dependency injection made easy: Phemto

  8. #83
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by WebDesignHome View Post
    Plus it also makes you look more respectable by passing validation
    To whom?

  9. #84
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tetsuo shima View Post
    Lapsus... is it not?
    I betrayed myself

  10. #85
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,869
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    That's not invalid, only unsemantic.
    The standards define <button> as a sub element of a form. The reason the validator doesn't report it as invalid when it isn't contained in a form is that there must be a block level element wrapped around the button and the form element wrapped around that block element in order for the button to be correctly defined in accordance with the specifications. The validator is not clever enough to test for that level of complexity. So having a button outside a form is an example of invalid HTML that the validator would accept as valid.

    I forget who it was on the forum here who pointed that out to me several months ago but when I checked the actual standards it does clearly show that the button is a form element that is therefore only valid inside a form tag.
    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. #86
    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
    Even though theoretically you're right, you obviously can't deny that 99.9% of the web users have the same relationship with a webpage than they do with print.
    I'm sorry, but I just don't buy into that lemming theory. Just because lots of people are doing something wrong doesn't mean that you have to, too.

    Quote Originally Posted by jjshell View Post
    It's just printed on the screen.
    No, it's not. It's also heard through screen readers and felt on Braille displays. And even if we restrict our discussion to visual media, there is no such thing as The Screen. There are hundreds of different screens with different dimensions, resolutions, colour depths, gamma correction and whatnot.

    If you understand that a web document is a document, not a picture, this is less of a problem. If you understand that HTML marks up what things are, and that CSS declares what things should, preferably, look like, you're almost home and dry. At least you're home and vigorously towelling yourself.

    Look at most of the questions asked in the Design Your Site section of SPF. Many of them are along the lines of 'how wide is a screen' or 'how do I prevent users from doing <whatever>'. This is a consequence of not understanding the fundamental nature of the web; of subscribing to the lemming mentality you outlined; of thinking of a web 'page' as a page or a static rendering like a printed sheet.

    Quote Originally Posted by felgall View Post
    The standards define <button> as a sub element of a form.
    Take a look in the HTML 4.01 DTD. Note in particular these two parameter entity declarations:
    Code:
    <!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">
    
    <!-- %inline; covers inline or "text-level" elements -->
    <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
    As I'm sure you know, %inline; is the content model for many element types. Furthermore, it's included in the flow parameter entity which is also very common.

    For instance, the declaration of the span element type states that a button can legally be a child of a span:
    Code:
    <!ELEMENT SPAN - - (%inline;)* -- generic language/style container -->
    I can't find anything that syntactically restricts the use of form controls outside forms. Of course, it's semantically wrong.
    Birnam wood is come to Dunsinane

  12. #87
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,869
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    I can't find anything that syntactically restricts the use of form controls outside forms. Of course, it's semantically wrong.
    It is one of those standards that is too complex to define in the doctype. It is specified in the written specification that a button is a form element but it is one of those parts of the standard that cannot be implemented via the doctype and can't be validated via the validator because there isn't any way of specifying the rule within the limitations of the language the computer can understand.

    With the exception of those rules that are too complex for the computer to test for there is no reason why web editors should not all produce code that will at least pass the validator. With the exception of scrambling the content of <textarea> tags, HTML Tidy can clean up and code that is close enough to valid that it is going to be able to display properly and make the changes necessary so that the code will pass the validator. The issue I saw with textareas is something that could be easily fixed. If a WYSIWYG editor produces HTML that is so badly constructed that HTML Tidy can't clean it up then it isn't a web editor. It would not be too hard for all the web editors to feed their generated HTML through HTML Tidy (or equivalent) whenever the save button in the browser is pressed and to save the resultant valid version of the HTML.
    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="^$">

  13. #88
    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)
    There are other validators out there other than the W3C one which will test for things like this.

  14. #89
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,072
    Mentioned
    103 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    It is one of those standards that is too complex to define in the doctype. It is specified in the written specification that a button is a form element but it is one of those parts of the standard that cannot be implemented via the doctype and can't be validated via the validator because there isn't any way of specifying the rule within the limitations of the language the computer can understand.

    With the exception of those rules that are too complex for the computer to test for there is no reason why web editors should not all produce code that will at least pass the validator. With the exception of scrambling the content of <textarea> tags, HTML Tidy can clean up and code that is close enough to valid that it is going to be able to display properly and make the changes necessary so that the code will pass the validator. The issue I saw with textareas is something that could be easily fixed. If a WYSIWYG editor produces HTML that is so badly constructed that HTML Tidy can't clean it up then it isn't a web editor. It would not be too hard for all the web editors to feed their generated HTML through HTML Tidy (or equivalent) whenever the save button in the browser is pressed and to save the resultant valid version of the HTML.
    I personally never use a WYSIWYG editor, the only one I've tried for editing HTML was word and the amount of "baggage" added to it by word i had to delete was annoying so ever since then I've hand coded. I can't speak for how bad other WYSIWYG editors are for adding a load of "baggage" to code.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  15. #90
    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)
    Word is one of the worst, by far. But I agree hand coding is the way to go, I don't do anything else.

  16. #91
    Non-Member
    Join Date
    Oct 2007
    Location
    Kolkata, India
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Its very hard to validate old static sites. But I am note sure whether validation helps in search engine rankings also?

  17. #92
    SitePoint Enthusiast conorp's Avatar
    Join Date
    Feb 2007
    Location
    Australia
    Posts
    55
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by biswa View Post
    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 .
    So if your page was invalid google wont index it?

  18. #93
    SitePoint Addict markov's Avatar
    Join Date
    Sep 2006
    Posts
    283
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm of the view that validation is a must for every website. It helps in browser compatibility and better understanding by the search engine robots.

  19. #94
    SitePoint Member biswa's Avatar
    Join Date
    Nov 2008
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sir , Indexing and ranking 2 different factor.

  20. #95
    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
    I'm sorry, but I just don't buy into that lemming theory. Just because lots of people are doing something wrong doesn't mean that you have to, too.
    wrong, right... Here we are again. What about efficiency? You don't want to hear what I'm saying: validation should the least of your worries. Use your resources to ensure much more important areas are secured. This wrong/right discussion is really annoying Tommy, I hope you realize this. What a lot of people are doing, is publishing webpages, and that's it. Your judgement isn't necessary. If some are coding what you may judge crappy document, live with it. A bit of pragmatism please... They may be your next employeur (you haven't answered my question, are you working or are you just a theorician?)

    Quote Originally Posted by AutisticCuckoo View Post
    No, it's not. It's also heard through screen readers and felt on Braille displays. And even if we restrict our discussion to visual media, there is no such thing as The Screen. There are hundreds of different screens with different dimensions, resolutions, colour depths, gamma correction and whatnot.
    What does it have to do with validation? I mean, it really has nothing to do with validation.

    Quote Originally Posted by AutisticCuckoo View Post
    If you understand that a web document is a document, not a picture, this is less of a problem. If you understand that HTML marks up what things are, and that CSS declares what things should, preferably, look like, you're almost home and dry. At least you're home and vigorously towelling yourself.
    lol One more image. I repsect you're really serious about all this, I mean with the pending doom hovering above poor-formatted document, and the dire consequences, and now the storm and the far away home, and the underlying risk of never reaching it, but dude, relax. Validating or not, a webpage is a webpage. It gets displayed, it gets read, heard etc. This is what matters. And validation, in all this relationship between the document and the user, is not that important, at least not as important as you seem to believe. There is no storm. You're fine.

    Once again, I really think it's better if a document validates, but it's fine if it does not, as long as the document does what it is intended to do. Browsers fill fix your mistakes anyway. Live with it. Get over it.

    Quote Originally Posted by AutisticCuckoo View Post
    Look at most of the questions asked in the Design Your Site section of SPF. Many of them are along the lines of 'how wide is a screen' or 'how do I prevent users from doing <whatever>'. This is a consequence of not understanding the fundamental nature of the web; of subscribing to the lemming mentality you outlined; of thinking of a web 'page' as a page or a static rendering like a printed sheet.
    If you call my mentality a lemming one (implicit), you'll agree I can call your mentality a narrow-minded puritanist one (explicit): validation is about saying what is right/wrong. If everything isn't completely right (should I say "by the book"?), some people get an almost religious-facing-a-dangerous-sin reaction. This is what annoys me. What you don't accept, is that quality-wise a document isn't either the devil or an angel. You can have a really efficient document, that does everything you want, that pleases your users, yet not valid. Well that's fine, you'll fix it one of these days.

    Now I must honestly tell you that we're reaching the point where your arguments are becoming really annoying to me, more and more abstract (wrong/right, the storm blah blah blah), and further and further away from the original question (the screen issue, which is far from being validation dependent).

    So... When is website validation not necessary? As long as you have more important things to do. And if it implies your publishing your site without it validating, don't worry. You'll be fine.

    Tommy, I think it's better I let you enjoy the purity of a well-formatted, right, flawless document, while I stick to my principle: be efficient, and when everything's done, take care of the last element on the priorities list: validation.


  21. #96
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Location
    Columbus, OH
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But writing valid code increases efficiency practically by default. A UA may interpret and render a deprecated attribute (e.g. img align) but relegating the positioning of your image to stylesheet gives a same or better result, allows more control over the presentation of the image (padding, etc, although technically there are deprecated attributes that address many of these as well), and will allow you to apply a single standard to 10 or 100 or 1000 different images on the site with a single declaration instead of img align right hspace 5 border 0 yadda yadda yadda in 100 different places. Both ostensibly will display "correctly" but valid code is infinitely more efficient in this scenario.

    Moreover, while UAs opt to interpret and render invalid code, by neglecting to validate, you're trusting the UAs to use the same non-standardized method to render your code. img align serves again as my example, because UAs actually do interpret that attribute differently. Don't we have enough on our plates campaigning to get UA developers to render valid code in the same way (cough Microsoft cough), without additionally suggesting to them how they should render our sloppy workmanship?

    I can understand making functionality and efficiency a priority, but learning and implementing best practices from the outset tend to achieve a better result because you have people trying to get it right on the first pass. In my haste to type this post, I spelled "because" with a "ua" not once, but twice. If vB did an auto-spell-fix and corrected my spelling, that would be great. If I left it the way it was and you read it and got that I meant "because", great. I went back and fixed it because proper spelling is important to a structured language, and for me to communicate effectively, it's best for me to understand how to communicate and get it right the first time, and not rely on other people to tell you what I mean to say if I can help it.

    The hypothetical auto-spell-fix might get it right. Or it might say "colour" and expect you not to find that a strange but valid spelling of "color". Or it might say "collar". Or I can type exactly what I want to say and communicate in a standard on which you and I agree without involving a third party. I can't really think of a good reason NOT to strive for valid code, as long as we don't take things to extremes and start talking about doing that to the exclusion of all other aspects of good design, which I'm not sure anyone has argued so far.

  22. #97
    SitePoint Guru glenngould's Avatar
    Join Date
    Nov 2005
    Posts
    661
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jjshell
    be efficient, and when everything's done, take care of the last element on the priorities list: validation.
    Well, it's possible to keep it valid while you are taking care of your priorities, and for the most part it's not that hard. It becomes a habit by time in fact, I'm about to forget how to code the invalid

    Validation should not be an item in your tasks list, it's more likely a method on how to handle those tasks.
    Tweep List adds an avatar menu to Twitter (open source)
    Word Stats shows your most used words on Twitter

  23. #98
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,072
    Mentioned
    103 Post(s)
    Tagged
    0 Thread(s)
    How much difference does it make for screen readers? It must make a difference for when people are using GreaseMonkey scripts to alter the look of a page.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  24. #99
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,869
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    One solution to this for people who want to make sure that the pages they view are valid would be to install a plugin or script of some sort into their browser that strips all the invalid garbage out of the web page.

    At the very least such a script would make checking your page easier.
    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="^$">

  25. #100
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Location
    Columbus, OH
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Or at the least, maybe some of these WYSIWYG editors could generate valid code. That would be nice, and would probably solve a good half of the "pages not validating" problems out there, given the number of CMS-driven sites out there now. You wouldn't think that would be too much to ask of the guys who are claiming, hey, plug your stuff into our software, and we'll spit out a website.


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
  •