473,320 Members | 1,848 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

XHTML or HTML 4.01?

Hi,

I converted most (not all) of my pages at http://johnbokma.com/ to
XHTML. I thought this was just a small change from 4.01.

However someone stated quite vaguely that my pages are *not* XHTML since
when a UA requests a page and states that it can handle XML the server
still responds with a Content-type: text/html

I see that http://www.w3.org/TR/xhtml1/ does the same (Firebird)

So is this wrong or not?

"XHTML Documents which follow the guidelines set forth in Appendix C,
"HTML Compatibility Guidelines" may be labeled with the Internet Media
Type "text/html""

Seems to suggest that nothing *is* wrong...

Related questions:

I have read somewhere (lost link) that this is rendered sometimes in
some UA's:

<?xml version="1.0" encoding="UTF-8"?>

Should I configure Apache to do this (if possible) and is this posible
with virtual hosting?

What is a recommended encodig for mixed English/Dutch text?
If I use Dutch on a mainly English page should I use

<span lang="nl" xml:lang="nl">Nederlands</span> Dutch ?

(assuming that nl means Dutch) or do I misunderstand the use of lang?

Many thanks in advance,
Regards,

John

--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
Web site hints: http://johnbokma.com/websitedesign/ ~ ICQ 218175426

Jul 20 '05 #1
20 3245
John Bokma <po********@castleamber.com> wrote:
I converted most (not all) of my pages at http://johnbokma.com/ to
XHTML.
Wieso? Weshalb? Und vor allem: warum? Because "it's cool"?
I have read somewhere (lost link) that this is rendered sometimes in
some UA's:
<?xml version="1.0" encoding="UTF-8"?>
Should I configure Apache to do this (if possible) and is this posible
with virtual hosting?
See http://ppewww.ph.gla.ac.uk/~flavell/...ist.html#xhtml
What is a recommended encodig for mixed English/Dutch text?
ISO-8859-1
If I use Dutch on a mainly English page should I use
<span lang="nl" xml:lang="nl">Nederlands</span> Dutch ?
(assuming that nl means Dutch)
Yes.
or do I misunderstand the use of lang?


No.

--
Meanwhile at the Google Ranch ...
"I can't read this bloody site; it's all Falsh and JavaScrap."
"Forget it and move on! Still 2*718*281*828 pages to crawl."
Jul 20 '05 #2
Andreas Prilop wrote:
John Bokma <po********@castleamber.com> wrote:

I converted most (not all) of my pages at http://johnbokma.com/ to
XHTML.

Wieso? Weshalb? Und vor allem: warum? Because "it's cool"?


Nope. I rarely do something because "it's cool".

However, please explain why I should *not* convert to XHTML.
Should I configure Apache to do this (if possible) and is this posible
with virtual hosting?


See http://ppewww.ph.gla.ac.uk/~flavell/...ist.html#xhtml


Thanks, will read it.

[snip other answers]

Thanks!

Regards,
John

--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
Web site hints: http://johnbokma.com/websitedesign/ ~ ICQ 218175426

Jul 20 '05 #3
John Bokma <po********@castleamber.com> wrote:
However, please explain why I should *not* convert to XHTML.


XHTML 1.0 is equivalent to HTML 4.01. You don't gain anything from
presenting web pages in XHTML 1.0. If you don't have any _real_
needs to use XHTML, it is pointless to convert _existing_ _valid_
HTML-4 documents to XHTML 1.0.

--
http://www.unics.uni-hannover.de/nhtcapri/plonk.txt
Jul 20 '05 #4
Alan J. Flavell wrote:
On Tue, Jul 29, John Bokma inscribed on the eternal scroll:

However someone stated quite vaguely that my pages are *not* XHTML since
They don't conform to XHTML/1.1 recommendations, is probably what the
message was trying to tell you.


Ah, well I state version="1.0" so that sounds a bit weird..
So is this wrong or not?

"XHTML Documents which follow the guidelines set forth in Appendix C,
"HTML Compatibility Guidelines" may be labeled with the Internet Media
Type "text/html""


Then they are XHTML/1.0 compatibility mode in that case.


<?xml version="1.0" encoding="UTF-8"?>, so yes, I think so.
Seems to suggest that nothing *is* wrong... Depends what DOCTYPE you are claiming.
XHTML 1.0 Strict (see http://johnbokma.com/ for full DOCTYPE)
I have read somewhere (lost link) that this is rendered sometimes in
some UA's:

<?xml version="1.0" encoding="UTF-8"?>


True.


Anyone has a link with the UA's that do this?
Should I configure Apache to do this (if possible)


Configure Apache to do what, exactly? Do you mean delivering
text/html to agents which don't indicate that XHTML is acceptable?
Or are you asking about some other feature of HTTP, maybe the
"charset" attribute?


The latter, sorry of my unclear question.
What is a recommended encodig for mixed English/Dutch text?


Strictly speaking, encoding and language are supposed to be
independent of each other in (X)HTML. In practice, different
choices may be preferable, depending on various considerations.

If you want to go for XHTML, then it might be advisable to leave off
the <?xml thingy and allow XML to take its default of utf-8. Then


The entire <?xml...> thingy or just the encoding part?
it can be more compatible with non-XML browsers. But if you want
non-XML compatibility _and_ follow W3C recommendations then you can't
go past XHTML/1.0, and it's not entirely clear why one would choose
XHTML/1.0 in preference to HTML/4.01, since the current crop of
browsers can do HTML/4.01 at least as well, if not better, than
XHTML/1.0.


Ok, I thougt to have some advantages due to the strictness and well
formedness of XHTML vs HTML/4.01. I will look into the XHTML > 1.0
documentation for problems I can run into with the current set up.
If I use Dutch on a mainly English page should I use

<span lang="nl" xml:lang="nl">Nederlands</span> Dutch ?


Put the language attribute(s) on whatever element is appropriate to
the context. If there is no such element, then indeed the <span...>
element can serve your purpose. Is my advice.


Ok, than I understand this one correctly. Thanks.

Regards,
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
Web site hints: http://johnbokma.com/websitedesign/ ~ ICQ 218175426

Jul 20 '05 #5
Andreas Prilop wrote:
XHTML 1.0 is equivalent to HTML 4.01. You don't gain anything from

John Bokma <po********@castleamber.com> wrote: I thought my gain was that there is a much stricter syntax. I consider
it as perl with the -w option and use strict; but I might be wrong here.


If you start with valid HTML, then it's easy to automate adding the useful
syntax strictness (closing tags, attribute quotes, etc.) that XHTML is
supposed to provide.

But current browsers don't support XHTML unless you pretend that it's
really HTML (by following Appendix C and sending it as text/html). And even
then, XHTML only works because browsers don't parse HTML properly. See
http://hixie.ch/advocacy/xhtml for more info on this.
--
Darin McGrew, da***@TheRallyeClub.org, http://www.TheRallyeClub.org/
A gimmick car rallye is not a race, but a fun puzzle testing your
ability to follow instructions. Upcoming gimmick car rallye in
Silicon Valley: The Italian Rob (Saturday, August 2)
Jul 20 '05 #6
Darin McGrew wrote:
Andreas Prilop wrote:
XHTML 1.0 is equivalent to HTML 4.01. You don't gain anything from

John Bokma <po********@castleamber.com> wrote:
I thought my gain was that there is a much stricter syntax. I consider
it as perl with the -w option and use strict; but I might be wrong here.

If you start with valid HTML, then it's easy to automate adding the useful
syntax strictness (closing tags, attribute quotes, etc.) that XHTML is
supposed to provide.

But current browsers don't support XHTML unless you pretend that it's
really HTML (by following Appendix C and sending it as text/html). And even
then, XHTML only works because browsers don't parse HTML properly. See
http://hixie.ch/advocacy/xhtml for more info on this.


Thanks Darin, very clear. I consider going back to HTML/4.01. My XHTML
documents are correct but I don't want to:

"send back XHTML as application/xhtml+xml to UAs that support it, and as
text/html to legacy UAs."

since then I probably have to convince my host admin to change things
*if* possible with Apache.

And I don't expect IE to be a proper XML UA in the near (if ever) future...

Regards,
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
Web site hints: http://johnbokma.com/websitedesign/ ~ ICQ 218175426

Jul 20 '05 #7
Kris wrote:
In article <10***************@halkan.kabelfoon.nl>,
John Bokma <po********@castleamber.com> wrote:

I have read somewhere (lost link) that this is rendered sometimes in
some UA's:

<?xml version="1.0" encoding="UTF-8"?>
True.


Anyone has a link with the UA's that do this?

Worse, IE4.x/Mac shows a blank page when encountering this. A fair
reason to leave it out.


Thanks Kris, enough reason for me to fall back to HTML/4.01 since I want
to support 4.x browsers as much as possible, and a blank page is bad.

John

--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
Web site hints: http://johnbokma.com/websitedesign/ ~ ICQ 218175426

Jul 20 '05 #8
On Wed, Jul 30, John Bokma inscribed on the eternal scroll:
Then they are XHTML/1.0 compatibility mode in that case.
<?xml version="1.0" encoding="UTF-8"?>, so yes, I think so.


I think at this point you're confusing XML version 1.0 (which is what
the above says) and XHTML version 1.0 (which was what we were talking
about before).
XHTML 1.0 Strict (see http://johnbokma.com/ for full DOCTYPE)
OK then.
Should I configure Apache to do this (if possible)
.... Or are you asking about some other feature of HTTP, maybe the
"charset" attribute?


The latter, sorry of my unclear question.


My answer would be "yes", you should configure the server to put the
appropriate charset attribute onto the real HTTP Content-type header.

Note that this satisfies the relevant requirements of the Appendix C
compatibility appendix. You don't then have to mess with the <?xml...
thingy *and* <meta http=equiv... , as appendix C wants you to do in
the absence of an HTTP-protocol 'charset' attribute.
If you want to go for XHTML, then it might be advisable to leave off
the <?xml thingy and allow XML to take its default of utf-8.
I may have been over-cautious there. If you can set the real HTTP
header, then you can use the more traditional iso-8859-1 if you wish.
But note the other considerations explored in my checklist (Andreas
gave the URL already).
The entire <?xml...> thingy or just the encoding part?


The rule is that if the XML version is 1.0 (which it is), and the
coding can be determined by certain other rules (which you can check
for yourself when you're serious enough) then you may omit the whole
thing. The whole point was to avoid certain non-XHTML browsers from
displaying it as data, so I was showing how you may omit it entirely.
it can be more compatible with non-XML browsers. But if you want
non-XML compatibility _and_ follow W3C recommendations then you can't
go past XHTML/1.0, and it's not entirely clear why one would choose
XHTML/1.0 in preference to HTML/4.01, since the current crop of
browsers can do HTML/4.01 at least as well, if not better, than
XHTML/1.0.


Ok, I thougt to have some advantages due to the strictness and well
formedness of XHTML vs HTML/4.01.


That might be useful for _you_ in your various publishing processes,
but at the present state of play, once you send it out of your server
as text/html, it's going to get processed as tag-soup anyway, so I
don't see any benefit -in that sense- in sending XHTML out to the web.

Btw there's nothing stopping you from writing HTML more rigorously
than the rules of HTML actually require, if you wish. There's
software that will fill in the "optional" tags if you like (such as
HTMLtidy), or that will take XML-based markups and emit disciplined
HTML. There's lots of different ways, and without knowing more about
your internal process it's hard to say what's best for you internally.
All that I was trying to say - on this point - was that it seems a
waste of talent and effort to take existing content and re-work it
into XHTML - without a very clear motive as to why, because the web
out there won't care in the least, in fact the result rates to be
somewhat less compatible than what you started with.

For new material and XML-based authoring/publishing tools then the
balance starts to shift the other way, sure.
Jul 20 '05 #9
John Bokma <po********@castleamber.com> wrote:
XHTML 1.0 is equivalent to HTML 4.01. You don't gain anything from


I thought my gain was that there is a much stricter syntax.


It is stricter only in the sense that XHTML removes some of the
variation that is allowed in "classical" HTML (and by actual browsers),
such as using upper or lower case in tag names. Naturally you can apply
such restrictions even when authoring in HTML 4.01. Maybe you meant
that you want a validator to report violations of the restrictions?

Contrary to popular belief, XHTML 1.0 has both Strict and Transitional
version, just as HTML 4.01 has. So in terms of _logical_ strictness,
they're the same.

Actually, XHTML is _less_ strict in some respects in its formalized
syntax. For example, a validator will not report nested <a> elements as
syntax errors, since the formalized syntax does not prevent them, only
the prose. "Classical" HTML is in theory SGML based, which means a more
expressive metalanguage, which means that a validator will catch errors
like nesting <a> elements.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #10
John Bokma wrote in message <10***************@halkan.kabelfoon.nl>:
Thanks Darin, very clear. I consider going back to HTML/4.01. My XHTML
documents are correct but I don't want to:

"send back XHTML as application/xhtml+xml to UAs that support it, and as
text/html to legacy UAs."

since then I probably have to convince my host admin to change things
*if* possible with Apache.


Why not? It can be relatively easy using Apache and content negociation,
as simple as activating the MultiViews Option.

What I am doing on my (tiny) website is having two copies of each XHTML
document (in fact, one of them is a symbolic link to the other one). The
first one has a name ending with .xhtml and served as
application/xhtml+xml, the other one ending with .html and served as
text/html. All links point to the filenames without the extension. If
the UA sends an HTTP Accept Field where application/xhtml+xml has a
better quality than text/html (which is what Mozilla does and I suppose
that XML understanding agents should do this), the application/xhtml+xml
version is returned; else the text/html is returned (even if the two
quality factors are the same, which is a good thing, since many UA send
an Accept field with quality factor 1 for */* :-( ).

--
Pierre Senellart
http://pierre.senellart.com
Jul 20 '05 #11
In article <10***************@halkan.kabelfoon.nl>,
John Bokma <po********@castleamber.com> wrote:
Worse, IE4.x/Mac shows a blank page when encountering this. A fair
reason to leave it out.


Thanks Kris, enough reason for me to fall back to HTML/4.01 since I want
to support 4.x browsers as much as possible, and a blank page is bad.


It is not the XHTML, it is the XML declaration before the DocType that
does it. Just to clear that up.

--
Kris
kr*******@xs4all.netherlands (nl)
Jul 20 '05 #12
John Bokma <po********@castleamber.com> writes:
I converted most (not all) of my pages at http://johnbokma.com/ to
XHTML. I thought this was just a small change from 4.01.

However someone stated quite vaguely that my pages are *not* XHTML
since when a UA requests a page and states that it can handle XML the
server still responds with a Content-type: text/html
Well, I think the shoe fits. Though i'm not sure about the 'vaguely'
part. My UA asks for XHTML and doesn't get it.
I see that http://www.w3.org/TR/xhtml1/ does the same (Firebird)

So is this wrong or not?
It depends a lot on what 'wrong' means in your book. text/html is tag
soup, and there's very little reason to advertise tag soup otherwise.
The whole Appendix C business is wrong in itself of course.
"XHTML Documents which follow the guidelines set forth in Appendix C,
"HTML Compatibility Guidelines" may be labeled with the Internet Media
Type "text/html""

Seems to suggest that nothing *is* wrong...


Nothing *is* wrong as long as HTML hasn't been treated as SGML as
a matter of implementation. The explicit message behind this is that
only braindead idiots would take w3c recommendations seriously, since
'compatibility' appears to be the first child of ignorance.
--
"America is the only country that went from barbarism to decadence
without civilization in between." --Oscar Wilde
Jul 20 '05 #13
On Sun, 03 Aug 2003 10:26:52 +0300, Henri Sivonen <hs******@iki.fi>
wrote:
In article <bg**********@blue.rahul.net>,
Darin McGrew <mc****@stanfordalumni.org> wrote:
But current browsers don't support XHTML unless you pretend that it's
really HTML (by following Appendix C and sending it as text/html).
ITYM "IE doesn't support..."


No, loads of other browsers don't either, you're being very misleading
saying it's only IE.
Mozilla-based browsers support XHTML 1.x delivered as
application/xhtml+xml. However, they don't support incremental rendering
of application/xhtml+xml as the content arrives from the network.
Which is absolutely disastrous, and makes their SVG content impossible
to be conformant to the spec, of course they claim they can't render
it incrementally to be conformant to the XHTML spec, so that's good,
either they can be a conformant SVG UA, or a conformant XHTML one, a
shame really.
Safari 1.0 supports some XHTML documents sent as application/xhtml+xml.
However, tbodyless tables (XHTML Basic doesn't allow tbody) make the
layout break. (First cell rendered and the rest of the document not
shown.)


So with Opera and Safari and IE all not really supporting XHTML
reliably, aswell as all the other browsers that don't support, it's a
pretty fair comment to say that current browsers don't support XHTML.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #14
Henri Sivonen <hs******@iki.fi> wrote:
Recent versions of Opera supports simple documents sent as
application/xhtml+xml (XHTML Basic is fine). Some large/complex
documents make the document loading stall until the user presses "Stop"
(in Opera 6). (This might be fixed in Opera 7.)


XHTML support in Opera 6 is pretty flaky, Opera 7 is much better, the
only thing lacking in the current release version is javascript support,
javascript is supported in the current beta.
Headless

--
Email and filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #15
In article <3f****************@news.cis.dfn.de>,
ji*@jibbering.com (Jim Ley) wrote:
Mozilla-based browsers support XHTML 1.x delivered as
application/xhtml+xml. However, they don't support incremental rendering
of application/xhtml+xml as the content arrives from the network.
of course they claim they can't render
it incrementally to be conformant to the XHTML spec


Who's "they"? Why would any of the XHTML specs forbid incremental
rendering?

AFAIK, it's just that Mozilla's XML content sink (the thing that
consumes data from the parser) can't deal with incremental loading.
http://bugzilla.mozilla.org/show_bug.cgi?id=18333

--
Henri Sivonen
hs******@iki.fi
http://www.iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 20 '05 #16
On Sat, 09 Aug 2003 16:04:49 +0300, Henri Sivonen <hs******@iki.fi>
wrote:
In article <3f****************@news.cis.dfn.de>,
ji*@jibbering.com (Jim Ley) wrote:
>Mozilla-based browsers support XHTML 1.x delivered as
>application/xhtml+xml. However, they don't support incremental rendering
>of application/xhtml+xml as the content arrives from the network.

of course they claim they can't render
it incrementally to be conformant to the XHTML spec


Who's "they"? Why would any of the XHTML specs forbid incremental
rendering?


Because a parser must not pass non-well-formed elements to the
application for normal processing, and incremental rendering requires
that non-well-formed elements are processed by the application before
it can even know if it's well-formed (e.g. the root element is never
closed)

So given an XML document with the root element not closed, what should
be rendered?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #17
ji*@jibbering.com (Jim Ley) wrote:
Who's "they"? Why would any of the XHTML specs forbid incremental
rendering?


Because a parser must not pass non-well-formed elements to the
application for normal processing, and incremental rendering requires
that non-well-formed elements are processed by the application before
it can even know if it's well-formed (e.g. the root element is never
closed)


Why do you keep repeating this nonsense?

As I've told you before, the only requirement is that a parser throws a
parsing error when encountering malformed code, there is no requirement
not to process/display.

Opera 7 does incremental rendering of xhtml and it complies with the
requirement to throw a parsing error on encountering malformed code.

This is a non issue that XHTML haters apparently like to throw up, go
tell Mozilla to improve Gecko instead.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #18
On Tue, 12 Aug 2003 07:51:25 +0100, Headless <in*************@dna.ie>
wrote:
ji*@jibbering.com (Jim Ley) wrote:
Who's "they"? Why would any of the XHTML specs forbid incremental
rendering?


Because a parser must not pass non-well-formed elements to the
application for normal processing, and incremental rendering requires
that non-well-formed elements are processed by the application before
it can even know if it's well-formed (e.g. the root element is never
closed)


Why do you keep repeating this nonsense?

As I've told you before, the only requirement is that a parser throws a
parsing error when encountering malformed code, there is no requirement
not to process/display.


Yep, I agree, so a browser is doing nothing wrong by rendering invalid
XHTML documents, _GOOD_, a browser is free to render invalid
documents, that's good to hear, but I understood that wasn't one of
the oft trumped advantages of XHTML?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #19
ji*@jibbering.com (Jim Ley) wrote:
Because a parser must not pass non-well-formed elements to the
application for normal processing, and incremental rendering requires
that non-well-formed elements are processed by the application before
it can even know if it's well-formed (e.g. the root element is never
closed)
Why do you keep repeating this nonsense?

As I've told you before, the only requirement is that a parser throws a
parsing error when encountering malformed code, there is no requirement
not to process/display.


Yep, I agree, so a browser is doing nothing wrong by rendering invalid
XHTML documents, _GOOD_, a browser is free to render invalid
documents, that's good to hear,


An XHTML renderer is required to throw a parsing error on _malformed_
code, invalid is something else entirely.
but I understood that wasn't one of
the oft trumped advantages of XHTML?


Apparently you misunderstood, the requirement to throw a parser error on
encountering malformed code is an advantage.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #20
In article <3f****************@news.cis.dfn.de>,
ji*@jibbering.com (Jim Ley) wrote:
Because a parser must not pass non-well-formed elements to the
application for normal processing, and incremental rendering requires
that non-well-formed elements are processed by the application before
it can even know if it's well-formed (e.g. the root element is never
closed)
No, the XML spec does not require the XML processor to check whether an
element is properly closed before passing information about the start of
the element to the application.

Quoting the XML spec (2nd ed.):
| fatal error
|
| [Definition: An error which a conforming XML processor must
| detect and report to the application. After encountering a
| fatal error, the processor may continue processing the data
| to search for further errors and may report such errors to
| the application. In order to support correction of errors,
| the processor may make unprocessed data from the document
| (with intermingled character data and markup) available to
| the application. Once a fatal error is detected, however,
| the processor must not continue normal processing (i.e.,
| it must not continue to pass character data and information
| about the document's logical structure to the application
| in the normal way).]

It says "after encountering a fatal error". That is, if an element is
not properly closed, the error would be encountered when the end tag of
the parent element is encountered or the end of the data streams is
encountered. Before that, it is OK to pass information about the
children of the unclosed element to the application.
So given an XML document with the root element not closed, what should
be rendered?


Until the end of the data stream is reached, the entire document. When
the end of the data stream is seen and the error is detected, also
displaying an error message would be appropriate. I guess whether the
error message replaces the rendering of the document so far is an
implementation-dependent choice.

--
Henri Sivonen
hs******@iki.fi
http://www.iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 20 '05 #21

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Captain Nemo | last post by:
Hi I'm essentially a back-end programmer so I don't know very much about Dreamweaver. However, I work with web-designers who are keen for me to write my pages using Dreamweaver templates. ...
3
by: Spam Survivor | last post by:
Hi folks: I'm assuming someone's been down this path before: we want to provide our users with a tool integrated into our content-management website that will allow them to validate their html &...
1
by: Gordon - Adelphia | last post by:
I have a question regarding xhtml. Why, why, why does the ELEMENT <body> allow “unblocked” text. HTML does not (though, most browsers will render). Xhtml (transitional) however allows text nodes...
41
by: CMAR | last post by:
What are the pluses and minuses of constructing and validating between XHTML Transitional vs. HTLM 4.01 Strict Thanks, CMA
15
by: Jake Barnes | last post by:
I'm trying to learn AJAX so tonight I sat down and came up with a little toy that I can do tests with. You can see it here: http://www.publicdomainsoftware.org/ajaxExperiment.htm I've got...
1
by: Lore Leunoeg | last post by:
Hello Can I parse an XHTML Document with XPath? I tried the following expressions with the following XHTML Document with n o result: Removing the doctype and the namespace (xmlns) statemens...
11
by: Michael Powe | last post by:
How can I make an XHTML-compliant form of an expression in this format: document.write("<scr"+"ipt type='text/javascript' src='path/to/file.js'>"+"</scr"+"ipt>"); this turns out to be a...
5
by: sniper | last post by:
hi ; i have this small code that consist in taking the name of the user and writing it in the same form as an output.the name is relative to /data/valid/string1 In my Js code i want to access the...
3
by: Nik | last post by:
I have been trying base my site on the Ruthsarian Lab's layout at http://webhost.bridgew.edu/etribou/layouts/skidoo/demos/tweak_01.html This design is in xhtml, whereas I would prefer to have my...
3
by: dantohester | last post by:
Hi there, I have the following situation: I want to create an XML document that contains 2 parts: a) a XHTML part (it can be either version 1.0 or 1.1 ) b) a non XHTML part that contains some...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.