[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] Whatever happened too CSS+XML?
--- "Steven T. Hatton" <email@example.com> wrote: > I'm in favor of redefining best practices in > terms of XML, not XHTML. I apologize but my conscience prevents me from failing to point out that the X in XHTML is the same X as in XML. XHTML is XML. > One of > the problems with using xhtml is the fact that > it requires a significant > restructuring of the original (DocBook) > document, and thus requires the > author and/or page designer to understand the > mapping between these two > disparate forms. I'm not sure if I agree. I've produced some pretty nice looking renderings of docbook to PDF and I don't know a thing about FO - aside from the fact that I'm pretty sure it isn't even remotely related to docbook. > Modern browsers and XML > should be able to leverage the > native structure of DocBook and provide a full > featured on-line interface. I would state that a user that claims docbook conformance _must_ correctly render what is documented in the TDG. IE, Gecko, Opera etc are in no way obliged to render docbook because they do not claim to conform (any more than they are obliged to correctly render say OWL or ANT.) > This may require some rethinking of current > approaches, learning new > technology, and pushing the browser technology > to conform to the existing W3C > specs. It will likely also involve modifying > these > specifications/recommendations. The mainstream user agents all correctly render XHTML with very few defects. Most also correctly render many day-to-day XML/XSL chores. When I say correct, I mean they render this content in an accessible fashion that complies with the recommendations of the W3C. The user agents are not the problem. No one in this thread is recommending that Adobe change their specs or update their PDF render so that it directly renders Docbook. I reject the idea that XHTML rendering user agents need to render docbook directly. Docbook is an excellent vocabulary for sourcing other documents. Let's work from there. I'm pretty sure we already have enough technology developed to do everything we want. We don't need more. > The pace where > XSLT would play a role is in > generating XML indexes, links between the > indexes and indexed terms, links to > and from glossed terms and glossary entries, > TOCs, etc. And here is where I'm lost. Because there is almost no precedent for your list on the web, I've found it extremely difficult to find well defined best practices for exactly what these items are supposed to look like using XHTML (both semantically and presentation-ally). XHTML and XSLT isn't much help when you almost never see and index or glossary. I'm working on it though. Docbook has it easy somewhat because most folks are expecting a nice flat two dimensional document stream and not a multi-dimensional hyperlinked web site. > I understand why people use XSTL transforms > into XHTML. I do it. But I > believe there is vast potential in breaking out > of the XHTML framework. I believe there is much uncharted territory yet to explore. Just a couple of searches on Dublin Core or CSS Image Map will keep you busy for weeks. > I've build modestly sophisticated web pages > with nothing but CSS and XML. I > know it can be done, and I know there are some > problems. One thing some > people on this mailing list seem to be missing > is that they are (or can be) > the driving force that determines which way the > technology goes. This is why I'm commenting. I surely can't be the only one that sees things the way I do. I'm fourty something, I like long walks on the beach and quiet moments in front of the telie. > The > response that the browsers don't support it, so > it can't be done isn't a > valid argument. Steve. We're on two different roads leading to the same definition. Cheers! Scott