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 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."
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
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
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
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)
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
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
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.
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
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
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)
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
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/
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
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/ 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
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/ 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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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.
...
|
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 &...
|
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...
|
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
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
| |