XHTML 1.0 now a W3C Recommendation
Posted by
jimjag
on Thu Jan 27, 2000 01:05 AM
from the still-lost-in-dynamic-html dept.
from the still-lost-in-dynamic-html dept.
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.
This discussion has been archived.
No new comments can be posted.
XHTML 1.0 now a W3C Recommendation
|
Log In/Create an Account
| Top
| 139 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
No one uses XML?! Are you for real? Or a troll.. (Score:5)
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 [ninjacode.com]. And this project makes extensive, pervasive use of XML.
- The documentation I'm writing [ninjacode.com] (other than POD in the Perl modules) is being done with the DocBook DTD [docbook.com], 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 [textpad.com] 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 [slashdot.org]. 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.
Re:Compatibility with existing browsers (Score:5)
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
Re:Meta-Standard? (Score:4)
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.
Re:XHTML - Extend HTML without breaking standard (Score:3)
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.
Re:What does this do for me? (Score:3)
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.
Compatibility with existing browsers (Score:3)
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.
XHTML - Extend HTML without breaking standard (Score:3)
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.