[Reading this email back again I have the impression I'm coming across as rather didactic and patronising - sorry if that's the case. I'm certainly being long-winded, but that's largely because I'm trying to avoid writing a conference talk at the moment!]
Bob Hanson wrote: > > > Toby White wrote: >> Bob Hanson wrote: >> >> No. Sorry. Reiterating my last email (which probably crossed paths >> with this one) the problem is that within the DOM model, you can't >> just pipe an arbitrary string to the browser in the hope that it's >> valid XHTML, and that the browser can do something with it. The >> browser will generate a DOM tree when it first parses the page >> (assuming the page is valid XML) which you can then dicky with >> to your heart's content, so long as you do it through the DOM >> interface - the browser won't parse isolated fragments of XHTML. > > I think you are fundamentally mistaken about that -- see below. (But, > really, I'm SURE you know more about this than I.) I'm not claiming to be an expert here - this is all self-taught! But I am sure about this. Passing arbitrary strings to an already-rendered webpage is not going to work for an XML/XHTML document. (It might well work for well-formed HTML-4.01 - but HTML is not XML) >> To put it another way, the browser parses valid XML documents - >> you're passing it a fragment of an XML document, which is >> meaningless without the context of a full document which might >> have namespace, DTDs, so on and so forth. How is the browser >> to know what "<applet>" means? > > I certainly do not intend to pass it an <applet> tag EVER. It knows > OBJECT; I'm happy with that. Sorry; bad example. Rephrase - how does it know what a <div> tag means? Answer - not at all, unless it's in a document which declares a DTD or schema of some sort, with maybe namespaces as well, to say "this is an XHTML document, therefore <div> has these semantics". [NB I can believe that in fact some browsers might let you do this - after all, it's fairly obvious what's intended. But I think it's fundamentally a misuse of XML technologies to try.] > Well, unless document.compatMode is lying, I'm not in quirks mode. Is > there another way of telling? From what I read, the browsers are smarter > than to rely on server headers for this. See > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp > > > under "doctype switch" I can't speak for IE, I'm afraid - I don't have access to it here, nor have I done any development using it, so it may be (indeed that page suggests) that IE is more smart. Nor was I intending to suggest that server-side mimetypes are the only way to force the browser to switch behaviour. I know it works for most of the browsers I've tried. And it seems to me the correct behaviour - if I want my browser to interpret a document as XML, I should tell it that I'm giving it an application/xml document. If I tell it I'm giving it text/html, then because there is so much broken html out there, the browser has no choice but to fall back into tag-soup mode, and make the best of what it's given - even if I have given it a well-formed document. As far as I can see, that's what mime-types were invented for - to provide metadata to describe the filetype. > far as I can tell, it works.... > I can't imagine what "XHTML mode" would be other than "strict standards > compliant mode" But I may have HTML 4.0 and XHTML confused here. > > I think what is really happeing is that the browser is taking the > strings and piping them into its HTML/DOM interpreter. It can do this on > the fly, as a page loads or alternatively with element.innerHTML(). In > both cases, a full DOM-based system is constructed. But even in tag-soup/quirks mode, a full DOM tree will be generated - that's how modern browsers work internally. The question is whether there's a direct translation from input to output, or whether the browser has had to fix up a few unclosed tags and out-of-place elements along the way. Once you've got a DOM tree, then you can manipulate it with JS DOM functions, of course. And clearly you're right over what the browser is doing. And if it can do that, it could do a document.write() as well - there's not really any difference. >> My current version is at http://www.uszla.me.uk/jmol/Jmol.js > > thanks. I look forward to seeing applications of this once you get it > further along. I'm really very interested in finding out how to test > this "XHTML mode" in IE or Firefox. > > to me what you > are doing with the DOM tree stuff is ensuring that if it works at all, > it is compliant. So there might be some advantage there. But what would > be the problem with letting the > browser do its work for me? > > I look at my DOM Inspector after clicking that link and the object node > and all the params are "suddenly" there. I can't imagine that I could do > all this dirty work any better than element.innerHTML(). Why would I > need to go to all that trouble, if the browser will do it for me? As I say, of course there's a DOM tree - that's how the browser represents the page internally. And if you'd passed it broken HTML in the innerHTML, it would probably work as well. Let me try and explain it a different way. Consider the problem you're having where you can't validate dynamic pages because you can't get the validator to see the dynamically-generated HTML. This is (a reflection of) precisely why this is not allowed for an XHTML browser - the browser can't guarantee that whatever it's being fed is going to nicely evaluate to a DOM tree. Therefore, it doesn't let you. If you think about it, what you want to do is not "insert an object tag into the document here"; what you want to do is "insert an object into the webpage here". And the webpage, to the browser, is not a XHTML document - the webpage is the visual representation of the DOM tree that the browser currently holds. So with XHTML, the browser is very friendly - it lets you manipulate the DOM tree directly, rather than having to try and generate a textual representation of the DOM tree, feed it to the browser, which then has to translate back into a DOM tree. It's actually trying to make your life easier. In return, however, it's asking you not to make it try and translate potentially-broken XML (strictly speaking, completely broken XML - fragments of XML do *not* make sense in isolation). Basically, a browser in XHTML mode is a vehicle for translating a well-formed, well specified XML document into a DOM representation; and then giving you a) a visual representation of said DOM tree and b) the ability to manipulate the DOM tree. But document.write() and innerHTML() functions simply don't fit into this interface. >> But you can have a look at the sort of thing I'm doing at >> http://www.uszla.me.uk/example/4CDF.xhtml > > > "not found" Sorry - http://www.uszla.me.uk/siesta/example/4CDF.xhtml -- Dr. Toby White Dept. of Earth Sciences, Downing Street, Cambridge CB2 3EQ. UK Email: <[EMAIL PROTECTED]> Tel: +44 1223 333464 Fax: +44 1223 333450 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
