XHTML vs. RSS
Comments: 19
From somebodydial911:
If you’ve gone through the effort of marking up your site in XHTML, you’ve gotta be asking yourself when some of the payoff is supposed to occur.
I don’t mean to come on like I have an opinion on the matter, not being as technically versed in the specifics as I would need to be to do so, but I can’t argue with the above idea at all.
•••
Posted to Computers • 2002.11.30 (Sat) • 21:47
Comments
Posted by tomas 2002.11.30, 21:59
I've always thought of the standards-compliance as the payoff.
I'm with Mark here; syndication is not publication.
Posted by James 2002.12.01, 02:02
"standards-compliance" for standards-compliance sake isn't a goal worth my time. I'm a web professional that wants tangible benefits. I know there are several so thats why I am slowly moving to standards compliance but sometimes the payoff isn't worth the sacrifice or time investment for my clients.
Posted by Alnisa 2002.12.01, 03:45
Well ignoring the fact that XHTML and RSS should never really have a 'vs' between them; I'd have to state the benefit of XHTML is multiple. Properly coded XHTML sites load faster, offer better accessibility (especially when coupled with CSS); plus give you a stronger foundation for building a site that has more interchangeable data.
For me, I've always taken for granted that once I can get a site to validate as XHTML (even if its transitional); that the site is that much closer to utimately separating content from design. I think this is very important when building sites that others have to maintain; and is obviously why more and more content management systems such as Moveable Type, and pMachine are becoming more popular.
I think the payoff of faster site downloading, as well as accessibility, are a great benefits. Plus the increased number of sites offer data exchanges via XML (RSS), I also attribute to a benefit of XHTML. Applications such as NewsWire Lite and Watson are changing the way the web is used, or at the very least the way I use the web; this coupled with changes to operating systems (specifically Mac OS X), where a number of the core functions and applications exchange data using XML offer an array of exciting opportunities and future benefits.
I think the benefit of posting data that can be interacted with in some manner is empowering; obviously sites such as Antipixel have received great benefit from this. They can design and handle content separately. They can use a number of applications to communicate with their CMS without having to open a web browser; and yes the time saved without having to manual create page after page of HTML; as well as a data feed; managing user comments via email, etc., is all part of the growing number of benefits being derived from the XHTML/XML/CSS combination.
I think XHTML goes along way in making web content, exchangeable data–content becomes transversable, allowing it to be grabbed, siphoned, observed, commented upon, and exposed.
Posted by noel 2002.12.01, 04:47
Just because you aren't used to coding in pure XHTML 1.1 (or 1.0 strict) doesn't give you a reason to say that its hard. If you know how to do it corretly, and know what to look for, its just as easy, if not easier, than coding in HTML 4.01. The payoff is the fact that you put in the effort to keep your pages up to par. The payoff is not syndication. XHTML is not hard to use, its just much different from HTML 4.01. But this does not make it something difficult. After converting my site to XHTML 1.1, I've found that it was a) easier than I had expected, and b) worth the effort I've put it. It eliminated unnecessary code, and taught me something new.
Posted by Ricardo Lamego 2002.12.01, 05:32
I've always thought about rss/xml feeds as bait. Maybe because of that I think this discussion is only 20% valid. It feels like an anti-climax discussion.
The major payoff of xhtml is definitely forward compatibility.
I dont care how much this sounds like an Manga cartoon slogan, but It's not the code itself that matters most but changing the coders habits!
Posted by Chris 2002.12.01, 08:38
They payoff of XHTML is predictable parsibility,. When every tag case has to match and every tag has to close, then the job is a lot easier. But what parse? Who knows. For small sites you could code up some crap HTML3 and be done, but that's a matter of pride in my book. IF you're going to do it, do it correctly.
Personally, if I want to go through the effort of having validated code and get 'payoff', then reusibility is the key. With my site, I started from the ground up with that in mind using XML, which then can be spit out in XHTML, HTML4, HTML3, Text, RSS, WAP, , DocBook, etc. via stylsheets, but since XHTML is XML, then you could also XSLT it into HTML3. Try that with HTML4, but I digress. What was my point again?
Posted by tomas 2002.12.02, 02:30
Well said everybody, well said.
Posted by James 2002.12.02, 02:34
I know the payoff for xhtml. As I stated above. I don't need a lecture :). In fact my weblog is xhtml loose valid.
All I'm saying is that validation for the sake of having a little xhtml icon shouldnt' be the goal. There should always be questions asked. Who's coming to my site, should I expect 4.0 browsers. How important is it to have a consistent look and feel. More important is I hate seeing people complian about nearly valid sites. They get on their high horses and complain when a character is improperly coded. When what matters is the code is as valid as circumstances allow.
re: "doesn’t give you a reason to say that its hard"
Hard is subjective so I have every right, I also never stated that it was hard. Thanks for putting words in my mouth :) It can be a little bit more time consuming for me personally and I also have a beef with url strings that break validation (such as links with "=" "?") I know the reasons I just consider it a pain in the butt to run it through a url cleaner.Thats my point :P and I think Jeremy may have similar feelings. Currently browser implimentation of standards are the best they have ever been, yet people still use older browser and bugs still exist. Hacks still have to be applied and sometimes very obscure problems arise.
Posted by tomas 2002.12.02, 02:39
James: I don't think anyone thinks of the little xhtml-button as the payoff. The inherent attributes of xhtml are the advantages and thereby the payoff of xhtml.
Posted by James 2002.12.02, 15:24
You'd be suprised tomas. Especially with people just getting into web design. There is alot of pressure from code purists to make valid sites, regardless of its fit to the project and its goals.
Posted by jh 2002.12.02, 16:07
Standards compliance is important, but only as a means to an end (as I think we've all agreed). Portability of data, faster downloads, forward compatibility, accessibility, &c. That little XHTML button has two main purposes for me:
1) It hopefully shows readers that I'm trying to make things as smooth as possible for them: use a standards-compliant browser and you should have no trouble with this site. There are no hoops to be jumped through here.
Incidentally, for those of us bloodied in the browser wars, it may act as a little emblem of promise that the days of multiple versions of sites are behind us, but perhaps I'm getting misty-eyed and nostalgic. ;-)
2) More impotantly, it acts as a housekeeping device for me. I can periodically run the site through a validator to see where I've forgotten to close a tag or where I've screwed up. Then I can fix it. Then I know that my archive of code is is reasonable enough shape to be siphoned off and poured into another system or database or whatever should I ever want to do this. (I also run rendered versions of pages through BBEdit's validator for the same purpose as it catches some things that the W3C's version currently doesn't.)
Separating content from presentation was a big attraction of XHTML. The first version of Antipixel was 1.0 transitional, this version is 1.0 strict. But there's a lot more to this than just cranking out valid XHTML (which, yes, was much easier than I thought it would be, some stubborn habits aside).
I need to do a lot more work to clean up my use of div and id, so one goal for the future is to try to minimise the number of classes I use and to try to get exisiting markup elements to carry more weight through a better use of CSS.
Posted by tomas 2002.12.03, 01:40
Speaking of which, I'm currently doing xhtml 1.0 transitional. It doesn't actually validate atm, due to a <ul> inside an MT-generated <p>, which I blame MT for entirely, and a couple of unencoded characters which I'll fix, some time.
Anyway, I've tried to validate it as xhtml 1.0 strict, and xhtml 1.1, and I've noticed I'm not very many errors away from either of them. But, is there any obvious downside to going with xhtml 1.1?
Posted by Mike 2002.12.03, 08:10
There is an W3C HTML 4.01 Specification. Is this a "standard"? If so, you can be standards compliant without authoring in XHTML. Just a thought. So if all you get from using XHTML is compliancy, well, then there are other ways.
Posted by Sebastian Schnitzenbaumer 2002.12.03, 13:04
Hey,
I actually was a member of the HTML WG when we developed XHTML in 1999, you'll see my name on the rec, and so this thread is very cool for read to me - thanks a lot, good discussion.
Everything has been said. It's just wonderful to see that the majority of voices today lean towards XHTML being a good thing to have, whereas at the time we did it literally the entire world was against us. You had to have a strong stomach in order to still see and do the right thing back then in 1999.
Haha…
- Sebastian :-)
Posted by Mike 2002.12.03, 19:58
Comments and links always seem to keep me from validating. This page right now, for example, has errors from jh's posting of "&c" (and now from my use of it.)
Just thought I'd bust out a holier-than-thou…
Posted by tomas 2002.12.04, 06:06
Mike: You need to encode those ampersands; use "&" where there would otherwise be "&".
Posted by noel 2002.12.06, 01:54
Actually yes, there is a downside to going with XHTML 1.1, albeit, not a big one at all.
XHTML should technically be sent as application/xhtml+xml instead of text/html. But doing so makes IE freak out. So what you should really do is write your code in XHTML 1.1 valid, and wait till the day IE doesn't freak out because of the mime type. Sending your code as text/html instead of application/xhtml+xml doesn't do anything wrong. Its just not "how you should do it".
Posted by jh 2002.12.06, 12:27
Right – the MIME type issue. I'm not aware of a fix for this, but it's annoying in a niggling little way. BBEdit also reports an error for type="application/rss+xml" in the RSS link, but the W3C let's this one through.
Posted by noel 2002.12.06, 23:14
I agree, it is "niggling" (thats a funny word). But, since there are no side effects, its not that big of a deal, at least not to me.
Post a comment:
Send This Story to an Enemy
• • •
