Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 8 of 8
  1. #1
    Regular Coder
    Join Date
    Dec 2002
    Posts
    169
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Unhappy "JavaScript, DHTML and XML! Oh my!"

    <removed> To be published on SitePoint

    Sorry!
    Attached Files Attached Files
    Last edited by ca_redwards; 11-26-2003 at 06:48 PM.

  • #2
    Moderator
    Join Date
    May 2002
    Location
    Hayward, CA
    Posts
    1,453
    Thanks
    1
    Thanked 21 Times in 19 Posts
    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
    "The first step to confirming there is a bug in someone else's work is confirming there are no bugs in your own."
    June 30, 2001
    author, Verbosio prototype XML Editor
    author, JavaScript Developer's Dictionary
    https://alexvincent.us/blog

  • #3
    Regular Coder
    Join Date
    Dec 2002
    Posts
    169
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Question Why run in fear?

    Alex,

    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 .
    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.)
    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 . 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...
    Code:
    <I>This is <B>invalid</I> markup!</B>
    This sort of not-well-formed markup is just not possible using the HTML() library .
    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.
    Code:
    'foo'.BODY(ONUNLOAD('bar()'))   yields
    <body onunload="bar()">foo</body>
    But ...
    Code:
    '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!!
    Last edited by ca_redwards; 11-19-2003 at 06:05 PM.

  • #4
    Moderator
    Join Date
    May 2002
    Location
    Hayward, CA
    Posts
    1,453
    Thanks
    1
    Thanked 21 Times in 19 Posts
    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!
    Last edited by Alex Vincent; 11-20-2003 at 01:22 AM.
    "The first step to confirming there is a bug in someone else's work is confirming there are no bugs in your own."
    June 30, 2001
    author, Verbosio prototype XML Editor
    author, JavaScript Developer's Dictionary
    https://alexvincent.us/blog

  • #5
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Why run in fear?

    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 How to serve XHTML as application/xhtml+xml

    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.
    Last edited by brothercake; 11-20-2003 at 11:35 AM.
    "Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark

  • #6
    Regular Coder
    Join Date
    Dec 2002
    Posts
    169
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.
    Code:
    INPUT(ONCLICK('foo();'))         already yields
    <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.
    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).

    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!
    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.
    Last edited by ca_redwards; 11-20-2003 at 06:07 PM.

  • #7
    Senior Coder
    Join Date
    Jun 2002
    Location
    Nashua, NH
    Posts
    1,724
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.
    Vladdy | KL
    "Working web site is not the one that looks the same on common graphical browsers running on desktop computers, but the one that adequately delivers information regardless of device accessing it"

  • #8
    Regular Coder
    Join Date
    Dec 2002
    Posts
    169
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Not to conserve keystrokes...

    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...
    Code:
    document.title.A(HREF(window.location.href)+TITLE(window.name)).write()
    ...can be used in all pages, each with unique results.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •