"JavaScript, DHTML and XML! Oh my!"

ca_redwards

11-17-2003, 04:16 PM

<removed> To be published on SitePoint (http://www.sitepoint.com/article/1256)

Sorry!

Alex Vincent

11-19-2003, 01:30 AM

XML enthusiasts will run in fear of document.write(), which seriously runs a risk of producing not-well-formed markup. XML documents in Mozilla don't support document.write(), including XHTML documents served as XML or as application/xhtml+xml. (As text/html, they may be allowed, but then you lose much of the benefit of having XHTML in the first place.)

At the same time, I don't see any evidence of using DOM-compliant code, which although sometimes longer, often safeguards against creating not-well-formed markup.

Your adding these methods directly to the String's and Array's prototypes is a little disturbing; I don't know why, but I have a bad feeling about it.

It looks like I could easily create an <onunload body="foo"></onunload> element. I would guess you use the capital first letter to distinguish between an element and an attribute.

Just a few observations from my standpoint; don't take this as an outright rejection of your widgets :)

ca_redwards

11-19-2003, 05:52 PM

Alex,

:confused: When you say...
Originally posted by Alex Vincent
XML enthusiasts will run in fear of document.write(), which seriously runs a risk of producing not-well-formed markup.
How is client-side (JavaScript) document.write any more dangerous than server-side (Java/PHP) write? As I understand it, the content itself (rather than how it comes to be written) has more to do with the success/failure of rendering a particular document type. Pages generated in this way can be written in toto using a single .write() invocation :thumbsup: .
XML documents in Mozilla don't support document.write(), including XHTML documents served as XML or as application/xhtml+xml. (As text/html, they may be allowed, but then you lose much of the benefit of having XHTML in the first place.)

:eek: How can I verify this?

At the same time, I don't see any evidence of using DOM-compliant code, which although sometimes longer, often safeguards against creating not-well-formed markup.

I designed the HTML() code itself to be very tight :D. Not unlike C programming, invalid output is quite possible ;), and thus, is clearly the programmer's responsibility. The HTML() library won't stop you from adding unsupported attributes to tags or unsupported values to valid attributes :(, but it does assure that container nesting doesn't get crossed...
<I>This is <B>invalid</I> markup!</B>
This sort of not-well-formed markup is just not possible using the HTML() library :thumbsup:.

Your adding these methods directly to the String's and Array's prototypes is a little disturbing; I don't know why, but I have a bad feeling about it.

It looks like I could easily create an <onunload body="foo"></onunload> element. I would guess you use the capital first letter to distinguish between an element and an attribute.

Actually, no you really cannot. :cool:

'foo'.BODY(ONUNLOAD('bar()')) yields
<body onunload="bar()">foo</body>

But :mad:...

'foo()'.ONUNLOAD(BODY('bar'))

...fails because ONUNLOAD is not defined on String, nor is BODY defined on window. That is precisely the kind of confusion I avoid by specifying whether window or String is to be extended.

Since .BODY() is defined on String, but not on window, it always renders a '<BODY...>' and '</BODY>' that enclose its string content. Likewise, because ONUNLOAD() is defined on window, but not String, it can only render ' onunload="..."' as an attribute. (The ellipsis indicates where passed parameters will appear).

The notable exceptions are TITLE and STYLE which can serve as either containers or attributes.... depending upon the context. If called on string, it is a container. If called on window, it is an attribute.

If you have suggestions on how HTML() can be made more XML-friendly, let me know. I'd be happy to incorporate your ideas.

Thanks!! :)

Alex Vincent

11-20-2003, 01:18 AM

Well, here's the hang-up:

Netscape 4.x and earlier browsers don't support XML. At all. Nor do they really support the DOM as defined by the W3C.

http://www.w3.org/DOM

So it's a trade-off: do you want your script to work in Netscape 4, or do you want it to work with DOM-compliant browsers?

I'm sorry, I should've mentioned that earlier. If you can afford to lengthen your script a bit, you can do some sanity checking for the DOM pretty easily. That would give you the best of both worlds. Take a look at the W3C's DOM pages, and see if they help. If not, there's a category for DOM scripting in the JavaScript Programming Help forum. :)

