David said:
Will it really? It has been suggested that because this period of
tag-soup HTML in the guise of XHTML is letting people authoring 'XHTML'
get away with all the abuses that they previously got away with in HTML
(because in reality they are still writing tag-soup HTML) if and when
Microsoft release a browser that 'supports' XHTML it will not have a
proper XML parser but instead a parser that second guesses and
error-corrects to the extent that they avoid having to field all the
complaints from people who's 'XHTML' that had been working with IE
suddenly stops working. So out of the window goes all the imposed
discipline of well-formed XML and valid mark-up and we are back to a
status-quo of "it works in IE so why shouldn't it work in other
browser?".
Version 7 almost had it, but they ran out of time at the end.
Yes, tag-souping XML is not going to be easy for them, and so not quick.
From what I have heard, version 8 will have an XML parser.
Given the 6 year interval between versions 6 and 7 promises of version 8
are not that encouraging.
However, the release of an IE versions that supports XHTML is not the
future that present-day author of HTML grounded web projects needs to be
'future-proof' against. What that release does is mark the point where
it becomes viable to start considering creating commercial XHTML only
projects. The future that an HTML only project needs to worry about is
the one where a major stops supporting HTML, presumably (in your vision
of the future) in favour of XHTML. My judgement would be that if that
future is going to happen at all it is so far off as to be beyond the
life expectancy of any web project being considered today. And if the
W3C end up releasing an HTML 5 that is back-compatible with HTML 4, and
it terns out that HTML5is (as intended) the language of choice for web
applications, then that future recedes even further into the distance.
Then there is the (possible) future of XHTML to consider. XHTML 2 is
supposed to be modular, and if it is modular it will need a radically
different DOM specification to accommodate/employ that. The current HTML
DOM applies to XHTML 1, and may only ever apply to XHTML 1. So you write
your XHTML/HTML DOM branching scripts today and by the time IE
introduces support for XHTML and you can weed out the HTML branches,
Mozilla/Firefox has introduced support for XHTML 2, and a new XHTML 2
DOM and you are back at square one, with as much maintenance work ahead
as you would have had if you had never attempted to be "future proof" in
the first place.
Future proofing is really a non-issue in the choice of XHTML or HTML,
and it may yet turn out to be a complete red-herring.
Yes I know. I have a library that deals with this issue.
Most people don't, and really could not justify the learning,
development and testing time needed to create one, nor the code bloat,
increased maintenance costs and performance hit that would go along with
one.
That's why I only use createElement when not in XML mode.
And so knowing that you are in "XML mode" means testing for that, and
branching.
The wrappers that deal with this aren't particularly complex.
But they must be more complex than not having them at all. A strategy of
writing HTML mark-up, serving it as text/html and scripting the
resulting HTML DOM is inherently simpler. Granted writing XHTML, serving
it as application/xhtml+xm and scripting the XHTML DOM would be as
simple, but it is not yet a commercially viable option. But messing
around trying to do both, and the right one at the right time, is (and
has got to be) more complex, more error prone, and so more expensive and
less successful. KISS is a nice principle to follow.
XHTML is already here and quite useful if you know how to exploit it.
XHTML brings nothing that cannot be achieved by other means.
Granted, it isn't for everybody.
Yes, it is not for commercial web work where IE support is required.
That is not everyone, but it is certainly most of us.
Not me. I serve the XHTML type to browsers that claim to accept it.
Do you mean all browsers that claim to accept it, or just those that
either express a preference for it over HTML or an equivalent
preference? There were, for example, those early Opera 7 versions that
expressed a preference for HTML over XHTML because their XHTML DOMs
where incomplete/defective. They would render XHTML fine, but scripting
them was pretty much a non-starter (not least because they would not act
upon script elements in the mark-up).
It isn't complicated to do.
Complexity is, at least in part, a matter of perception. Applying
quality values to media ranges of varying specificity and coming to a
(correct) conclusion as to how what you have available best meats the
preferences asserted by the user-agent in its Accept headers is
certainly more complicated a problem than most would want to address if
they did not have to. And this leads to a situation were HTTP content
negotiation is abandoned in favour of the stupidly simplistic. That is,
a situation where inept developers do no more than search the Accept
header for the sub-string "application/xhtml+xm" and serve XHTML
whenever it appears. This is, of course, absolutely against the HTTP 1.1
and will result in XHTML being served to any browser that expresses its
rejection of XHTML (i.e. includes the sequence "application/xhtml+xm;
q=0" in its Accept header), and also means that User Agents expressing a
preference for HTML along side support for XHTML will be getting the
XHTML regardless.
It is at lest in part the prominence of this half-ass hack in the
"serving XHTML to browsers that support it" school that makes its
proponents look like they don't know what they are talking about. A am
assuming that when you say "it isn't complicated" you are referring to
real HTTP content negotiation not this nonsense, because talking of 'web
standards' and then throwing HTTP out of the window would be
unparalleled hypocrisy.
On another point with content negotiation; one of the obvious problems
with the dual XHTML/HTML DOM script is the testing and branching that
must go on inside the script to accommodate the two DOMs. That could be
avoided if the server could use the content-negotiation decision made
for the mark-up to serve one of two distinct scripts (for externally
referenced script resources). Unfortunately a script served with an
XHTML page has the same media types as a script served with an HTML
page, and the techniques that could otherwise have the different mark-up
types served different scripts just act to move the added complexity in
the script to the server doing extra work when serving it.
Of the major browsers, IE is the only one that gets text/html
and it has no problem with my pages. I do not convert them to proper
HTML for IE's benefit as it isn't necessary. IE couldn't
care less about the extra slashes, so why should I? And yes, I
have tested with lots of handheld devices, appliances, etc. Not
a one of them is a true SGML parser, so they don't care about the
extra slashes either. It seems the only outcry about those is
from those who are dead-set against dealing with XHTML.
The "outcry" about the slashes is about the way that their use makes
people think that they are writing (and by implication scripting) XHTML
when they are not. It really is best, in all cases, if people perceive
what they are doing as being what they are actually doing.
Look at the questions asked on this group. How often do you see someone
starting of with "I am writing XHTML" and then posting an HTML DOM
script that could never work with XHTML, even to the extent that they
say it does? Or starting with that and just asking how to do something,
when if you showed them an XHTML DOM script for the task you know they
will just go off and try it in IE and come back and say "your script
does not work", when you know dam well that in an XHTML DOM it will work
just fine.
Is it really too much to expect people to see the distinction between
XHTML and HTML? Or to expect that when they understand that they are
working exclusively with HTML they would then be then be using HTML
mark-up.
Of course as script authors we are in the fortunate position of being
able to say whether a document is HTML or XHTML without any ambiguity.
If it is an HTML document then the browser exposes and HTML DOM to be
scripted (regardless of the form of the mark-up used) and if it is an
XHML document (where supported) it is an XHTML DOM that is exposed to be
scripted, with sufficient distinctions between the two types of DOM that
nobody can be in any doubt as to which any given resulting DOM is.
Not for those people, no.
You haven't seen any of mine.
You are yet to post anything non-trivial.
Nothing at all. ...
It doesn't do anything.
What does nothing at all? Calls to - document.write - certainly do throw
exceptions in some XHTML DOMs. Because - document.write - is in the W3C
HTML DOM standard, which does apply to XHTML 1, we had a long discussion
a few years back about what XHTML DOMs should do with the calls, which
lead to testing the XHTML DOMs available at the time, and some threw
exceptions, while others did nothing, and still others omitted the
method entirely. The conclusion being the fairly obvious 'it is not even
worth trying to use - document.write - in an XHTML DOM'.
I agree with the second point, but I think anyone who uses it to
inject elements would be better off learning the standard
DOM-manipulation methods.
What makes you think that using - innerHTML - and knowing the DOM
manipulation methods are mutually exclusive? If it is mark-up that you
have to inject then writing an HTML parser that can create the
corresponding DOM fragment with the DOM manipulation methods and then
inserting it in an Element is a ridiculous effort to go to, and a
needlessly inefficient way of doing something that the browser could do
natively.
I would accept that transmitting fragments of mark-up for injection is
probably almost always a bad design decision, and so the vast majority
of cases where - innerHTML - is used to inject mark-up could, and
should, be avoided. And I am particularly unimpressed with designs where
this is carried through to the point where presentational (as opposed to
semantic) mark-up is being stored in the database for use in this
context.
As was mentioned, innerHTML is not standard and likely never
will be.
Microsoft would not implement any - innerHTML - standard that changed
what they have done historically (because they would not chose to break
half the world's Windows-based Intranets) so anyone trying to
standardise it has either got to define it as being precisely what IE
does or they may as well not waste their time. So, yes, it is never
likely to be standardised. On the other had, more browsers support -
innerHTML - (in one form or another) than support the W3C HTML DOM
standard.
Richard.
