In article <a0hn05$m3m$[EMAIL PROTECTED]>, Torsten Bronger wrote: > > Well, "I read" that exactly there. Those discussions always were on a > practical level, but I wonder why the W3C creates a 400-pages > standard although the two Big Browsers won't support it. Maybe the > XSLFO creators should have asked _before_? :-)
Well, XSL:FO is (IMO) more suitable for documents destined for printed rendering and complex typography than for the WWW, which is accessed by a variety of user agents with very different capabilities. This has been clearly recognized by the W3C with its work on "profiles", mobile devices, etc. XSL:FO largely exists (as I understand it) because designers for printed media found CSS lacking in precise typographical and layout capability. OTOH, the CSS recommendation is written to allow the flexibility necessary for WWW design. >> From a practical point of view, this would require substantial work on >> the layout engine. The current mozilla layout engine is basically an >> XML+CSS renderer. Supporting XSL-FO would mean generalizing the >> engine or writing another one, both of which would be very >> complicated. > > But now it's for _me_ complicated! I must not only create XSLT trafo to > LaTeX and XSL:FO for my FO-Processors (especially the transformation > to RTF); additionally I have to write XSLT to HTML. This last step is > actually superfluous. And I may keep all three versions consistent. :-( > > The same is true for all other XML application out there. I think not > supporting FOs creates an annoying redundancy. But your XSLT transformation to HTML should, in fact, be preserving semantics (headings, code, addresses, for instance) which are lost by the very nature of XSL:FO. I will admit that HTML is not a very *good* language for expressing document semantics (compared to DocBook et al.) but it's better than nothing (e.g., XSL:FO). Of course, you could also style your XML directly with CSS, at the expense of most older browsers. >> >> Then there's the question of what XSL-FO provides that XML+CSS (and >> possibly XSLT, which mozilla supports) doesn't. > > Granted, but one argument more to delete one of them from the W3C > home page. See above. CSS works best for the WWW, where content presentation tends to be flexible; XSL:FO is leveled at publishing/"dead trees". >> Some people fear that >> sites would start serving XSL-FO content instead of serving XML with >> an associated FO stylesheet. > > I don't know why people would do that, but automatically generated > ugly web files are already existing. It's not the ugliness, it's the semantics. (See dbaron's URLs). In an HTML document, it's possible to determine whether some text is a heading, a list, a definition, an acronym...etc. all from the markup, *regardless of how the user agent actually displays it*. With pure XSL:FO documents, all you have is appearance with which to guess the author's intent. So already elements begin to overlap (<code>, <kbd>, <tt>, for instance), and things get even worse if the user agent can't deal with some complex piece of layout. Auf wiederhoeren, -- Chris Hoess
