MozillaZine

XML Transformations with CSS and DOM

Saturday September 28th, 2002

Apple Developer Connection has a tutorial describing how to render XML in Mozilla using CSS and DOM. The article starts off by explaining how to style XML using CSS and then uses DOM Level 2 to transform some of the output into XHTML. This is all standards-compliant stuff that should work in any 'next generation' browser but only Mozilla is currently cool enough to support it all. The tutorial is by Scott Andrew LePera, who also wrote ADC's last article about Mozilla.


#1 Excellent article

by kunta

Saturday September 28th, 2002 2:52 PM

Reply to this message

As alway from Scott Andrew, didn't expect anything less from him. Stumbled upon his site about a year a go, visited ever since.

#2 nice, but...

by Sander

Saturday September 28th, 2002 4:35 PM

Reply to this message

Nice article - shame only that turning link elements into links as described there doesn't work anymore. It did in 1.0, but with current nightly (or 1.1, according to a friend I just asked to try it) there are no links... Our mistake? Anyone know enough about the technologies used here to really investigate and see if there's already a bug and file one if not?

#11 Re: nice, but...

by scottandrew

Tuesday October 1st, 2002 6:33 PM

Reply to this message

Many people have written in about the broken support for the XHTML links in the demo. I'm trying to track down a corresponding bug in Bugzilla, but so far no luck. Advice and clues appreciated. ;)

#3 Shouldn't XSLT be used?

by dpol <dpol@swipnet.se>

Saturday September 28th, 2002 7:08 PM

Reply to this message

While I agree that the article is well-written, I have a couple of reservations.

First, our goal with publishing XML-based formats on the Web is to introduce semantics - the information should mean something, not only for humans who read visually, but also for computers (that's the idea behind the Semantic Web). I don't approve of the author's usage of the <a>-element from the XHTML namespace. XLink should be used for this; to the author's credit, an XLink version is also included.

However, I really don't care for the inclusion of a JavaScript to programmatically modify the DOM tree. There is no "xml-script" processing instruction, and for good reason. We have XSLT for that job.

#5 Re: Shouldn't XSLT be used?

by masi

Sunday September 29th, 2002 2:14 AM

Reply to this message

> There is no "xml-script" processing instruction, and for good reason.

> We have XSLT for that job.

Won't have XLST 2.0 have 'user defined' functions?

#6 XSL considered harmful

by fab

Sunday September 29th, 2002 2:14 AM

Reply to this message

Here's an article that could change your mind about XSL:

<http://www.xml.com/pub/a/…/xsl/xslconsidered_1.html>

#9 Re: XSL considered harmful

by masi

Monday September 30th, 2002 12:41 AM

Reply to this message

The article is VERY old. It is (mainly) about XSL, now XSL-FO, and not XLST. As the author self states: "some XSL advocates have begun to call for a clean separation between the proposed transformation language and the formatting language."

Plus, it is a bad article because of it's unnecessary angry tone. While the author is right, you can do transformations with a (procedural) language, it doesn't mean it's the only way to do it. As mentioned in another post, XLST 2.0 will get some 'user functions' to beef up the basic (declarative) transformation language.

What I don't get is the point on being "interactive". I do not remember the hopes about the orginal XLS, but certainly I see nothing about XSL-FO and XSL that's there to support interactivity. Obviously, DOM manipluation + CSS is the way to go.

Anyway, XLST is now mostly a server-side used technology. IE 5.x supports has onyl an implementation of the old working draft (there is a 'plugin' in MS' download area). And IE 6.x finally implements XLST out of the box, but defaults to the working draft. You have to explictely invoke a transformation on a DOM tree using JScript! This breaks all XML code that uses XML prosseing instructions. So XLST will stay serevr side, bu on a very few sites with a closed user base like intranets.

Masi

#4 Shouldn't XSLT be used?

by dpol <dpol@swipnet.se>

Saturday September 28th, 2002 7:18 PM

Reply to this message

While I agree that the article is well-written, I have a couple of reservations.

First, our goal with publishing XML-based formats on the Web is to introduce semantics - the information should mean something, not only for humans who read visually, but also for computers (that's the idea behind the Semantic Web). I don't approve of the author's usage of the <a>-element from the XHTML namespace. XLink should be used for this; to the author's credit, an XLink version is also included.

However, I really don't care for the inclusion of a JavaScript to programmatically modify the DOM tree. There is no "xml-script" processing instruction, and for good reason. We have XSLT for that job.

#7 Whatever

by Tanyel <tanyel@straightblack.com>

Sunday September 29th, 2002 11:34 PM

Reply to this message

I would like somebody to tell me why Mozilla is better than Java for cross-platform programming.

#8 Re: Whatever

by leynat

Sunday September 29th, 2002 11:51 PM

Reply to this message

this article describes it well:

<http://home.attbi.com/~bconway31/test.html>

#10 Re: Whatever

by asa <asa@mozilla.org>

Monday September 30th, 2002 11:31 AM

Reply to this message

Better for programming what? For programming rich internet enabled clients? For many, probably becase Mozilla has better xp networking and layout capabilities than Java and that it's got lots of great xp functionality scriptable via JS and Python (pearl too?) and that it's got a xp UI toolkit that's very full featured and relatively easy to use.

(see Phoenix, for example. it is the result of a few weeks of work by a few part-time developers and it's already a great web-browser. i don't see anyone throwing together a fully Java web browser with that few resources in that many hours that comes even close to Phoenix in functionality and usability)

--Asa