...

View Full Version : documentWrite in XHTML 1.1



gsnedders
10-21-2004, 11:03 PM
Just wondering how you would go about outputting something in XHTML 1.1 without using documentWrite (because you shouldn't)...

jbot
10-21-2004, 11:11 PM
Just wondering how you would go about outputting something in XHTML 1.1 without using documentWrite (because you shouldn't).

don't use XHTML 1.1. it's not supported by 90% of browsers, ie IE :rolleyes:

to output nodes, use DOM methods such as createElement and appendChild.

liorean
10-21-2004, 11:22 PM
Well, using document.getElementById, document.getElementsByTagName, document.createElement, document.createTextNode, node.replaceChild, node.appendChild, node.insertBefore, element.setAttribute.

I would try setting an id on the script tag if I wanted to replace it with the generated tree, similar to how document.write works.

gsnedders
10-21-2004, 11:25 PM
don't use XHTML 1.1. it's not supported by 90% of browsers, ie IE :rolleyes:

Never said I was serving it as XHTML 1.1 to all browsers... and why not develop for standards...


Thanks David

jbot
10-21-2004, 11:58 PM
Never said I was serving it as XHTML 1.1 to all browsers... and why not develop for standards.

well, davie, there is indeed nothing wrong with developing to standards. i never said anything to the contrary. but you simply can't develop an XHTML document for one browser and not for another. you might serve it up differently, using a different doc type and content type, but there's much more to XHTML than that.

for example, doing this "<br/>" will validate under XHTML, but not under HTML. so, while it may work in FF, etc, it won't work in IE - the marjority of users. the page might render, but it won't validate. also, HTML 4.01 is also a standard - in other words, standards don't just mean XHTML.

thus in order to serve up valide markup to both browsers you'd have to change more than just a few head elements.

read this: http://www.hixie.ch/advocacy/xhtml

brothercake
10-22-2004, 02:57 AM
Yeah read it, then forget about it

The first 4 of his 6 "specific problems" are circular arguments - if an author is aware of the difference then there's no reason not to serve the same XHTML in different ways. Developing like that avoids the issues of conversion to XML, because you already know what's going to happen.

The penultimate reason is fair enough, but moot I think - we know that most legacy browsers don't have a problem with XHTML, providing you add the space before self-closing tags. Nobody's going to come out with new legacy browser, and equally, nobody's gonna come out with a stricter HTML parser. I mean why would they? What use is it?


I strongly dislike the mini-movement back to HTML 4 that this article has spurned. Encouraging people to go back to an outdated technology because of a handful of preventable or utterly academic issues. What about the semantic web, and making it easier to aggregate content for yourself? Doesn't that rely on a baseline of XML formedness throughout the web?

XHTML is inherently better than HTML, even if it's served as tag soup, because it has XML formedness.

jbot
10-22-2004, 10:24 AM
What about the semantic web, and making it easier to aggregate content for yourself? Doesn't that rely on a baseline of XML formedness throughout the web?

XHTML is inherently better than HTML, even if it's served as tag soup, because it has XML formedness.


XHTML is not synonymous with semantic markup or well-formedness. you can do both with HTML 4.01. the fact that a lot of sites weren't was not down to the schema, but that the developers were themselves lazy.

hemebond
10-23-2004, 02:18 AM
XHTML is inherently better than HTML, even if it's served as tag soup, because it has XML formedness.HTML may be more lax in its strictness, but that does not mean it can't be as semantic or as well-formed as XHTML.

I myself have gone back to promoting the use of HTML because otherwise people are going to keep sending XHTML dosuments as HTML (these forums included), which is just plain wrong. There's nothing wrong with HTML when its used responsibly.

For the record, I use XHTML Strict for my system here at work, because I, and anyone else who requires access, use Mozilla Firefox.

brothercake
10-23-2004, 04:57 AM
HTML is never as well formed as XHTML - if your definition of "well-formed" is "complying with XML formedness" - which is what I was saying. You can't run XSL transformations on HTML, and you can't use an XML DOM parser to read it either. The web would be much better off if everything was XML, and XHTML 1 is a step towards that.

Now okay - I accept the falseness of any implied connection between semantic code and XHTML - HTML Strict can be just as semantic and non tag-soupy. But there's nothing actually wrong with content-negotiating and serving XHTML as text/html to browsers that can only handle it that way .... Well allright there is - it's broken - but that doesn't really matter, because error handling in known browsers is entirely predictable.

I think going back to HTML 4 is a retrograde step. I know there are plenty of people who feel strongly that's it's the right thing to do, but I strongly disagree, because ... well what? There's nothing really wrong with XHTML, and the convenience of working exclusively in that and having all browsers using a single document (served and then extended in different ways) is invaluable. I think it's plain silly to walk away from those benefits because of a handful of preventable or academic issues.

And even sillier to stop using it just because other people might copy but get it wrong - that's not your responsibility.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum