Slashdot Mirror
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.
Fine. Pick nits. I was quoting Tim Bray. I know what XML is and isn't.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
It's not backwards compatible with HTML
I think it is backwards compatible enough, at least if you use the 'transitional' DTD. It isn't that hard to convert old sites to it.
And anyhow, the idea here is that by starting to enforce syntatically correct mark-up, the browser engines can be a lot simpler and so browsers can potentially be less bloated.
Old (existing) browsers can't parse it properly
They can't? Why? If you follow the backwards compatibility guidelines that are provided in the appendix of the spec, you shouldn't have problems with existing browsers.
As a real-life example, there is a site my girlfriend built last weekend for the local Kendo society at http://kendo.greywolves.org. That site is in XHTML, and I believe older browsers will mostly have problems with only the PNG images there.
Compared to what general XML can offer, it's a pretty lame DTD
That is not the point here. The point here is to allow gradual transition from legacy SGML-based HTML to te XML-based one. And anyway, it is possible to put parts of a XHTML document to follow another DTD by using the XML namespaces. This way you can use any XML DTD you want, and still stay relatively compliant with existing browsers.
There is a lot hype around XHTML, but I think it really is a good idea (and standard), even while not everything that people write about it is correct.
And as to who will be using it, I'm doing all my Web development work with it even now, and my employer is also slowly transitioning to the standard...
I hope this helped at least slightly with the question...
--
Midgard Project - Open Source CMS
A hairpiece? Really? I couldn't tell (:-) )
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.
This is good. But I didn't see any notion of referential integrity in the spec.
The biggest problem with the web is that we will still have to manage links manually. I hope someone takes the bull by the horns and figures out how to eliminate (or at least mitigate) the "404 Not Found" problem. Perhaps that now-open-source Udanax code could be mined to turn up some good algorithms?
Another good idea (but really an unrelated spec) would be a file system redirector architecture that enabled all documents (per user preference, of course) to vend docs automagically via an HTTP or "blocks" server.
.............. kris
"I thought I could organize freedom. How Scandinavian of me."
Well.. since you seem to want compact code...
,'s
while() {
@arr=split(/([^\\]\")?,([^\\]\")?/); }
finds , delimited stuff that is surrounded by quotes if present, delimited by
but if this was true csv, the ?'s would disappear... it would have to be surrounded by quotes...
---
-
ping -f 255.255.255.255 # if only
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
Ummm, that's pretty much exactly what they did. HTML and XML are both evolved from the same language, SGML.
The information you are looking for is contained in the links. Read them carefully. If you don't understand, read it again.
And I'd like to emphasise, because you seem to be a little clueless about this: this is not Microsoft hype. In fact, this has nothing to do with Microsoft. Frankly, you can bet they'll take this standard and warp it like they do everything else.
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
Unless you've got an ancient browser, like IE2 or NN2, any web site's XHTML will work as well in your "existing" browser as HTML would ... if it looks at it as HTML, which it probably will. The HTML spec always allowed lowercase tags, and almost all tags allow the matching end tags (which XHTML now requires).
The "really ancient browsers" incompatibility relates to empty tags like "br", "hr", "link", and so on ... if the browser is that old, it probably doesn't understand the notational convention of "<br />" (space before the regular XML empty element terminator -- hope that shows up!).
The reason for XHTML is so that tools have a more solid target than HTML can ever be. It's easy to get a good XML parser nowadays, and validators are getting more common (especially for Java programmers). That means that generating valid XHTML is something any tool can realistically do, so the bizarre hacks can start to fade away over time. Not quickly enough for me, probably. Browser bloat is with us for a long time.
Best possible result: enough XHTML starts to show up that people start discarding all those really ancient browsers. NN3 is current enough, but designing a website to deal with older code is just plain awful.
I never thought of that.
Neither did I until it bit me.
I thought it wasn't well-formed XML if there was a space before the backslash.
Nope. Take a look at rule 44 in the XML spec
[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'
The place you can't have a space is after the slash and before the tagname in an ending tag: </ P>
As part of the "suite" of XML standards, XLink is a standard for the management and declaration of more advanced linking features.
I'm not sure if you ever took a look at HyperG, an experimental hypertext system from a few years back, but it had an excellent link management system. Dead links didn't exist by design, and there was an excellent link navigator that showed you the structure of links, not just the page text.
That's partially right, namely about that future being envisioned: cut the bloat associated with needing to handle any old garbage that shows up at the client.
But it's also wrong. Extensibility is the "X" of XML; XHTML added nothing to XML's extensibility. Except to standardize one more 'vocabulary' of elements and attributes. That's useful; everyone knows the HTML vocabulary.
The idea is pretty much like this. XHTML 1.0 has defined the vocabulary of HTML (tags and attributes), and its namespace. An upcoming version (XHTML 1.1 is its current codename :-) will modularize that, so you can have a "text" module or a "table" module or a "list" module.
So that when you need to define a custom XML document type to fit into some custom application, with PDAs and cell phones being the classic examples, you can pick and choose: Text and lists may be plenty, you don't need bibliographic citations or definitions. BUT you do need your own particular biz-to-biz vocabulary addition; maybe you're providing catalog entries, and the descriptions are simple text but there's all sorts of ways to define fields to describe pricing options, ordering, stocking, etc.
Or another way to look at it: you're going to be able to throw away HTML tags you don't need, and use only the ones you care about when you create new kinds of documents.
That's one hundred and eighty degrees away from the "extend HTML" model. It's a new model for how information will show up, as part of the "semantic web".
They used to, back in the days of HTML 2.0->4.0. I think it's a bit different these days, since the CSS/DOM people have built quite a big bunch of standard which is way beyond what most browsers support, and the browser writers are playing catch-up. Of course Microsoft are adding all sorts of weird extended style-sheet stuff, but I've never seen any of it actually used, probably because no-one really understands it.
Sometimes. I think in more cases, they just don't really know standards are even there to be followed. I think most content on the web is hacked up by people who've learnt HTML from reading other people's HTML, or from a woefully inaccurate "HTML for Tossers" book. Or they're using FrontPage, God help 'em.
You're right, of course. :-(
But ten years from now, we'll fantasise that politicians were honest, prices reasonable, Netscape implemented standards and JavaScript ever worked. :-)
--
This comment was brought to you by And Clover.
Why everyone is trying to use XML for every possible application while XML itself is not very well "standardizable"? It has no predefined way to attach any formal (or even not so formal) description of semantics of the data to DTD -- I would understand if I was able to attach pieces of, say, portable C code into "the definition", and say that everyone who wants to support my format can compile code, extracted from my "definition" using some standard parser/converter, link it with standard parser library, feed the same DTD to that parser, and the result will be a "skeleton" of compliant with my standard input/output/display/... procedure. But right now we have only trendy-sounding TLA for simple "open tag -- recursion -- close tag" format that isn't much better than anything else, but differs from any other format in rather spectacular way -- no one so far produced completely compliant and usable parser for it in compiled language (no, gnome-xml isn't compliant -- unicode conversion from charsets, other than hardcoded in the source, shows its ugly head).
I understand the need for standardization. I understand that comma-separated values or plain key-value list poorly represent complex nature of the data. I understand that HTML standard committees royally screwed up under the pressure of companies. I understand that in general text is cheap. I understand that XML at least provides some means to show structure and attributes of the data (but so did RFC-822 + MIME more than ten years ago -- just with a bit more waste of space). But sorry, this feeble attempt of meta-standardization just doesn't _do_ enough to justify itself now. Semantics of the data still should be defined in English, and quality of definitions that I see declines rapidly. It helps with displaying that data, but displaying is a microscopic, almost unnoticeable piece of any serious data processing. Semantics still has to be handled by "manually" written, rewritten, ported everywhere and debugged programs that actually are supposed to know what to do with data. Programmers still can't derive any useful information about the data nature from DTD, and should rely on vague texts and their interpretations of it, so the effort, XML saves (writing a parser for arbitrary format) is a big fat zero compared to the real work programmer still has to do to make his program work. No way to do formal proof of anything except that data is formatted as it's supposed to. No way to derive testing procedure for implementation of the processing program. No anything that actually helps programmers to write a useful program and make sure that it works.
Parsers are written in the languages that are nice for demos and small web sites, but don't scale on anything large (what is it, a conspiracy of hardware manufacturers?). I can churn out XML-like meta-standards at the rate ten per week, but since all of them will share the same flaws, why would anyone care? Why do we see a lot of "uses" for XML, but no real progress in improving it in the most natural way -- standardizing the linking between format and semantics? It's possible to keep XML as it is -- it's good enough to define some "canonical" form, the data is (or can be) kept, but without a useful way to handle semantics it's dead.
I am afraid that this situation is created on purpose -- there are already some formats of data that have semantics attached. The problem is, they are proprietary, tied to platforms, languages and architectures. They have semantics, however the formats, they use for data exchange are unnecessarily cryptic or hard to serialize to the stream of bytes. By keeping proprietary "guts" with algorithms, object models, transaction-level protocols and adding "open" formatting of the data vendors get the best of the both worlds -- no one but them can make any sense with the data (both implementation of data handling and the objects-handling engine itstlf are closed-source -- say, COM), but they look "open" and "nice".
Contrary to the popular belief, there indeed is no God.
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.
XHTML isn't as much a protocol as a language, though that may have been explained to you.
Probably more interesting to come out of this discussion is this: you were led to believe that Microsoft was coming out with XML and XHTML. And this is exactly what Microsoft likes to happen. Every time they can make someone believe this, that's one more shoe-in customer.
It's sad, really. And it's not your fault.
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
No! This is a total misunderstanding. XHTML 1.0 is simply a recasting of HTML 4.01 into XML compliant syntax. You cannot extend XHTML as such by adding your own tags. You can produce hybrid documents by combining XHTML with other XML dialects, but the result would not be XHTML. You could even combine XHTML with XML dialects you create yourself. But you would be very foolish to do so.
XML dialects are only useful if they serve a significant community who have tools which understand the dialect and can do useful things with them. If you just make it up yourself as you go along, then the only thing you can really do with it is use XSL to translate it back into standard XHTML, so you've gained nothing.
I'm old enough to remember when discussions on Slashdot were well informed.
If XML is a failure, then I hope we should all fail so spectacularly ! I'll be writing the XML handlers that send out welfare cheques to you, and all the other unemployed CSV import coders.
The downside and "failure" of XML is that it's still immature as a wetware discipline (not as a protocol). XML and especially schema design is regarded in the same way as database design was 5-6 years ago. For years before RDBMS design had been the sole preserve of gurus like Ted Codd (i.e. the SGML era), then along come M$oft with Access and suddenly everyone and their dog thinks they're a real database designer. Cue a whole pile of badly normalised (or just downright ugly) data models, or in today's situation a lot of nasty slapped-together XML structures. It will be a year or so before people realise that XML schema design is a discipline in just the same way as good RDBMS design is.
TipOfTheDay: Use tags like <br /> instead of <br/> when writing "tight" HTML, otherwise older browsers choke on it.
The web will never be fully standardized. Standards lag behind the technology, and people are way too lazy to actually follow standards.
Ten years from now, there will still be messy "optimized for Netscape" (whether or not Netscape is still even used) HTML on the web, browser writers will still fudge the standard, and people will still check their HTML on the only browser they have before putting it on the web.
Who was it who said "The great thing about standards is that there are so many to choose from." ?
did anyone else notice that the Recommendation itself was authored in XHTML 1.0?
First step to knowledge is realising when you don't know something.
A year ago, I realised that I was missing the XML boat and played some rapid catch-up. Now I'm a real evangelist for it. XML is the most exciting new tech I've seen since reliable IP stacks on every desktop. Until Summer I had to push clients into using XML, Autumn I was first recruited because of my XML knowledge, and this year the phone has gone into meltdown.
Should you rush out and dive into XHTML ? Not IMHO. Start out by getting a good grasp of XML in isolation. I don't know what you do all day, but many big markets will always be pure XML without any XHTML involvement. WAP/WML might be relevant to you too, if you're into palmtops or wireless.
XHTML is less revolutionary than XML. XML is a way of doing new and exciting stuff that just wasn't practical before, XHTML doesn't really add much to that, it just lets developers roll it out without breaking every existing client. It's good stuff and we should adopt it, but it isn't going to invent new business models the way that XML has (how do I syndicate content from everything in the known universe without something universal like XML ?).
I think this is another hype from Microsoft
No, definitely not Microsoft's hype. Microsoft are keen on it, for sure, but they're riding the bandwagon, not generating the hype.
Yes, Microsoft have broken things. Fortunately XML was up and running before Redmond woke up, so they didn't get to break it. OTOH, XSL has been thoroughly trashed by them and XML Schemas are under attack (it's neck & neck between MS & W3C). I haven't looked at this week's XPath goodies from Redmond (new MSXML download yesterday ! Go get it). Much of the M$oft steamroller effect is because they're actually implementing new and useful stuff like parameterising stylesheets (Caveat - I haven't yet seen what they've done, but I know I want it) and they're still the only people with a usable client-side XSL on desktop browsers. I hate IE5, but it's just so damn useful that I can't avoid it.
A csv parser?
Okay, that's a good quick hack to parse: foo,bar,baz
How about: "John Malkovich", "John \"Blah\" Doe", "Steven Wright", Cher, "Larry Wall"?
Yeah, I know, you needed a quick hack to parse #1, but eventually someone will export an Excel file to what *it* calls CSV and get something like #2. Then, that little hack gets a lot bigger.
#!/usr/bin/perl
$parser = new XML::Parser(Style => 'Tree');
$tree = $parser->parsefile('coolstuff.xml');
And you get a pretty simple tree data structure of your XML, ready for quick hacks to walk through it and pluck out your data. It's not that hard.
tidy -asxml yourfile.html > yournewfile.xhtml
Get tidy here.
Looking over the spec, I see that the w3c spec will begin enforcing things that most browsers have allowed, such as
without a closing tag. Any idea how browsers such as mozilla or whatever will deal with this restriction?
Are we going to be getting errors or unrenderable pages due to bad HTML? Frankly, I hope we do :-) It'd serve them right.
Just an observation/question.
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
While it might not be realistic, the W3 likes to envision a future where clients become much more lightweight and flexible by putting all parsing and presentation into standard XML parsers and stylesheet tools. Currently a significant amount of browser bloat is due to the fact that the browsers pretty much render anything you throw at them. Hopefully this will change lest our HTML parsers grow to 20MB.
Here's how you use XHTML in your pages:
Reach around the back.
Pull out the plug.
Place your computer in its original packaging. You *did* keep your original packaging, right?
Return your computer to where you bought it.
If they ask why, tell them you're too stupid to own a computer. (The more astute among you will recognize this punchline from an allegedly true WordPerfect Tech Support call and its support tech's response.)
And to quote Craig McPherson: thank you.
And if you were actually serious about your question, it will require more explanation than I'm ready to give in this comment. Suffice it to say that when it is finally adopted there will probably be some point-and-click MS program out there. You don't need to worry about that. Don't think. Let MS and its cruddy software do the thinking for you :-) That IS how you trained for your MCSE, right?
I know this looks like a flame. It isn't. I'm assuming the guy above was a troll, so I am trying to be funny. I don't think it's working...
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
A week and a half ago, I began converting my site from HTML 4.0 to XHTML 1.0. Thanks to the W3C's validator, it was pretty easy to do.
Aside from changing the DOCTYPE and adding an XML declaration, all I had to do was make all elements and attributes lowercase, quote all attributes, and close all standalone tags (<br/>, <hr/>, <img src="tweet.jpg" ... />, etc.). It only took a little further tweaking to make it display nicely in Netscape 4.7, IE 5, and even lynx!
Unfortunately, it seems that XHTML chokes Mac IE 4.5 (and presumably surrounding versions). That browser just displays the page source without rendering it. Since I want my site to be viewable by anybody on any platform (and IE5 is not yet out for Mac), I had to go back to HTML 4.0. Argh!
I really like XHTML so far, though, and will probably convert to it as soon as Mac IE supports it (4.5 users: tough luck). If you want to see one of my preliminary XHTML endeavors, go to moby.org's mailing list archives page. Try it with any browser. AFAIK, it works fine with almost all of them.
Incidentally, I don't see any support for such tricks as using tables to lay out a page. Will this force people to recode their layouts with CSS (which they probably should do anyway), or just give coders another excuse to ignore W3C recommendations?
Quantum mechanics: the dreams that stuff is made of.