Hey all,
Does anyone know if all the newer browsers support XHTML? My main target is
IE6/NN6+(firefox/mozilla/etc), but I'd like to know if Safari, Opera,
Konqueror, and other browsers also support it.
Anyone know of any major compatibility problems with XHTML?
How do older browsers, such as Netscape 4, react to the doctype?
TIA
--
--
~kaeli~
Murphy's Law #2000: If enough data is collected, anything
may be proven by statistical methods. http://www.ipwebdesign.net/wildAtHeart http://www.ipwebdesign.net/kaelisSpace 21 4148
On Tue, 17 Aug 2004 07:48:00 -0500, kaeli <ti******@NOSPAM.comcast.net>
wrote: Hey all,
Does anyone know if all the newer browsers support XHTML? My main target is IE6/NN6+(firefox/mozilla/etc), but I'd like to know if Safari, Opera, Konqueror, and other browsers also support it. Anyone know of any major compatibility problems with XHTML? How do older browsers, such as Netscape 4, react to the doctype?
TIA
XHTML code is essentially HTML, and as such it's relatively portable to
different browsers. The real problem comes when you serve the document. If
you do not serve your XHTML as text/html, IE cannot handle it. However, in
this case browsers which could have parsed the XML will not. So it's a
choice: serve as text/html and lose the primary benefit of doing XHTML,
serve as application/xml+xhtml and lose the most prevalent UA, or work out
a complex content-negotiation craziness that allows you to serve the
proper document to the user despite what might be cached for them
someplace.
In short - as long as IE or any similar UA exists which holds market share
and cannot handle XHTML properly, HTML 4.01 is the best available way to
code the document.
kaeli wrote: Does anyone know if all the newer browsers support XHTML? My main target is IE6/NN6+(firefox/mozilla/etc), but I'd like to know if Safari, Opera, Konqueror, and other browsers also support it.
Real XHTML?
* Unsupported by IE, lynx and links.
* Supported by Gecko (Mozilla, Firefox, NN 6+ etc)
* Opera - I think has XHTML support.
* Safari - I think it fakes XHTML by treating application/xhtml+xml as
text/html.
XHTML served as text/html?
* Most browsers can error correct
* Emacs W3 (correctly under SGML rules) interprets XHTML self-closing tags
as elements followed by a >
How do older browsers, such as Netscape 4, react to the doctype?
They don't. Guessing the intelligence of the page author based on the
doctype is a new thing.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
In article <cf*******************@news.demon.co.uk>,
David Dorward <do*****@yahoo.com> wrote: Real XHTML? * Safari - I think it fakes XHTML by treating application/xhtml+xml as text/html.
It throws up a fatal error when the XHTML is not well-formed, for all it
is worth.
--
Kris
<kr*******@xs4all.netherlands> (nl)
David Dorward <do*****@yahoo.com> wrote: Real XHTML?
- - * Opera - I think has XHTML support.
In a sense. Some people might say it has too good support: it does not
recognize predefined entities like ä (this is permitted by XHTML
rules), and it refuses to display the page at all if there is a single
"well-formedness" error like missing end tag.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Tue, 17 Aug 2004 18:59:51 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote: David Dorward <do*****@yahoo.com> wrote:
Real XHTML? - - * Opera - I think has XHTML support.
In a sense. Some people might say it has too good support: it does not recognize predefined entities like ä (this is permitted by XHTML rules), and it refuses to display the page at all if there is a single "well-formedness" error like missing end tag.
The wellformedness issue is mandated by the XML specs; MSIE and Mozilla
also honor it. Opera renders as good as it can up until the error,
followed by an error message, while the latest releases of Mozilla will
only show an error message.
--
Rijk van Geijtenbeek
The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote: Real XHTML?- - * Opera - I think has XHTML support.
In a sense. Some people might say it has too good support: it does not recognize predefined entities like ä
Incorrect.
and it refuses to display the page at all if there is a single "well-formedness" error like missing end tag.
Also incorrect, that's the way Gecko based UAs work.
--
Spartanicus
In article <op**************@news.individual.net>, ne*****@yahoo.com
enlightened us with... In short - as long as IE or any similar UA exists which holds market share and cannot handle XHTML properly, HTML 4.01 is the best available way to code the document.
Wow, you know, for such a popular browser, it doesn't seem to support much of
the new stuff. I can't get it to do XML right, either.
I was just using XML for passing some info to and from my applications, so I
figured I'd check out XHTML again. The last I checked on it, like a year or
more ago, it wasn't supported. I was hoping that would have changed. Guess
not.
Thanks to everyone who replied.
--
--
~kaeli~
A man needs a mistress... just to break the monogamy. http://www.ipwebdesign.net/wildAtHeart http://www.ipwebdesign.net/kaelisSpace
David Dorward wrote: kaeli wrote:
Does anyone know if all the newer browsers support XHTML? My main target is IE6/NN6+(firefox/mozilla/etc), but I'd like to know if Safari, Opera, Konqueror, and other browsers also support it.
Real XHTML? * Unsupported by IE, lynx and links. ... * Safari - I think it fakes XHTML by treating application/xhtml+xml as text/html.
BTW, the latest development version of Lynx also treats
application/xhtml+xml as text/html, which seems to be adequate for text
browsers (which don't have to bother with xml-stylesheet PIs, and CDATA
sections within script and style elements).
On Tue, 17 Aug 2004 14:51:21 -0500, kaeli <ti******@NOSPAM.comcast.net>
wrote: Wow, you know, for such a popular browser, (IE) doesn't seem to support much of the new stuff.
As the old Lily Tomlin line goes, "We don't have to care. We're the Phone
Company."
In article <op**************@news.individual.net>, ne*****@yahoo.com
enlightened us with... On Tue, 17 Aug 2004 14:51:21 -0500, kaeli <ti******@NOSPAM.comcast.net> wrote:
Wow, you know, for such a popular browser, (IE) doesn't seem to support much of the new stuff.
As the old Lily Tomlin line goes, "We don't have to care. We're the Phone Company."
*snort*
--
--
~kaeli~
Why did kamikaze pilots wear helmets? http://www.ipwebdesign.net/wildAtHeart http://www.ipwebdesign.net/kaelisSpace
Spartanicus <me@privacy.net> wrote: Real XHTML? - - * Opera - I think has XHTML support.
In a sense. Some people might say it has too good support: it does not recognize predefined entities like ä
Incorrect.
What would you like to characterize as incorrect? My description, or the
behavior described? On which grounds would you call either of them as
incorrect? The behavior is inadequate, especially for a WWW browser, but
not incorrect by the specifications. and it refuses to display the page at all if there is a single "well-formedness" error like missing end tag.
Also incorrect, that's the way Gecko based UAs work.
Again, _what_ is incorrect, in your opinion?
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote: Real XHTML? - - * Opera - I think has XHTML support.
In a sense. Some people might say it has too good support: it does not recognize predefined entities like ä
Incorrect.
What would you like to characterize as incorrect?
Your statement that Opera doesn't recognize entities like ä in
XHTML mode. Do try to keep up: http://www.opera.com/download (entity
support in XHTML mode was added in 7.50) and it refuses to display the page at all if there is a single "well-formedness" error like missing end tag.
Also incorrect, that's the way Gecko based UAs work.
Again, _what_ is incorrect, in your opinion?
Your statement again. Opera does not "refuse to display the page at
all", it renders what it can and tacks on the mandatory parsing error at
the end, demo: http://www.spartanicus.utvinternet.ie/xhtml11.xhtml
--
Spartanicus
Spartanicus <me@privacy.net> wrote: What would you like to characterize as incorrect?
Your statement that Opera doesn't recognize entities like ä in XHTML mode. Do try to keep up: http://www.opera.com/download (entity support in XHTML mode was added in 7.50)
Thank you. Why didn't you say that in the first place?
The fact still is that there are versions of Opera around that support
XHTML and treat references to predefined entities as nonexistent (that
is, display ä as null and void, not even as ä literally).
But genuine XHTML isn't suitable for practical authoring for the WWW
anyway, of course. Some people think that it's possible to detect the
browser's capabilities and send XHTML or classic HTML depending on them.
It's hard to see what that would achieve even if it were reliably
possible, but how would one sniff, for example, whether a browser that
claims XHTML support in the HTTP headers will ignore entity references or
not? and it refuses to display the page at all if there is a single "well-formedness" error like missing end tag.
Also incorrect, that's the way Gecko based UAs work.
Again, _what_ is incorrect, in your opinion?
Your statement again. Opera does not "refuse to display the page at all", it renders what it can and tacks on the mandatory parsing error at the end, demo: http://www.spartanicus.utvinternet.ie/xhtml11.xhtml
Again, thank you. My statement was exaggerated. The effects depend on the
location and kind of syntax errors. If you wrote, e.g.,
<title Spartanicus' Web tips</title>
then Opera would report "XML-jäsennys epäonnistui: ei oikeinmuodostettu
(Rivi: 6, Merkki: 18)" or something similar, depending on the browser's
language, followed by a copy of the XHTML source code. My point is that
this is really bad to usability. When server as classic HTML, a browser
renders the page normally despite the error - just without showing the
title anywhere since it did not get it.
This is more or less what XML and XHTML are _supposed_ to mean. How many
authors can really organize things so that their XHTML documents never
get edited in a manner that creates a tiny syntax error? (Even if could
guarantee that, you could still play with classic HTML for a couple of
years. After all, contrary to the tone of many statements about XHTML and
HTML, it _is_ possible to write valid code in classic HTML too. And even
use redundant tags.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote: Do try to keep up: http://www.opera.com/download (entity support in XHTML mode was added in 7.50) Thank you. Why didn't you say that in the first place?
Only after posting my first reply did I remember that previous versions
had a shortcoming there.
But genuine XHTML isn't suitable for practical authoring for the WWW anyway, of course.
Agreed for the time being.
Some people think that it's possible to detect the browser's capabilities and send XHTML or classic HTML depending on them. It's hard to see what that would achieve even if it were reliably possible, but how would one sniff, for example, whether a browser that claims XHTML support in the HTTP headers will ignore entity references or not?
No such guarantees for text/html either. Opera does not "refuse to display the page at all", it renders what it can and tacks on the mandatory parsing error at the end, demo: http://www.spartanicus.utvinternet.ie/xhtml11.xhtml
Again, thank you. My statement was exaggerated. The effects depend on the location and kind of syntax errors. If you wrote, e.g., <title Spartanicus' Web tips</title> then Opera would report "XML-jäsennys epäonnistui: ei oikeinmuodostettu (Rivi: 6, Merkki: 18)" or something similar, depending on the browser's language, followed by a copy of the XHTML source code.
Use that if you want as an argument against XHTML, but it doesn't form
an argument against Opera's handling of it. A standard compliant XHTML
parser is required to stop parsing after it has encountered malformed
code.
My point is that this is really bad to usability. When server as classic HTML, a browser renders the page normally despite the error - just without showing the title anywhere since it did not get it.
This is more or less what XML and XHTML are _supposed_ to mean. How many authors can really organize things so that their XHTML documents never get edited in a manner that creates a tiny syntax error?
XHTML only renderers could shed the error correcting mechanisms that
weigh down current tag soup slurpers. Currently alternative UAs struggle
to emulate IE's error recovery mechanism, something that has to be done
by process of trial and error, and it will never be perfect.
I can't see XHTML only renderers on the desktop for decades, but I can
imagine web content created for other platforms like cellphones, wrist
watches etc. taking off in the near future. These devices and their
renderers would almost require well formed code, incorporating a classic
tag soup slurper is difficult on these resource strapped devices.
Since it's impossible to prevent malformed XHTML code being created, a
step in the right direction is if parsers clearly show malformedness
errors, assuming that most authors check their work in a UA before
publishing. And if they don't, every user that accesses the document
will be made aware of the error(s), making it far more likely that the
author will be informed.
That could result in a significant reduction of published malformed
code.
After all, contrary to the tone of many statements about XHTML and HTML, it _is_ possible to write valid code in classic HTML too. And even use redundant tags.)
Best not mention validity and well formedness in such close proximity of
each other so as not to give the impression to lurkers that the 2 are
the same.
--
Spartanicus
On Wed, 18 Aug 2004 10:47:07 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote:
... This is more or less what XML and XHTML are _supposed_ to mean. How many authors can really organize things so that their XHTML documents never get edited in a manner that creates a tiny syntax error?
If they use XML-based publishing systems, it shouldn't be too hard. And
that is of course, IMHO, also the only reason currently to even try using
XHTML :)
There are a lot of webloggers that try to write valid strict (X)HTML
nowadays. And as soon as they turn on the 'comment' capability of their
blogging tools, they run into trouble, as those tools are not XML based
and not very good at handling invalid or variosuly encoded input.
(Even if could guarantee that, you could still play with classic HTML for a couple of years. After all, contrary to the tone of many statements about XHTML and HTML, it _is_ possible to write valid code in classic HTML too. And even use redundant tags.)
Agreed. Everyone who is handcoding can just as well stick to HTML 4.01 and
save a few bytes and headaches in the process. Example of someone who
understands this: http://diveintomark.org/archives/2004/08/16/specs
The content of the article is also nice :)
--
Rijk van Geijtenbeek
The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen
On Wed, 18 Aug 2004 14:05:25 +0100, Spartanicus <me@privacy.net> wrote:
... XHTML only renderers could shed the error correcting mechanisms that weigh down current tag soup slurpers. Currently alternative UAs struggle to emulate IE's error recovery mechanism, something that has to be done by process of trial and error, and it will never be perfect.
I can't see XHTML only renderers on the desktop for decades, but I can imagine web content created for other platforms like cellphones, wrist watches etc. taking off in the near future. These devices and their renderers would almost require well formed code, incorporating a classic tag soup slurper is difficult on these resource strapped devices.
Since it's impossible to prevent malformed XHTML code being created, a step in the right direction is if parsers clearly show malformedness errors, assuming that most authors check their work in a UA before publishing. And if they don't, every user that accesses the document will be made aware of the error(s), making it far more likely that the author will be informed.
That could result in a significant reduction of published malformed code.
See the XHTML-MP guide fromm one of the leading WAP 2.0 browser
manufacturers...
<URL:http://developer.openwave.com/dvl/support/documentation/guides_and_references/xhtml-mp_style_guide/chapter2.htm>
.... for evidence that this is not what will happen. A few quotes:
"In this regard, the Openwave browser is very forgiving when it comes to
mark-up. If you avoid adding the XML processing instruction and the DTD,
your code will still work. Unrecognized tags and CSS properties will be
ignored and tags without a closure won't break your page (e.g. <br>
instead of <br/> and <p> without a matching </p> )."
"If, for whatever reason, you want your code to make it through a
validating parser (the one at W3C, for example http://validator.w3.org/ ),
your application must comply with whichever DTD you declare.
It is important to note that we are not advocating that developers write
sloppy mark-up; we simply wanted to make sure that the previous chapter
did not scare you."
--
Rijk van Geijtenbeek
The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen
In article <kr*****************************@news1.news.xs4all .nl>,
Kris <kr*******@xs4all.netherlands> wrote: In article <cf*******************@news.demon.co.uk>, David Dorward <do*****@yahoo.com> wrote:
Real XHTML? * Safari - I think it fakes XHTML by treating application/xhtml+xml as text/html.
It throws up a fatal error when the XHTML is not well-formed, for all it is worth.
The current Safari uses expat. An upcoming version will use libxml.
(The behavior mentioned by David Dorward was in an early beta a long
time ago.)
--
Henri Sivonen hs******@iki.fi http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
"Rijk van Geijtenbeek" <ri**@opera.com> wrote: XHTML only renderers could shed the error correcting mechanisms that weigh down current tag soup slurpers. Currently alternative UAs struggle to emulate IE's error recovery mechanism, something that has to be done by process of trial and error, and it will never be perfect.
I can't see XHTML only renderers on the desktop for decades, but I can imagine web content created for other platforms like cellphones, wrist watches etc. taking off in the near future. These devices and their renderers would almost require well formed code, incorporating a classic tag soup slurper is difficult on these resource strapped devices.
Since it's impossible to prevent malformed XHTML code being created, a step in the right direction is if parsers clearly show malformedness errors, assuming that most authors check their work in a UA before publishing. And if they don't, every user that accesses the document will be made aware of the error(s), making it far more likely that the author will be informed.
That could result in a significant reduction of published malformed code. See the XHTML-MP guide fromm one of the leading WAP 2.0 browser manufacturers... <URL:http://developer.openwave.com/dvl/support/documentation/guides_and_references/xhtml-mp_style_guide/chapter2.htm> ... for evidence that this is not what will happen. A few quotes:
It's impossible to disprove a statement of something that *could*
happen, unless you've found a way to time travel. Stating that the above
url amounts to "evidence" for this is silly.
"In this regard, the Openwave browser is very forgiving when it comes to mark-up. If you avoid adding the XML processing instruction and the DTD, your code will still work.
I really don't see your point here, sure it's possible for a xhtml
parser to ignore the w3c requirements, it's therefore automatically not
a standard compliant xhtml renderer.
Let's hypothesise and assume that we will end up with a mix of standard
and non standard compliant xhtml renderers, in that situation it's fair
to expect that some content will still be better formed due to some
people using standard compliant renderers.
Don't take what I wrote as some sort of dreamy prediction of what I
think will happen, I haven't got a clue. What I wrote only intended to
argue that there is some logic and potential benefit to client side well
formedness checking.
You can take a cynical view and assume that it will never happen, and
for all I know you could be right, but that's a separate discussion.
There might also be an argument to say that there are drawbacks to
client side well formedness checking, but again that is a separate
discussion, and drawbacks usually coexist with benefits.
--
Spartanicus
On Wed, 18 Aug 2004 14:05:25 +0100, Spartanicus wrote: I can't see XHTML only renderers on the desktop for decades, but I can imagine web content created for other platforms like cellphones, wrist watches etc. taking off in the near future. These devices and their renderers would almost require well formed code, incorporating a classic tag soup slurper is difficult on these resource strapped devices.
This is already the case. The browser that comes with Ericsson and
(I think, but haven't tested extensively) Nokia phones will only render
well-formed XML.
That being said, the newest mobile phones are capable of running Opera's
mobile version, complete with tag-soup parser, so it may be that
XHTML-only mobiles will turn out to be a short-lived phenomenon
--
" - Penny, I worry that you are loosing heart... You are not the sweet little
girl I once knew. Where's your sense of wonder?
- Currently flowing into a sanitary napkin... Guess where my childlike
innocence and idle dreams are currently wedged. Come on, I dare you." http://www.huh.34sp.com/
Rijk van Geijtenbeek wrote: On Tue, 17 Aug 2004 18:59:51 +0000 (UTC), Jukka K. Korpela <jk******@cs.tut.fi> wrote:
In a sense. Some people might say it has too good support: it does not recognize predefined entities like ä (this is permitted by XHTML rules), and it refuses to display the page at all if there is a single "well-formedness" error like missing end tag.
The wellformedness issue is mandated by the XML specs; MSIE and Mozilla also honor it.
In this regard, I tend to agree with Mark Pilgrim's point that enforcing
well-formedness in the browser is the wrong place to do it. The end result
is that the visitor is prevented from retrieving the content - albeit
broken.
I understand the reasoning behind well-formedness in XML and its error
handling - but in this regard, there needs to be something better / earlier
that does this brokenness testing.
--
Isofarro.
FAQ: http://www.html-faq.com/
Recommended Hosting: http://www.affordablehost.com/
isolani: http://www.isolani.co.uk/blog/
Rijk van Geijtenbeek wrote: The wellformedness issue is mandated by the XML specs; MSIE and Mozilla also honor it.
Isofarro <sp*******@spamdetector.co.uk> posted:
In this regard, I tend to agree with Mark Pilgrim's point that enforcing well-formedness in the browser is the wrong place to do it. The end result is that the visitor is prevented from retrieving the content - albeit broken.
I understand the reasoning behind well-formedness in XML and its error handling - but in this regard, there needs to be something better / earlier that does this brokenness testing.
But, if all the browsers behave like that, it does.
If the author immediately sees that their data is broken (assuming that do
at least try looking at it in a browser), they should fix it there and
then. Compare that to authors using a browser which shows anything
withouth protest. If all they do is check it in that browser and declare
that "it works for me", many will do nothing more to check that it also
works for you.
--
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Nobody |
last post by:
Okay, you are all so smart in here. Answer me this:
IE6 in standards mode doesn't seem to hide scrollbars on the body element
(overflow:hide) Ain't this a quandary. I have it in my head that I...
|
by: John Bokma |
last post by:
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*...
|
by: Roedy Green |
last post by:
does converting the XHTML make matters better or worse vis a vis CSS
not behaving the way you expect?
--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly...
|
by: Mcginkel |
last post by:
I am trying to find a way to load XHTML content in an Iframe.
I use to do this in html by using the following code :
var iframeObject = document.createElement("iframe");...
|
by: Buford Early |
last post by:
I read this in http://annevankesteren.nl/2004/12/xhtml-notes
"A common misconception is that XHTML 1.1 is the latest version
of the XHTML series. And although it was released a bit more
than a...
|
by: Alex D. |
last post by:
How can I stop asp.net from rendering XHTML istead of HTML?
My javascripts are rendering wrong because of that. It is rendering & to
clients instead of &.
Any help?
Thanks,
Alejandro.
|
by: Tomek Toczyski |
last post by:
What is the best way to attach a caption to an image in xhtml?
I can attach a caption to a table by a "<caption>" tag
but I would like to do sth similar to an image.
How to do it in a natural...
|
by: Gianni Rondinini |
last post by:
hi all. please excuse the misusage of some tech terms, but writing in
english is not as easy as in italian :)
i'm designing our new website and, since i want to do something that
will last as...
|
by: Rolf Welskes |
last post by:
Hello,
if I have for example:
<table style="width: 100%; height: 100%;" border="1">
<tr>
<td style="width: 100px">k
</td>
<td style="width: 100px">k
</td>
</tr>
|
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: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
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: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |