- From: David Carlisle <davidc@nag.co.uk>
- Date: Fri, 14 Jul 2006 16:29:53 +0100
- To: whitelynx@operamail.com
- Cc: www-math@w3.org
> The problem with xml-stylesheet is that it will interfere with native > implementations, plugins and even UserJS and spoil rendering of MathML > in those UAs that are MathML aware, well it interferes in the sense that it always activates, but it doesn't need to break native rendering. pmathml.xsl just passes everything through if running in mozilla for example, so you get mozilla's native rendering. > l, text/mathml please) and if namespace is declared explicitly (don't > rely on default attribute value in external DTD). So I think that > UserJS approach is the way to go as it does not require hacks on > author side. Yes they are the advantages of detection in the client, the disadvantage is that the client needs to install something first and you get (typically) less graceful fallback behaviour if a client that hasn't been adapted is use to look at the page. Ideally xhtml would be automatically detected in all the major browsers and they'd automatically dispatch to whatever was needed if the mathml namespace is there, but with the current generation of browsers that isn't the case, and I think both methods (and the third method of configuring the server to serve different versions to different browsers) all have a place, depending on local needs. > Existing niche in XML + CSS framework does not need to be standardized > in order to work, it exists canonically). It only works canonically as far as rendering in a CSS engine goes. That was my point, you lose the benefits of using an agreed more widely implemented markup. MathML is usable in many places where css is not: maple, mathematica, openoffice (MS Word2007 as far as I understand, although I haven't been able to verify that). David
Received on Friday, 14 July 2006 15:30:14 UTC