Right these topics may have been covered in previous threads but i scanned through and didnt find a specific answer but sorry if i repeat anything I have recently been employed for a company that does webdesign but they have a few seo clients too which they have just emplyed me to take over looking after them. Now the main designer left and the new main designer is pretty good at design and programming, but he doesnt seem to be too great at the html coding. From what i have seen so far non of the HTML is validated, he doesnt add alt tags or anything. Im not slating him but i in the new year i want to ask him to change. Now the question is, should i make him just do html that is properly validated etc or is it worth me asking him to try and get to grips with XHTML? I remember reading on here one guy was on about how he does all his sites in XHTML as it is the future of the net, but another guy said he still uses HTML browsers dont actually support XHTML and IE7 wont even fully support it
First, regarding HTML or XHTML: you should still continue to use HTML. A good discussion on the subject can be found at IWDN (IWDN-XHTML); you will need to read through at least the first two pages. Next, about HTML validation—writing code that will pass the W3C's validator is a means to an end, not an end itself. Just as when you are writing a program in PHP or C or whatever, you need to check for compile time errors; that is, errors in the syntax. That, essentially, is what the W3C validator is: a syntax checker. However, correct syntax in your PHP code does not mean it is free of logical errors, or that the program is well structured. Similarly, a validated Web page, while certainly free of syntactically errors, may not be well structured or may misuse an element. For example, using the BLOCKQUOTE element to indent text is incorrect usage, but will not trigger an error in the validator—it has no way of knowing if the enclosed text is or is not a quotation. A List Apart's article A Dao of Web Design may give some insights. The Web site CSS Zen Garden is also an excellent example of how an HTML document should be coded. As a result of CSS Zen Garden's correct and logical usage of HTML elements, the site is accessible to all browsers, all devices, and all people, as well as the added amazing benefit of being able to drastically alter the site's design without ever touching the HTML document itself; the "select a design" links on the right are examples of the possibilities. For every design, you may view the page source to see that the HTML is indeed indentical for every one, except for the different style sheet being imported, of course. With these examples to follow, I can only further suggest that your fellow project member read the HTML and CSS specifications; they are the definitive references for each language.
I think it is best not to confuse (X)HTML with the rendering of XML data. HTML and XHTML are the exact same language. XHTML is simply the continuation of HTML - it may as well be called HTML 5. The reason for calling it extensible is that the hope is one day the markup generated by HTML programmers will be XML compliant, which allows data to be platform independent (the same data used on your Web page can be used in a variety of non-browsing situations). It's important to learn HTML, because there's a lot of it out there, and it works. It's more important to learn XHTML, but only because it forces you to code more efficiently and to separate style from structure. Here's the deal - not counting self-closing tags (<img /> <br />, etc.), an XHTML document of any type will validate to the HTML 4.01 spec, because XHTML is actually a stripped down version of HTML. It is HTML with the garbage removed. It's a matter of to what level you wish to hold your coder accountable. I can't think of a single reason why you shouldn't strive to create markup that validates to the XHTML 1.1 spec (though I wouldn't use that doctype, because of XML declaration issues with IE - use XHTML 1.0 Strict instead). I think you give too much latitude for poor coding practices when you only ask for HTML validation, which is the same position I held in the IWDN thread FeelLikeANut referenced. But like FeelLikeANut also said, validation isn't the end. It's a baseline. You can write some remarkably bad markup that still validates. Validation is simply a start. You're not writing (X)HTML if you can't validate. You're writing something that isn't (X)HTML and hoping it will work. If you're serious about your designer doing a good job with coding, you'll want to concentrate on the concept of semantic validity, using the proper semantic markup to describe objects on the screen, something XHMTL urges you to achieve and HTML does not. Also, it's a good idea to have him review the Web Content Accessibility Guidelines, guidelines that make sure coding is done to the benefit of the visitors.
XHTML is really a reformulation, not a continuation of HTML. Aside from the benefits that come from being an XML document, XHTML does not add or detract anything from HTML. It is called extensible because XML allows you to extend the set of markup elements and attributes with modules. HTML, when coded correctly, is already platform indepedant; neither XML nor XHTML are necessary in this respect. It does not force you to code more efficiently, and it does not force you to separate style from structure. XHTML 1.x Strict includes all the same elements as does HTML 4 Strict, and XHTML 1.x Transitional includes all the same elements as does HTML 4 Transitional. This means that an XHTML document may still use FONT, CENTER, ALIGN, etc. Not true. Since you may include additional XML definitions, or import modules, you may do far more in XHTML than was ever possible in HTML. The impression is given that an XHTML document will look almost the same as an HTML counterpart only because such pages are coded specifically so legacy HTML browsers may still understand an XHTML page, meaning only a small subset of XHTML's potential is used. If we were to make use of the full features of XHTML, it would certainly not validate as an HTML document. Again, XHTML contains the same set of elements as does HTML. Nothing is stripped down and nothing is removed. From what I read the upcoming XHTML 2 specification will throw backwards compatibility out the window and get rid of all the garbage, but for now every XHTML specification still inherits all the elements of HTML 4. The definition of XHTML is (almost) exactly the same as HTML, and the only real benefit—the extensions available from being an XML application—are not supported by browsers. XHTML does not hold the coder to any new lever of strictness, at least not any significant level; class="foo" is not significantly better than Class=foo. I don't see you taking any such position in that thread. If you did, someone could have corrected you. XHTML contains the same set of elements and same set of rules, barring a few insignificant exceptions. Most of what I see is IE bashing. The first two pages of the thread I referenced—before any of your posts appear—is the section that thoroughly discusses what XHTML is and what it isn't. HTML does urge you to achieve this. Most do not follow the practice, however, because the Web is swamped with tutorials that are ignorant to how HTML was designed to work, which then creates uninformed students.
That would be the extended version of the answer (i.e. the definition of extensibility), and a good one. I was moreso trying show what the X is - you covered what it means. Has this been put into practice? I just ran these elements through a validator to make sure I wasn't dreaming, and they were not accepted. Let's not confuse what browsers will accept v. what the technology accepts. Browsers are lenient in what they will allow, but if you code to the standard, you are not using these elements. Yes, the coder is the one who forces him/herself to code to the standard. I wish the browsers didn't accept poor markup, but we're overcoming years of a lack of ISO (and indeed, the accepted "ISO" - W3C standards - isn't really an official one anyway). No, but not having the option to use backgroundcolor="#123456" and being forced to move this into a CSS rule .foo is significantly better. I'm comparing XHTML to HTML 4.01 Transitional. I suppose I was making the assumption this is the standard to which OP is considering holding his coder. If we're talking about Strict, then nevermind about a good portion of what I said. Much like the standards for libel/slander/defamation, it's only bashing if it isn't true IE does a lot very badly, and it prevents a lot of progress. It's relevent to (X)HTML technology, and it's factual. Besides, IE was never mentioned until long after the thread had meandered past it's original intent. It may urge you to do this, but it allows you to use second-best practices as well. It's that allowance about which I'm not particularly a proponent.
Your explanation for the term extensible was the hopes the W3C has for developers, which isn't really accurate. Yes. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en-us"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <title>Hello</title> </head> <body> <p>Hello, World!</p> </body> </html> Code (markup): Granted this is a small example, but any other page that follows the rules of semantics, not matter how large or complicated it may be, will still be just as independent. And it is certainly no more or less independent than its XHTML counterpart would be. Check the following XHTML document. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xml:lang="en-us" lang="en-us"> <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> <title>Hello</title> </head> <body bgcolor="#123456"> <p><font color="red">Hello, World!</font></p> </body> </html> Code (markup): You do have the option. The former XHTML document proves this. Well there is the confusion. You are referring to the languages in general, but only comparing a specific subset of each. XHTML may be transitional as well as strict, and HTML may be strict as well as transitional. You can't just pretend these other DTDs don't exist, and doing so is why many of your comments regarding the languages are not correct. As I have now demonstrated, XHTML has just as many allowances as HTML.
I should have made my clarification clearer: I'm looking at XHTML Strict 1.0 and XHTML 1.1. I've contended in other threads in other forums that transitional XHTML is largely a waste, when you can simply make the transition without relying on transitional markup along the way. Now, putting my comments into the context I originally intended: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xml:lang="en-us" lang="en-us"> <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> <title>Hello</title> </head> <body bgcolor="#123456"> <p><font color="red">Hello, World!</font></p> </body> </html> Code (markup): fails, hard. The difference is that the data cannot be served as XHTML+XML, because of the doctype being used to define the data. What you've written is perfectly valid XHTML 1.1 and called it something else. Now, show me something that's acceptable in HTML but not XHTML 1.0S/1.1 and how that is platform independent. Still it's the reason the differentiation was made, whether or not it's come to fruition as of yet.
HTML Strict will fail just as hard. In what way does serving data as XHTML+XML increase independence? What I've written is HTML Strict, and I called it HTML Strict. So... I don't see what your point is. Huh? XHTML Strict has all the same elements as HTML Strict, and thus there is no HTML Strict element that is not in XHTML. So... I really don't understand what you want me to write. So the W3C has stated the reasoning you suggest is why they made the differentiation? Or are you in fact just assuming?
Oy. You're right. You're right. You're right. I'm confusing my doctypes and the elements allowed within them, and challenging you to offer HTML Trans that's platform independent. Yes, if something validates to HTML 4.01 Strict, it will validate to XHTML 1.0 Strict, barring 1) the requirement for well-formed mark-up (a benefit in any coding "language"), and therefore 2) the ability to easily convert to XHTML+XML in the future, and incorporate other XML Isn't it the hope and dream and possible future reality that XML will allow for non-browsing devices to share the same data as browsers, and isn't this the reason W3C introduced the idea of standardizing in the first place, so there wouldn't be multiple "valid" ways to write the same thing? If I'm wrong, please set me straight. I was under the impression this was the case from the beginning. If so, then the point of writing to the XHTML 1.0 Strict+ standard is a matter of quality control, holding your coders to writing something well. Heck, a few of the more rebellious W3C members are working on standardizing IDs for specific containers on Web pages! I can't see this flying though.
wow cheers guys, its a little over my head but it has helped. I actually checked most of the code myself and it pretty much validated apart from he didnt put alt tags in, which as far as i have learnt is pretty bad for accesibility? However it isnt the end of the world as i go through them all to try and make sure they use the right keywords etc. As for FeelLikeANut who replied first i was always taught to practically worship the validator thing at Uni, i dont think uni estabishments always realise the best way to do things though.
No matter what, I would keep away from the Transitional versions of either language and make sure he can understand and follow WCAG guidelines (most of which address the issue of semantic validity anyway). If he can handle this, he'll be a fine coder.
cheers i have past the info onto him. I am going to try and learn how to code properly aswell, even though it is not as important for me, i think it is a pretty dam usefull skill especially if i change jobs one day!