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.
Page 1 of 2 12 LastLast
Results 1 to 15 of 23
  1. #1
    Senior Coder
    Join Date
    Aug 2002
    Posts
    3,467
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Edit:
    Note: This thread was originally split from this one.

    Your friendly supermoderator,
    jkd




    Originally posted by Alex Vincent
    Fortunately, you shouldn't use the namespaced-attribute methods as well.
    Pardon my ignorance, but I'm not quite sure what you're saying here....

    Oh, and other than "it's what's right", how does using the namespace affect the code/result/whatever
    Last edited by jkd; 03-23-2003 at 06:18 AM.
    My Site | fValidate | My Brainbench | MSDN | Gecko | xBrowser DOM | PHP | Ars | PVP
    “Minds are like parachutes. They don't work unless they are open”
    “Maturity is simply knowing when to not be immature”

  • #2
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Originally posted by beetle
    Pardon my ignorance, but I'm not quite sure what you're saying here....

    Oh, and other than "it's what's right", how does using the namespace affect the code/result/whatever
    HTML documents don't need to (can't) deal with namespaces. However, in an XML document, such as XHTML, elements MUST be namespaced. createElement by default returns a non-namespaced element. Therefore, you need to use createElementNS.

    As for namespaced attributes, with the exception of XLink and RDF, it seems every common XML Application published by the W3C uses non-namespaced attributes. I'm not entirely sure if that is a good idea, but whatever.

  • #3
    Senior Coder
    Join Date
    Aug 2002
    Posts
    3,467
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Yes, I understand all that, but why "must they"? What I mean is, if they must, there must also be consequences for not doing so.

    It's the consequences that I don't know. All my test-pages are XHTML Trans. Must I be using Strict to see some sort of adverse effect?
    Last edited by beetle; 03-22-2003 at 03:03 AM.
    My Site | fValidate | My Brainbench | MSDN | Gecko | xBrowser DOM | PHP | Ars | PVP
    “Minds are like parachutes. They don't work unless they are open”
    “Maturity is simply knowing when to not be immature”

  • #4
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Originally posted by beetle
    t's the consequences that I don't know. All my test-pages are XHTML Trans. Must I be using Strict to see some sort of adverse effect?
    No, I can almost guarantee your pages are tagsoup. Documents served as text/html are just that, HTML, even if you pretend it is XHTML. Unless you serve the page as text/xml, application/xml, or application/xhtml+xml (or anything that invokes an XML parser), the page is being interpretted as HTML, regardless of any XML formity.

  • #5
    Senior Coder
    Join Date
    Aug 2002
    Posts
    3,467
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Okay, I think that's what I was looking for. So this script would just plain not work if the page was served as text/xml etc?

    Remember jkd, I'm an application guy, not a theory guy
    My Site | fValidate | My Brainbench | MSDN | Gecko | xBrowser DOM | PHP | Ars | PVP
    “Minds are like parachutes. They don't work unless they are open”
    “Maturity is simply knowing when to not be immature”

  • #6
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Originally posted by beetle
    Okay, I think that's what I was looking for. So this script would just plain not work if the page was served as text/xml etc?
    Probably not.

    And I'm telling you, theory is soooo much nicer. Especially when you can bypass the application with nice browsers like Mozilla .

  • #7
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeå, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    When it comes to the DOM, theory is like childrens game against application.

    But, the theory can get maze-like when you're taking version differences, MIME-types and namespaces into account.

    DOM1 has no namespace functions, but you *should* be able to use it on xml-files.

    DOM2 provides namespace functions, but here you have another difference: createElement and createElementNS without a namespace aren't entirely alike. createElement only works in environments without namespace handling, while createElementNS must be used in namespaced environments, even if the namespace is the default one.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #8
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by beetle
    So this script would just plain not work if the page was served as text/xml etc?
    I just tried using createElement('name') on a page served as application/xhtml+xml. It's what jkd said - it doesn't work at all. But how do you add an object created using createElementNS? I tried to append it to document.body but 'document.body is not an object'?

    As for theory vs application - well, theory is what we'd like things to be; application is what they actually are. 95% of the time I don't have a choice - application has to win or I don't get paid
    Last edited by brothercake; 03-22-2003 at 11:01 PM.

  • #9
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    The reason you didn't get document.body is that Mozilla doesn't create an HTML DOM unless it has the text/html mime-type. application/xhtml+xml is basically treated like text/xml, and so it uses the Document constructor, not the HTMLDocument constructor.

    One can argue that the HTML DOM should be applied to an XHTML document, but one can also argue that since an XHTML document can contain lots of funky things, it may not be a good idea to throw application-specific DOM's in the mix.

    Either way, that's basically a long way of saying that there is no document.body when you serve the document as something other than text/html, at least in Gecko.

  • #10
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Right ... so at this point we're dealing with the XML DOM and not the HTML DOM ... so what are the major differences?

  • #11
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Originally posted by brothercake
    Right ... so at this point we're dealing with the XML DOM and not the HTML DOM ... so what are the major differences?
    Primarily things to do with document. Remember, document is now an instance of XMLDocument, not HTMLDocument, so you lose an application-specific properties and methods, like document.body, document.getElementsByName(), the document collections (forms, links, etc).

    Element-level things are still the same, as those constructors remain the same.

    http://www.w3.org/TR/2003/REC-DOM-Le...ml#ID-26809268

    You basically just lose those properties and methods. (note that document.write() is no more)

  • #12
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeå, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    For xhtml served as 'text/xml', 'application/xhtml+xml' or 'application/xml'; the document is essentially DOM Core, not DOM HTML. Since moz has an "extensive knowledge" of the xhtml namespace, though, it knows what semantics and functionality should be added to xhtml elements.

    In iew, it's worse - that browser brings no knowledge of the xhtml namespace into it's xml parser, and it doesn't have the namespaced DOM functions.

    Op7 also gets tricky - that browser knows xml - all right - and it does have some knowledge of the xhtml namespace, but it doesn't parse script tags and it doesn't support the namespaced functions in DOM.

    I have no knowledge of how saf/konq handles xhtml as xml, but I'd say it's a fair bet that mozilla is the only browser that really brings some good support.

    (BTW, as xml contains no way of including a script in a page, opera might very well be the browser that does the right thing - it's likely that people will have to either append scripts by xlink or run them from the opener application.)


    The reason for not creating an HTMLDocument instead of a plain Document, is a few compatibility issues xhtml has with other xml languages. They are roughly the same as those given for explanation why mozilla isn't an xhtml user agent, but an html user agent and an xml user agent with extensive knowledge of the xhtml namespace.



    The difference between HTMLDocument and Document (HTMLDocument carries pver all properties and methods of Document, so these are only the additional ones for HTMLDocument):

    properties:
    title, referrer, domain, URL, body, images, applets, links, forms, anchors, cookie
    methods:
    open, close, write, writeln, getElementsByName
    Last edited by liorean; 03-23-2003 at 01:25 AM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #13
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by liorean
    properties:
    title, referrer, domain, URL, body, images, applets, links, forms, anchors, cookie
    methods:
    open, close, write, writeln, getElementsByName
    Doesn't look like anything I'll miss; nothing useful that can't be done some other way (unless you count being able to open windows as useful, which I don't)

    But a couple of things sprang into my mind that might be problems -

    - how do you refer to a cookie? Can you not refer to cookies in XML DOM?

    - how do you deal with radio controls if there's no name? You can't, surely, have multiple radios with the same ID??

  • #14
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by liorean
    I have no knowledge of how saf/konq handles xhtml as xml
    It handles .xhtml pages served as application/xhtml+xml I don't know after that.

  • #15
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeå, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Originally posted by brothercake
    Doesn't look like anything I'll miss; nothing useful that can't be done some other way (unless you count being able to open windows as useful, which I don't)
    This is document.open, not window.open. This means you still can open windows, but you can't open a stream for writing sourcecode to the document.

    But a couple of things sprang into my mind that might be problems -

    - how do you refer to a cookie? Can you not refer to cookies in XML DOM?
    W3C felt like cookies weren't really part of the document. Browsers can handle them any way they wish, which includes adding the cookies property to the Document interface.

    - how do you deal with radio controls if there's no name? You can't, surely, have multiple radios with the same ID??
    You'll have to filter out the name attributes, like you'll have to sort out the type attributes, by regular DOM methods. As xml doesn't specify either a specific CLASS, NAME or ID type of attribute you'll simply have to check the elements for them. Same goes for #id and .class in css. Besides, getElementsByName was so inconsistent across browsers that you couldn't use it anyway.
    Last edited by liorean; 03-23-2003 at 12:18 PM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

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