Cart
[Home] [By Thread] [By Date] [Recent Entries]
> I don't know, XHTML only starts to look iffy when considered in terms of > traditional browsers, I agree with this part. I am just saying it is dumb to tell people to use XHTML if they are only targeting traditional browsers, and we know that the browsers and tool support is spotty. > as fairly straightforward XML document markup it > seems perfectly reasonable. Even with XML+XSLT+CSS we're dependent on Now this I disagree with. HTML is a mess. Some tags are semantic, some tags are presentation-only. It is all jumbled together. It's a very poor vocabulary, and should be hidden from all but web page designers. The actual data files should be written using a specific vocabulary with well-defined vocabularies. > The references to RSS are interesting, it's rather like Len's case > turned inside out - document islands in a data format. But there the > aggregator points to a completely different species of browser where the > data should (in principle at least) be XML. But content being delivered The key point is that the data is semantically well-defined. Just imagine if we had tried to build a universe of aggregators based on screen-scraping XHTML rather than using moderately well-defined XML vocabularies. It would have been a disaster. How can anyone say that screen-scraping XHTML is a good idea?? > in syndicated feeds has to be interpreted somehow, and the options > currently on the table are escaped HTML or nested/namespace-qualified > XHTML. The former is a pretty awful approach when the latter is That is a good point. Storing presentation data as XHTML is not such a terrible thing, but I still would prefer escaped HTML (because of tools support). But again, the point is that the machine-processable part uses a well-defined XML vocabulary, and the presentation part is just an embedded blob. Mixing them is a terrible idea.
|
