I am trying to validate my site and down to just one error. I am assuming I have to change my doctype to allow this tag to exist. But what specific doctype do I need? Or that is considered good for validation/coding reasons? I think this tag is used for either Google sitemaps or analytics, can it be removed and still work properly?
Which DTD are you validating against? If it's an xhtml DTD, META should be meta (lowercase). If it is, you should have another error saying that META is not recognized. You have not given us enough info to do more than guess. cheers, gary
This is what I am using: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Should I be using a different doc type? I am not sure how I selected or ended up with this particular doc type.
There is no sane reason not to use a strict DTD on a new document. If you do not understand the DTD you're using, it is important that you study the syntax. Since you're using xhtml, all elements and attributes are lower case, and xhtml is case sensitive. Thus, META ≠meta, and META is unknown. Does that clue you to what you need to do? cheers, gary
There are two current DTDs for html type documents, html 4.01 and xhtml 1.0. Since IE cannot handle xhtml serve as xhtml, we serve both syntaxes as text/html. The net effect is there is no practical difference between the two. There are syntactical differences. XHTML is html reformulated as xml. Choose whichever. If you're just starting, start with html. Learning to use (x)html as well formed, well structured and semantic markup is the important part. I use xhtml1.0 strict because I write for an intranet that uses modern browsers (IE is not a modern browser) to take advantage of the eXtensible features of xhtml. I see no reason to alternate between DTDs, risking syntactic errors. cheers, gary
All meta tags are unnecessary; they are purely for the benefit of user agents (UAs) which may read additional info from them. Also, if you come across meta tags for content-type, character set, and other such things which can be specified using HTTP headers: don't learn from their use. Headers are the correct way, meta tags can only supplement them. I don't think that's particularly good advice; in any case, it's a dangerous generalisation to make without explaining it in more depth. Sending XHTML as text/html may work, in practice, but consider this: Fred learns HTML. Fred then learns about XHTML, sees it as an updated HTML, decides to use XHTML 1.0 Strict. Serves as text/html. Fred discovers combined DTD such as XHTML+MathML, or some other XML-only feature, and decides to deploy it on his "XHTML" pages. Fred is confused and lost when said pages fail to work despite following the tutorial exactly. Cue the original content type issue. Thus, it is imperative that the importance of the content type is emphasised to beginner authors. Also, even if you are personally aware of the drawbacks of sending XHTML as text/html, your doing so can unwittingly encourage other less-informed coders to do so when they inspect the content and doctype of your pages. Thus, one should either: Send XHTML as application/xhtml+xml, and ignore non-XML-conformant UAs. After all, it is XML, thus it requires an XML parser. This is the uncompromising solution. Send XHTML as application/xhtml+xml to UAs which indicate acceptance of that content type via the HTTP Accept header, and HTML as text/html to UAs which indicate acceptance of HTML media only. This is my personal preferred solution as it fits in with the HTTP media type negotiation model that has been in use since the dawn of the WWW. Language and character encodings can also be handled using this method and it can and should handled in a transparent manner by the UA. This is the ideal solution. Send only HTML as text/html, and forget about using XML features. This is the simplest, easy solution, but if employed en masse will ultimately lead to stagnation of the state of web markup. Notes: If option B. is employed, it is inevitable that at some stage the issue of how markup should be stored will arise. There are several solutions to this. At the most basic level, content that is originally marked up as XHTML can be converted to HTML using a regular expression replacement routine. However, this restricts the author from using advanced features of XML, thus making the whole endeavour rather pointless; one could simply use HTML 4 in the first place, and eliminate the hassle. For a more complex database-driven site, it is possible that content can be dynamically outputted using either media type. Thus, one can output either HTML or XHTML markup, and determine whether or not to include XML-only features, their SGML-compatible fallback equivalents, or discard them altogether. They say that variety is the spice of life. I say that versatility is the mark of the professional coder. Although, if you are referring to transitional vs. strict doctypes, I wholly agree; there is absolutely no reason to use transitional doctypes, and in particular not XHTML 1.0 Transitional. The distinction between XHTML and HTML is not something which should be blurred, as this DTD unfortunately does. Further reading: Smackthemouse.com: XHTML, http accept-header and mime-type application/xhtml+xml Ian Hickson: Sending XHTML as text/html Considered Harmful
The content-type should be in all (x)html documents. They are not all served up with headers. Consider, for one, those opened from file. That browsers do not give great support is a different issue. At the level of the question, it was sufficient. Besides which I suggested html over xhtml for those who don't know better. True enough. But, I'm not taking on an html lecture series. There are any number of tutorials, articles and even books there for the reading. I would expect anyone to make some effort on their own to broaden their own knowledge base. See response above. I grant that "B" is the ideal. If you want to espouse it, fine. The W3 quite clearly states you may serve xhtml 1.0 as text/html. I see no compelling reason to do otherwise in general. In the specific, I serve with the appropriate MIME type. It is not a question of versatility. I can work flawlessly in either syntax. There is a question of compatibility. XHTML may be served as either; html may not. I haven't studied the first reference, but Hixie's argument is specious and disingenuous. He argues that if the xhtml is invalid, it won't render when served as xhtml+xml. Well, d'oh. Sorry, but that's just a reason to write syntactically correct markup. The same would apply to html if browsers were not so fault tolerant. That's not about xhtml vs html, but strict parsing vs loose parsing. If someone writes invalid xhtml that breaks when served as application/xhtml+xml, that's not the fault of the xhtml, but of the author. gary
That's different, now you are branching off into OS/UA-specific details, I was referring to pages accessed through a HTTP web server. OSs (Windows at least) usually use the file extension to guess at the MIME type, at any rate. I don't personally know of an environment where the meta content-type tag is required. Admirably idealistic, but that expectation dooms your whole argument - people tend not to make an extra effort to do in-depth research on such seemingly trivial topics. Indeed! But when you serve XHTML as text/html you lose the primary benefits of employing XHTML in the first place. HTML 4.01 is just as "clean" as XHTML 1.0. So if you are only prepared to serve one representation of the resource then let it be HTML, for otherwise there is little to no gain, and a possible detrimental effect. I don't think it's within the scope of our discussion to pick apart Hixie's article, but it has been cited in many other discussions on the topic, so I felt it relevant to include a link to it. In particular the section headed 'The Myth of "HTML-compatible XHTML 1.0 documents"' is quite clear (whether it is entirely true in regard to modern UAs, I am not sure).
Not all pages are served by an http server. But, ok. Not all web servers are properly configured and may not have a charset header, or even a content header which is required. The meta http-equiv is supposed to cause the browser to generate these headers if not sent by the server. Let me quote from a W3 tutorial, (emphasis added) I don't believe I used the term, "required", or the keyword, "must". Do not put words in my mouth. Sure, coulda, shoulda, woulda. If "… people tend not to make an extra effort to do in-depth research on such seemingly trivial topics." Why do you expect me to present a dissertation? Get real. If the poster asks, I'll be glad to expand on my remarks. But, I see no reason to do so before called upon. What benefits? If I need the extensibility, it's because I'm in an environment that requires it and can utilize it. That does not mean it's lost anything just because I don't use a feature. I very, very seldom use the kbd tag. Should I use some more restricted markup language, so that I don't lose a primary benefit of html4, the variety of element tags? That's a silly arguement along with the rest of the paragraph. What detrimental effect? You're the one who cited it, presumably in support of your statements. That makes it open season on his points. There is no practical difference between the two when delivered as html, so use whichever is more comfortable for you. In my case, I have to use xhtml at least part of the time, I'm comfortable with it and I see no sane reason to switch back and forth. gary
Yeah - they should, though. You didn't, nor did I say you did; I was simply making a statement. Look, it doesn't matter what you do personally, if it works for you, that's great. Web standards aren't rules, just guidelines, and idealistic ones at that. We only post here because we want to help others; I hope this discussion went some way towards doing that.