azz:
Hey, and even our source sites believe we exist now.
Muhahahaha.
azz:
Now officially back on!
Point your friends there!
David:
How compatable are DivX and XviD?
Does this mean we could be seeing DivX capable players that plug into the telly ?
azz:
This is the old DiVX (i.e. the nasty proprietary DRM crap), so "not at all".
XviD is an implementation of baseline MPEG4 video.
David: Oh wonderful! What fantastic advantages! How amazingly useful! Oh wait ... it doesn't work for IE, Opera, Konqueror or Safari. How useful.
azz: Yes, and if everyone keeps using that particular line of reasoning then it never will.
David: Thanks to the wonders of <object> and well formed HTML - most of those advantages are available without switching to XML.
azz:
But the long-term objective is to switch to XML, so I'm not entirely sure what's wrong with extolling the advantages of it.
XML sucks, but it's several orders of magnitude better than SGML as a basis for HTML.
David:
The trouble is that the 'advantages' being extolled are highly minimal in the face of the current market.
Great - so you can mix XHTML and SVG in one document. Do you know any user agent that supports it?
Ditto MathML - You can have Mozilla cope with such mixed documents - but the user has to jump through so many hoops that its not practical.
azz: Erm, this is the W3C -- they're describing the spec, not implementations of it.
David: There isn't going to be any advantage for the author (whom this document is targeted at) until there is support for it in the market place.
azz:
It doesn't matter that clients don't support most of the cool stuff you can do with XHTML right now, because they're describing what you will be able to do with it in the future.
And the only way these technologies are ever going to get support in the marketplace is if people want them, so the W3C are entirely right to describe why you might want to get your client's author to support them.
David:
The trouble is that (a) Its coached in terms of now not then and (b) Its practically impossible to get any of the client authors to support the technologies. Mozilla is making an effort, but it isn't exactly going quickly. As for the other major browsers - nada.
In the meantime, thanks to Appendix C, we have all these people creating XHTML documents in ways which will break
So when we do get around to having support in the clients for proper XHTML, pages are going to stop working all over the place.
Then of course we have the joyfulness of No. CSS rules that apply only to HTML, apply only to documents that are delivered as text/html.
So you get forget about your .class notation working in properly handled CSS/XHTML.
The trouble is that in an effort to be backwards compatable, then whole thing has ended up being forwards broken.
If the w3c had jumped directly to XHTML 2.0, then it would be likely to succeed a lot sooner.
Unless Microsoft hacked Trident to treat application/xhtml+xml as HTML and XHTML 2.0 as HTML 5 with lots of the usual parsing correction rubbish.
which they probably would
Client side web is so depressing at present
azz:
Given that it's very careful to talk about "your document", I don't think your (a) is fair -- if you have a document right now that uses XHTML and other namespaces (which is entirely reasonable if you've got something that's transforming it into another format, even if you're not using a browser that supports it), then that is something that you can only reasonably do with XML.
It's talking about documents, not clients. It's extolling the virtues of the specification.
It is traditional to do this before a spec is widely implemented, because otherwise nobody's going to bother implementing it.
Hey, I didn't say XHTML is good, just that it's better than HTML.
David:
The trouble with the nobody bothering to implement it part is that they've made XHTML 1.0 close enough to HTML 4.01 that implementations of it have been hacked versions of HTML 4.01 support - which suck mightily.
They approach they've gone to in their development of XHTML has probably set the whole thing back a fair while
azz: What's the CSS classes and XHTML problem? I hadn't heard of it before, and a quick Google doesn't find anything relevant...
David: The CSS class selector is specific to HTML. XHTML is not HTML so the class selector doesn't apply. (Current implementations ignore this)
azz:
And XHTML2 implementations are similarly going to be based on HTML4 implementations, because there's no other way you can actually make a usable browser.
Realistically, no browser author is going to build a browser that refuses to render malformed XML, because experience has shown that virtually nobody can write valid HTML.
David:
Anybody can write valid HTML. The problem is making them (a) know and (b) care
And once we have to deal with malformed XML we hit the usual problems of Postal and have a massive barrier to entry for authors of new user agents.
azz: That's an extremely odd interpretation of "HTML". ;)
David: Its the w3c's interpretation. See the FAQ entry I referenced and "For style sheets used with HTML, authors may use the dot (.) notation as an alternative to the "~=" notation when matching on the "class" attribute." from the spec.
azz: Browsers will deal with malformed XML, though; it's actually pretty easy, given that every browser already has a parser that'll do a half-decent job...
David: Which still leaves the barrier to entry for new parsers.
azz:
(The parser that browsers use for HTML is usually closer to XML than to SGML -- they almost never support any of the SGML fancy features...)
That's, uh, an odd decision for them to make.
No, that's a completely stupid decision for them to make.
David: Yes. The w3c has a huge number of morons working for them.
azz: I think that's a bug in the CSS spec, though, rather than in XHTML...
David: There seem to be large bunches of people interested only in the theory and forgetting about practical implications.
azz: Well, you have to have some people interested in the theory, otherwise you never actually develop anything.
David: And just as many people working entirely in the field of making things nice for big business
azz: It seems more like a lack of communication than academia syndrome.
David:
The trouble is that the first group seem to be responsible for desinging HTML while the second group seem to be responsible for WCAG.
This leaves both teams rather unbalanced and causes them w3c to spew out rather a lot of ... crap.
azz: I give up. Henceforth, all my web pages will be encoded in TEI.
David: TEI?
azz:
The Text Encoding for Interchange format; it's like HTML, but aimed at people transcribing existing text.
It's quite neat because it supports both semantic and limited-presentational markup -- so you can say "this I know to be strong, but this was just italic in the original and I'm not sure what they meant".
And it has proper handling for omissions, quoting, annotations etc.
David:
Interesting. I was thinking of going and doing everything in LaTeX.
I wonder if there is a LaTeX plugin for Mozilla.
azz: BleX. ;)
David: I can't find any reference to BleX on the web. Are you just being insuilting about LaTeX?
azz:
"BleX" would be pronounced "Blechhh". ;)
LaTeX isn't a very nice system for authoring web pages; it's too presentation-oriented.
azz: Now with silly picture of me.
David:
Nice picture actually
Shame about the horrific markup
azz: NOT MY FAULT.
David: Of course not... now put pressure on the creature responsible :D
azz:
I think it was Iain who did the design, and he's not working for UKMS any more as of yesterday.
We're going to fix it at some point, but we've got more important things to do right now...
David:
Like finding money to pay me to fix it?
Yes. I would like to hold down two jobs and that wouldn't put me under any stress whatsoever (gibber)
azz: Money? Hahahahahahahahaha. ;)
azz: Tidying up the UKMS web pages, one step at a time.
(The remaining ugliness here is in the web templates.)