Aahhh, and I thought you'd come up with a way to make an all-Flash site accessible to people without the Flash plug-in. I'm so disappointed.
| SitePoint Sponsor |
Aahhh, and I thought you'd come up with a way to make an all-Flash site accessible to people without the Flash plug-in. I'm so disappointed.
Birnam wood is come to Dunsinane
I don't get this argument that because my documents being sent as text/html aren't really xhtml at all.
I've read the text-like article that complains that if its not sent as "application/xhtml+xml" then its not xhtml at all.
Then there's the argument that I hear about "well if you're not using a strict doctype, then its not truely xhtml"....
But...
1) The documents I write are validated by the W3C Validator as XHTML
2) The documents I write are in transitional, and validate properly.
3) I make a concious effort to reduce the number of tags, code and optimise as much as possible, and I ensure that the navigation, functionality, usability and all-round quality is ensured.
4) The documents aren't just "validating" - they are also fast to load, have good quality written code and do the job that its intended to do.
5) I've read that IE6/7 doesn't like "application/xhtml+xml" anyway...
If its doing its job, its validating, if its functional, usable, fast-to-load and has a benefit to the website - then *what* is the problem?
If there is a problem, can somebody please explain how to correct it with quick examples, and a doctype case-study.
Thank you.
It's true. Anything served as text/html must be parsed and interpreted as HTML by user agents.Originally Posted by worchyld
Well, you could serve it with other XML media types as well, e.g. application/xml or <shudder/> text/xml. The important thing to remember is to use the proper XML namespace (xmlns attribute) on your <html> tag. Otherwise it's treated as general XML, with no built-in semantics and no default style sheet (i.e. you have to specify p {display:block; margin:1em 0} etc.).
That is false. XHTML 1.0 comes in three flavours, and all are XHTML (i.e. XML) when served with the proper media type.
There are some major benefits from using a Strict DTD, but those apply regardless of whether you use HTML 4.01 Strict or XHTML 1.0 Strict, and regardless of whether you serve the XHTML as application/xhtml+xml or as text/html.
That means your markup conforms to the grammar of XHTML. Good for you, but it doesn't mean much as long as user agents see it as HTML.
I'm sure they do. Again, that has nothing to do with things. An XHTML document is not required to be valid, only well-formed.
Attaboy! But you can do that with HTML, too. Besides, the 'quality' might improve if you use a Strict DTD (or it might not, depending on how much deprecated markup you use).
Yep. That's because browsers treat them as HTML. If they were treated as XHTML, you might notice a slight performance degradation, since AFAIK no browser implements incremental rendering of XML. (There is nothing preventing that, but I suppose most parsers want to ascertain well-formedness before doing anything else.)
You could say that. It panics and asks you if you want to download the file.
It's not certain that there is a problem. You're just not using XHTML, that's all.
If your documents are written in a way that requires them to be interpreted as HTML, then I'd say that there is a problem. That sort of markup is harmful to the web, IMHO, because they devalue XHTML.
A few examples of things that don't work in real XHTML:
'Hiding' scripts or style rules inside comments:
Uppercase tag names, attributes, or CSS element selectors:HTML Code:<style type="text/css"> <!-- #mydiv {color:#f00} --> </style>
Unquoted attribute values:HTML Code:<STYLE TYPE="text/css"> H1 {font-size:150%} </STYLE>
Modifying the document in mid-parse:HTML Code:<div class=foo>...</div>
Using .innerHTML:HTML Code:<p>...</p> <script type="text/javascript"> document.write("<p>Hello, " + username + "!<\/p>"); </script>
A few things that will only work in real XHTMLHTML Code:divRef.innerHTML = "<p>New content!<\/p>";
Referencing style sheets through an XML PI:
Using self-closing tags for elements that are not declared as EMPTY in the DTD:HTML Code:<?xml-stylesheet type="text/css" href="/css/style.css"?>
Using CDATA sections:HTML Code:<script type="text/javascript" src="script.js"/>
HTML Code:<pre><code><![CDATA[<h1>Markup Example</h1> <p>This is <em>markup</em> written literally.</p>]]></code></pre>
Birnam wood is come to Dunsinane
Does this mean there is no real benefit to xhtml? I thought that xhtml was meant to aid usability, functionality, navigation, standards, and ultimatley impinges on search engine optimisation (because search engines are increasingly becoming savvy to these things)....
We we all lead up the garden path?
Anyway....
Thank you for explaining it so clearly.
I've been doing projects in the past with xhtml validation, but now I see that isn't really xhtml at all... Especally since I've been trying so hard to get to a certain standard... now, my belief in the standard is rocked...
I guess its back to square one.... But at least my documents will be proper xhtml, or html, or whatever it is these days....
Thanks again.
Sounds framiliar, Tommy sent me for a dizzy a year or so ago too.
The roblem is not quite as you define it.
Not really, the idea of XHTML and the standards and all are good and solid IMHO, the problem is not the XHTML, the problem is the browsers not supporting it! Most do OK, except as usual IE which the majority of people still insist on using for some reason or another.
XHTML is threatened by lack of interest because in my opinion the W3C screwed up with making XHTML 1.0 and all that transitional stuff. I think we should have jumped straight to XHTML 1.1 or 2.0. But that did not happen so people like you now and me a year ago think we are doing XHTML when we were not. Especially those of us teachig ourselves, I avoided the W3C for years as I understood little. Tommy forced it on me
Now I see why I can use HTML 4.01 Strict...... but am so use to using closed empty elements and such that I really do not feel like changing, so keep writing XHTML, but serving it correctly where I can and wrong where I can't.
They should never have allowed Transtional anywhere, HTML or XHTML ...... they should have called for strict and left it at that. (IMHO)
Uhm, no.
Even HTML Strict will allow you to omit closing tags, the html, head and body elements, and more such things. It's actually very easy to produce valid HTML 4.01 Strict. But valid XHTML, now there's a challenge.
Sure, it's even much easier to write HTML which is complete and utter crap and won't validate one bit, but it's definitely not difficult to produce valid HTML.
THIS is a very dangerous misconception that people on the HTML-fence have.
To make things very clear:
Valid HTML 4.01 Strict documents can still have no closing tags, no HTML, no HEAD and no BODY tags!
Hence, producing a valid XHTML document is indefinitely more challenging than producing a valid HTML document. They can be equally difficult, when you write your HTML out in full, but HTML Strict does not require you to do that at all, whereas XHTML does.
The one having the misconception here is you, I'm afraid. HTML does allow for sloppy code. Strict conformance to HTML can still produce very sloppy markup, but strict conformance to XHTML requires at least well-formed markup where all required elements are present and where all closing tags are added. Sure, you can still create completely unsemantic chaos with Strict (validating) XHTML, but if it validates you at least don't have tag soup, which you may well have with HTML.
The HTML Validator will not tell you about missing closing tags in Strict mode. This means your code can be sloppy and you won't even know it. This simply isn't the case with XHTML.
That is a false statement, so feel free to correct anybody who says that
The "Strict", "Transitional" and "Frameset" variants of XHTML 1.0 are actually continuations of the same Strict, Transitional and Frameset variants of HTML 4.01. Because XHTML 1.0 is a reformulation of HTML 4.01 in XML, it has the same three variants as HTML 4.01 did.
The "Transitional" variant of HTML 4.01 (and therefore XHTML 1.0 as well) was created in order to ease the transition from HTML 3.2 and earlier versions of HTML, which used markup for presentational information. The Transitional variant allows you to use features of HTML 3.2 such as the font, center, applet, and iframes element, or the bgcolor, color, noshade, target or nowrap attributes.
When creating a new document in HTML 4.01 or XHTML, however, it is recommended that you use the Strict variant and use stylesheets for the presentational information.
It is quite acceptable to use XHTML 1.0 Transitional for your Web page, particularly if you are in the process of upgrading your existing website from HTML 3.2 or Tag Soup. XHTML 1.0 Transitional is unique in that it is the only variant of XHTML that will ever allow legacy presentational markup (and forever will be).
[mmj] My magic jigsaw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Bit Depth Blog · Twitter · Contact me
Neon Javascript Framework Jokes
You've never sent a Content-Type header with Apache (or PHP/ASP/whichever) then, because IE simply cannot handle true XHTML.Ok, that was just an example taken from another page on my site. MEANT FOR DEMONSTRATION PURPOSES ONLY!
Guess I should start adding disclaimers.
P.S. I've always used "application/xhtml+xml" with no problems from IE.
Joe
Using a <meta> element to specify application/xhtml+xml does only one thing: your HTML document, with HTML Content-Type, should be saved as a .xhtml page, but no browsers I know actually do that, and so there is absolutely nothing that happens when you use a meta element for that.
If your page is light in size, meaning not a lot of KB, all conforming browsers (all mainstream browsers except for IE) will render your page faster. Additionally, your pages are ensured of being well-formed, because if they're not they'll give you a nasty Yellow Screen of Death
More complex or notable advantages are currently not great in number: you can combine MathML in your pages, for instance, but there are very very few people that have a need for that at all. Think mathematical professors that need to write out equations and formulas and don't want to use images for it.
Beyond that, there are only advantages if you come up with ideas of your own to include alternative content like MathML in your pages.
However, there are advantages to using XHTML itself, even when you serve it as text/html (or at least as text/html to all browsers that don't support application/xhtml+xml). For that, read the Case for XHTML.
Not really, there has just been a lot of confusion along the way and now people are mixing up XHTML with semantic purity.
If you want to aid usability, functionality, navigation, standards and search engine optimization, use semantically rich and meaningful markup. Whether you use XHTML or HTML is irrelevant for your own site, at that point.
The only thing that really makes a difference when you choose XHTML instead of HTML is the way you present yourself to other webdevelopers. Writing proper, semantically rich and valid XHTML effectively means you're being a very good evangelist for web standards all around. If you use semantically rich and valid HTML, on the other hand, then most people that look at your source will not learn a thing about web standards at all.
I'm afraid I'll have to disagree with you. I believe it is no easier to produce valid HTML 4.01 Strict than it is to produce valid XHTML 1.0 Strict.
It is not simply the case that HTML 'allows' empty elements to be unclosed. HTML requires empty elements to be unclosed. Closing an empty element in HTML is invalid. The situation with XHTML is different. Not harder, nor easier. There is still a syntax that must be adhered to, it is just a different syntax.
HTML 4.01 Strict will not allow you to omit the head or body element - it just specifies that the start and end tags for these elements are optional. So if you leave them out, they are implied. To be able to leave out beginning or end tags of elements, you have to know which elements have optional tags and which do not.
You cannot just omit the start or end tags of any element in HTML. If you omit the end tag of the title element, for example, you'll end up with an invalid document. If you are going to omit the start or end tags of any element, you have to memorise which elements do and do not have optional tags. There's a lot of elements in HTML. On the other hand, the same is very easy to memorise for XHTML, because the rule is exactly the same for all elements - that is, start and end tags are required on all elements.
Last edited by mmj; Apr 20, 2005 at 05:37.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Bit Depth Blog · Twitter · Contact me
Neon Javascript Framework Jokes
Is it still okay to create pages as xhtml as I am currently doing (or as many designers/developers are doing) with the following doctype, or do I have to make them strict?
Do I have to start using the application/html+xml thing for it to be truely considered to be XHTML, or do I need to wait until XHTML1.1 / 2 comes out?Code:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
Bottom line -- is it okay to keep coding as it is, even if isn't truely XHTML?
If you know CSS (or another stylesheet language) then I'd personally recommend Strict. If nothing else, using stylesheets will better prepare you for future versions of XHTML. There's nothing technically wrong with XHTML 1.0 Transitional and it's quite valid. It's just that it is recommended that stylesheets be used for presentation now and in the future. But the choice is yours. If you are not familiar with CSS and for whatever time or economic reasons it isn't worth learning, then it may be better in your situation to use Transitional - stick with the devil you know.
No, XHTML 1.0 may be served as text/html and still be considered XHTML - as defined in Appendix C of the XHTML 1.0 spec.Do I have to start using the application/html+xml thing for it to be truely considered to be XHTML
In my opinion (note, it's just an opinion) you will need to wait until all browsers support XHTML to use application/xhtml+xml. I am quite satisfied with the fact others will choose to use it with conforming browsers, or they may even avoid XHTML altogether and stick with HTML 4.01. This is personal choice as far as I am concerned. I think whether the code is valid and used correctly is a lot more important that which flavour or variant is used., or do I need to wait until XHTML1.1 / 2 comes out?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Bit Depth Blog · Twitter · Contact me
Neon Javascript Framework Jokes
Do you mind explaining why that is? I was under the impression that it would infact take longer to render, considering most browsers don't support incremental display of xhtml. I know Mozilla browsers don't, read here: http://www.mozilla.org/docs/web-deve...aq.html#accept. According to that very FAQ question:
And then, when you look at Google's pages most of the time there isn't a DOCTYPE to be seen! Even majour vendors seem not in a hurry to make the transition to XHTML! Is there really, then, for most circumstances, any advantage of using XHTML? The future is XHTML, but for now, is HTML 4.01 Strict the best option. If you code HTML 4.01 now in mind of a possible transformation to XHTML 1.0 Strict or a new version of XHTML then you should keep the process quite simple, even automatic with a bit of programming ability (and some additional testing of pages).
You're completely missing the point. The markup is what matters here, the markup is what I'm talking about, and the markup is the only thing that you, the writer of a web document, are involved in. You can more easily write a valid HTML Strict document as you can make mistakes by accident and still validate. Yes, if you omit BODY tags the element is implied -- in the DOM! NOT IN THE MARKUP!
If you omit <body> then nothing will suddenly, magically, place that in your markup. In effect the body element will be implied, yes, but it's still not in your markup.
Hence, given the very definite proof that I already gave in the form of that link, it is most definitely easier to write a valid HTML Strict document than it is to write a valid XHTML Strict document. HTML allows you to make a mistake, XHTML does not. That's a difference, and one of great importance even. It makes a difference in how difficult they are (or aren't), and thus, there is a difference between valid HTML Strict and valid XHTML Strict.
Also, nobody said anything about empty elements.
I've agreed with everything you've said so far in this thread, Thomas, but I'll have to disagree on this one.
Writing XHTML markup as specified in Appendix C "allows" you to serve it as text/html, i.e. to pass it off as HTML. If you do that, it is not XHTML as far as user agents are concerned, because they must interpret it as HTML.
The confusion here seems to come from a lack of understanding of something fundamental: The doctype declaration only tells a validating user agent which grammar to check conformance against. It's the media type (a.k.a. content type or MIME type) that tells the user agent which parser to use (XML or "SGML"), and it's the XML namespace of the <html> tag that tells the user agent that the document is XHTML – provided it is served as an application of XML.
Birnam wood is come to Dunsinane
Reality check: a user agent reads the markup, parses it, and builds a DOM tree. Then it renders the page from that DOM tree. Whether an implied element exists in the markup or not is completely irrelevant, since it exists in the DOM tree generated from that markup.
However, that is a moot point as long as it's sent as text/html, because it is then HTML, an HTML parser will be used, an HTML DOM tree will be built, and HTML error handling will be in place.
Well-formedness in XHTML is only enforced if you serve it as an application of XML. I'm all for that. Let's start doing it now. Anyone who still owns Microsoft shares had better sell them quickly.
Birnam wood is come to Dunsinane
I think this is quite a bombshell -- all this time, all those sites, all those people telling me to write xhtml, and I haven't been... It's like being told that the foundation for your house was really, in fact, sand...
No, you're missing the point again. The point is the markup, serving as an example to others. The DOM tree is completely irrelevant for this because people see the markup and not the DOM (unless they go use the DOM inspector, but that's not what beginning webdevelopers do at all).
I know perfectly well that the markup is used by the browser to build the DOM tree; if you'd read my post correctly, you'd notice that I already said this, too. But we're not discussing the DOM, we're not discussing the presence of elements in the DOM, we're discussing the markup that is used as an example by others.
Again, you're missing the point. It's not error-handling that we're discussing, it's the markup, being used by new webdevelopers as an example.However, that is a moot point as long as it's sent as text/html, because it is then HTML, an HTML parser will be used, an HTML DOM tree will be built, and HTML error handling will be in place.
Well-formedness in XHTML is only enforced if you serve it as an application of XML. I'm all for that. Let's start doing it now. Anyone who still owns Microsoft shares had better sell them quickly.
Since HTML allows you to make a mistake and still be Valid HTML 4.01 Strict, the message that you send out to new webdevelopers is that it's okay to make a mistake. However, once they switch to true XHTML, they'll find out that it's not okay to make a mistake.
HTML is slowing down progress because it's not telling you that you are not allowed to make mistakes. XHTML is not like that.
On a side note: my CMS sends all pages as application/xhtml+xml to browsers that support it.
Basically, incremental rendering is only useful if you don't have the entire document instantly. So, if you're on dialup or the page is extremely big, then you'll want incremental rendering because you're only getting the page in increments.
However, if you're on any broadband connection and your bandwidth isn't being consumed for the full 100%, you'll get the entire page instantly (excluding images, but those are irrelevant for this) and you won't need incremental rendering. And in such situations, you'll get the page faster in front of you than you would if it'd been HTML.
No, Mr T. didn't say if you produce malformed HTML 4.01 it would be valid; he did say it is likely the User Agent would probably render and display the results from the markup.
Though if you used malformed XHTML or just wrote XHTML-P don't expect it to just work when served as aplication/xhtml+xml. I think you were getting confused when he was talking about well-formedness verses valid.
};-) http://www.xhtmlcoder.com/
Thinking Web: Voices of the Community
> March 2013 - SitePoint forums: Spot the Error 3: Calling all Sleuths! Winner Announced!... She knows how to spot simple <code> errors but do you?
OK, I didn't understand that. Sorry. I thought we were still talking technical merits of one vs. the other.
Anyway, as long as the document is valid, what more can you ask? If HTML allows you to omit the <body> and </body> tags, and you choose to do so for some reason, that is perfectly acceptable HTML. If a beginner looked at that markup and copied it, s/he would also create acceptable HTML that would work in any HTML user agent. Sooner or later they'd find out that this is frowned upon by the propeller-heads, and they will probably start putting those tags in.
I agree that it doesn't set a good example, and that we should always try to set good examples. But using an XHTML doctype does not in any way guarantee a good example! Do you think that this markup (which would be valid except for the unencoded ampersands in the URI) sets a good example for XHTML?
When a beginner sees this, s/he'll think that using the 'language' attribute is necessary, and that you should put comment tags around your script code. That's not good XHTML, is it?HTML Code:<script language="javascript" type="text/javascript"> <!-- var __CMS_PostbackForm = document.Form1; var __CMS_CurrentUrl = "(bad URI)"; __CMS_PostbackForm.action = __CMS_CurrentUrl; // --> </script>
Birnam wood is come to Dunsinane
My point was and is that with HTML you can make a mistake and still be valid, but with XHTML you cannot. If you mess up with XHTML, you fail, you lose at Internets, you are teh suck. (to throw in some silly catch phrases)
If you mess up with HTML, there's a chance you won't know because your document still validates as Strict.
But here's the key: if a beginner does that, their end-result may be acceptable, but they have no clue what they're doing, still, nor why exactly. With XHTML, they're forced to know, at least to SOME extent, what they're doing and why.
I'll agree with you on the obvious rebuttal that tons of people are using XHTML without knowing what they're doing, or even why (though, they know to an extent at least: Web Standards), but that's because the experts of today were all pretty clueless themselves, "yesterday" (i.e. 2-3 years ago at the start of the hype).
I'll agree with you in that all the people writing XHTML without having a clue are not being a good example. However, I can give you 8 billion pages worth of people doing HTML in an absolutely horrible way. At least the people writing (crappy) XHTML have taken the first step towards a better future, which is more than can be said about those 8 billion pages. It is now up to us, the informed webdevelopers, to enlighten these people that just slapping on an XHTML doctype doesn't make their pages be good all of a sudden. But they've taken the first step at least.
Or: they'll switch to XHTML and have tons of problems because they got used to leaving out a lot of stuff and will curse XHTML and condemn the future of the web. Risky business, that.
I agree, but I never said that using an XHTML doctype was any form of guarantee for that. Please keep that in mind. I don't support people mindlessly jumping the XHTML bandwagon and just slapping an XHTML doctype on their horrible tag soup, no! But I see a great many people switching to XHTML and putting serious effort into learning how to write semantic markup, and them I support!
That's not good XHTML no, but I never said XHTML was perfect either
Hi, folks!
Sorry, but I couldn't figure out how to start a new thread?!? So, here goes:
Sometime ago I made the mistake of purchasing a Flash Template from TemplateMonster.Com: and, what I paid for was a virutal mess of scripting. I have been months trying to fix everything. I recently completed chaning everything to small letters, adding "#" where there were none in the bgcolor="#" script, placing "alt=""" tags where there were none, and placing "" where there were none. (See the example here: <TABLE WIDTH=100% height="100%" BORDER=0 CELLPADDING=0 CELLSPACING=0 bgcolor="FFFFFF">.)
Now my home page --http://www.willametteweb.us-- is all askew. It nakes it even worse if I add the following <!DOCTYPE> to the page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
I have to omit the latter script?!?
My question to all of you is, "How do I fix these problems?" In addition, the W3C HTML Validator doesn't recognize the following scripts either: "td colspan="5" background="images/bgtop1.gif" height="29" width="606">"
Thank you, for your support.
Jallard
Posting Permissions
Bookmarks