XHTML 1.0 now a W3C Recommendation
thehermit writes "New info on the W3C's Web site as XHTML 1.0 became a W3C Recommendation on Jan. 26. The specification now features a single namespace, and takes a more cautious approach to Internet media types, following feedback from W3C members on the previous version of the specification. " W3C notes that "XHTML 1.0 is the first step toward a modular and extensible Web based on XML". The full XHTML spec is also available.
WHAT?!
XML is the best thing since sliced bread! And, no this isn't a troll, I mean this! Hard to parse? What are you talking about?
First of all, YOU shouldn't be parsing it. I don't care what language you're coding in, you'll probably find that someone else has taken care of that for you. I use Perl primarily, and switch between XML::DOM and XML::Parser, both of which handle all of the dirty work of chewing on the tags and characters.
As I mentioned in the story on the Slashdot code release, I have a project: Iaijutsu: Open Source Content Management and Web Application Framework. And this project makes extensive, pervasive use of XML.
- The documentation I'm writing (other than POD in the Perl modules) is being done with the DocBook DTD, which lets me write in one common format and publish in HTML, Word doc format, etc... all from one document.
- Content classes may be created using a hybrid Perl/XML format which defines the class' properties, methods, template accessors, and various other aspects.
- Objects in my system may be imported and exported in a simple, self describing XML format listing all of their properties. You can write it by hand easily in Textpad or Emacs to make lots of objects easily...
- XML is used to syndicate news and headlines from other sites, like the service Slashdot offers in the backend. I've written content classes in Iaijutsu which download these syndication files to collect headlines. And, I believe, Slashdot uses these files to make slashboxes.
yes, I *do* write import/export routines, everyone still uses comma-delimited or dbf files, occasionally Access files tooThen you've REALLY missed the boat. XML is EASY. Screw comma delimited, I've actually found it easier and more maintainably elegant to write quick Perl scripts which use the XML::DOM, than to hack out a CSV parser. Hell, I even have Oracle DB servers spewing XML streams at me to handle.
XML is far from failed. Go back and try it again. As for XHTML, I don't know that it will ever be truly adopted, but if it catches on... we could write web browsers and web service consumers in a fraction of the time and code.
I'm involved in the W3C working group, so maybe I can answer...
:-) If a document declares itself to be HTML, normal (lenient) processing will take place. If a document declares itself to be XML, then strict processing will take place. When authors are unable to view malformed documents, that forces them to fix problems at the front end, which is A Good Thing.
XHTML, like all XML, is *required* to be "well-formed", which basically means matched tags, no missing quotes, etc. The XML 1.0 Recommendation *requires* implementations to stop normal processing of an XML document that isn't well-formed. In short, if it isn't well-formed, it isn't XML.
Browsers will eventually get smart about this. Mozilla already is.
Anon on purpose. Moderate accordingly.
Posted with M13
But I don't see them specifically ruled out either, any more than in HTML 4.01. Sure, W3C don't want people using them, but there's nothing much they can do about that.
Yeah, I know it's very worthy and everything, but have you ever tried converting a table layout to CSS? It ain't fun.
First, of course, browser support is terrible; Netscape tends to break if you have the temerity to put a positioned element inside another positioned element, and it messes the whole page up if you try to mix CSS-P with tables to achieve some kind of graceful degradation on
But that's not what's wrong with the standard, obv. What's wrong is the total lack of flexibility in positioning. Normally with positioning you want to say things like "this element is to go 3 ems to the left of that element", or "this element should line up horizontally with that element and vertically with the other element". But CSS gives you only two choices: specify an absolute page position, or move the element a bit in some direction; you can't mix the two horizontally and vertically, and the latter option is usually useless anyway since it leaves an element-shaped hole in the parent.
This could nearly be half-workable, since you can achieve more complex effects by putting elements inside other elements. But Netscape 4 breaks so very, very badly if you try that the page often becomes completely unreadable.
So what you end up doing is either making every element absolutely-positioned to the page pixel, which is okay for the kind of fixed-layout fixed-width page which idiots write, but otherwise useless, or you end up writing a complete page-layout engine in several KB of JavaScript at the top of the page, slowing everyone down. And of course writing layout JavaScript that works with IE4+, Netscape 4 and the W3C DOM is a Sisyphean task. Oh, and of course people with JavaScript turned off are screwed.
To summarise: CSS is not up to producing interesting, dynamic-page-size layouts, and browser-supported CSS is not up to anything at all.
To summarise the summary: Style. Is a problem.
To summarise the summary of the summary: Aaaarrrrrghhh.
--
This comment was brought to you by And Clover.