[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: Re: Fw: Re: XHTML Stylesheets
Hello, On Sun, 16 Dec 2001, Lars Trieloff wrote: > For creating valid XHTML 1.0 Strict/XHTML 1.1 we will have to > - change the doctype And not to forget the correct namespace on the html root element. That problem was addressed in a recent thread on this list. IIRC Norm said it wouldn't be so easy to accomplish this. So are we supposed to process the xhtml-output once more to add the namespace? This should be no problem as the output is well-formed xml and xslt can be used, right? I tried different other patches to get the xhtml namespace continually throughout the whole xhtml output files, all without success (which could just be due to my limited xslt knowledge): -adding xmlns="..." to my stylesheet driver => every other stylesheet fragment imported/included is still missing that declaration (and that are quite a lot both in website-xsl and dbxsl). -<xsl:namespace-alias stylesheet-prefix = "#default" result-prefix = "#default"/> together with xmlns="..." in my driver (in the hope this would override the missing declarations in other fragments). I had quite some tough hours this weekend figuring out why Mozilla (0.96 with MathML) doesn't render XHTML with embedded MathML correctly in all cases. So far I would say it requires a correct namespace for html and mathml-elements, the correct content-type (text/xhtml or text/xml?) or the correct file-suffix (.xhtml or .xml) if loading through file:-protocol. If MathML markup uses symbolic character entities one additionally needs a system identifier of "mathml.dtd" which is IMHO a dirty fudge to resolve them internally, but this is not necessary with dbxsl because by default only numeric charents are output. > + one thing that was already mentioned, the proper nesting of elements: > there are no div elemtents allowed inside p elements (validator.w3.org says: > "Error: element "div" not allowed here; possible cause is an inline element > containing a block-level element"), > so we have to replace nearly all p elements by div elements, one exception > would be the simpara-->p transformation, which seems to be ok. > this are the first things that have come into mind, so this list has to be > filled. Wow, this seems to be a really radical switch to complete CSS-reliance to me. I wonder where to draw the border to not generate _any_ xhtml-elements but <div>s and <span>s and some other necessary action-(e.g. <a>) and meta-elements? What I mean is: We don't say goodbye to e.g. <b>,<i>,<hx> and others because it could all be done with CSS, do we? Bye, Steffen. -- http://w3studi.informatik.uni-stuttgart.de/~maiersn/ mailto:Steffen.Maier@studserv.uni-stuttgart.de
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC