A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript, then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat: http://blog.outer-court.com/chat/
(And I was inspired by Google Suggest, which uses XMLHTTP.)
Of course, this can also be used for form validation and similar tasks. 50  4619 
Philipp Lenssen wrote: A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript,
document.innerHTML? Is there any browser giving anything else but
undefined for that expression?
I suppose you use element.innerHTML on an element node.
then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat:
http://blog.outer-court.com/chat/
It is not quite up to "international chat", I entered the Euro character
'€' and that was reflected as '%u20AC' then in the "bubble" with the
entered text. So while XML snippets should give you the possibility
using UTF-8 and using such characters literally and without conversion
problems in your app there seems to be a problem with that.
--
Martin Honnen http://JavaScript.FAQTs.com/
Philipp Lenssen wrote: A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript, then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat:
http://blog.outer-court.com/chat/
With Mozilla browsers this function
function checkKey(e)
{
var returnKey = 13;
var characterCode = -1;
if(e && e.which)
{
e = e;
characterCode = e.which;
}
else
{
e = event;
characterCode = e.keyCode;
}
if(characterCode == returnKey)
{
saidSomething();
}
return false;
}
causes error messages alike
Error: event is not defined
Source File: http://blog.outer-court.com/chat/dynamic.js
Line: 275
in the script console so you would need to change that to
function checkKey (evt)
{
var returnKey = 13;
var characterCode = -1;
evt = evt || window.event;
if (evt.keyCode) {
characterChode = evt.keyCode;
}
else if (evt.charCode) {
characterCode = evt.charCode;
}
else if (evt.which) {
characterCode = evt.which;
}
if(characterCode == returnKey)
{
saidSomething();
}
return false;
}
Crosspost/followup-to comp.lang.javascript.
--
Martin Honnen http://JavaScript.FAQTs.com/
Philipp Lenssen wrote: A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript, then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat:
http://blog.outer-court.com/chat/ (And I was inspired by Google Suggest, which uses XMLHTTP.)
That's fine for IE-specific limited-audience applications, and I've used
it, but it's useless for a broader audience. Look at the Google Suggest
code to see what hoops they jump through to find out first whether
XMLHTTP is even available. It looks like they probably have work-arounds
for each kind of browser, though I'm not going to take the time to
interpret their obfuscated code.
Of course, this can also be used for form validation and similar tasks.
It was somewhere outside Barstow when Martin Honnen
<ma*******@yahoo.de> wrote: document.innerHTML? Is there any browser giving anything else but
undefined for that expression?
If your browser has a hope of using XMLHTTP, then finding .innerHTML
or equivalent is easy.
I use this a lot, and have done so for years - but only for intranet
apps. It's pretty much unworkable for the www.
Philipp Lenssen wrote: A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript
Do you realise that innerHTML is a non-standard function and it *does
not* work in X(HT)ML documents (when they are parsed as XML, rather than
tag-soup). innerHTML may be convenient, but it is essentially useless
since there is nothing that it can do that cannot be achieved through
the standardised DOM methods. BTW, this really seems to be off topic
for an HTML group, try a scripting group instead.
--
Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
Martin Honnen wrote:
Philipp Lenssen wrote:
A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript,
document.innerHTML? Is there any browser giving anything else but
undefined for that expression? I suppose you use element.innerHTML
on an element node.
Well yeah, you are right, actually I'm using
var elm = document.getElementById("bla");
elm.innerHTML = "boo";
etc.
I don't know if document.innerHTML returns anything, I suppose it
could, but I didn't use it so far. then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat:
http://blog.outer-court.com/chat/
It is not quite up to "international chat", I entered the Euro
character '€' and that was reflected as '%u20AC' then in the "bubble"
with the entered text. So while XML snippets should give you the
possibility using UTF-8 and using such characters literally and
without conversion problems in your app there seems to be a problem
with that.
Yeah, thanks for letting me know and thanks for trying.
--
Google Blogoscoped http://blog.outer-court.com
Harlan Messinger wrote: Philipp Lenssen wrote: A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript, then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat:
http://blog.outer-court.com/chat/ (And I was inspired by Google
Suggest, which uses XMLHTTP.)
That's fine for IE-specific limited-audience applications
No, it works in Firefox too. So it's fine for IE- and Firefox-specific
audiences, which are not *that* limited. I wouldn't use it to display
first-aid information when you enter "heart stroke" into Google and I'm
the top result, but for a chat -- no problem.
and I've
used it, but it's useless for a broader audience. Look at the Google
Suggest code to see what hoops they jump through to find out first
whether XMLHTTP is even available. It looks like they probably have
work-arounds for each kind of browser, though I'm not going to take
the time to interpret their obfuscated code.
I wanted to write a clean and simple XMLHTTP script -- thank God I'm
not Google so if it works in 95% of popular browsers (or even 90%), I'd
be happy.
--
Google Blogoscoped http://blog.outer-court.com
Lachlan Hunt wrote: Philipp Lenssen wrote: A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript
Do you realise that innerHTML is a non-standard function and it *does
not* work in X(HT)ML documents (when they are parsed as XML, rather
than tag-soup). innerHTML may be convenient, but it is essentially
useless since there is nothing that it can do that cannot be achieved
through the standardised DOM methods. BTW, this really seems to be
off topic for an HTML group, try a scripting group instead.
"innerHTML" works fine in at least Windows Firefox and IExplorer. While
I usually avoid non-standard methods, this one -- outerHTML and
innerHTML -- is a really handy short-cut. You need it all the time and
I wish there'd be a simple way like that to have the same in basic XML.
--
Google Blogoscoped http://blog.outer-court.com
Philipp Lenssen wrote: Lachlan Hunt wrote:
Philipp Lenssen wrote:
A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript
Do you realise that innerHTML is a non-standard function and it *does
not* work in X(HT)ML documents (when they are parsed as XML, rather
than tag-soup).
"innerHTML" works fine in at least Windows Firefox and IExplorer.
No, it doesn't. Try serving your document as application/xhtml+xml to
Firefox and see what happens to your broken scripts with innerHTML. I
set up two test cases for your convenience. http://lachy.id.au/dev/script/exampl...L/innerHTML001 (HTML) http://lachy.id.au/dev/script/exampl...L/innerHTML002 (XHTML)
Check the Javascript Console to see what FF says about it. If you don't
have access to Firefox (or other Mozilla based browser) then this is
what the error message will state:
Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLElement.innerHTML]"
nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://lachy.id.au/dev/script/exampl...erHTML-test.js ::
test :: line 3" data: no]
In fact, it might be an idea to check the Javascript console anway to
see all those other scripting errors you've made in your chat system.
However, both tests do seem to succeed in Opera, though I'm not sure
why. Opera must treat anything set on the innerHTML property as
tag-soup, regardless of what the rest of the document is, and just
insert whatever DOM it creates from it. Regardless of that fact, it
still fails to work in Mozilla based browsers and is still a
non-standard extension that should not be used (As is XmlHttpRequest(),
though it is at least designed to work with XML).
--
Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
Lachlan Hunt wrote: Do you realise that innerHTML is a non-standard function and it *does
not* work in X(HT)ML documents (when they are parsed as XML, rather than
tag-soup).
In recent Operas and in recent Mozilla 1.8 nightlies you can set
innerHTML of XHTML elements in XHTML documents parsed as XML. You can
also read it but I think only Opera 8 beta then produces well-formed
XHTML while Mozilla doesn't. But there is work on that done:
<https://bugzilla.mozilla.org/show_bug.cgi?id=133827>
<https://bugzilla.mozilla.org/show_bug.cgi?id=155723>
As that is rather off-topic in ciwah followup-to set to
comp.lang.javascript.
--
Martin Honnen http://JavaScript.FAQTs.com/
Lachlan Hunt wrote: Philipp Lenssen wrote: Lachlan Hunt wrote:
Philipp Lenssen wrote:
> A nice way to dynamically update HTML on a page (without
> leaving the page) is to use document.innerHTML and XMLHTTP in
> JavaScript
Do you realise that innerHTML is a non-standard function and it
*does not* work in X(HT)ML documents (when they are parsed as
XML, rather than tag-soup).
"innerHTML" works fine in at least Windows Firefox and IExplorer.
No, it doesn't. Try serving your document as application/xhtml+xml
to Firefox
Wait, I never serve my XHTML as "application/xhtml+xml" -- because
AFAIK that breaks IE.
--
Google Blogoscoped http://blog.outer-court.com
Philipp Lenssen wrote: Harlan Messinger wrote:
Philipp Lenssen wrote:
A nice way to dynamically update HTML on a page (without leaving the
page) is to use document.innerHTML and XMLHTTP in JavaScript, then
communicate with the server via XML snippets (plus some server side
scripts of course, I use PHP5+MySQL). If you want to see an example,
you can take a look at my chat:
http://blog.outer-court.com/chat/ (And I was inspired by Google
Suggest, which uses XMLHTTP.)
That's fine for IE-specific limited-audience applications
No, it works in Firefox too.
Honestly??? I thought that Firefox was a cross-OS browser. I didn't
think its Javascript implementation would include Microsoft-specific
extras like ActiveX automation. Interesting.
Harlan Messinger wrote: Philipp Lenssen wrote: Harlan Messinger wrote:
Philipp Lenssen wrote:
> A nice way to dynamically update HTML on a page (without
> leaving the page) is to use document.innerHTML and XMLHTTP in
> JavaScript, then communicate with the server via XML snippets
> (plus some server side scripts of course, I use PHP5+MySQL). If
> you want to see an example, you can take a look at my chat:
> http://blog.outer-court.com/chat/ (And I was inspired by Google
> Suggest, which uses XMLHTTP.)
That's fine for IE-specific limited-audience applications
No, it works in Firefox too.
Honestly??? I thought that Firefox was a cross-OS browser. I didn't
think its Javascript implementation would include Microsoft-specific
extras like ActiveX automation. Interesting.
I guess they realized it was the only proprietary thing that made
sense. Didn't you often find yourself doing XML, and just wishing for
an easy-to-use "innerXML" function?
And yes, honestly. I always use Firefox, and the chat does work :)
--
Google Blogoscoped http://blog.outer-court.com
Philipp Lenssen wrote: Wait, I never serve my XHTML as "application/xhtml+xml" -- because
AFAIK that breaks IE.
Will you never serve it as such in the future?
Why are you using XHTML if you never serve it as such?
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Harlan Messinger wrote: Honestly??? I thought that Firefox was a cross-OS browser. I didn't
think its Javascript implementation would include Microsoft-specific
extras like ActiveX automation.
The Firefox / Opera / Safari implementation of HttpRequest is not ActiveX
based. http://jibbering.com/2002/4/httprequest.html
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Philipp Lenssen wrote: Lachlan Hunt wrote:Philipp Lenssen wrote:"innerHTML" works fine in at least Windows Firefox and IExplorer.
No, it doesn't. Try serving your document as application/xhtml+xml
to Firefox
Wait, I never serve my XHTML as "application/xhtml+xml" -- because
AFAIK that breaks IE.
Then why use XHTML at all? If you're not going to use it properly, why
not just stick with HTML 4.01?
--
Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
David Dorward wrote: FAIK that breaks IE.
Will you never serve it as such in the future?
Why are you using XHTML if you never serve it as such?
David Dorward <http://blog.dorward.me.uk/>
Why do you?
I prefer XHTML for a variety of reasons. First of all because I prefer
XML-style syntax. Second of all because I can spit it out easier with
tools which spit out XML. Third, because it is more strict in its
validation, and I always preferred e.g. "<p>...</p>" to "<p>...", even
when latter was allowed in HTML4. Fourth, because it's the most recent
HTML suggestion by the W3C, and I like to tinker with what's good and
modern. 5th, because I don't see any downside to it, so I don't even
need any other reason than 1 to begin with...
--
Google Blogoscoped http://blog.outer-court.com
Lachlan Hunt wrote: Philipp Lenssen wrote: Lachlan Hunt wrote: Philipp Lenssen wrote:
> "innerHTML" works fine in at least Windows Firefox and
> IExplorer.
No, it doesn't. Try serving your document as
application/xhtml+xml to Firefox
Wait, I never serve my XHTML as "application/xhtml+xml" -- because
AFAIK that breaks IE.
Then why use XHTML at all? If you're not going to use it properly,
why not just stick with HTML 4.01?
(Just answered that in the same thread to another curious person...
it's great to see this newsgroup never changed...)
--
Google Blogoscoped http://blog.outer-court.com
Philipp Lenssen wrote: Why are you using XHTML if you never serve it as such?
Why do you?
1. I do serve it as such - my CMS is just broken at present so my insurance
against non-well-formed documents isn't in place.
2. The CMS which I used to use for that site spat out XHTML and, short of
hacking the source, wouldn't be persuaded to use HTML.
Third, because it is more strict in its validation
Interesting myth.
<a href="foo"><b><a href="bar">foo</a></b></a>
That code fragment is valid in XHTML, but not in HTML.
, and I always preferred e.g. "<p>...</p>" to "<p>...", even
when latter was allowed in HTML4.
Nothing stopping you validating against a custom DTD that required end tag
on all non-empty elements (and then switching to a real HTML DTD for
publishing).
Fourth, because it's the most recent HTML suggestion by the W3C, and I
like to tinker with what's good and modern.
If you are going to count XHTML 1.0 as an HTML suggestion, then the more
recent is XHTML 1.1 - of course that "SHOULD NOT" be served as text/html at
all.
5th, because I don't see any downside to it, so I don't even
need any other reason than 1 to begin with...
How about ">" characters being rendered after every image, line break and
horizontal rule in browsers which get HTML right (like W3-mode)?
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
David Dorward wrote: Philipp Lenssen wrote:
Why are you using XHTML if you never serve it as such? Why do you?
1. I do serve it as such - my CMS is just broken at present so my
insurance against non-well-formed documents isn't in place.
2. The CMS which I used to use for that site spat out XHTML and,
short of hacking the source, wouldn't be persuaded to use HTML.
Third, because it is more strict in its validation
Interesting myth.
<a href="foo"><b><a href="bar">foo</a></b></a>
That code fragment is valid in XHTML, but not in HTML.
Yeah, but usually it's the other way around. Like the example I gave.
Or AFAIK cross-nesting. URL-quotes. These are all things I simply want
to do in just one way and not think about.
, and I always preferred e.g. "<p>...</p>" to "<p>...", even
when latter was allowed in HTML4.
Nothing stopping you validating against a custom DTD that required
end tag on all non-empty elements (and then switching to a real HTML
DTD for publishing).
Yeah, but why should I when there's no problem with using XHTML. That
would be really annoying.
--
Google Blogoscoped http://blog.outer-court.com
in comp.infosystems. www.authoring.html, Philipp Lenssen wrote: David Dorward wrote:
Philipp Lenssen wrote:
Third, because it is more strict in its validation
Interesting myth.
<a href="foo"><b><a href="bar">foo</a></b></a>
That code fragment is valid in XHTML, but not in HTML.
Yeah, but usually it's the other way around.
But worse than that example?
Like the example I gave.
You mean no end tags? Well, that is of course because such tags are not
needed in HMTL. Same with quote rules for attributes. If you by cross
nesting mean <b><i></b></i>, it is forbidden in both.
But validator don't notice, if you have <img/> or <img></img> in your
XHTML. These, and other valid XHTML constructs cause problems on
browsers. There is no validator that would check if your XHTML is
Appendix C comforming.
(of course, there is these browser bugs conserning elements without end
tags, but they are rarely problem, andthere is bugs for xhtml as well.)
, and I always preferred e.g. "<p>...</p>" to "<p>...", even
when latter was allowed in HTML4.
Nothing stopping you validating against a custom DTD that required
Yeah, but why should I when there's no problem with using XHTML.
That is just because you don't admit problem with XHTML.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
In article <38*************@individual.net>,
"Philipp Lenssen" <in**@outer-court.com> wrote: Second of all because I can spit it out easier with
tools which spit out XML.
IME, hacking an XML serializer to do Appendix C takes more time than
writing an HTML-emitting (XHTML event-absorbing) SAX serializer from
scratch. YMMV, of course.
--
Henri Sivonen hs******@iki.fi http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
David Dorward wrote: Third, because it is more strict in its validation
Interesting myth.
<a href="foo"><b><a href="bar">foo</a></b></a>
That code fragment is valid in XHTML, but not in HTML.
More importantly, that can't be worked around, unless perhaps you
apply some great big heuristic analysis. , and I always preferred e.g. "<p>...</p>" to "<p>...", even
when latter was allowed in HTML4.
Nothing stopping you validating against a custom DTD
Far too much trouble! Just set OpenSP to warn when optional tags
are omitted. E.g. use Page Valet's "fussy" mode. Fourth, because it's the most recent HTML suggestion by the W3C, and I
like to tinker with what's good and modern.
If you are going to count XHTML 1.0 as an HTML suggestion, then the more
recent is XHTML 1.1 - of course that "SHOULD NOT" be served as text/html at
all.
Serving either as text/html means some serious risks. For example,
<script src="..."></script> will be reduced to <script src="..."/>
by XML-based tools. And that'll screw up completely in browsers
processing text/html. So you have to insert mod_xhtml to rewrite
your markup again, or run a maintenance nightmare by hand.
--
Nick Kew
Lauri Raittila wrote:
You mean no end tags? Well, that is of course because such tags are
not needed in HMTL. Same with quote rules for attributes. If you by
cross nesting mean <b><i></b></i>, it is forbidden in both.
You are right on that.
But validator don't notice, if you have <img/> or <img></img> in your
XHTML. These, and other valid XHTML constructs cause problems on
browsers. There is no validator that would check if your XHTML is
Appendix C comforming.
Sure, validation is just a first step, a basis, for good HTML. You can
do 52,000 valid things in HTML4/XHTML1/HTML3.2 that will cause problems
in browsers.
I wrote Yeah, but why should I when there's no problem with using XHTML.
That is just because you don't admit problem with XHTML.
Well, maybe you have problems with XHTML, and it's everybody's choice
to go for their favorite HTML flavor. I never said "go for HTML4" or
"go for XHTML1", the only thing I propagate -- if asked by newbies --
is "if you don't know anything at all, go for XHTML1, but you may as
well go for HTML4". You gotta start somewhere and sometimes people
starting out with HTML look for advice, and they don't care about
cross-nesting, they might care more about career choices. If you tell a
newbie "choose HTML4 and disgard XHTML" then that'd be telling more
about you then the difference between the two flavors. Just my opinion.
--
Google Blogoscoped http://blog.outer-court.com
Henri Sivonen wrote: In article <38*************@individual.net>,
"Philipp Lenssen" <in**@outer-court.com> wrote:
Second of all because I can spit it out easier with
tools which spit out XML.
IME, hacking an XML serializer to do Appendix C takes more time than
writing an HTML-emitting (XHTML event-absorbing) SAX serializer from
scratch. YMMV, of course.
I wonder why it is that so many people here oppose XHTML, since, like
ever... is it because it introduced an imperfection by lying about its
content-type to be backwards-compatible? Is it because SGML needs be
defended? Because XML is getting bloated (oh yeah, it is, most
definitely)? Just curious, and this is not directed specifically at
your remark Henri -- more at the general tendency towards whoever
speaks out for XHTML.
--
Google Blogoscoped http://blog.outer-court.com
"Philipp Lenssen" <in**@outer-court.com> wrote: Sure, validation is just a first step, a basis, for good HTML.
Not really. Knowing the rules is the first step, playing by them is the
second one, and at some point, you might wish to use an automated
checker to verify that you have really played by the rules. A validator
does some checking in that respect; nothing more, nothing less.
Similarly, the first step for writing good English is not the use of a
spelling checker.
the only thing I propagate -- if asked
by newbies -- is "if you don't know anything at all, go for XHTML1,
but you may as well go for HTML4".
Then you propagate wrong advice. It's just the opposite: if you know
what XHTML is (and what it is not), then you might as well use it,
though normally you have no reason to do so. If don't know anything at
all, use HTML 4.01 and avoid all the confusion around HTML vs. XHTML
(you will have enough problems with Strict vs. Transitional as well as
HTML itself, and CSS).
Knowing what XHTML is includes both the theoretical side (such as
basics of XML) and the practical side, especially the Content-Type
confusion and Appendix C. Also remember that <?xml ...> is officially
recommended, yet throws IE into quirks mode. Why would you encourage
novices into getting into that mess?
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Philipp Lenssen" <in**@outer-court.com> wrote: I wonder why it is that so many people here oppose XHTML
There have been countless discussions on this topic over the years, the
archives are available to you. I listed some arguments at http://www.spartanicus.utvinternet.ie/no-xhtml.htm in the hope of not
having to repeat the same discussion here over and over again.
--
Spartanicus
Jukka K. Korpela wrote: "Philipp Lenssen" <in**@outer-court.com> wrote:
Sure, validation is just a first step, a basis, for good HTML.
Not really. Knowing the rules is the first step, playing by them is
the second one, and at some point, you might wish to use an automated
checker to verify that you have really played by the rules. A
validator does some checking in that respect; nothing more, nothing
less.
Similarly, the first step for writing good English is not the use of
a spelling checker.
Of course. I should "a basis for good HTML after you initially wrote
it, with a clue." But even then, I use a spell-checker before I further
proofread my text and edit for clarity, e.g. in my blog -- I want to
get the necessary no-brainer problem out of the text after I wrote it.
Expanding your example I could say the first step is not knowing the
rules, but understanding logic, or knowing English, or being born unto
this planet, etc., which must all come first. In any case, that'd be
splitting hairs.
the only thing I propagate -- if asked
by newbies -- is "if you don't know anything at all, go for XHTML1,
but you may as well go for HTML4".
Then you propagate wrong advice. It's just the opposite: if you know
what XHTML is (and what it is not), then you might as well use it,
though normally you have no reason to do so. If don't know anything
at all, use HTML 4.01 and avoid all the confusion around HTML vs.
XHTML (you will have enough problems with Strict vs. Transitional as
well as HTML itself, and CSS).
I don't see any confusion. I think the confusion is largely being
created by telling people XHTML contains these big problems. I don't
think so. If you think of XHTML1 as XML, and then complain about the
XMLish side-effects (content-type, bloat), then you might as well think
of HTML4 as SGML, and SGML is also rather complex.
Knowing what XHTML is includes both the theoretical side (such as
basics of XML) and the practical side, especially the Content-Type
confusion and Appendix C. Also remember that <?xml ...> is officially
recommended, yet throws IE into quirks mode. Why would you encourage
novices into getting into that mess?
Just omit the XML declaration then! No problem.
--
Google Blogoscoped http://blog.outer-court.com
Spartanicus wrote: "Philipp Lenssen" <in**@outer-court.com> wrote:
I wonder why it is that so many people here oppose XHTML
There have been countless discussions on this topic over the years,
the archives are available to you. I listed some arguments at
http://www.spartanicus.utvinternet.ie/no-xhtml.htm in the hope of not
having to repeat the same discussion here over and over again.
I didn't say "I wonder what people here said against XHTML". I'm a
follower of this group for many many years. I said "I wonder *why*"
people bring up all these arguments, and simply reading the archives
won't explain this -- as in, the psychological phenomonen. It's more of
a religious war -- SGML vs XML -- than anything else. You can construct
problems to dismiss either approach, but I don't see all those
problems. I get along *fine* with XHTML in the real-world: we use it at
work, we teach it to new people asking for advice, we spit it out using
transformations, etc. etc. It's simply *easier* to think of HTML as a
kind of XML, especially when you work with XML all day long (and use
its syntax everywhere else) -- it is by no means complicated to
remember the 3 or 4 rules needed to make XHTML backwards-compatible
(like omitting the declaration, using a space before a leading slash,
etc.)
--
Google Blogoscoped http://blog.outer-court.com
"Philipp Lenssen" <in**@outer-court.com> wrote: Then you propagate wrong advice. It's just the opposite: if you
know what XHTML is (and what it is not), then you might as well
use it, though normally you have no reason to do so. If don't know
anything at all, use HTML 4.01 and avoid all the confusion around
HTML vs. XHTML (you will have enough problems with Strict vs.
Transitional as well as HTML itself, and CSS).
I don't see any confusion.
The confusion is there, whether you see it or not. There are some rules
for what XHTML is, and serious practical considerations that say
something quite different. Where would you start from, as a novice?
I think the confusion is largely being
created by telling people XHTML contains these big problems.
Oh really. People run into the problems and then come here and ask for
help. It was lack of knowledge of what XHTML is (and using XHTML just
because someone told it's "modern" or "the current recommendation")
that created the problems, not knowledge.
If you think of XHTML1 as XML, and then complain
about the XMLish side-effects (content-type, bloat), then you might
as well think of HTML4 as SGML, and SGML is also rather complex.
SGML is surely complex, but nobody really teaches or learns classic
HTML on a purely SGML basis.
With XHTML, it is different. XHTML _is_ XML, whether you like it or
not, in a very real sense. You can fool IE into seeing XHTML as classic
HTML, and you need to, but this _adds_ to the confusion, instead of
simplifying things. And if you are going to do your best to fool
browsers into seeing your XHTML as classic HTML, what was the big idea?
Just omit the XML declaration then! No problem.
So _you_ are saying that the authority of W3C should be ignored.
I agree with you here, but why should anyone believe us? And what _was_
the reason for recommending XHTML, then?
Besides, it's simply not feasible unless you author in a language that
can be written in pure ASCII. What would you do if your document needs
to contain lots of accented characters? Using character references or
entities just messes things up. Using 8-bit data in some ISO 8859 works
fine when you use classic HTML. So what about XHTML? When you omit the
XML declaration, you are implying UTF-8 (or UTF-16). Do you intend to
rely on a happy outcome of the resolution between different conflicting
declarations of the encoding (XML declaration, meta tag, HTTP header)?
The poor novice must be lost now. He has little way of undestanding how
browsers are _supposed_ to resolve it, and this in turn might deviate
from what they actually do.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Philipp Lenssen" <in**@outer-court.com> wrote: > I wonder why it is that so many people here oppose XHTML
There have been countless discussions on this topic over the years,
the archives are available to you. I listed some arguments at
http://www.spartanicus.utvinternet.ie/no-xhtml.htm in the hope of not
having to repeat the same discussion here over and over again.
but I don't see all those
problems. I get along *fine* with XHTML in the real-world
I hope that you have managed to avoid the practical problems and can
work within the restrictions, this doesn't mean that there are no
problems with using xhtml.
we teach it to new people asking for advice
Something tells me that you don't educate new people on the associated
problems.
--
Spartanicus
"Philipp Lenssen" <in**@outer-court.com> posted: I get along *fine* with XHTML in the real-world
It doesn't matter what works for the author, it's what works for the
browser that's more important. And XHTML doesn't work properly for many
browsers. Know that it *does* that, the *why* is less important, as we
can't do anything to fix up the browser.
--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.
This message was sent without a virus, please delete some files yourself.
In article <39*************@individual.net>,
"Philipp Lenssen" <in**@outer-court.com> wrote: Henri Sivonen wrote:
In article <38*************@individual.net>,
"Philipp Lenssen" <in**@outer-court.com> wrote:
Second of all because I can spit it out easier with
tools which spit out XML.
IME, hacking an XML serializer to do Appendix C takes more time than
writing an HTML-emitting (XHTML event-absorbing) SAX serializer from
scratch. YMMV, of course.
I wonder why it is that so many people here oppose XHTML, since, like
ever...
So you see my comment about writing serializers as a comment opposing
XHTML? :-)
I do not believe the "XML tools" argument, because I have a actually
produced HTML with XML tools. I have also sorted out a problem caused by
serving XHTML produced with off-the-shelf XML tools as text/html. I have
co-authored an HTML serializer[1]. Been there, done that, wrote a
paper[2]. :-) I have also modified an XML serializer that was supposed
to be XHTML-compatible to actually be more compatible with text/html.
When people invoke the "XML tools" argument, I tend to assume they
haven't looked into the Appendix C issues with arbitrary XML tools or
haven't considered how easy it is to stick an HTML serializer at the end
of a SAX pipeline.
I encourage anyone writing server-side software to use XHTML internally,
but it does not follow that XHTML should be used as the text/html
on-the-wire serialization.
is it because it introduced an imperfection by lying about its
content-type to be backwards-compatible?
Yes, Appendix C snake oil is the problem.
XHTML served as text/html is a case of the emperor's new clothes. When
people are confused and ask for advice, I rather acknowledge that the
emperor is naked than claim that the new clothes offer "better living".
(Some people who feel a need to rationalize the nakedness like to say
that it is actually good that the emperor is naked, because clients
always like newer clothes better).
People who try out the real XHTML (application/xhtml+xml) tend to take
their Appendix C-induced misguided assumptions with them and get even
more confused. That's why I have addressed the issue in the Mozilla Web
Author FAQ[3]. So Appendix C causes harm even on the real XML side. I
don't want the real XML side to be pulled down to the tag soup because
of Appendix C (and RSS) -induced misguidedness.
Is it because SGML needs be defended?
No, I feel no need to defend SGML, and I don't believe HTML is a genuine
application of SGML.
Because XML is getting bloated (oh yeah, it is, most
definitely)?
No, that's not it.
[1] http://hsivonen.iki.fi/HtmlSerializer.java
(Does not support inline scripts or styles. Use external ones.)
[2] http://hsivonen.iki.fi/cms/te/
[3] http://www.mozilla.org/docs/web-deve...html#xhtmldiff
--
Henri Sivonen hs******@iki.fi http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jukka K. Korpela wrote: "Philipp Lenssen" <in**@outer-court.com> wrote: If you think of XHTML1 as XML, and then complain
about the XMLish side-effects (content-type, bloat), then you might
as well think of HTML4 as SGML, and SGML is also rather complex.
SGML is surely complex, but nobody really teaches or learns classic
HTML on a purely SGML basis.
I wouldn't teach XHTML as plain XML application, either. I recently
tought XHTML + CSS to someone with no HTML knowledge, and I didn't
start with the history of SGML, XML content-type problems, or anything
else. It simply isn't relevant at that stage, and in most other
contexts. It is a matter of style, and both dialects bring their own
problems. I guess this issue can't be resolved, as much as the
Americans can't resolve "Republicans vs Democrats", and simply continue
to have both sides.
--
Google Blogoscoped http://blog.outer-court.com
Tim wrote: "Philipp Lenssen" <in**@outer-court.com> posted:
I get along fine with XHTML in the real-world
It doesn't matter what works for the author, it's what works for the
browser that's more important. And XHTML doesn't work properly for
many browsers. Know that it does that, the why is less important, as
we can't do anything to fix up the browser.
So, you're telling me HTML4 works properly for all browsers?
Are you serious?
--
Google Blogoscoped http://blog.outer-court.com
Henri Sivonen wrote: In article <39*************@individual.net>,
"Philipp Lenssen" <in**@outer-court.com> wrote:
is it because it introduced an imperfection by lying about its
content-type to be backwards-compatible?
Yes, Appendix C snake oil is the problem.
XHTML served as text/html is a case of the emperor's new clothes.
When people are confused and ask for advice, I rather acknowledge
that the emperor is naked than claim that the new clothes offer
"better living". (Some people who feel a need to rationalize the
nakedness like to say that it is actually good that the emperor is
naked, because clients always like newer clothes better).
People who try out the real XHTML (application/xhtml+xml) tend to
take their Appendix C-induced misguided assumptions with them and get
even more confused. That's why I have addressed the issue in the
Mozilla Web Author FAQ[3]. So Appendix C causes harm even on the real
XML side. I don't want the real XML side to be pulled down to the tag
soup because of Appendix C (and RSS) -induced misguidedness.
Is it because SGML needs be defended?
No, I feel no need to defend SGML, and I don't believe HTML is a
genuine application of SGML.
So, wouldn't that mean HTML was also naked (not being real SGML, as you
say)?
Again, for me the choice between XHTML and HTML is an arbitrary one. As
I said I prefer the style of always-closed p's, always-quoted
attributes, always using both attribute-name and attribute-value, and
having the same syntax as XML. Even if all modern browsers would handle
the propert content-type XML in XHTML content fine, I'm not sure I'd
use it, because I like the fact (X)HTML stayed backwards-compatible for
so long. That's why I also like CSS, because it doesn't create
backwards-compatibility problems. In these regards I think HTML and
XHTML are completely equal. I think it's BS if people say "XHTML is
more search engine friendly" or "leaner" or anything. I think it's
equally silly to say "avoid XHTML because there are problems". There
are *always* problems no matter what language you choose on the web.
--
Google Blogoscoped http://blog.outer-court.com
"Philipp Lenssen" <in**@outer-court.com> wrote: As
I said I prefer the style of always-closed p's, always-quoted
attributes, always using both attribute-name and attribute-value
I see that you didn't bother to read the resource I provided, it
dispells these bogus arguments.
--
Spartanicus
Spartanicus wrote: "Philipp Lenssen" <in**@outer-court.com> wrote:
As
I said I prefer the style of always-closed p's, always-quoted
attributes, always using both attribute-name and attribute-value
I see that you didn't bother to read the resource I provided, it
dispells these bogus arguments.
Yes, you suggest a custom DTD for HTML. I saw that argument. But why
would I if I don't have any problem with XHTML, neither do my visitors?
--
Google Blogoscoped http://blog.outer-court.com
Tim wrote: It doesn't matter what works for the author, it's what works for the
browser that's more important. And XHTML doesn't work properly for
many browsers. Knowing that it does that, the why is less important,
as we can't do anything to fix up the browser.
"Philipp Lenssen" <in**@outer-court.com> posted:
So, you're telling me HTML4 works properly for all browsers?
Are you serious?
It works a darn sight better than XHTML does... And we certainly know that
MSIE is totally incapable of browsing properly served XHTML. Improperly
served XHTML is a waste of time. Why bother creating XHTML is you're just
going to pretend that it's HTML?
--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.
This message was sent without a virus, please delete some files yourself.
Tim wrote: Tim wrote:
It doesn't matter what works for the author, it's what works for
the >> browser that's more important. And XHTML doesn't work
properly for >> many browsers. Knowing that it does that, the why is
less important, >> as we can't do anything to fix up the browser.
"Philipp Lenssen" <in**@outer-court.com> posted:
So, you're telling me HTML4 works properly for all browsers?
Are you serious?
It works a darn sight better than XHTML does... And we certainly
know that MSIE is totally incapable of browsing properly served
XHTML. Improperly served XHTML is a waste of time. Why bother
creating XHTML is you're just going to pretend that it's HTML?
I told why many times over in this thread. At least these are my
reasons. Your opinion might (and obviously does) differ.
--
Google Blogoscoped http://blog.outer-court.com
"Philipp Lenssen" <in**@outer-court.com> wrote: > As
> I said I prefer the style of always-closed p's, always-quoted
> attributes, always using both attribute-name and attribute-value
I see that you didn't bother to read the resource I provided, it
dispells these bogus arguments.
Yes, you suggest a custom DTD for HTML.
No, the document states:
There's nothing to stop an author from applying the same "strictness" to
HTML. This is purely down to the author, it doesn't need a stricter DTD.
And then it continues:
For those that like the idea that validation warns them if they for
example forget to close a paragraph element, it's not difficult to
validate using a custom HTML DTD that is as strict as the XHTML DTD.
I saw that argument. But why
would I if I don't have any problem with XHTML, neither do my visitors?
Yes we know, you've stuck your fingers in your ears whilst chanting
"don't want to know, don't want to hear", again this does not mean that
there are no problems.
--
Spartanicus
in comp.infosystems. www.authoring.html, Philipp Lenssen wrote: Jukka K. Korpela wrote:
"Philipp Lenssen" <in**@outer-court.com> wrote:
If you think of XHTML1 as XML, and then complain
about the XMLish side-effects (content-type, bloat), then you might
as well think of HTML4 as SGML, and SGML is also rather complex.
The difference is that biggest argument on using XHTML has been and is
that you can use XML tools (is there some other reason? I don't think so.
Pure XHTML browsers are of course XML tools). Practically nobody uses any
sgml tool exept validator for html.
I wouldn't teach XHTML as plain XML application, either. I recently
tought XHTML + CSS to someone with no HTML knowledge, and I didn't
start with the history of SGML, XML content-type problems, or anything
else.
That's sencible.
It simply isn't relevant at that stage,
Yes, but with HTML, it never comes relevant. If you tech XHTML, it either
will become relevant or you are teaching XHTML as if it was HTML. Latter
is far worse.
and in most other contexts. It is a matter of style, and both dialects
bring their own problems.
But XHTML has more problems, and no gain. If XHTML would have exluded
transitional, as well as done somthing to most broken parts of HMTL, it
would have been really useful, even with lots of problems, it would have
helped to actually change something. Now, it just another way to write
tagsoup.
I guess this issue can't be resolved, as much as the
Americans can't resolve "Republicans vs Democrats", and simply continue
to have both sides.
Yes, americans have 2 party system with 2 conservative rightwing parties.
That is strange, I agree. And it is strange that W3C released 2 variants
of same markup language that are not exactly same, but similar enaough to
creat lots of confusion. Neither option is best possible, but one is
better than other.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
in comp.infosystems. www.authoring.html, Philipp Lenssen wrote: Tim wrote:
"Philipp Lenssen" <in**@outer-court.com> posted:
I get along fine with XHTML in the real-world
It doesn't matter what works for the author, it's what works for the
browser that's more important.
Yes.
And XHTML doesn't work properly for many browsers.
For example, IE6 wont support it at all, gecko don't support fast
rendering on it, that most CHTML out there is not well formed but still
rendered...
Know that it does that, the why is less important, as
we can't do anything to fix up the browser.
So, you're telling me HTML4 works properly for all browsers?
Are you serious?
Of course not. But there is very little stuff that works better using
XHTML rather than HTML (I don't recall you giving any example. There is
some, of course, I know few, but they are minor, and easily avoided or
even unlikely to ever see them). There is lots of stuff that works worse
in XHTML than in HMTL.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
in comp.infosystems. www.authoring.html, Philipp Lenssen wrote: Again, for me the choice between XHTML and HTML is an arbitrary one. As
That is exactly why your choise is not good. You should not choose it
because you like to write it more. You don't suggest using Word to write
your webpages because it is easier to use, do you.
Even if all modern browsers would handle
the propert content-type XML in XHTML content fine, I'm not sure I'd
use it, because I like the fact (X)HTML stayed backwards-compatible for
so long.
So is there any reason why you use XHTML, rather than HTML, that are not
arbitrary?
That's why I also like CSS, because it doesn't create
backwards-compatibility problems.
Unfortunately, that was its aim, and has nothing to do with reality. It
is entirely possible to write good CSS that will create backwards
compatibility problems. Of course, that is for far future, when FF1 and
Opera 8 are called broken ones, instead NN4 and IE6.
In these regards I think HTML and XHTML are completely equal.
So, all example given how XHTML breaks this or that mean nothing?
I think it's BS if people say "XHTML is
more search engine friendly" or "leaner" or anything. I think it's
equally silly to say "avoid XHTML because there are problems". There
are *always* problems no matter what language you choose on the web.
Yes. But if you have choise between more and less problems, and you
choose the one with more problems, I don't think it is very good
decision. OF course, people do such, and much worse decisions all the
time.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Lauri Raittila wrote: in comp.infosystems.www.authoring.html, Philipp Lenssen wrote: Jukka K. Korpela wrote:
"Philipp Lenssen" <in**@outer-court.com> wrote:
> If you think of XHTML1 as XML, and then complain
> about the XMLish side-effects (content-type, bloat), then you
> might as well think of HTML4 as SGML, and SGML is also rather
> complex.
The difference is that biggest argument on using XHTML has been and
is that you can use XML tools (is there some other reason? I don't
think so. Pure XHTML browsers are of course XML tools). Practically
nobody uses any sgml tool exept validator for html.
Well, I stated many other arguments, actually this "easier to spit out"
is just a minor bonus. For me the difference boils down to a matter of
taste, or religion, like I've stated before. I was just wondering why
this newsgroup seems so much on just one side of the argument, because
if you read blogs, online tutorials, the W3C, and what-not, you'll get
a much different picture. People may say e.g. "You can't serve XHTML as
XML because of ... and this and that" etc. but they will not simply say
"Say no to XHTML" (well, the first time I saw a site saying that was
from a link posted here, and the site's visual design just makes an
argument against any kind of "pure HTML").
I wouldn't teach XHTML as plain XML application, either. I recently
tought XHTML + CSS to someone with no HTML knowledge, and I didn't
start with the history of SGML, XML content-type problems, or
anything else.
That's sencible.
It simply isn't relevant at that stage,
Yes, but with HTML, it never comes relevant.
It will become relevant in any case -- people will be reading about
XHTML, they will see the source of pages as XHTML, and they will see
job descriptions containing XHTML. You can't hide this technology from
people by teaching them HTML4.
and in most other contexts. It is a matter of style, and both
dialects bring their own problems.
But XHTML has more problems, and no gain. If XHTML would have exluded
transitional, as well as done somthing to most broken parts of HMTL,
it would have been really useful, even with lots of problems, it
would have helped to actually change something. Now, it just another
way to write tagsoup.
I've got a feeling the term Tag-soup is overused in this newsgroup. In
Germany we have a saying, and it has been adopted in English, and it's
"don't throw out the baby with the bathwater."
--
Google Blogoscoped http://blog.outer-court.com
Lauri Raittila wrote: Of course not. But there is very little stuff that works better using
XHTML rather than HTML (I don't recall you giving any example. There
is some, of course, I know few, but they are minor, and easily
avoided or even unlikely to ever see them).
I don't think there's *any* difference in these regards. Strict is
better than Transitional, but XHTML is not better than HTML. It's just
a matter of syntax. I think TBL would have done it in XML from the
beginning if not for political reasons (SGML had a big lobby). The only
thing I'm saying is that people shouldn't try to make newbies afraid of
XHTML in this newsgroup. And actually, I'm not even saying that
anymore; I can sort of live with the fact that happens here, and I'm
happy in back in the blogosphere, people have different views on the
issue.
--
Google Blogoscoped http://blog.outer-court.com
Lauri Raittila wrote: in comp.infosystems.www.authoring.html, Philipp Lenssen wrote:
Again, for me the choice between XHTML and HTML is an arbitrary
one. As
That is exactly why your choise is not good. You should not choose it
because you like to write it more. You don't suggest using Word to
write your webpages because it is easier to use, do you.
Even if all modern browsers would handle
the propert content-type XML in XHTML content fine, I'm not sure I'd
use it, because I like the fact (X)HTML stayed backwards-compatible
for so long.
So is there any reason why you use XHTML, rather than HTML, that are
not arbitrary?
Yes. XHTML1 in its style is much closer to the way I was writing HTML4
in the first place. E.g. I wrote a colorizer for my Netpadd web editor
program, and it simply only works with XHTML or XHTML-style-HTML --
parsing HTML, with all its optional thingies, was more complicated. Now
I'm sure you'll find 100 reasons why actually XHTML is more complicated
(mixed name-spaces, XSLT, ...), but if we keep it to real world usage
examples, I found XHTML much easier to parse (e.g., building a
validation tree without knowledge of the DTD -- simply impossible in
HTML because I don't know which end-tags are optional unless I
understand the DTD). That's why I also like CSS, because it doesn't create
backwards-compatibility problems.
Unfortunately, that was its aim, and has nothing to do with reality.
It is entirely possible to write good CSS that will create backwards
compatibility problems.
Are you referring to the "content" property?
Typically, CSS is quite backwards-compatible (in the sense that older
browsers ignore it, or can be made to ignore it). In these regards I think HTML and XHTML are completely equal.
So, all example given how XHTML breaks this or that mean nothing?
The W3C for XHTML1.0 suggests to use a backwards-compatible
content-type, so I did that, and that would be the biggest thing it
could break. By sticking to an HTML content-type, nothing big is
broken, except of course it might be a religious offense in a purist
way. I'm more pragmatic.
--
Google Blogoscoped http://blog.outer-court.com
in comp.infosystems. www.authoring.html, Philipp Lenssen wrote: Lauri Raittila wrote:
in comp.infosystems.www.authoring.html, Philipp Lenssen wrote:
Again, for me the choice between XHTML and HTML is an arbitrary
one. As
That is exactly why your choise is not good. You should not choose it
because you like to write it more. You don't suggest using Word to
write your webpages because it is easier to use, do you.
Even if all modern browsers would handle
the propert content-type XML in XHTML content fine, I'm not sure I'd
use it, because I like the fact (X)HTML stayed backwards-compatible
for so long.
So is there any reason why you use XHTML, rather than HTML, that are
not arbitrary?
Yes. XHTML1 in its style is much closer to the way I was writing HTML4
in the first place.
You just defined it as arbitrary reason on your last post.
E.g. I wrote a colorizer for my Netpadd web editor
program, and it simply only works with XHTML or XHTML-style-HTML --
parsing HTML, with all its optional thingies, was more complicated. Now
I'm sure you'll find 100 reasons why actually XHTML is more complicated
(mixed name-spaces, XSLT, ...), but if we keep it to real world usage
examples, I found XHTML much easier to parse (e.g., building a
validation tree without knowledge of the DTD -- simply impossible in
HTML because I don't know which end-tags are optional unless I
understand the DTD).
Yes. But there is and has been tools to do that since beginning. Editors
have had DTD support for years, or maybe decades. Sure it is easier to
write XML tools, but still makes no much argument for not serving real
html.
Unfortunately, that was its aim, and has nothing to do with reality.
It is entirely possible to write good CSS that will create backwards
compatibility problems.
Are you referring to the "content" property?
No (not only). There is huge number of stuff that don't work right in
most modern browsers (but work wrongly) - these will be problem of
backward compatibility of future. Then you will curse why on earth did
Opera 7 try to use inline-block, even if it never was able to do it
right... From futures perspective, CSS support of these browsers is
nothing, the problem is that they have bugs and thus cause backwards
compatibility problems.
There is also the problem of not having ability group CSS. So if your
browser supports something and not other thing, you end up bad results.
Typically, CSS is quite backwards-compatible
(in the sense that older
browsers ignore it, or can be made to ignore it).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exactly. But what you need to make it ignore?
In these regards I think HTML and XHTML are completely equal.
So, all example given how XHTML breaks this or that mean nothing?
The W3C for XHTML1.0 suggests to use a backwards-compatible
content-type, so I did that, and that would be the biggest thing it
could break.
Of course, you also need to avoid some perfectly valid constructs on your
XHTML.
By sticking to an HTML content-type, nothing big is
broken,
That is, becase broken browsers of past, with only one exeption, that was
not widely used.
except of course it might be a religious offense in a purist
way. I'm more pragmatic.
Using HTML is essentially practical aproach. I wouldn't use it if XHTML
was supported.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
"Philipp Lenssen" <in**@outer-court.com> writes: I think TBL would have done it in XML from the
beginning if not for political reasons (SGML had a big lobby).
In the beginning, there was procedural tagsoup
<http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Link.html>
(watch time stamp, but just babbling on is OK though, since this only
Usenet).
Pancho's windmill effort (RFC 1866) to make new clothes for his emperor
dates from 1995, and the first XML efforts date 1996 (the only relevant
T.B. there is not yet a Sir) if memory serves, and that's before the W3C
hijacked, pardon, adopted, it.
--
Hello world This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: fochie |
last post by:
Greetings,
I'm having a problem when I try to GET a file from my server
via xmlhttp when using Mozilla. With IE I can get any type of file
fine, get/display headers fine, etc. With Mozilla,...
|
by: Ike |
last post by:
Ive copied an online example for writing out a php file, programmatically,
then would like to re-display that data in a browswer window that
automatically refreshes as the data file (getdata.php,...
|
by: hatsumoto |
last post by:
Hello,
I create an ActiveXObject("Msxml2.XMLHTTP") from my HTML page to submit
(i.e. post) XML to a server.
I can see the content of the XML response via javascript
alert(xmlhttp.responseText)....
|
by: balakrishnan.dinesh |
last post by:
hi friends,
Exactly what i want to know is, In my product we are using
xmlhttp request to retrive some data from the server, And Im using IE
browser, its working fine in IE.
Now i want to work...
|
by: yawnmoth |
last post by:
<http://www.quirksmode.org/book/printable/xmlhttp.txtshows two
alternatives to Microsoft.XMLHTTP - Msxml2.XMLHTTP and Msxml3.XMLHTTP.
If my understanding is correct, the different numbers refer to...
|
by: wkerplunk |
last post by:
Below is what I have build with several different languages. It works great but I need help, I am stuck.
When you click on an item in the dropdown autocomplete div it does a mousedown function...
|
by: Andrewh |
last post by:
Hi,
I am having a bit of a problem with using xmlhttp. The code of the javascript file is shown below used in Windows XP.
var xmlhttp = null;
function SetURLDiv(url) {
if...
|
by: trpost |
last post by:
Is it possible to execute javascript as passed in xmlHttp.responseText
Here is what I am doing:
search.js
var xmlHttp
xmlHttp=GetXmlHttpObject()
var url="search.php"...
|
by: StevenS |
last post by:
Ok, I'm very new to AJAX programming, and fairly new to Javascript. (I was originally trained on low-level C programming.) I'm trying to build a simple AJAX routine in a file named ajax.js:
...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