Re document.write(): it's in the HTML DOM, Levels 1 and 2, but not in the Core DOM. Core DOM applies to HTML and XML documents; the HTML DOM only to HTML documents and in some respects (where it's safe to do so) XHTML served as application/xhtml+xml. We actually have a bug filed at Bugzilla for adding document.write() to XML (RESOLVED INVALID, if you do a query under Browser, XML, I believe, http://bugzilla.mozilla.org/query.cgi ).

There's also something you don't understand very well with respect to XML, and it's something many people new to XML miss. With XML, there's well-formedness (making sure your tags are nice and neat, mainly), and there's validation (making sure your document follows the rules of a particular XML language, such as XHTML). Well-formedness is a very complex thing to grasp; for one thing, elements that don't have a closing tag must close themselves, with a slash at the end. (This makes life interesting for HTML, which doesn't allow that in the HTML 4.01 Recommendation)

XHTML:
<input onclick="foo();"/>

HTML 4.01:
<INPUT ONCLICK="foo();">

I'd say your script is good for HTML documents served as text/html, and thusly for most web browsers, including Mozilla (if you're serving as text/html). It was your approaching XML that bothered me, and that's what I'm stepping in on. My replies to this thread as just intended as "user's manual" comments; if you're going to use this script for XML documents, particularly for XHTML as application/xhtml+xml, be very careful, as it may not work.

I'd suggest that if you feel it is necessary, put up a second version of the script, which is DOM-compliant. XML compliance and HTML compliance do not always go hand-in-hand; there's a number of issues to deal with, which no one specification covers. In my opinion, it would be too much trouble -- and bloat -- to extend your script to support XHTML.

Cheers! :D

brothercake

11-20-2003, 11:30 AM

Originally posted by ca_redwards
How can I verify this?
There's a few different ways of serving XHTML as XML - this sticky talks about it http://www.codingforums.com/showthread.php?s=&threadid=19775

You'll notice a few things are different - most notably:

- document.write doesn't work
- document.body doesn't exist
- innerHTML and other proprietary extensions are gone
- createElement is superceded by createElementNS

And shortcuts that might work in HTML documents won't work in XML - like setting the position of an object as numbers when it should be strings - that kind of thing.

Have a poke around the DOM scripting category - there's a few threads in there on the subject.

ca_redwards

11-20-2003, 05:09 PM

Originally posted by Alex Vincent
So it's a trade-off: do you want your script to work in Netscape 4, or do you want it to work with DOM-compliant browsers?

Netscape 4 support is secondary. DOM-compliant browser support is the primary concern.

There's also something you don't understand very well with respect to XML, and it's something many people new to XML miss. With XML, there's well-formedness (making sure your tags are nice and neat, mainly), and there's validation (making sure your document follows the rules of a particular XML language, such as XHTML). Well-formedness is a very complex thing to grasp; for one thing, elements that don't have a closing tag must close themselves, with a slash at the end. (This makes life interesting for HTML, which doesn't allow that in the HTML 4.01 Recommendation)

XHTML:
<input onclick="foo();"/>

HTML 4.01:
<INPUT ONCLICK="foo();">

Perhaps you might have missed it, but my script already does this. :) Tags (my term for those "elements that don't have a closing tag") do close themselves with a slash at the end.

INPUT(ONCLICK('foo();')) already yields
<input onclick="foo();" />
:thumbsup:

I'd say your script is good for HTML documents served as text/html, and thusly for most web browsers, including Mozilla (if you're serving as text/html). It was your approaching XML that bothered me, and that's what I'm stepping in on. My replies to this thread as just intended as "user's manual" comments; if you're going to use this script for XML documents, particularly for XHTML as application/xhtml+xml, be very careful, as it may not work.

Thanks for the warning. Admittedly, I am uncertain as to when which browser renders what dom details under whose document type. And as the name of this library implies, it started solely as a way to generate HTML. Later on, it was suggested to me (by whammy or jkd, CodingForums moderators) that perhaps I could at the very least support XHTML, which I have endeavored to do (and rather successfully, I think). :cool:

I've used HTML for years and years, but my XML experience is much more limited. :(

In my opinion, it would be too much trouble -- and bloat -- to extend your script to support XHTML.

Cheers! :D
I believe that it supports XHTML now (unless I've misunderstood something!), and at this point, I'd be more interested in seeing what folks can actually do with it! I can keep polishing it, but I really don't want to change the method signatures as they stand, 'cause that'll break the multitude of HTML() dependent scripts. ;)

Vladdy

11-20-2003, 05:39 PM

I can not see a practical application for it. You make pages depend on client-side javascript just to save some typing - not a good approach IMHO.

ca_redwards

11-20-2003, 05:55 PM

My original motivation was not to conserve keystrokes, but rather to make HTML constructs more flexible.

Originally posted by Vladdy
I can not see a practical application for it. You make pages depend on client-side javascript just to save some typing - not a good approach IMHO.

For example...
document.title.A(HREF(window.location.href)+TITLE(window.name)).write()
...can be used in all pages, each with unique results.