Posted on January 24, 2009 - by Khaled
XHTML Users: Grow up!
During the last years Web standards started to gain an increasing popularity among Web designers. Still Web standards addicts are a ceaselessly growing minority until now. This is probably due to the fact that the majority regards the use of web standards in their projects as a hard process that requires a lot of time and process. Which is not 100% true in my opinion as Web Standards are the only right way to go! Dedication to standards is the key! following the W3C recommendations is a must! This is the first post from the “WEB STANDARDS ARE THE ONLY WAY!” series. And what a better start than having a “pragmatic evangelist for web standards and accessibility” sharing his view about subjects like the future of HTML, the use of XHTML or Should we start using HTML5?
So here’s a short, yet very interesting, interview with Tommy Olsson. But first let’s introduce Tommy to those who don’t know him. Tommy is a Swedish Web standards and accessibility Guru. He’s the Design Team leader at the SitePoint forums (so he’s my boss there!). He has written many articles for SitePoint and especially he co-authored with Paul O’Brien the SitePoint CSS reference. He had also won the “HTML/XHTML Guru” award of the SPF community for several consecutive years. You can check out his blog here.
The Future of HTML and HTML5
1. Almost 20 years after the first relase of HTML how do you see its future?
I’ll confidently state that HTML will have its place in web development for the foreseeable future … provided you don’t ask me how long that is.
There is a need for a semantic markup language to exchange information between people. Although there are fashionable trends with ‘rich content’ (which invariably means ‘flashy’ and ‘pretty’ rather than ‘useful’), all such technologies have drawbacks when it comes to accessibility. HTML as such is inherently accessible.
2.What are your thoughts about HTML5? should we start using the released drafts especially with the available validators? What does it add? is it heading towards more respect of semantics? What potential does HTML5 has?
HTML5 worries me. A lot. I’ve been using HTML since 1993 (before it even had a version number), so I’ve seen the changes it has gone through. In the mid-’90s there was a loss of focus on semantics, in favour of presentation, but it quickly became apparent that this was the wrong way to go. Content and presentation should be kept separate, which is why CSS was invented.
The ongoing work with HTML5 seems to ignore semantics to a large degree. Yes, it proposes to add a handful of semantic element types, but it also adds purely presentational stuff that – in my opinion – doesn’t belong in a markup language.
Even worse is that it redefines long-established semantics of existing element types. For instance, the P element type no longer denotes a paragraph; it becomes a generic block-level container – nothing more than a synonym for DIV.
The contempt for accessibility is even more worrying. The drafts propose to eliminate several important attributes (or at least make them non-required). The reason appears to be a lack of support in contemporary assistive technology.
My opinion is that HTML5 is to semantics and accessibility what Herod was to the Bethlehem Playground Association!
Should we use it? For experimental purposes, perhaps, but I would strongly recommend against any attempt to use it on a serious, professional web site. Why? Because it’s not a W3C recommendation. It’s just an early draft which is likely to change many times before consensus is reached. (If that ever happens.)
XHTML? Again?
3. What are your thoughts about combining HTML5 and XHTML2?
XHTML2 is not backwards compatible with HTML at all. That’s also true for parts of HTML5, but not to the same degree. (If I’ve understood the drafts correctly.)
XHTML2 did show some interesting proposals for semantics and accessibility, but the fact that it’s an application of XML makes it utterly inappropriate for web pages, at least until the day we have really good authoring tools. Handcoding XML is not a good idea in a production environment, due to its draconian error handling.
XHTML2 and (X)HTML5 aren’t compatible, and their progress appears to diverge. I think it would be difficult to reconcile them into a single markup language.
4. What do you say to people ‘using‘ XHTML ?
Grow up! 
Seriously, XHTML is long dead, due to a decade of horrible abuse. Not even the bleached bones remain.
Web Standards & Browsers?
5. Why should Web designers always respect Web standards?
For the same reason that other professionals should respect the standards of their business. It makes life so much easier for everyone – browser vendors, web designers and developers, users, …
Anyone who tried to create web sites during the Browser Wars of the late ’90s will know what I mean .
6. What’s your favourite browser and why?
Opera. It’s the most standards compliant browser, which means it’s easy to see if I got my stuff right. It also comes loaded with tons of useful features (and, admittedly, quite a few I haven’t yet found a use for). It’s more customisable than any other browser and it’s available for lots of different platforms. I use it with GNU/Linux at home and with Windows XP at the office, and it looks and works exactly the same. I even use Opera Mini on my mobile.
I rarely use the mouse when I browse, preferring keyboard navigation. And there’s no browser that beats Opera when it comes to keyboard navigation!
7. Which Web browser do you think is going to gain even more market shere in 2009?
I really wish I could say Opera, but I don’t think it will happen. I’m sure IE8 will take a large piece of the cake when it’s released, regardless of how good (or bad) it turns out. I also think it’s quite possible that Chrome will increase its share – possibly at the expense of Safari and/or Firefox.
8. Anything you want to add?
You really don’t want to ask a chatterbox like me that question! I can talk ’til the cows come home, you know that.
But I’ll settle for, ‘Thanks for letting me use your soapbox for a while.’
I enjoyed having Tommy answering these questions that might briefly summarize the actual situation when it comes to HTML, XHTML and HTML5. I think this short interview will be a good and fast to read reference for many web designers. I hope you enjoyed it too and that it will help you making the right decisions when it comes to web design and web development. To make this blog post even more interesting I am including Tommy’s HTML Guru list! check it out
So You Want To Be An HTML Guru?
Try this list compiled by Tommy Olsson based on articles published on SitePoint:
I may add another nice article: Learn HTML and CSS: An Absolute Beginner’s Guide by Ian Lloyd.
Stay tuned for the next posts of the “WEB STANDARDS ARE THE ONLY WAY!” series! Don’t forget to subscribe to be notified via RSS or E-mail.
SitePoint HTML & CSS references:
137 Comments
We'd love to hear yours!
Leave a Comment
Here's your chance to speak.
Visit My Website
February 5, 2012
Permalink
Футболка Защитник отечества
Футболка АК-4 7http://www.vsemayk1.ru/doc/82/search/Tolstovka-Bez-bab
Visit My Website
January 24, 2009
Permalink
So what do you recommend we use in place of XHTML?
Visit My Website
January 24, 2009
Permalink
just use Strict HTML4.01
Visit My Website
January 24, 2009
Permalink
So what is the follow-up recommendation, then? This reads sort of like an inside joke that outsiders like myself may not know the answer to.
Great interview. Thanks!
Visit My Website
January 24, 2009
Permalink
The other 2 comments (asking & answering my question) weren’t there a minute ago. Oops.
Visit My Website
January 24, 2009
Permalink
No problem at all
Happy you liked the interview!
Visit My Website
January 24, 2009
Permalink
Can you please explain how you came to that conclusion? In any case, that is not correct. the definition for the p element clearly states:
where “paragraph” is defined in the spec as:
Visit My Website
January 24, 2009
Permalink
I like the interview. I was using XHTML1 since few years now and I thought it was the right thing to do and that it was somehow the new HTML. It seems that I am wrong…
Visit My Website
January 24, 2009
Permalink
nice post and easy to understand even for beginners like me
Visit My Website
January 24, 2009
Permalink
Ditto Rania, I am a web designer since few years now, despite that I started as a graphic designer, and I’ve been using XHTML since 2006. Nobody ever told me I shouldn’t and even some clients required it.
Visit My Website
January 24, 2009
Permalink
@Aalaap Ghag and D9r: The latest recommendation with widespread support is HTML 4.01, so that’s what I recommend. Using the Strict DTD, of course, since it’s clearly stated by W3C as the only appropriate choice.
@Lachlan: You answered your own question.
First you offered the correct definition of a paragraph, and then you added a “but” and a string of completely unrelated stuff (except for the stanza). You’re only focusing on presentation (it’s got line breaks before or after, hence it’s a paragraph) and ignoring semantics.
A ‘part’ of a form may or may not be a paragraph. If it’s a label and an input control, it’s very unlikely that it will constitute a paragraph. If you want an element type for that, why not use as in XHTML2?
@Maybel and Sonia Marras: You are not alone. Thousands of designers and developers have been tricked into believing that they use XHTML and that it’s superior to HTML. They don’t, and it isn’t (except for a small number of advanced users with very limited target audiences).
@Khaled: Thanks for asking me for the interview!
Visit My Website
January 24, 2009
Permalink
My answer to Lachlan was mangled by the comment system. I was suggesting the use of an L element (<l>) as in XHTML2.
Visit My Website
January 24, 2009
Permalink
Terrific post I just love it thanks and the links are great too
Visit My Website
January 24, 2009
Permalink
@Lachlan Hunt Nice to see you here!
@Tommy thanks again!
@Rania you took the plunge?
Visit My Website
January 24, 2009
Permalink
@Tommy Olsson: Thank you for comforting me lol
Visit My Website
January 25, 2009
Permalink
Nice interview.
I also use XHTML for my projects cause I didnt know that we should use HTML, yikes!
thanks anyways.
-Zair
Visit My Website
January 25, 2009
Permalink
Opera may do a good job with standards, but it’s graphics rendering engine is inferior to both Firefox and Safari.
As for the statement on XHTML…HTML 4 is to markup, like 8-track is to music.
Visit My Website
January 25, 2009
Permalink
@Tommy Olsson: I too do not understand what you said about the P-element in the HTML 5 draft. And I understand nothing more from your follow-up comment to Lachlan.
A P-element can only represent a paragraph. However, a P-element is not the only way to represent a paragraph. There is no contradiciton in this, even if you think so.
Here is my attemt to define what a element of paragraph type is, in *HTML*: A paragraph is block element that (A) is semantic – AKA more than a container – and (B) which cannot nest itself within itself. (A paragraph cannot contain a paragraph.)
I am not sure if this is a good enough defintion, as it will also cover DT elemetns and TH elements (but I am not sure that it bad that those are included, either). It does make ADDRESS a paragraph, and H1-H6 elements, which I feel is right.
In HTML it is impossible to nest TABLE elemens inside P-elements (unless you use Quirks-Mode!). Thus it is impossible to create paragraphs that consist purely of a TABLE. Does that mean that the the TABLE element between those two P-elemnts does not make up a paragraph?
Outside HTML, I think that it is pretty common to think of texts – in general – as made up of paragraphs. We can look at the P-element as paragraphs in the most *narrow* sense. But we can also have more general definitions of what a paragraph is.
The Norwegian name for paragraph is ‘avsnitt’, and it has no formal definition. In fact, a ‘avsnitt’ can cover several p-elements. I believe it is the same for Swedish ‘stycke’. And I think both Swedish and Norwegian uses ‘paragraf’ to mean ‘article in a law’ – in other words: a format that has more to do with a list item.
Well. I am not satisfied with the draft. It need an element for stanzas, for example. But at the very least I see no basis for the claim you make about the P-element.
Visit My Website
January 26, 2009
Permalink
[...] XHTML Users: Grow up! | WebScienceMan [...]
Visit My Website
January 26, 2009
Permalink
KANKER HOER
!!
Visit My Website
January 26, 2009
Permalink
@Shelly: Please provide some information to back up your statements. Gecko and WebKit (the rendering engines in Firefox and Safari) provide (experimental) support for a few more properties expected in CSS3 than Opera does. Opera supports more of CSS2.1, though (especially for paged media). Gecko also has a number of serious float-related bugs.
I’d also like to know what you mean by your statement about XHTML vs HTML. I agree that *real* XHTML is more powerful than HTML, but virtually no-one uses real XHTML since IE doesn’t support it. And pretend-XHTML cannot possibly be anything other than HTML, since it *is* HTML.
@Leif Halvard Silli: The problem, as I see it, is that the HTML5 specification redefines the ‘paragraph’ concept. An address is not a paragraph by any known definition outside the HTML5 spec.
A ‘stycke’ in Swedish is one or more *sentences* that deal with one thought or idea. Sentences are sequences of words. A byline might be acceptable as a degenerated paragraph (usually elliptic, since there’s no explicit verb).
A legal ‘paragraf’ in Swedish (and, I suspect, Norwegian) corresponds to a ‘section’ in English legal vernacular. It can comprise several paragraphs.
Re your statement about nesting a table inside a paragraph: that’s not possible in HTML4 at all. Quirks mode has nothing to do with it; that only deals with rendering, not syntax or semantics.
Visit My Website
January 26, 2009
Permalink
@Khaled yep few days ago!
Visit My Website
January 26, 2009
Permalink
HTML4? wow that's ancient man!
Visit My Website
January 26, 2009
Permalink
@Rambler: Both HTML4 and XHTML1 are fairly old by now.
The HTML 4.01 specification is dated 24 December 1999.
The XHTML 1.0 specification is dated 26 January 2000.
That means XHTML1 is a whole month younger than HTML4.
Visit My Website
January 26, 2009
Permalink
I don't know about the examples chosen in the Spec, but the content-model of the HTML5 <p> element is much closer to the proper grammatical notion of "paragraph" than the HTML4 <p> element.
That certainly counts as a semantic improvement.
As to XHTML vs HTML, are you guys still wasting time arguing over that?
Yeesh!
XHTML 1.1 suits my needs just fine. HTML4 is useless to me. HTML5 may become relevant someday.. But not (I predict) anytime soon.
Visit My Website
January 26, 2009
Permalink
And, as to presentational fluff added to HTML5 (ie, not present in HTML4), what do you have in mind? Canvas? SVG?
Visit My Website
January 26, 2009
Permalink
Well interesting points here and there. How can I choose which way to follow?
Visit My Website
January 26, 2009
Permalink
@Leaflet Well I was wondering about the same thing?
Visit My Website
January 26, 2009
Permalink
@Tommy Olsson. (I can't see your answer *online*, yet. But may be when this get posted it becomes visible … ) My perception of 'stycke' was based on a Swedish wp for Mac. Perhaps a bad localisation, then. "Stykke" in Norwegian means "bit" or "part". It can be a bit of a paragraph. Or a bit of text – covering several paragraphs. "Deal with one thought or idea", is probably right – one would nto read a bit of a text unless it has som unity. The problem is that our word for paragraph (avsnitt) can be used the same way as 'stykke' (although perhaps typically so). Btw, perhaps you would like to rewrite what Swedish Wikipedia says about 'stycke'? Because it links to paragraph now … Just click the link to English wikipedia: http://sv.wikipedia.org/wiki/Stycke
"HTML 5 redefines the 'paragraph' concept" is a way of putting it that is more fruitful critique that to say that it defines P as a DIV. If you say "an address is not a paragraph by any known definition", then of course you are right. However, there is a difference between ADDRESS, the element and address, the concept. Just as IMG is an element and not an image. HTML 4 designates ADDRESS as "information on author", btw – which isn't a known definition of address anywhere, except in HTML 4, you could say … Address is for addresses, yes. But it is a paragraph lookalike, still.
In Norwegian laws, one typically hasn't used even the word "avsnitt" ("paragraph" in English) but rather the corresponding word for "link" (in Norwegian: "led", "ledd"). A "led" si the unnumbered and/or perhaps sometimes lettered paragraphs/blocks within a §# (numbered section – thanks for the correction on section). Well, I guess it would be possible to see these led-s as paragraphs *if* we have some consept of "paragraph kind of text".
QuirksMode isn't – when it comes to nesting of tables inside p-element – only a style thing, but another model of what HTML is. Of coursre it is illegal syntax – never meant anything else – becaue official HTML doesn't follwo the quirks model.
My view is more that it is amazing that the Hypertext Markup Language has no clear consept of what Paragraph is or of what itself means by paragraph. HTML 4 clearly only tells us how to mark-up paragraphs in the most narrow sense. HTML 5 draft tries to say, I think, that in real life, we cannot only view what lands in p-elements as paragraphs. We perhaps need another word than 'paragraph', though … However, it also has to be a usable concept, for authors..
Visit My Website
January 26, 2009
Permalink
Not necessarily an authoritative source, but here are some extracts of what dictionary.com has to say about the noun ‘paragraph’:
Essentially, you should be able to precede a paragraph with a ‘⁋’ symbol (used in typography to mark the beginning of a paragraph).
Visit My Website
January 26, 2009
Permalink
Opera's rendering engine may seem inferior but that's only because it doesn't make the allowances that Fx & IE do for invalid code. The fact that Opera aces the acid test proves that it has a decent rendering engine.
Now, as for your statement re: XHTML, you'll see that Tommy posted the following comment:
"Both HTML4 and XHTML1 are fairly old by now. The HTML 4.01 specification is dated 24 December 1999. The XHTML 1.0 specification is dated 26 January 2000. That means XHTML1 is a whole month younger than HTML4.
"
Besides, are you trying to make your case for the superiority of XHTML based on such a meaningless comparison? What you said proves absolutely nothing.
Visit My Website
January 26, 2009
Permalink
yep, XHTML/HTML is still being argued because there is still a substantial difference between the two … and masses of people being deceived that XHTML is the be-all end-all of perfect web markup.
Visit My Website
January 26, 2009
Permalink
The ACID test is more trouble than its worth. As we've seen recently, there was a race to be "first" to pass it, but it hasn't translated into any real advances. I'm not knocking Opera, I like Opera. But Opera also needs to improve it's rendering capability for SVG, and it also needs to see about incorporating color profiles. Want to see differences in the browsers? Then check out http://svgfeed.burningbird.netwith Opera, Safari, and Firefox (latest versions).
As to my comment on HTML4, it's no more "out there" than saying XHTML is a pile of bones. What a ridiculous statement to make, since XHTML is a standard a lot of sites use, though they don't serve their pages as XHTML. And frankly, when I see HTML 4 I think, old and quaint. Just like 8-track.
For those of us who do use XHTML (my site implements 1.1), served as XHTML, then we have a host of capabilities you don't have in HTML4, including RDFa, SVG, MathML, and so on–as Jacques mentioned. XHTML is nothing more than a platform on which to build — it continues to be "fresh" because we're not limited to a finite set of elements, and a boxed in set of capabilities.
Visit My Website
January 26, 2009
Permalink
Did you forget XHTML 1.1, which released in 2001? Regardless, as I mentioned in earlier comment, XHTML served as XHTML also allows us to incorporate all new elements and functionality, such as MathML, SVG, and RDFa. Can't do that with HTML4.
As for X/HTML5, I'm not the effort's biggest fan, but I know it's the way of future, not to mention sparking innovation that exists today in everything but IE. And even IE has implemented a few pieces.
Unless the web page functionality that was good enough for your grandpappy is good enough for you?
Visit My Website
January 26, 2009
Permalink
@Shelley, as you probably know, XHTML 1.0 is nothing but a reformulation of HTML 4.01 as an application of XML 1.0. It doesn’t add any semantics or anything; it’s just a parallel syntax for those who need to use XML features (such as including elements from other namespaces).
XHTML 1.1 is a reformulation of XHTML 1.0 using Modularization of XHTML. It does deprecate some attributes and it adds the Ruby annotation module (which no browser supports natively, as far as I know).
Either way, using XML namespaces or Ruby annotations require that you serve your XHTML markup as an application of XML. As I said above, I do agree that *real* XHTML is more powerful than HTML. The problem is that by serving XHTML as such you immediately exclude 70-90% of the surfing population, viz. those who use Internet Explorer (including IE7 and, in the near future, IE8).
There are a few ‘advanced’ authors, like Jaques Distler, who do make use of XHTML. But 99.999% of all ‘XHTML’ authors don’t. Yet most of them still believe that they are somehow avantgarde and superior, and that XHTML is much ‘newer’ and ‘stricter’ than HTML.
I don’t mind people using pretend-XHTML, but I think they should be aware of what they are doing.
Visit My Website
January 26, 2009
Permalink
If you use XHTML 1.1 served as XHTML, and it fits your needs, then more power to you. But that kind of setup is definitely not suitable to be recommended for just any website out there. For one, it won't work in IE, which eliminates a sizeable chunk of audience (depending on the makeup of a site's audience).
A few more points are listed here: http://www.spartanicus.utvinternet.ie/no-xhtml.ht…
Visit My Website
January 26, 2009
Permalink
There is a world of difference between XHTML, served as application/xhtml+xml, and HTML4.
Between "XHTML 1.0" served as text/html (please note the scare quotes) and HTML4? Not so much. The former is functionally equivalent to the latter, with some extra forward slashes (and a superfluous "xmlns" attribute) thrown in.
Since such markup spandrels are popular, but harmless, HTML5 makes them conforming. Which — one would have thought — would render the debate as to whether to include them obsolete.
Evidently not …
Visit My Website
January 26, 2009
Permalink
Comment system seems to be acting odd. Oh well.
Garrett, from the link you gave, I know you're aware of the use of content negotiation because of IE. Yes, it is a pain, but if I want to continue using both RDFa and SVG, which I do, I'll continue having to deal with IE.
The point of all of this is there no "right" way to develop web pages. If your site takes comments, you're going to want to be careful about using XHTML. If you have a bunch of ham handed designers and web page folks, you're going to want to be careful about XHTML. If you're not using things like SVG, then you don't "need" to server your pages as XHTML If you want to take advantage of SVG, inline, well, until HTML5 hits the street, all we have is XHTML. If you're using a tool like Drupal, which supports XHTML out of the box, you don't have to serve the XHTML as XHTML. If you're willing to walk the edge, then HTML5 might be the option for you.
A good designer, web developer weighs all the options. They don't just say, "Only use HTML 4" or "Only use XHTML".
Visit My Website
January 26, 2009
Permalink
Serving XHTML 1.0 as text/html isn't as harmless as you indicate. Please read these two pages for full enlightenment:
http://www.spartanicus.utvinternet.ie/no-xhtml.ht…
http://www.hixie.ch/advocacy/xhtml
Visit My Website
January 26, 2009
Permalink
true, but for the vast majority of sites, XHTML is not a good idea.
As I posted to Jacques above:
http://www.spartanicus.utvinternet.ie/no-xhtml.ht…
http://www.hixie.ch/advocacy/xhtml
Visit My Website
January 26, 2009
Permalink
Ben there, done that.
Nothing said there changes a word that I said.
And, I'll point out that the author of one of your two references is the Editor of the HTML5 Spec. So, at least on this issue, one may presume that he knows what he's doing.
I'll repeat: "XHTML 1.0" served as text/html is functionally equivalent to HTML4, with some extra forward slashes (and a superfluous "xmlns" attribute) thrown in. Since such markup spandrels are popular, but harmless, HTML5 makes them conforming.
Arguing that one is "better" than the other is useless waste of time.
Visit My Website
January 27, 2009
Permalink
Shelly wrote "A good designer, web developer weighs all the options. They don't just say, "Only use HTML 4" or "Only use XHTML"."
Good web authoring also relies on not repeating the same misguided and non-sequitur sources that Garrett keeps citing. These are pure misinformation spewed by monopolists (and their unsuspecting followers) to maintain their monopolies. There is no harm in serving XHTML1.0 as text/html. I doubt there would be much harm in serving XHTML2 as text/html (though there would be some visual problems with Ruby and other content model changes).
The problem is that Internet Explorer does not support XHTML (though it does support XML syntax when using colons in the names of elements like svg:path). So using XHTML and serving it to IE as text/html with namespaces actually can work just fine. The problem is that Microsoft has succeeded in stifling the development of HTML with their stunts. Continuing to cite these sources does a service to the web community.
Visit My Website
January 27, 2009
Permalink
You can serve anything you want, with any MIME-type you choose. The question is whether clients will be able to do something useful with the result.
HTML5 specifies a profile of MathML and SVG content that can be sent as text/hrml. Currently, very few browsers support that profile, even when sent as application/xhtml+xml. I’m not holding my breath for them to support it in text/html.
We’re even less likely to see browser implementations of XHTML2 anytime in the foreseeable future — even as XML, let alone as text/html.
I think Shelley can tell you that the travails of using “real” XHTML have little to do with its lack of support in IE.
Visit My Website
January 27, 2009
Permalink
@Jaques, yes XHTML 1.0 (compatible with Appendix C) served as text/html is “functionally” equivalent with HTML 4.01, but only because all common browsers have buggy HTML parsers.
The NET syntax is quite different between HTML and XML, and the singleton tag syntax used in XHTML really means something else in HTML.
It’s all theoretical, of course. Anything served as text/html *must* be parsed and treated as HTML, as per RFC 2854.
Visit My Website
January 27, 2009
Permalink
@Tommy, the browsers are not buggy unless you first assume that 1) they are supposed to parse HTML as SGML and 2) that the SGML they should parse HTML as has the NET syntax enabled (unlike XML which has the NET syntax disabled). Moreover if anyone tried to write an HTML document with any of those assumptions in mind it would not work in any major browser, so it seems twisted to say that the browsers are buggy rather than those assumptions are mistaken.
What is more, the parsing specified for HTML5 (which largely specifies browser parsing as it exists) would not be consistent with those two assumptions. So I think it's more accurate to say that the reason XHTML 1.0 appendix C conforming documents work when vended as text/html is that appendix C was designed to make it work that way. Again, no harm in vending XHMTL 1.0 documents as text/html (which is what I understand Jacques and Shelly as saying)
Visit My Website
January 27, 2009
Permalink
They *should* parse HTML as SGML, since HTML from version 2.0 up to and including version 4.01 are applications of SGML. (HTML5 won’t be.)
The SGML declaration for HTML specifies SHORTTAG YES, so NET syntax should be supported.
XML uses an extension to SGML which introduces a NESTC delimiter (NET-enabling start tag close). HTML’s NET syntax uses the default SGML NET delimiter (‘/’), so you should be able to write, e.g., >abbr/HTML/. XML uses ‘/’ as the NESTC and ‘>’ as the NET, but disallows NET syntax for anything but empty elements. Thus you can write an empty foo element as
I agree that there is no harm in serving XHTML 1.0 markup as text/html, if you know what you’re doing. However, there is no *point* in it, either. None whatsoever. It can’t be, because that *is* HTML from a user agent point of view.
Visit My Website
January 27, 2009
Permalink
All coded in XHTML 1.0 Strict SP refrences
Visit My Website
January 27, 2009
Permalink
Right, Shelley. Then please point out the amazing features in this reference that couldn’t have been achieved with HTML 4.01 markup!
Visit My Website
January 27, 2009
Permalink
Hopefully a comment of mine earlier didn't break the page. There's seems to be some mechanical issues with the comments.
Anyway, the point I made earlier is that Sitepoint just announced the release of a new JS section, and when I looked at the page, I noticed it was created in XHTML 1.0 Strict. Looking further, I noticed the whole site is in XHTML 1.0.
In fact, this page is in XHTML Transitional. I guess people don't eat their own dogfood?
Not many sites serve up their pages as XHTML, but few design with HTML4, either. As for not using XHTML because of IE, you know, if a page opens in IE, and it's viewable, that's all I care about with that browser.
Visit My Website
January 27, 2009
Permalink
The best approach would really be–when hand-coding content in a source code manner–to: 1) write content as XHTML1 (following appendix C); 2) parse that content into a DOM/Infoset as text/html (as specified by the HTML5 parsing algorithm or a better one); and 3) then serialize the content again into a database as pure XHTML. This would eliminate many errors such as the one currently exhibited on this page and it allows much easier XML processing by a content management system.
So for those of you wondering whether you should be coding to XHTML1 (appendix C), just go ahead and continue doing so. You're not doing anything wrong. You're CMS on the other hand is probably doing something wrong that you cannot fix by changing back to HTML4.01.
Visit My Website
January 27, 2009
Permalink
Just to add a little more explanation of where I'm coming from on this.
This is based on the tenet “be strict in what you produce and lenient in what you accept” so authoring XHTML (Appendix C which is even stricter than just XHTML) is the best approach (strict in what the author produces). Then the XHTML needs to be parsed into an Infoset/DOM as text/html (lenient in what the CMS accepts) and finally serialized again into the database and later into a compiled web page as XHTML appendix C again (strict in what the CMS produces). Then if it is served as either text/html or applicaiton/xhtml+xml, it will work fine.
Errors will be discovered immediately by the author (a commenter for example) in the preview (if the CMS has a preview). Either way, the final content emitted from the CMS will be totally well-formed XHMTL content (and valid in the sense that it conforms to XHTML1.0 appendix C). The serialization as XML (and a Unicode UTF) is what allows all the content to be unambiguously combined with other content without breaking anything.
Visit My Website
January 27, 2009
Permalink
I don't think anyone can tell us how little XHTML deployment problems have to do with lack of support in IE. Microsoft has been pursuing this strategy to undermine XHTML for 10 years now. We have no way to determine how much better support for XHTML would be in all browsers if Microsoft had not pursued that strategy but I would be the support would be substantially better than it currently is (including for compound documents and other XML applications)
Visit My Website
January 27, 2009
Permalink
I'm not talking about browser support. I'm talking about authoring.
In any case, even when it comes to browser support, "supports XHTML" doesn't mean much by itself.
Neither Opera, nor Safari, support MathML. As Shelley has complained, Opera's SVG support is kinda dodgy…
Just because a browser has "application/xhtml+xml" in its Accept header, that doesn't mean you can actually do anything useful.
Visit My Website
January 27, 2009
Permalink
Do you actually have an implementation that does that?
I have something that's pretty close, But, of course, I'm interested in producing "real" XHTML.
I'm very interested to hear if anyone has done anything remotely similar in their CMS.
I'm not sure I understand.
Step 1 of your fantasy CMS system uses an HTML5 parser to parse the user input into a DOM. That could just as easily be done with user input that purported to be HTML4 as with user input that purported to be XHTML1.0.
"Just as easily", of course, works both ways. HTML4-like input is neither better nor worse than XHTML1.0-like input.
Visit My Website
January 27, 2009
Permalink
In terms of the parser XHTML1 and HTML4.01 are largely the same. However from an authoring standpoint XHTML is actually much easier to understand. It's much easier for authors to understand always quote attribute values than to sometimes quote and other times omit. It is much easier for authors to understand void (defined as empty) elements when the syntax always includes <br /> than to make "br" seem similar to "p", when it is not. So there are many pedagogical benefits to XHTML that HTML4 does not have. Ideally we would just use visual//GUI editors in our CMS and never touch text/html parsing until the last moment. However, until that day comes it is far better to use XHTML for composing than traditional HTML. Also following appendix C approaches of linking rather than embedding stylesheets and scripts and using excaped CDATA sections otherwise can be a more complicated thing for authors to understand, but those are areas typically not touched by casual CMS posters or commenters.
Now for all you "power-coders" out there saying, but I already know all of the idiosyncrasies of traditional HTML serializations, this doesn't apply to you. But for God's sake please stop making everyone else feel bad about using XHTML.
Visit My Website
January 27, 2009
Permalink
Also on the HTML5 or better parser that's the most fantasy part of the suggestion. However, the text/html parsers of all current browsers is a sufficient approximation to accomplish the necessary results (IE, WebKit, Gecko, Opera, etc.). Especially for CMS parsing of comments and posts, the issues are minor to non-existent. A CMS could simply rely on the DOM produced on the client end of the CMS poster, but rather than using the serialized string of what the poster entered, get the actual DOM and serialize that as XHTML client-side before sending it to the server. Most of the common problems could be elminated with such an approach.
Visit My Website
January 27, 2009
Permalink
I'm sorry, I'm not the one trying to dissuade people from producing XHTML1.0 as text/html.
I have just as little patience for bogus arguments for the superiority of HTML4 over XHTML1.0 as text/html as I have for bogus arguments for the superiority of the latter over the former.
If your concern is actually getting people to produce better markup then, if I were you, I would spend less time engaged in making bogus arguments on one side or the other of this "debate", and more time advocating for better coding practices, with or without the extra forward-slashes and the superfluous xmlns attribute.
Visit My Website
January 27, 2009
Permalink
Rather than just calling my arguments bogus, you would gain more points by actually addressing what is wrong with the arguments.
As for changing coding practices but not producie XHTML 1.0, why? Producer's have limited resources for validation purposes. As an author it is much easier to add the self-closing tag (which also has valuable pedagogical effects) and add an xmlns attribute (which provides additional information and therefore is not superfluous just because one UA or another UA might not make any use of the information) and then be able to validate against XHTML1.0, then to validate against HTML 4, and then manually check to see if other syntactic requirements are met.
What I meant by applying your word "fantasy" was that I was suggesting we should get a better text/html parser than the HTML5's parser, which focuses on the needs of Microsoft more than on the needs of HTML users and authors (I am working now on speccing just such an improved parsing algorithm).
In any event, this misses the point of what I'm suggesting (again caught up in pissing contests instead of engaging arguments). The point is that the parsing should typically be done client-side. In that way the user/author sees the results of their parsed string. However, instead of submitted the original parsed string from the user/author, the CMS should proceed to XHTML/UCS (ISO10646) serialize the DOM produced by that string and submit that to the server. The CMS should then only add that content as a child of other content. No more well-formedness errors, no more surprises, etc. With the errors that occurred on this page (following that approach), the worst we would have seen is perhaps a broken link (which is far superior than entire threads disappearing from the page).
Visit My Website
January 28, 2009
Permalink
I would say that if every major rendering engine (or is it every rendering engine) treats the parsing as SHOTTAG NO then the bug is in the SGML declaration meant to describe HTML 1 and not in all the rendering engines that parse HTML. It would be much easier to fix the DTD declaration than to break all of the various text/html rendering engines to introduce the SHORTTAG YES syntax.
I would also reverse what you say about harm. It take much more know-how to produce and reuse HTML 4.01 content than it does to produce and reuse XHTML 1.0 content—particularly for appendix C XHTML 1.0 content. Imagine someone following the common practice of learning HTML through copying other existing web content where they encounter this <img alt=John href=anurl > and changing that to <img alt=my trip to the county fair href=anotherurl >. Such copying goes from valid HTML 4.01 to invalid XHTML 1.0. However, the same thing is not true of XHTML 1.0 content <img alt="John" href="anurl" /> and changing that to <img alt="my trip to the county fair" href="anotherurl" />. Authoring to XHTML 1.0 requirements also gives authors an easy DTD to validate against (one that's the closes to appendix C they can get from the W3C). The gotchas that might arise when authoring to XHTML 1.0 appendix C all relate to the syntax prior to the root element (processing instructions and XML declaration) which might trigger quirksmode.
Visit My Website
January 28, 2009
Permalink
Content, sent as text/html, whether ostensibly "XHTML1.0" or ostentibly "HTML4" is html.
It is treated identically by browsers, and it SHOULD NOT (in the RFC sense of the phrase) be treated as XML by other clients.
Any argument that assumes that XHTML 1.0, sent as text/html, is anything other that html is prima facie bogus.
But, if you insist …
I don't see why it is of any greater pedagogical value that BR admits a self-closing tag, but an empty DIV (used to clear a float) does not.
The latter, of course, is completely legal in "real" XHTML, but will totally screw up if you send it as text/html.
Ditto for SCRIPT elements which reference an external Javascript file (and hence are empty). Try explaining why IMG admits a self-closing tag, but SCRIPT does not.
In this context, the xmlns attribute contains no information whatsoever, as all content sent as text/html is html. That attribute does not exist in html and, like all unknown attributes, is silently ignored.
This is not a matter of "one UA or another UA". It's the way the Web works.
Validating your content against some markup Standard is valuable. I thought you were advocating one particular standard, with an "X" in the name, as superior to another. I'm not sure I understand this sentence.
What is your metric for "better" in this case?
There are a large number of HTML parsers on the market. For the vast majority of them, "better" means "behave more like browsers".
In that respect, the HTML5 parser is "better" than all of the competition (excepting, of course, the parsers actually contained in browsers).
There are lots of Javascript-based schemes like that ("live previews" they're often called). They frequently suck because the markup restrictions imposed by the application on the server fail to match those of the client-side javascript.
The server-side CMS still has to parse and sanitize the received snippet of XHTML anyway, so I don't see where the saving is.
Why parse and reserialize on the client side, if you're just going to have to re-parse and re-serialize that content server-side anyway?
This appears to be a heavily modified version of WordPress.
Retrofitting WordPress to use your scheme seems like a hopeless task.
And, if one is going to build a blogging platform from scratch, there are much better ways to achieve the desired degree of robustness.
o?
I would suggest that retrofitting a scheme such as yours onto WordPress would be a completely hopeless task.
And if one were writing a blogging platform from scratch, there are a lot better ways to achieve the desired robustness.
Visit My Website
January 28, 2009
Permalink
I think the reason you're arguments keep reducing to "it is bogus" is because you can't come up with a better argument. For example it is not bogus to consider a document that conforms to XML, XHTML 1.0, and XHTML 1.0 recommendations as not an XHTML document. The metadata content-type passed along with the document indicates the content-type/media-type of the document and it provides an authoritative indication to the UA on how to process the document. But it cannot change the document into something other than what it is. If the document is sent in one second as text/html and the next second as applicaiton/xhtml+xml (just as Shelly does), does the document get transformed from one form to another. No, what is happening is that the server or some other protocol is changing how the document is processed. We must still be able to understand that the document is different from how it might be parsed at one time or another. Or consider the extreme example where a hard link points myxhtml.html => myxhtml.xhtml (where the filename extensions are mapped to the usual mime types). What kind of file is that if it conforms to XHTML 1.0 appendix C and its DOCTYPE delcares it as XHTML 1.0 file? Is that a bogus XHTML file? Or is it a genuine XHTML file? If it is a bogus XHTML file, then I guess I shouldn't be so concerned with things being bogus. But I'd rather we stop using the word bogus in that way because it scares people away from using XHTML because they think bogus might be a bad thing.
Let me take just the one issue of using the user's own browser to parse as text/html rather than doing so server-side. The reason to serialize client-side is because that step eliminates any surprises because the user has an opportunity to view a DOM/Infoset of what they entered and can verify the content parsed as it is meant to parse (the user could even verify the links are not broken if they bother to get that detailed). Then it is a great benefit to send an XML serialized instance of that DOM/Infoset to the server to remain pure XML from that stage onward until nearly the end (if the final consumer of the content needs to have text/html parsing again). By keeping it XML through out the middle stages, it simplifies processing greatly. The parsing of XML is understood much better than text/html style parsing. Each browser has its own idiosyncrasies when it comes to parsing and many CMS deployments add even more bizarre quirks to text/html parsing (html5lib included). Keeping it XML (and UTF), as much as possible would solve many of the problems plaguing CMS administrators. The server needs an XHTML1.0 appendix c compliant serializer and the client javascript needs to serialize as XHTML (of any stripe). That's a much simpler approach to the dizzying approaches emulated in one CMS after another.
One more thing I'll say about santizing. While server-side santizing does nothing to diminish the benefits I just outlined, I will say that server-side santizing tends to be way too aggressive, often removing accessibility related content or deciding that nesting lists three levels deep is a sign of insanity. Obviously scripts and maybe stylesheets should be sanitized, but too often sanitizing is abused.
Visit My Website
January 28, 2009
Permalink
@me
That should have read
Visit My Website
January 28, 2009
Permalink
Now, there you are wrong. I can embed RDFa in the page, and other applications can access it. Opera doesn't handle all aspects of SVG, but does handle others. I use SVG all the time at my sites, and it works for all the browsers but IE.
These may not be useful to everyone, but they are to me
Visit My Website
January 28, 2009
Permalink
Tommy, can you point out which comment of mine you're responding to?
Visit My Website
January 28, 2009
Permalink
Tommy, I mentioned the rendering engine, not the architecture. Put a diagonal resizing SVG as background to the page, and you'll see that Opera has rendering problems with it. Not as bad as Chrome, but lacking the smoothness and efficiency of Webkit/Safari. There is more to the graphics of a page than how many elements you support. You also have to support them well.
This page is XHTML, your Sitepoint is all XHTML, most pages are XHTML. They are not served as XHTML, but they are "coded" in XHTML. Your arguments are, frankly, specious.
Convert all of Sitepoint to HTML 4.01, and then I'll take your statements more seriously.
Visit My Website
January 28, 2009
Permalink
The comment system here is really a problem, but I'll try…
I have used XHTML at my sites for years, and yes, served as XHTML. I use SVG in most of my pages. I also use RDFa in my pages, too. I'm not excluding IE, but they don't see all of the annotation. As for 70-90%, you have to stop living in yesterday. IE is losing market share, and IE8 will only hasten people leaving. IE8 and Google's aggressive campaign with Chrome.
Visit My Website
January 28, 2009
Permalink
Perhaps I didn't express myself as well as I could have.
My point was that the advantage of XHTML (for you, for me, and for most users of "real" XHTML) is the ability to include foreign namespaces in your content.
The fact that a given client has 'application/xhtml+xml' in its Accept header does not mean that it will necessarily be able to make heads or tails of that foreign content. Perhaps some other client will be able to make sense of that content, but that's another matter.
Even if IE8 were to magically start sporting 'application/xhtml+xml' in its Accept header, this would not do you (or me or anyone else) the slightest bit of good, unless it also some of the foreign namespaces you use in your content.
That sort of support is slow in coming (even from the other browser-makers).
In fact, IE, with a plugin, does a quite creditable job of rendering MathML. Which, ironically, puts IE far ahead of Opera and Safari, for my particular use-case, despite the fact that the latter have 'application/xhtml+xml' in their Accept headers.
Visit My Website
January 28, 2009
Permalink
You seem to have a platonic notion of the ontological status of the aforementioned "document".
Not being privy to the internal workings of the server in question, all I know about is the stream of bytes sent in response to my GET request. That stream of bytes might contain the content of a file on disk, or it might have been generated on-the-fly.
Indeed, the precise stream of bytes returned, in response to my request may differ, depending on all sorts of details, including the precise headers sent along with the request.
But let us pretend, for the sake of argument, that there is such a thing as "the" document, whose platonic nature is unaffected by the server's authoritative statement as to its Content-Type.
Since 90+% of the documents, sent as text/html, which purport to be XHTML, are in fact ill-formed, it would be folly indeed for clients to ignore the RFCs, and attempt to treat such documents as XHTML.
You can jump up and down all you want, attempting to convince me that such document "really are XHTML", but in the real world, they are not.
I would be much easier to convince if you could point me to an implementation that actually used the approach you suggest.
Perhaps I am simply misunderstanding, but what you describe doesn't seem to me to solve any of the problems one actually encounters in trying to build a CMS (in particular one capable of handling XHTML).
As to you comments on Sanitization, I would suggest you take a look at the html5lib Sanitizer.
Visit My Website
January 28, 2009
Permalink
@me
That certainly is one possible metric. And the HTML5 parsing algorithm does a fairly good job by that measure. However, the WhatWG refuses to add some features of IE to the algorithm to give Microsoft the upper-hand (which creates trouble for authors and users) For example, IE8 permits XML-like syntax within elements containing colons in their names, but WhatWG blocks any attempt to bring such foreign element name parsing to their algorithm.
I'm using several metrics however. I would like to see a new text/html parsing algorithm support XML-like void element syntax for all unknown (non-HTML) elements (not only those with colons in their name and not only those with namespace declarations, though I'd like to see text/html parser support for namespaces too). Such parsing improvements allow the HTML vocabulary to evolve even without switching to XHTML (though it also renders IEs strategy of stifling XHTML moot as well).
Visit My Website
January 28, 2009
Permalink
LOL, in what response?
I believe you. I don’t use SVG (yet) since I don’t have the luxury of writing a website that can ignore IE users. I’m sure it’s a great thing.
This page and SitePoint are written with XHTML markup, but they are not using XHTML. Just check the HTTP headers (e.g., using the Info panel in Opera). They are served as text/html, hence they are HTML. Missing a </p> tag in the markup would not cause browser parsers to grind to a halt.
Just to clear up any misapprehensions, I have nothing to do with SitePoint. Like Khaled, I’m merely a volunteer moderator for their forums. We have no influence over how the site or the forums are made.
Some of the SitePoint employees are rather fanatic about XHTML and refuse to admit that pretend-XHTML is technically pointless. It amazes me, really, because they are very clever people who are otherwise very savvy.
If you want to indicate some hypocrisy on my part, you should point out that my humble blog uses XHTML 1.1 for user agents that support XHTML (and for Safari, which claims to support it but doesn’t handle style sheets specified via PIs properly). It serves HTML 4.01 Strict to user agents that do not state that they prefer XHTML. It’s utterly silly, since I can’t use any XML features. If/when I find the time to rewrite the software it will be HTML 4.01 Strict for all.
Visit My Website
January 28, 2009
Permalink
@Jacques Distler wrote
From the continued tone of your responses, I get the feeling you're not actually trying to engage in the discussion, but again simply trying to score some points in a pissing contest. So I'll simply leave the discussion by trying to respond substantively one more time.
If you're not privy to the internal workings of the server in question, then you're not really the subject of this conversation. This has been about producers of content and what type of content they should produce and the ways they should go about producing that content. By definition, these producers know the inner workings of the server or other mechanism by which the content is produced, manipulated and finally vended to an unknowing client like yourself. Certainly I'm not telling the client to consumer of content to produce XHTML. The client consumer of content should produce nothing in that role, but simply consume the content with the data (including metadata) delivered.
Visit My Website
January 28, 2009
Permalink
Well, I'm very interested in distributed extensibility (as Sam Ruby likes to call it). But Ian Hickson has pointed out that there are formidable obstacles to including support for the xmlns attribute in text/html.
There are large numbers of pages with tags like <a xmlns="">, which would break if you suddenly started supporting namespace attributes in text/html. (Even worse are pages with bogus xmlns attributes on the HTML or BODY elements. Such pages would not render at all.)
If you can find a way out of that impass, more power to you.
Ultimately, though, I think there's real value in having one widely-adopted HTML parsing algorithm (with lots of different implementations). The same stream of bytes should not produce radically different DOMs, depending on whose parser you use. That's a huge advantage now possessed by the XML world.
We've also been discussing HTML parsing algorithms. Sorry if that caused me to get confused.
"What type of content they should be producing" is not a question that can be asked in a vacuum. The answer depends cricially on how clients, ultimately, are going to handle that content.
Content destined to be sent as application/xhtml+xml (and hence treated by clients as XML) has completely different requirements than content destined to be sent as text/html (and hence treated by clients as HTML).
You seem to have some quite novel ideas about how to build a CMS. Having some modest experience with XHTML-capable CMSs, I've expressed a certain amount of scepticism about your idea.
But, rather than arguing back and forth about it, I should probably let you get back to coding. The proof of the pudding is in the eating and I (really, honestly) would hugely appreciate your sending me a link when you have a working prototype.
Visit My Website
January 28, 2009
Permalink
You and I know that IE will never support XHTML. That's why we're so persistent with the HTML5 group. That's why answers from the group that people wanting to use RDFa should use XHTML are not acceptable.
The real issue: will IE support SVG, if it becomes incorporated in HTML5. In the meantime, I make do with my uses of SVG, which does have broad support, and RDFa, which browsers ignore, but that's OK, other agents consume. But to use them, I use XHTML. agree with you, if you though: if you're not using something that requires XHTML, you should use application/xhtml+xml. But you can still use XHTML as your markup.
Visit My Website
January 28, 2009
Permalink
Sorry, I'm having the worst darn time with these comments. Anyone else having problems? I meant you should NOT serve pages as XHTML if you don't need the functionality. Especially if you allow comments.
Visit My Website
January 28, 2009
Permalink
This comment system make me want to pound my fist into the monitor.
But I will persist for your sake.
I would put a different spin on this.
If you are going to serve your pages as XHTML, then you need to have a system in place to ensure that the output is, in all cases, well-formed.
This is rarely worth the trouble, unless you are doing something fancy, like including foreign namespaces. But there are exceptions.
My 8 year old has a website.
He built his website using Instiki. There is nothing he could possibly do which would make the site ill-formed. So I have absolutely no fear about an 8 year old child serving his website as XHTML.
Visit My Website
January 30, 2009
Permalink
XHTML Users: Grow up! | WebScienceMan…
During the last years Web standards started to gain an increasing popularity among Web designers. Still Web standards addicts are a ceaselessly growing minority until now. This is probably due to the fact that the majority regards the use of web standa…
Visit My Website
February 3, 2009
Permalink
I don't really see what the problem is with using XHTML. Where is the aforementioned abuse happening, and is it not also happening to html4?
Visit My Website
February 4, 2009
Permalink
[...] XHTML Users: Grow up! | WebScienceMan [...]
Visit My Website
February 9, 2009
Permalink
@josh: The ‘abuse’ is that a lot of authors believe they are using XHTML, but browsers treat it as HTML. That means the purported advantage of the well-formedness requirement is lost (unless you validate, in which case invalid HTML will be caught as well).
It also means they still can’t use full XML syntax; the NET syntax is only ‘allowed’ for element types that are always empty in HTML.
Furthermore, it means they cannot include elements from other XML namespaces – perhaps the only real advantage of using real XHTML.
Finally, unless they validate meticulously and test their pages both as real XHTML and pretend-XHTML, they may still use bad practice that won’t work if the documents are served as XHTML. For instance, uppercase CSS selectors, document.write() in JavaScript, omitting certain tags, etc. In other words, those documents MUST be served as HTML to work, which I consider to be ‘abuse’ of XHTML.
There is nothing wrong with using pretend-XHTML, as long as you know what you are doing. The problem is that most authors probably don’t, and think that XHTML is a type of HTML.
Visit My Website
February 9, 2009
Permalink
[More site problems here since Tommy Olsson’s reply isn't showing up here for me.]
@josh
There's a lot of information spread about XHTML and it has led to a lot of confusion. There are very few concerns about using XHTML1 and sending it as regular old text/html. The one thing to watch for is one thing Tommy Olsson mentioned: do not use the self-closing tag on elements that are not defined as empty but just happen to be empty (such as “<div />”). Such elements will not actually be closed properly in several browsers and the subsequent elements will be placed inside that "div". Beyond that, you might also need to use the 'lang' attribute along-side the 'xml:lang' attribute to ensure language processing (if any) is done correctly.
However, the other issues Tommy Olsson raises are not quite the whole truth. There are benefits to authoring XHTML instead of HTML regardless of how it is handled in browsers. Many things required in XHTML authoring are considered best practice in HTML authoring (for example: always using quotations for attributes, not relying on implicit opening and closing tags). Using these approaches in HTML makes much more readable and more maintainable HTML code. These are some strong benefits to XHTML whether processing it as XML or text/html.
And in Internet Explorer (only, so far) some of the other advantages of XHTML are also supported (or at least partially). So in IE you can use namespace declarations and colon separate prefixes to introduce other content (such as RDF, SVG, MathML) and it can be processed correctly as a hybrid document (and even rendered correctly by some IE plugins in the case of SVG and MathML). The other browsers have not yet adopted these capabilities except in XML processed HTML (which IE does not support), but it does open up the possibility of vending content to all browsers as long as it is carefully authored to work in both browser modes (text/html and XML).
The other issues raised are not problems with processing XHTML as text/html (regular old HTML), but problems with migrating other non-HTML content (CSS, javascript, etc.) to XML processed XHTML. Authoring and maintaining XHTML proper actually takes much less know-how than authoring and maintaining HTML (since the shortcuts HTML allows compared to XHTML are intricate, difficult to remember, and therefore easy to get wrong). I hope these responses help.
Visit My Website
February 10, 2009
Permalink
That is the funniest sentence I have ever read on the subject of XHTML.
Thanks. [wipes away tear]
On a more serious note,
is far from complete. Consider (as but one example) how base-URLs are specified in XHTML versus HTML. Or consider the handling of whitespace in attribute values. Or …
Visit My Website
February 10, 2009
Permalink
@Jacques Distler
This is more of the same type of misinformation and innuendo I was trying to dispel. If someone's familiar with HTML they probably will not consider taking advantage of XML whitespace in attribute handling. XHTML1 also include the base element just as HTML4. As for your laughing and crying, this is just innuendo meant to scare people and make them think it's CRAZY to author XHTML.
It is not crazy. Microsoft has a campaign to try to make us think that XHTML was a mistake. and that IE was the only product team that saw the light. The problem with that marketing campaign is that HTML authors have adopted XHTML authoring in stunning numbers: even though they cannot deploy it to IE as XML. Keep in mind that IE has supported non-XHTML XML since IE5 and adding support for XHTML would mostly involve moving the contents of the 'title' element to the window's title, enabling hyperlink activation, and recognizing the 'script' element as a container for javascript. Ten years later Microsoft tells us they're trying to work out their DOM issues (though most DOM issues would apply to non-XHTML XML content as well and they already support that).
Let's focus on real problems here. If Josh is asking what could possibly be the problem, then he must not have ever tried to use an alternate mechanism to express base URLs or added carriage returns to his attribute values in away that browsers can't handle. I've yet to run into anyone stumbling on these problems when producing XHTML. Does it happen. I imagine it does. Do people rip their hair out trying to track down missing quotation marks in HTML4 authored content? That I've actually encountered. Most of the guys I know going bald can trace it to that specific issue. Of course XHTML4's appendix C is the definitive authority on how to author text/html parser compliant XHTML. There are very few issues there that relate to HTML proper (and not the peripheral formats such as CSS and javascript). The big one is remembering to close empty elements that allow content (like the 'div' example I mentioned) and using the self-closing tag for the elements defined as VOID or EMPTY (though the validator will catch that since that's required for the XHTML part of author HTML compatible XHTML).
Visit My Website
February 10, 2009
Permalink
That should have read XHTML1's appendix C.
http://www.w3.org/TR/xhtml1/#guidelines
Which has been largely replaced by a new W3C note:
http://www.w3.org/TR/xhtml-media-types/
Visit My Website
February 10, 2009
Permalink
Probably because you don't hang out with anyone actually producing XHTML.
Those who do, stumble onto these sorts of problems all the time. ( Example)
No. I am not trying to scare people away from authoring XHTML.
I am trying to explain to them that faux-XHTML (XHTML served as text/html) is not XHTML, and if they think it is, then they are deluding themselves.
Which is why I find comments like this problematic:
No, they (or at least 99.9% of them) cannot deploy it to any browser as XML.
Because their site would crash and burn if they tried to send it as XML.
As long as this is clear to people, I (unlike Tommy) have no problem with people using faux-XHTML.
And I encourage them (if their needs require it) to produce real-XHTML.
I just don't want people to make the mistake of confusing the two.
Visit My Website
February 10, 2009
Permalink
Again you're using wild innuendo with no evidence to back it up. First of all if you think XHTML 1.0 conforming documents suddenly become something else when the sever says they are text/html, then you don't understand what you're talking about. An XHTML 1.0 document is one that conforms to the requirements for document production of XML and XHTML1.0 So a document that conforms to XML, XHTML1.0 and XHTML1.0 appendix C is an XHTML document. You can call it a faux XHTML document, but then you're using the word faux in a way unlike anyone else who is conversant in English (and I imagine French too).
So you're using the same old tactics we've seen again and again with this nonsense. You're discussing what happens when an author who has produced XHTML 1.0 document transitions to deploying those documents as XML parsed documents. This is a completely different topic then the one that Josh is asking about (if I understand Josh correctly). The example of the site that broke was misusing an input element in HTML. That misuse became critical when the document was moved to XML (many things do). And yes HTML is semantic in that an 'input' element is designed for the input of text (among other things) that has no line breaks in it and a 'text' area element is designed for the input of text that has line breaks. If they turned around and once again deployed that fixed XHTML document as text/html it would again work fine.
So yes if you create a document that is not working as XML document and try to deploy it as an XML document, it won't work. However, if you're authoring a document to XHTML 1.0 appendix C standards and you deploy it as text/html, it will work just fine. Authoring to XHTML1.0 is a best practice approach. You're innuendo (and at this point fabrication in calling XHTML 1.0 conforming documents faux XHTML), is clearly false. You're "evidence" doesn't even support what you're saying (it supports something else, but it doesn't support any problems with authoring content to XHTML standards).
I too don't want authors to get confused about the two possible mime types to use for XHTML content. There is a difference in deploying content as XML content. However, the problems are all about going from text/html to application/xhtml+xml and very little about going in reverse. Authoring to XML (and XHTML appendix C) standards will actually reduce headaches (even when deployed as text/html).
Visit My Website
February 10, 2009
Permalink
If it's treated by all user agents as HTML, then regardless of the DOCTYPE it sports, it's faux-XHTML.
If it would crash and burn when sent as real XHTML (as 99.9% of "XHTML" documents sent as text/html would), then it's faux-XHTML.
If we move beyond the world of one-off web pages, and discuss web sites, then I can say with confidence that there isn't a single text/html website that wouldn't instantly crash and burn. I thought there was one (authored by someone a thousand times more knowledgeable about XML than either you or I), but I just checked, and it's not namespace well-formed.
There are all sorts of amusing problems about going in the reverse directions. But, somehown I don't think "Josh" is worried about why his application/xhtml+xml pages don't work as text/html.
Visit My Website
February 10, 2009
Permalink
I think you've missed the point. It's not about line-breaks (though that was the immediate subject of the complaint); it's about any input where whitespace is significant.
Appendix C provides no guidance whatsoever as to how to deploy hidden form-field containing whitespace-significant data … or a dozen other similar such issues. So saying "just follow Appendix C" and "it will work just fine" is almost certainly false for anyone doing anything remotely nontrivial (which, IMHO, is the only context in which anyone would have reason to be interested in XHTML in the first place).
Visit My Website
February 10, 2009
Permalink
Those benefits (which are not as self-evident as you indicate) are not enforced as long as you serve your document as text/html. That’s the whole issue.
I agree that including optional tags and quoting attribute values are good ideas, but there are reasons why these things are different in HTML, and some of those reasons may still be valid today. What you (and I) consider best practice is subjective and varies over time. 15 years ago omitting everything that wasn’t absolutely necessary was considered good practice, because it reduced valuable bandwidth.
What you (and others who use this argument) need is an HTML version of lint(1). A validator must not give false alarms, but a lint program isn’t bound by the same strictness requirements.
Jacques, I don’t think our opinions differ very much. I’ve stated in these comments that using what I call pretend-XHTML and you call faux-XHTML is fine, provided that the author knows what he or she is doing. In other words, that the document still works as intended if served as an application of XML.
I don’t have a problem with people using pretend-XHTML, but I’m bothered when those people claim that it brings technical benefits (faster parsing/rendering, etc.). And the reason I’m bothered is that it’s deceptive and can convince unsuspecting beginners that ‘XHTML’ is somehow superior to HTML.
Visit My Website
February 10, 2009
Permalink
Good points there Tommy!
Visit My Website
February 11, 2009
Permalink
Tommy invisibly wrote:
The only way I know of to achieve that is to actually serve it as XML to compatible browsers.
If you do that, and then send the same stream of bytes (complete with forward slashes and xmlns attributes), as text/html to IE, then I think we all agree that's just fine.
Where I think we disagree is when authors serve their "XHTML" content exclusively as text/html. I'm of the opinion that that's harmless provided the authors realize that what they are doing is sending out a funny dialect of HTML ("faux XHTML") which would almost certainly not work if served as XML.
As long as they realize that what they are producing is HTML, and will be processed with HTML rules (e.g., inferred TBODY elements), then I have no complaints.
Agreed.
It is the height of irresponsibility to try to convince neophytes that markup spandrels like superfluous forward slashes and xmlns attributes confer magical properties on your HTML (because that's how it's processed) content.
But it's also silly to tell them that these spandrels are bad. They're harmless. One of the (minor) things that I like about HTML5 is that it will make those markup spandrels conforming, which (one hopes) will put an end to that debate.
Visit My Website
February 11, 2009
Permalink
Well, in theory you could just make sure to test each page with the proper MIME type (e.g., via a query parameter switch) and still serve text/html to all user agents. Not very likely, though.
Yes. Technically pointless, but fine. How nice to agree with someone for a change. I’m not used to that. *guffaw*
It’s harmless from a practical point of view. The reason I think it’s ‘harmful’ is that it will fool non-savvy users into believing that this is how XHTML really works. Hence statements like ‘it’s easier to maintain than HTML’ and suchlike.
So it’s ‘harmful’ to the ‘pure spirit of XHTML’, but harmless to the Web as a whole. Anyone got any more hairs that need splitting?
Visit My Website
February 11, 2009
Permalink
Tommy Olsson invisibly wrote:
Ha! Well, if you want behaviour that will fool non-savvy users about how XHTML works, consider the behaviour of IE with the MathPlayer plugin installed. You can send that User-Agent application/xhtml+xml. Indeed, if you want the MathPlayer plugin to detect and render embedded MathML content, you need to use the application/xhtml+xml MIME-type.
The naïve user would think that this has magically turned IE into an XHTML User-Agent. This is false. With the plugin installed, IE accepts XHTML content, and then parses it as HTML. You can throw unencoded ampersands and all sorts of other junk into you application/xhtml+xml content, and IE+MathPlayer will handle it with aplomb.
Quite a shock when Firefox throws up a YSoD.
Visit My Website
February 11, 2009
Permalink
@Tommy Olson and @Jackues and @Rob,
The problem with XHTML is indeed if one is not using it for the right reasons. If one isn't taking advantage of any of the XHTML benefits, then one is not using it for the right reasons.
I agree with Rob that XHTML can have benefits from an author's point of view. But then you need to have either an editor or a browser that parses your document as XHTML during editing.
This need not be so difficult, though.
For any non-savvy author, if you create a XHTML document and save it with the as "document.xhtml" instead of "document.html", then your browser (unless it is IE) will parse it as XHTML, and therefore also report any coding errors to you. Until the page is errorfree, you will be unable to view the page (unless you answer yes when or if the browsers asks you permission to parse the document as HTML – also known as text/html). I believe that an author which isn't at least taking advantage of this author advantage of XHTML, probably should not be using XHTML at all.
The problem after you've created your "document.xhtml", however, is that when you drop your document into the World Wide Web (most typically you drop it into an Apache server) then the page will be served not as something that Internet Explorer cannot consume. To get it right you must either change the file extension to .html, or you must ask your webserver to serve .xhtml as text/html. (Or, if possible, you could configure your browser to browse file URLs ending in the ".html" extension not as text/html, but as xhtml – by which I mean application/xhtml xml. Then you would not need to reconfigure your apache server.)
The key thing to know is that one can be just as "semantic" with HTML as with XHTML.
Visit My Website
June 3, 2009
Permalink
[...] View Tutorial No Comment var addthis_pub=”izwan00″; BOOKMARK This entry was posted on Thursday, June 4th, 2009 at 2:25 am and is filed under Html Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. [...]
Visit My Website
September 23, 2009
Permalink
never heard of this!
Visit My Website
October 7, 2009
Permalink
Opera is great for standards.
Visit My Website
March 10, 2010
Permalink
web standards are important but I also don't like to waste time either.
~
the best web host provider!
~
Get a Free Apple IPad! Do an offer, cancel it or keep it, then referr others
~
We think about the web so you don't need to
Visit My Website
March 10, 2010
Permalink
web standards are important but I also don't like to waste time either.
~
the best web host provider!
~
Get a Free Apple IPad! Do an offer, cancel it or keep it, then referr others
~
We think about the web so you don't need to
Visit My Website
April 7, 2010
Permalink
standards are important and in law they are crucial. People need to be protected by the law and so do websites with high standards and quality.
Visit My Website
April 7, 2010
Permalink
standards are important and in law they are crucial. People need to be protected by the law and so do websites with high standards and quality.
Visit My Website
April 29, 2010
Permalink
I am so excited for HTML5!
Visit My Website
May 10, 2011
Permalink
I could say I am already very good in HTML coding. But what I really wanted to learn is CSS and PHP coding. But the problem is I do not have any basic skills on this.
Visit My Website
June 2, 2011
Permalink
bvlgari sunglasses its tradition of providing luxurious and elegant accessories
with their eyewear collection. Bvlgari Sunglasses are embellished with semi-precious rhinestones, Swarovski crystals and small diamantes for that dash of
glamour and sophistication.
bvlgari eyewear are the favorite of the rich and famous
due to its timeless designs and intricate detailings.
Bvsunlgari glasses are like nothing you have ever seen before. When you look at the
authentic Bvlgari sunglasses offered to you here, at Sunglassesitaly.com, you will
be amazed by the luxury that is delicately presented in each pair. They are like
nothing you have seen before. If you want to be original in your choice of eyewear
and want to be alone in your exclusivity of elegant design, then
Bvlgari sunglasses is the right decision for you.
Visit My Website
June 13, 2011
Permalink
They are referred to a style of Australian boot made with sheepskin, with wool as the inner lining and a tanned outer surface.
Visit My Website
June 23, 2011
Permalink
good site.
Visit My Website
June 23, 2011
Permalink
thanks for your sharing,I like it!
Visit My Website
June 23, 2011
Permalink
thank you very much!
Visit My Website
June 23, 2011
Permalink
I like your site,thank you!
Visit My Website
June 23, 2011
Permalink
thank you for your help,I like it!
Visit My Website
June 23, 2011
Permalink
good article I like it very much!
Visit My Website
June 23, 2011
Permalink
very good ,thank you very much!
Visit My Website
June 23, 2011
Permalink
very good ,thanks a lot!
Visit My Website
June 23, 2011
Permalink
very good,thank you!I like it!
Visit My Website
July 3, 2011
Permalink
good!!!!!Thank you share, the article will make people good progress soon, I will share my article to you, because only together can share the progress.
Visit My Website
July 19, 2011
Permalink
pasting
Thanks alot for this! i was looking for this query because i found one a while ago but a i lost it…i made sure to engrave this into a notepad file right away so that i wont lose it again thanks! http://www.truereligionjeansoutlet247.com
Visit My Website
July 21, 2011
Permalink
Good post. Very helpful. Thanks for sharing.
Visit My Website
August 16, 2011
Permalink
The Engaging Dress is Karen Millen for Celebrities
Karen Millen Dress disigers are dedicated to shape the womens line grace, especially this Karen Millen Tribal crochet Dress, that really help you actually hot and lovely. The stars are her free speaking on another’s behalf that saw the attractive dress is Karen Millen! None of us will ingore your grace regardless of where you are with this particular leading-edge and eye-catching karen millen outlet.
While a large number of women thronged to fashion world-famous Ladies Day, their counterparts attended what’s fast-becoming its popular Welsh equivalent at Ffos Las in Carmarthenshire, the first new all-purpose racecourse in great britan for 81 years.
People to the event cheered on champion jockey Tony McCoy with an evening that marked the 2nd anniversary from the opening of the racecourse. Fashion tycoon Kevin Stanford made a fortune by selling his be part of Karen Millen, the womenswear chain he co-founded.She gave high compliments to Karen Millen Dress.
Since my son Jimmy was created in 2008 year, I can no more use tight-fitting Karen Millen dresses, the Karen Millen Dress lauched a brand new Tribal crochet dress,this is fit me perfectly. This dress let me look the sunshine in Dark space. and I am contemplating buying another cheap karen millen dress out of this site again.
evening dresses karen millen
Visit My Website
August 17, 2011
Permalink
the huge majority of us hold on to adhere to the exploits of Vladimir Guerrero or Orlando Cabrera on their new teams. or even the Canadians which could be developing the important thing leagues in actually escalating numbers. To go toward the stadium and give our bucks to MLB can be like victims having to buy to sustain their rapist in jail. It merely is not right.
Visit My Website
August 26, 2011
Permalink
Hey! I visit your site regularly, but your blog doesn’t load in IE8. Why do I get a timeout after a while? Gracias. Barabara
Visit My Website
August 29, 2011
Permalink
tiffany bracelet
Visit My Website
September 3, 2011
Permalink
I wonder what html6 will bring
hope useful options for better applications
Visit My Website
September 9, 2011
Permalink
Longchamp
Longchamp bags
Longchamp sale
Longchamp outlet
Longchamp Le pliage
Longchamp Le pliage Tote
Visit My Website
September 16, 2011
Permalink
It was worth visiting your blog.
Visit My Website
September 28, 2011
Permalink
Do you know what dose the Louis Vuitton Outlet mean ? Some cheap LV items but original ? But Where these cheap Louis Vuitton Item come from ? A OEM factory ? Who could tell me where the LV OEM factory are loacted in ?
Visit My Website
October 5, 2011
Permalink
Both HTML4 and XHTML1 are fairly old by now. The HTML 4.01 specification is dated 24 December 1999.
Visit My Website
October 10, 2011
Permalink
Nice coming
Visit My Website
October 12, 2011
Permalink
I really appreciate your efforts. Thanks for sharing such a great post.
Bachelors's Degree Online | Masters's Degree Online | doctorate degree online
Visit My Website
October 12, 2011
Permalink
Your explanation about the topic is very clear. Everyone can understand.
High School Diploma | GED Test
Visit My Website
October 14, 2011
Permalink
this blog is very nice
and thanks for giving such a wonderful knowledge.
Visit My Website
October 21, 2011
Permalink
Of course, louis vuitton outlet output can spend the Indian population that results in a few louis vuitton online to be too few. with cloth of high military rank, delicate design, formfitting clipping, leaves every season, finished louis vuitton outlet is full of charm, and the expression pattern, louis vuitton bags sale slender unadorned, but the interior will also be deducted louis vuitton outlet incomparably perfect! Reporter interviewed some young students in regular shopping malls, most of them have heard louis vuitton bags, but she never wanted to go shopping.
Visit My Website
October 27, 2011
Permalink
i like it,thanks your post
Visit My Website
October 30, 2011
Permalink
The cheap moncler online are founded of shiny consuming water repellent polyamide material and quilted with 100% goose reducing filling course A, moncler vests that could make this product instead mild and warm, Today, even moncler jacket is owning an escalating need many thanks toward styles and colors. Jackets usually can be found in inventory colours like white, black, however the cheap winter coats for women girls have brilliant colours and pleasant as pink, red, green, colours which you can imagine.
Visit My Website
November 17, 2011
Permalink
Hey great finding this post in google was looking for somthing like this anyhow love web design and thanks for creating this kind of site.
Visit My Website
November 20, 2011
Permalink
Very happy to see your article, I very much to like and agree with your point of view. Thank you for sharing. At the same time,i love best pram very much .Welcome to look at my website and blog articles.Hope we can become good friends, and exchange and to help each other! Thanks!! cheap wedding dresses
Visit My Website
November 22, 2011
Permalink
Insteresting post I agree with some parts of it not all but nevertheless, I learned a lot from reading this.
Visit My Website
January 4, 2012
Permalink
Good and nice information post. Thanks for sharing this post.
Visit My Website
January 18, 2012
Permalink
So what do you recommend we use in place of XHTML? http://www.hotdiscountbootsoutlet.com