Re: insert text dynamically into textarea

On Jul 23, 1:23 am, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
David Mark said the following on 7/22/2007 7:09 PM:





On Jul 22, 6:45 pm, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
David Mark said the following on 7/22/2007 2:00 PM:

On Jul 21, 9:48 pm, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
David Mark said the following on 7/21/2007 3:41 PM:
On Jul 21, 2:22 am, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
David Mark said the following on 7/20/2007 2:54 PM:
One Dumm Hikk wrote:
On Jul 18, 2:05 pm, "David Mark" <dm...@xxxxxxxxxxx> wrote:
"cyprian" <cyprian.ek...@xxxxxxxxx> wrote in message
news:1184771520.008461.269050@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<snip>

<snip that probably isn't proper>

I am sure you understand the value of having content in XML as most
of the Web understands RSS (for example.)
And you have not seen me say differently. We are not discussing XML, we
are discussing XHTML and - directly - it's use as a language on the Web.
As I am sure you know, XHTML is XML. That's the whole point. Just
like RSS and XHTML Basic are XML. You can easily transform one flavor
into another, but you can't efficiently transform HTML into anything
useful.
That is why I don't store static HTML. To do that is idiotic if you want
to transform it.

So what do you store then? I assume XML, which would mean your server
has to transform it to HTML with each request.

Actually, there are very very few HTML files on the Intranet server that
I use. Most of the data is stored in a database and creates .js files on
the fly. Everything in the system was designed with two things in mind -
speed and server load. The more I can make the client machine do then
the less my server has to do. Switching to the current back end system
(the front end looks almost identical to the old version) took almost 3
years and more hours of work than I care to remember. It has sped up my
Intranet almost 10-fold by moving the processing load from the server to
the client machine.

What do JS files have to do with the XHTML vs. HTML discussion?


The public website is slowly being migrated to the same system of using
.js files loaded on the fly. I have found it to be simpler, more
reliable, and quicker than trying to make XHR requests and deal with the
response. The major issue with the website being migrated is the lack of
support and problems with loading .js files on mac platforms and some of
the older legacy PC browsers. If, and when, the support becomes more
available on mac browsers and the legacy PC browsers are finally dead
and gone, the website will be switched to the same system as well.

As for transforming XML to HTML, you might try looking at the
process.wsf file and the index.xml file that is used to create this very
groups FAQ. Edit the xml file, run the process.wsf file, and it creates
the HTML file on the fly for you. So no, I don't buy into the "Its
easier to transform XML to XHTML than HTML" argument.

That wasn't my argument. Of course you transform XML into HTML. What
is silly is transforming XHTML into HTML, when you could just send the
XHTML.


<snip>

It seems to me that the real concern of the "XHTML is harmful on the
Web" crowd is that 90% of the authors don't know what it is. But that
is not my concern.
<URL:http://www.spartanicus.utvinternet.ie/no-xhtml.htm>
Try it and the links in it......

I've seen many sites just like it. That particular one seems outdated
as it warns about Opera 7, which prefers HTML (not a problem if you
negotiate properly.) The latest Opera browsers prefer XHTML.

While it is slightly outdated, the only information on that page that is
still outdated is indeed the warning about Opera 7. The other issues
that it brings up are still valid issues for not serving XHTML on the
web though. If you want to serve XHTML on the web, by all means do so.
Just don't expect to push it here in comp.lang.javascript without being

I don't push anything in here. I think the original discussion arose
from some silly tag line of yours that insulted anyone and everyone
who used XHTML on the Web. So don't expect to do that without being
challenged. Or perhaps you can as I am growing weary of this whole
argument.


.

Relevant Pages

  • Re: XHTML vs HTML
    ... XHTML pages correctly) what are the benefits to coding now with XHTML ... we're talking about XML here. ... the information that HTML doesn't cut it anymore is nuts. ... into virtually *any* other data format. ...
    (microsoft.public.frontpage.programming)
  • Re: XHTML vs HTML
    ... If you can't raionally argue why XHTML should or should not be persued and ... we're talking about XML here. ... the information that HTML doesn't cut it anymore is nuts. ... into virtually *any* other data format. ...
    (microsoft.public.frontpage.programming)
  • Re: XHTML vs HTML
    ... to be the predominant type of HTML used on the web for many years yet. ... First, it is XML. ... XHTML is also ... transformed using XSL from and into virtually *any* other data format. ...
    (microsoft.public.frontpage.programming)
  • Re: HTML vs XHTML
    ... As to why HTML 5 is bogus, rather than Hixie's attitude being bogus... ... XHTML is currently problematic because of transitory issues ... _lightweight_ components are all based around XML, ... training, skill and competence out at large, not the spec itself. ...
    (comp.infosystems.www.authoring.html)
  • Re: insert text dynamically into textarea
    ... As I am sure you know, XHTML is XML. ... You can easily transform one flavor ... That is why I don't store static HTML. ...
    (comp.lang.javascript)