Michael said:
As that is the XML namespace attribute (prefix), would you care to
suggest how it could be applicable to namespaces in HTML? On second
thoughts, don't.
Because W3C on second thought said that "HTML namespace no", "XHTML
namespace yes"? You can find these quotes too - and plenty of.
As I stated already: if you made your mind that namespaces are /not
allowed/ to be used in HTML, no matter /can/ they be used or not, then
simply don't use them, what's the problem? Same with <iframe> in HTML
Strict - don't use it, no problem. Use only higher blessed ways. I
don't want to put anyone's soul in troubles by forcing to commit
actions treated as sins in her/his religion.
:-|
I just can humbly ask (pretending for a second to stay on /your proper/
point of view): why did you decide that the posted code is HTML and not
XHTML?
Because it is served as text/html? It is not a criterion for local
files, and it is allowed for XHTML1.0
Because it has extension .html ? It is not a criterion, from the server
you can serve it w/o extension at all.
Because it doesn't have a prolog? It is not a requirement for a valid
XML if encoding is default UTF-8 or specified on a higher level. So
guess what: my server sends not just Content-Type: text/html\n but more
proper Content-Type: text/html;charset=iso-8859-1\n
Because it is not a well-formed XML? It is. Just remove the redundant
meta (we don't need it as the encoding is set by the server) and change
the extension to .xml - now validate it.
Other words you want to pass a strict division line between two matters
where at least one of them (XHTML) is not strictly defined to the
common consensus. If you believe it is then post this definition at
ciwah - it conveniently did not have intensive "XHTML with text/html"
discussions recently, so everyone is full of fresh energy I think.
The regular HTML supports namespaces - this fact can be checked on
practice by everyone by using say document.createElementNS method, even
leaving bindings out. So the discussion can be only about "can I use
the supported feature or it is morally wrong". I really don't want to
push any further on that, as someone's moral issues is definitely not
my business.
Technically I can make one more attempt to "bring the desires in a
harmony with (self-)imposed moral rules" (in case if anyone is willing
to use the proposed solution but s/he is afraid of sleepless nights
because of bad feeling after that) :-
Both binding and behavior are XML-conformant data sources used to
generate layer out content for the document-requestor. They are not
inserted directly into document. They are being parsed by XML parser
and the /result content/ is added into the document. This way it is not
more "illegal" than <script> with content-type "text/javascript" used
to insert text/html content into page (over say document.write); or
XML+XSL combo resulting in an HTML 4.01 page.
If W3C docs do not help and the possibility of sleepless nights is
really a matter, one can look at this from the point of view above.
For some value of 'working'.
It provides intended results on supported platforms and degrades
seamlessly to some predefined behavior for non-supported platforms,
where the degradation results do not prevent the document from
viewing/browsing. This result is not affected by script
enabled/disabled.
It is called "working" in its pure sense, w/o any "some value of",
"kind of" etc.
P.S. Keep in mind that in this very particular case the bottleneck is
not binding but MathML itself which is currently supported AFAIK by
Firefox only (Amaya out). On the regular run it covers IE5.5+,
Firefox1.0+, MozSuite, Camino1+, Netscape8+
Yet I readily accept the statement that it doesn't work for from 1 to
100 (and counting) not listed UA's Some of them I possibly never heard
about, but they all have in common that I do not care of any of them.
Still it always the question of particular demand and for some intranet
solution it may be required to have full MathML support for Safari 1.2
(that would be a challenge
P.P.S. That my last and best attempt on the theoretical matter. I
accept bets 1:10 that in three years from now a mention of XHTML will
raise a question "and what is it?", so whoever is theoretically right
now - it has no big importance anyway. It can be you - so be you.
P.P.P.S. The future can have all kind of surpises, so I better drop the
bet to 1:5