473,326 Members | 2,805 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,326 software developers and data experts.

help with DOM and IE

I can't figure out why the function below isn't doing anything in IE 6.
I pass the id of a table as the "which" variable. When I activate the
function, nothing happens. It doesn't return any errors.

This works perfectly fine in Firefox - a new table row appears with a
table cell containing the text "Hi there".

Can anyone give some advice on this?

Thanks!

N
function ieTest(which) {
var objTmp1 = document.createElement("td");
objTmp1.appendChild(document.createTextNode("Hi there"));
objTmp1.setAttribute("colspan",5);
var objTmp2 = document.createElement("tr");
objTmp2.appendChild(objTmp1);
document.getElementById(which).appendChild(objTmp2 );
window.alert(document.getElementById(which).getAtt ribute("cellpadding"))
}

May 1 '06 #1
29 1647
The alMIGHTY N wrote:
I can't figure out why the function below isn't doing anything in IE 6.
I pass the id of a table as the "which" variable. When I activate the
function, nothing happens. It doesn't return any errors.

This works perfectly fine in Firefox - a new table row appears with a
table cell containing the text "Hi there".

Can anyone give some advice on this?

Thanks!

N
function ieTest(which) {
var objTmp1 = document.createElement("td");
objTmp1.appendChild(document.createTextNode("Hi there"));
objTmp1.setAttribute("colspan",5);
var objTmp2 = document.createElement("tr");
objTmp2.appendChild(objTmp1);
document.getElementById(which).appendChild(objTmp2 );
window.alert(document.getElementById(which).getAtt ribute("cellpadding"))
}

Use insertRow(-1) and insertCell(-1) to create and add the row and cell.

var row = document.getElementById(which).insertRow(-1);
var cell = row.insertCell(-1);
.....

--
Ian Collins.
May 1 '06 #2
The alMIGHTY N said the following on 5/1/2006 4:39 AM:
I can't figure out why the function below isn't doing anything in IE 6.
I pass the id of a table as the "which" variable. When I activate the
function, nothing happens. It doesn't return any errors.

This works perfectly fine in Firefox - a new table row appears with a
table cell containing the text "Hi there".
In this case, Firefox is actually getting it wrong.
Can anyone give some advice on this?

Thanks!

N
function ieTest(which) {
var objTmp1 = document.createElement("td");
objTmp1.appendChild(document.createTextNode("Hi there"));
objTmp1.setAttribute("colspan",5);
Don't use setAttribute with IE, it is known to be buggy.

objTmp1.colspan = "5";
var objTmp2 = document.createElement("tr");
objTmp2.appendChild(objTmp1);
document.getElementById(which).appendChild(objTmp2 );
You can't appendChild to the Table element in IE, you have to append it
to a TBODY. In that regards, Mozilla based browsers get it wrong.
window.alert(document.getElementById(which).getAtt ribute("cellpadding"))


You can access the attributes directly also:

alert(document.getElementById(which).cellpadding);

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 1 '06 #3
Great thanks! I'm surprised that Firefox would have gotten something
wrong... of course, I probably should have tested with IE a lot
earlier.

Thanks again!

May 1 '06 #4
Thanks a lot for your suggestions and help. I'm quite surprised that
Firefox would have gotten something wrong. I'm also quite surprised
that O'Reilly would have gotten something wrong - I learned all about
getAttribute, setAttribute, etc. from their AJAX book.

Oh well.

You learn something new everyday. Thanks again!

May 1 '06 #5
On 1 May 2006 06:07:00 -0700, "The alMIGHTY N" <na******@yahoo.com>
wrote:
Thanks a lot for your suggestions and help. I'm quite surprised that
Firefox would have gotten something wrong.


What it gets wrong is that it treats all documents as if they could be
XHTML, the requirement for a TBODY doesn't exist in XHTML, so
therefore it is valid if you have an XHTML document.

Jim.
May 1 '06 #6
Jim Ley said the following on 5/1/2006 11:15 AM:
On 1 May 2006 06:07:00 -0700, "The alMIGHTY N" <na******@yahoo.com>
wrote:
Thanks a lot for your suggestions and help. I'm quite surprised that
Firefox would have gotten something wrong.


What it gets wrong is that it treats all documents as if they could be
XHTML, the requirement for a TBODY doesn't exist in XHTML, so
therefore it is valid if you have an XHTML document.


Is there a URL anywhere that documents that? I don't doubt you at all,
just curious/wanting a URL reference for the future.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 1 '06 #7
Randy Webb wrote:
Jim Ley said the following on 5/1/2006 11:15 AM:
On 1 May 2006 06:07:00 -0700, "The alMIGHTY N" <na******@yahoo.com>
wrote:
Thanks a lot for your suggestions and help. I'm quite surprised that
Firefox would have gotten something wrong.

What it gets wrong is that it treats all documents as if they could be
XHTML, the requirement for a TBODY doesn't exist in XHTML, so
therefore it is valid if you have an XHTML document.

Is there a URL anywhere that documents that? I don't doubt you at all,
just curious/wanting a URL reference for the future.

http://www.w3.org/TR/xhtml1/

The element is described as optional in C.11.2 (which explains why) and
C.13.2.

--
Ian Collins.
May 2 '06 #8
Ian Collins said the following on 5/1/2006 9:13 PM:
Randy Webb wrote:
Jim Ley said the following on 5/1/2006 11:15 AM:
On 1 May 2006 06:07:00 -0700, "The alMIGHTY N" <na******@yahoo.com>
wrote:

Thanks a lot for your suggestions and help. I'm quite surprised that
Firefox would have gotten something wrong.

What it gets wrong is that it treats all documents as if they could be
XHTML, the requirement for a TBODY doesn't exist in XHTML, so
therefore it is valid if you have an XHTML document.


Is there a URL anywhere that documents that? I don't doubt you at all,
just curious/wanting a URL reference for the future.

http://www.w3.org/TR/xhtml1/

The element is described as optional in C.11.2 (which explains why) and
C.13.2.


I wasn't wanting a URL to TBody being optional, I was wondering if there
was a URL reference that shows Mozilla treating all documents as if they
could be XHTML and thus getting the TBODY wrong. Or, if the behavior is
just observed behavior and a guess at the explanation.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 2 '06 #9
On Tue, 02 May 2006 08:46:39 -0400, Randy Webb
<Hi************@aol.com> wrote:
I wasn't wanting a URL to TBody being optional, I was wondering if there
was a URL reference that shows Mozilla treating all documents as if they
could be XHTML and thus getting the TBODY wrong. Or, if the behavior is
just observed behavior and a guess at the explanation.


In that they only have a single document mode, so need to support both
xhtml and html. so I guess you'd say it was observed behaviour.

Jim.
May 2 '06 #10
VK

Randy Webb wrote:
I was wondering if there
was a URL reference that shows Mozilla treating all documents as if they
could be XHTML and thus getting the TBODY wrong. Or, if the behavior is
just observed behavior and a guess at the explanation.


It is a shifty term "treating" :-) If you mean "trying to render it"
then FF behavior is the same as for all other UA's willing to be in use
(and not W3C demos). If document is served as text/html, FF will render
it somehow anyhow.

Obviously it doesn't connect every time to w3.org to get a DTD, it uses
a build one. That would be another aspect of your question: what DTD/
tag database is build in into FF? Only one so far: XHTML 1.0 The only
namespace for HTML Firefox knows about is
xmlns:html="http://www.w3.org/1999/xhtml"
But what decision will it make based on this table - it depends
completely on the Content-Type. Say absolutely the same content with
Content-Type text/html will go through or get adjusted, but with
application/xhtml+xml will lead to a parsing error.

And if anyone curious: the build in DTD of IE6 is
<http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is the
only one it's aware of and the only one it uses. Respectively the only
type of documents existing in IE is <!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 4.01 Transitional//EN">

By providing other DTD's one can switch IE in "CSS1Compat" mode, but
it's just a formal reaction on "Unknown DTD" programmed into the
browser, DTD itself never changes. Say you can put IE into CSS1Compat
mode by placing instead:
<!DOCTYPE FOOBAR "Micro$oft must die!">
:-)

May 2 '06 #11
VK said the following on 5/2/2006 9:48 AM:
Randy Webb wrote:
I was wondering if there
was a URL reference that shows Mozilla treating all documents as if they
could be XHTML and thus getting the TBODY wrong. Or, if the behavior is
just observed behavior and a guess at the explanation.
It is a shifty term "treating" :-)


Only if you allow it to be.
If you mean "trying to render it" then FF behavior is the same as for
all other UA's willing to be in use (and not W3C demos). If document is
served as text/html, FF will render it somehow anyhow.
So you are saying it totally disregards the DTD and any hints from the
server how to handle the document?
Obviously it doesn't connect every time to w3.org to get a DTD, it uses
a build one.
So you are saying, again, that DTD's are irrelevant?
That would be another aspect of your question: what DTD/
tag database is build in into FF? Only one so far: XHTML 1.0 The only
namespace for HTML Firefox knows about is
xmlns:html="http://www.w3.org/1999/xhtml"
If that is true, then Firefox is not even close to Standards Compliant.
But what decision will it make based on this table - it depends
completely on the Content-Type. Say absolutely the same content with
Content-Type text/html will go through or get adjusted, but with
application/xhtml+xml will lead to a parsing error.
Odd behavior if you tell it text/html with a 4.01 DTD
And if anyone curious: the build in DTD of IE6 is
<http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is the
only one it's aware of and the only one it uses. Respectively the only
type of documents existing in IE is <!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 4.01 Transitional//EN">
Now that I don't believe.
By providing other DTD's one can switch IE in "CSS1Compat" mode, but
it's just a formal reaction on "Unknown DTD" programmed into the
browser, DTD itself never changes.
Can you prove that?
Say you can put IE into CSS1Compat mode by placing instead:
<!DOCTYPE FOOBAR "Micro$oft must die!">


Does the fun never end?

document.doctype gives some neat info in Firefox though.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 2 '06 #12
VK

Randy Webb wrote:
VK said the following on 5/2/2006 9:48 AM:
If you mean "trying to render it" then FF behavior is the same as for
all other UA's willing to be in use (and not W3C demos). If document is
served as text/html, FF will render it somehow anyhow.
So you are saying it totally disregards the DTD and any hints from the
server how to handle the document?


Except server reported Content-Type (text/plain, text/html, text/xml,
application/xhtml+xml etc.)
DTD string itself is irrelevant (and this string by itself is not a
"hint from the server" but a "hint from the document").

Obviously it doesn't connect every time to w3.org to get a DTD, it uses
a build one.


So you are saying, again, that DTD's are irrelevant?

From the document parsing point of view: yes, absolutely irrelevant. They have some theoretical importance for documents' indexing and
searching. Most importantly DTD allows - so far - to switch IE into W3C
box model (unless short HTML Transitional). Without the latter their
usage would be limited by ciwas and ciwah exclusively.

That would be another aspect of your question: what DTD/
tag database is build in into FF? Only one so far: XHTML 1.0 The only
namespace for HTML Firefox knows about is
xmlns:html="http://www.w3.org/1999/xhtml"


If that is true, then Firefox is not even close to Standards Compliant.


It is true, but Firefox *is* Standards Compliant - as much as it's
humanly possible without rendering a UA useless and by keeping it
attractive for potential users.

But what decision will it make based on this table - it depends
completely on the Content-Type. Say absolutely the same content with
Content-Type text/html will go through or get adjusted, but with
application/xhtml+xml will lead to a parsing error.


Odd behavior if you tell it text/html with a 4.01 DTD


WWW doesn't go by extensions or formal document signs, never did and
never will. The only important part is Content-Type. It defines
everything.
And if anyone curious: the build in DTD of IE6 is
<http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is the
only one it's aware of and the only one it uses. Respectively the only
type of documents existing in IE is <!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 4.01 Transitional//EN">


Now that I don't believe.


As you wish. But you believe or disbelieve doesn't change anything in
this matter. The only "major" change expecting in IE7 will be <abbr>
element added as separate entity (now it goes as synonim or <acronym>).
Of course IE knows a bounch of other proprietary tags. It has tables
for behaviors (<public>, <component>, <attach> etc.), tables for VML
(<v:group>, <v:line>, <v:oval> etc.) and so on. But talking about
*those* DTD - from W3C - the above mentioned DTD is the only one.

By providing other DTD's one can switch IE in "CSS1Compat" mode, but
it's just a formal reaction on "Unknown DTD" programmed into the
browser, DTD itself never changes.


Can you prove that?


Oh com'on! Again: "prove me that the sky is blue" ? :-)

<!DOCTYPE FOOBAR "Micro$oft must die!">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body onload="alert(document.compatMode)">
</body>
</html>

Say you can put IE into CSS1Compat mode by placing instead:
<!DOCTYPE FOOBAR "Micro$oft must die!">


Does the fun never end?


See above
document.doctype gives some neat info in Firefox though.


document.doctype is just a convenience access to the provided DTD
string wich is hardly accessible otherwise (because it's formally
located outside of any document blocks, even outside of
documentElement). In IE document.doctype==null for all HTML documents -
to not make DTD users too much upset I guess.

May 3 '06 #13
"VK" <sc**********@yahoo.com> writes:
Randy Webb wrote:
So you are saying, again, that DTD's are irrelevant?


From the document parsing point of view: yes, absolutely irrelevant.


The document type declaration subset ist absolutely relevant if the
document instance is not fully- or amply-tagged and absolutely
irrelevant for rendering.

For HTML as of UAs in the wild it's the other way around of course; but
as usual, it's not really clear what you actually mean, which seems to
be your general discussion strategy.
They have some theoretical importance for documents' indexing and
searching.
¿Que?
Most importantly DTD allows - so far - to switch IE into W3C
box model (unless short HTML Transitional). Without the latter their
usage would be limited by ciwas and ciwah exclusively.
Try to get a clue; the target audience scope of 'DTD users' is not a
particular news group but simply those people who care to employ
software that can process the declaration subset in the *authoring*
process, where it belongs.
And if anyone curious: the build in DTD of IE6 is
<http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd>


1) Clarify what you mean by that, if anything
2) Please finish step 1 1st
3) Provide evidence
<!DOCTYPE FOOBAR "Micro$oft must die!">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body onload="alert(document.compatMode)">


The point being? And as the declaration above is invalid in any
scenario you could boil it down to the string which is relevant for M$IE
here, namely '<!DOCTYPE', e.g.

<!DOCTYPE<html><body onload="alert(document.compatMode)">
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
May 3 '06 #14
VK
The thread is moved to ciwah as OT to clj.

One may look at
<http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_frm/thread/4ac44109aac7fa53/9849c2f0f8ec9a28>

May 3 '06 #15
In article <11*********************@j73g2000cwa.googlegroups. com>,
"VK" <sc**********@yahoo.com> wrote:
Randy Webb wrote:
So you are saying it totally disregards the DTD and any hints from the
server how to handle the document?


Except server reported Content-Type (text/plain, text/html, text/xml,
application/xhtml+xml etc.)
DTD string itself is irrelevant (and this string by itself is not a
"hint from the server" but a "hint from the document").


The DTD is irrelevant (it is not fetched). However, for text/html, the
doctype is relevant:
http://hsivonen.iki.fi/doctype/
They have some theoretical importance for documents' indexing and
searching.
No, they do not.
Most importantly DTD allows - so far - to switch IE into W3C
box model (unless short HTML Transitional).
And Firefox. And Opera. And Safari.
WWW doesn't go by extensions or formal document signs, never did and
never will. The only important part is Content-Type. It defines
everything.


Except, of course, when it doesn't.
And if anyone curious: the build in DTD of IE6 is
<http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is the
only one it's aware of and the only one it uses.


IE does not have built-in DTDs at all. The parsing is not DTD-based.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
May 3 '06 #16
VK

Henri Sivonen wrote:
The DTD is irrelevant (it is not fetched). However, for text/html, the
doctype is relevant:
http://hsivonen.iki.fi/doctype/


Not for IE6... "not exactly" for a better wording. This browser has
four options for two states (backCompat and CSS1Compat):

Option 1: No DTD at all
compatMode -> backCompat == IE box model

Option 2: Short Transitional (no URI)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
compatMode -> backCompat == IE box model

Option 3: Full Transitional (with URI)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html401/loose.dtd">
compatMode -> CSS1Compat == W3C box model

Option 4: Any text within <!.. > brackets as the first line in the
document except Option 2
compatMode -> CSS1Compat == W3C box model

In this aspect say both
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> and
<!DOCTYPE FOOBAR "Micro$oft must die!">

are going by the Option 4

On more than one <> pair before <html> tag IE treats everything as
trash and disregards until it hits a pair starting with <!DOCTYPE...
This way in XHTML agglomerate like
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
it sees only the last <> pair and goes by Option 4.
Actually the above agglomerate makes me wonder myself because it's a
wrong syntax for XML documents (if it pretends to be such).

They have some theoretical importance for documents' indexing and
searching.


No, they do not.


*theoretically* ;-)
Most importantly DTD allows - so far - to switch IE into W3C
box model (unless short HTML Transitional).


And Firefox. And Opera. And Safari.


No, because it's impossible. Firefox and others do not have IE box
model one could switch on or off. They have only one box model -
irrelevant of DTD.

WWW doesn't go by extensions or formal document signs, never did and
never will. The only important part is Content-Type. It defines
everything.


Except, of course, when it doesn't.


As if?

> And if anyone curious: the build in DTD of IE6 is
> <http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is the
> only one it's aware of and the only one it uses.


IE does not have built-in DTDs at all. The parsing is not DTD-based.


Of course it does: otherwise how it would decide that tag to render and
how, what attributes to use for rendering and what to disregard? It
does have the above mentioned DTD - but of course not in the text
format as posted at the URL, it's binary coded in its parser.

May 3 '06 #17
VK
Damn, somebody messed up followups... must be me... sorry

May 3 '06 #18
VK wrote:
Randy Webb wrote:
VK said the following on 5/2/2006 9:48 AM: <snip>
And if anyone curious: the build in DTD of IE6 is
http://www.w3c.org/TR/1999/REC-html4...1224/loose.dtd
This is the only one it's aware of and the only one it uses.
Respectively the only type of documents existing in IE is
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <snip> By providing other DTD's one can switch IE in "CSS1Compat" mode,
but it's just a formal reaction on "Unknown DTD" programmed into
the browser, DTD itself never changes.
Can you prove that?


Oh com'on! Again: "prove me that the sky is blue" ? :-)


Experience has told us that your perception of blue looks far too
magenta for anything you say to be beyond question. Indeed so magenta at
times that it makes more sense to assume that everything you say is
nonsense.

In this case you are asserting that:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

- is the only formulation of <!DOCTYPE ... > that IE is 'aware' of, and
that _all_ others are "Unknown DTD" and that the use of an "Unknown DTD"
will result in IE going into standards mode (as manifest in the JScript
expression - document.compatMode - returning the string "CSS1Compat").
<!DOCTYPE FOOBAR "Micro$oft must die!">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body onload="alert(document.compatMode)">
</body>
</html>


So if I substitute:-

<!DOCTYPE FOOBAR "Micro$oft must die!" HTML 3>

In the above IE will consider this an "Unknown DTD" and the javascript
will alert "CSS1Compat"? But it doesn't, it alerts "BackCompat",
indicating that it went into quirks mode. And it does the same with:-

<!DOCTYPE HTML 4.99>
<!DOCTYPE HTML 40>
<!DOCTYPE HTML 200000000 ANY OLD RUBBISH>
<!DOCTYPE html 3210987654>
- and:-
<!DOCTYPE ANY OLD RUBBISH HTML 200000000>

- along with literally millions of other permutations.

This, of course, demonstrates that what you have been whitening on about
is utter nonsense, again. You would benefit considerably by
understanding that making things up off the top of your head and then
asserting that they are as true as "the sky is blue" is not the rout to
understanding, and certainly will not convince anyone to take you
seriously.

Richard.
May 3 '06 #19
In article <11**********************@g10g2000cwb.googlegroups .com>,
"VK" <sc**********@yahoo.com> wrote:
Henri Sivonen wrote:
The DTD is irrelevant (it is not fetched). However, for text/html, the
doctype is relevant:
http://hsivonen.iki.fi/doctype/
Not for IE6... "not exactly" for a better wording. This browser has
four options for two states (backCompat and CSS1Compat):


Let me guess. You did not read the document referenced above.
Option 4: Any text within <!.. > brackets as the first line in the
document except Option 2
compatMode -> CSS1Compat == W3C box model
Like <!DOCTYPE HTML PUBLIC "ISO/IEC 15445:1999//DTD HTML//EN"> perhaps?
;-)
This way in XHTML agglomerate like
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
it sees only the last <> pair and goes by Option 4.


Are you sure?
Most importantly DTD allows - so far - to switch IE into W3C
box model (unless short HTML Transitional).


And Firefox. And Opera. And Safari.


No, because it's impossible. Firefox and others do not have IE box
model one could switch on or off. They have only one box model -
irrelevant of DTD.


Actually, earlier versions of Opera did have the IE box model in the
quirks mode. My point was that even though they don't have the exact IE
box model quirks, they do doctype sniffing nonetheless.
WWW doesn't go by extensions or formal document signs, never did and
never will. The only important part is Content-Type. It defines
everything.


Except, of course, when it doesn't.


As if?


http://ln.hixie.ch/?start=1144794177&count=1
> > And if anyone curious: the build in DTD of IE6 is
> > <http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is
> > the
> > only one it's aware of and the only one it uses.


IE does not have built-in DTDs at all. The parsing is not DTD-based.


Of course it does: otherwise how it would decide that tag to render and
how, what attributes to use for rendering and what to disregard?


From hand-crafted C++ code and from CSS.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
May 3 '06 #20
VK wrote:
Richard Cornford wrote:
In this case you are asserting that:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

- is the only formulation of <!DOCTYPE ... > that IE is 'aware' of
right
and
that _all_ others are "Unknown DTD" and that the use of an
"Unknown DTD" will result in IE going into standards mode
(as manifest in the JScript expression - document.compatMode
- returning the string "CSS1Compat").


I'm using document.compatMode value only for a quick demo. From a
practical point of view it is irrelevant what document.compatMode
property is set to. What *is* relevant if IE in IE Box Model or W3C
Box Model. So a real "manifestation" would be say a div with
width:100% with margin/padding set inside another element and the
rendering change. But for a quick demo document.compatMode value
does the trick.


What are you whittering about now? The - document.compatMode - property
exposed to scripts is there to state the mode the browser is operating
in. For IE, if one value then one box model, always, and if the other
value then the other box model.
So if I substitute:-

<!DOCTYPE FOOBAR "Micro$oft must die!" HTML 3>

In the above IE will consider this an "Unknown DTD"


No. It will consider it as a non-rendering trash before the opening
<html> tag.
You are missing the difference between "Unrecognized DTD declaration"
like
<!DOCTYPE FOOBAR "Micro$oft must die!">
and "Not a DTD declaration at all" like
<!DOCTYPE FOOBAR "Micro$oft must die!" HTML 3>


ROTFLOL

<!DOCTYPE FOOBAR "Micro$oft must die!" HTML 3>

- Quirks mode, and:-

<!DOCTYPE FOOBAR "Micro$oft must die!" HTML 5>

- Standards mode. If IE considers either as "Not a DTD declaration at
all" because of its format it must consider both of them not to be DTDs,
and treat them the same, it doesn't treat them the same.

<snip> Change <!DOCTYPE FOOBAR "Micro$oft must die!" HTML 3> back to
<!DOCTYPE FOOBAR "Micro$oft must die!"> - and the parser will hit a
match right away.


And change it to:-

<!DOCTYPE FOOBAR "Micro$oft must die! HTML 30">

- and we are back to quirks mode. There is no point in your winding
around trying to justify your nonsense. You made it up off the top of
your head so the odds are that it does not describe reality.

Richard.
May 3 '06 #21
VK wrote:
It is true, but Firefox *is* Standards Compliant - as much as it's
humanly possible without rendering a UA useless and by keeping it
attractive for potential users.


Nonsense. Firefox doesn't support, for example, 'font-size-adjust'[1] from
the CSS 2 spec, but doing so wouldn't make it less attractive to potential
users.

And there are plenty[2] of other bug-fixes and improvements to standards
compliance that could be implemented without making it less attractive to
users.

____
1. http://www.w3.org/TR/REC-CSS2/fonts....nt-size-adjust
2. https://bugzilla.mozilla.org/show_bug.cgi?id=238072
https://bugzilla.mozilla.org/show_bug.cgi?id=325680
https://bugzilla.mozilla.org/show_bug.cgi?id=318518
https://bugzilla.mozilla.org/show_bug.cgi?id=178258
https://bugzilla.mozilla.org/show_bug.cgi?id=312880
https://bugzilla.mozilla.org/show_bug.cgi?id=311942
https://bugzilla.mozilla.org/show_bug.cgi?id=311623
etc

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

May 4 '06 #22
ASM
Toby Inkster a écrit :
Firefox doesn't support, for example, 'font-size-adjust'[1] from
the CSS 2 spec,
____
1. http://www.w3.org/TR/REC-CSS2/fonts....nt-size-adjust
anyway ...
any of my browsers (Safari 1.3, Opera 9.00, IE 5.2, Fx 1.5.0.3)
supports this spec :-(

And there are plenty[2] of other bug-fixes and improvements to standards
compliance that could be implemented without making it less attractive to
users.

2. https://bugzilla.mozilla.org/show_bug.cgi?id=238072
My English is too poor to understand whatever about this reports
Where are examples for encountered problems ?
etc


--
Stephane Moriaux et son [moins] vieux Mac
May 4 '06 #23
VK

Henri Sivonen wrote:
"VK" <sc**********@yahoo.com> wrote:
Henri Sivonen wrote:
The DTD is irrelevant (it is not fetched). However, for text/html, the
doctype is relevant:
http://hsivonen.iki.fi/doctype/


Not for IE6... "not exactly" for a better wording. This browser has
four options for two states (backCompat and CSS1Compat):


Let me guess. You did not read the document referenced above.


Now I did. It is a nice table there, but AFAICT you build it with the
same wrong assumption of how really DTD sniffing works, at least in IE.
Without it it will be just a record of test results, not an
explanation. The real explanation and relevant links see in my post in
this thread. Besides the results listed in your table it also explain
why say
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 222//EN">
leaves IE in BackCompat mode while
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 666//EN">
switches it into CSS1Compat mode.

Your table also doesn't tell anything about "Unrecognized DTD"
situation, thus about even perfectly valid DTD but not from W3C lists.
It is often forgotten but DTD files creation is not an exclusive right
of W3C. Everyone is welcome (and it's widely used in XML) to create own
DTD's for a particular set of documents.

Option 4: Any text within <!.. > brackets as the first line in the
document except Option 2
compatMode -> CSS1Compat == W3C box model


Like <!DOCTYPE HTML PUBLIC "ISO/IEC 15445:1999//DTD HTML//EN"> perhaps?
;-)


:-)
No, this gives BackCompat. If you have "HTML" string in DTD, it has to
be followed by <space><number 5 or greater> in order to trig CSS1Compat
mode, see my post.
This way in XHTML agglomerate like
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
it sees only the last <> pair and goes by Option 4.


Are you sure?

Here you got me: indeed XHTML declaration soup nocks IE out and it
simply ignores everything until <html> tag (so staying in BackCompat
mode). So the parsing rule is more narrow as I though: it must be only
one string before <html> and it must start with "<!DOCTYPE" in order to
parser to pick up on it.

The practical conclusion would be never use "fully qualified" XHTML
declarations (with <?xml version="1.0" encoding="iso-8859-1"?>) in
documents served as text/html. Besides all other drawbacks it forces IE
to stay in quirk mode.

The rest goes by my explanations though. The only text (besides
!DOCTYPE) the parser is interested in is "HTML" or "XHTML" sequences.
Say to have CSS1Compat mode it is enough to place <!DOCTYPE XHTML>
> Most importantly DTD allows - so far - to switch IE into W3C
> box model (unless short HTML Transitional).

And Firefox. And Opera. And Safari.


No, because it's impossible. Firefox and others do not have IE box
model one could switch on or off. They have only one box model -
irrelevant of DTD.


Actually, earlier versions of Opera did have the IE box model in the
quirks mode. My point was that even though they don't have the exact IE
box model quirks, they do doctype sniffing nonetheless.


Point taken.
> WWW doesn't go by extensions or formal document signs, never did and
> never will. The only important part is Content-Type. It defines
> everything.

Except, of course, when it doesn't.


As if?


http://ln.hixie.ch/?start=1144794177&count=1


Uhm... It seems like a message from another planet to me :-) At least
nothing similar in 100 miles area around me in the last 7 years. But
Switzerland is known for many specifics, so maybe it's true for the
area. But I would guess that the author simply mis-interpreted the
rumors about hackers attacks using Content-Type tricks. Originally some
..src indeed presumed only one content type, and it was used to serve
malicious content into them. But it was in 4th era. Later it was
another trick by serving proper Content-Type but followed by a wrong
malicious content (that is more recent, the last case was for images
for Windows XP below SP2). For the latter hack browser producers indeed
had to add some binary content check to see if it corresponds to the
Content-Type. But it has nothing to do with "Content-Type is useless
and disregarded". Just a small part of ever lasting battle with
hackers.

> > > And if anyone curious: the build in DTD of IE6 is
> > > <http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is
> > > the
> > > only one it's aware of and the only one it uses.

IE does not have built-in DTDs at all. The parsing is not DTD-based.


Of course it does: otherwise how it would decide that tag to render and
how, what attributes to use for rendering and what to disregard?


From hand-crafted C++ code and from CSS.


And C++ code is made based on... right,
<http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> :-)

May 5 '06 #24
In article <11********************@e56g2000cwe.googlegroups.c om>,
"VK" <sc**********@yahoo.com> wrote:
Henri Sivonen wrote:
"VK" <sc**********@yahoo.com> wrote:
Henri Sivonen wrote:
> The DTD is irrelevant (it is not fetched). However, for text/html, the
> doctype is relevant:
> http://hsivonen.iki.fi/doctype/

Not for IE6... "not exactly" for a better wording. This browser has
four options for two states (backCompat and CSS1Compat):
Let me guess. You did not read the document referenced above.


Now I did. It is a nice table there, but AFAICT you build it with the
same wrong assumption of how really DTD sniffing works, at least in IE.


What's my wrong assumption?

If you believe that the quoted "The DTD is irrelevant (it is not
fetched). However, for text/html, the doctype is relevant" is my wrong
assumption, I assure you that the assumption is right as far as
text/html in IE goes and you need to be more precise about the words
doctype and DTD.
Without it it will be just a record of test results, not an
explanation.
Explaining the exact inner workings is not the goal of that document.
The goal of the document is to
a) explain why weird stuff happens (to people who don't
realize doctype sniffing is taking place)
b) motivate people to use the Standards more or at least
the Almost Standards mode.
I believe I give enough facts to meet these goals. I am deliberately
withholding details that I believe would either obscure the main point
or would make people feel too confident about deliberately using the
Quirks mode or deliberately using a doctype other than the two I've been
recommending for almost six years now.

(I will recommend the HTML5 doctype, when the spec stabilizes.)
The real explanation and relevant links see in my post in
this thread.
FWIW, I have read the relevant code from the Gecko and WebKit codebases.
(Have you?) I don't have access to the code of Opera, Mac IE 5 or
Windows IE 6, so I could only speculate based on black box testing.
While it would be interesting for the curious, I fail to see why J.
Random Web author would need to see that speculation.
Your table also doesn't tell anything about "Unrecognized DTD"
situation, thus about even perfectly valid DTD but not from W3C lists.
I have left it out deliberately in order to discourage people from using
them.
It is often forgotten but DTD files creation is not an exclusive right
of W3C. Everyone is welcome (and it's widely used in XML) to create own
DTD's for a particular set of documents.
Homegrown DTDs for XML are legitimate for XML (but still arguably a bad
idea on the Web). It is not so clear whether homegrown DTDs are
appropriate for text/html.
http://ln.hixie.ch/?start=1144794177&count=1

But I would guess that the author simply mis-interpreted the
rumors about hackers attacks using Content-Type tricks.


He wasn't going by rumors. He has actually worked for Netscape and Opera
and also followed the bug database of Safari.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
May 5 '06 #25
VK

Henri Sivonen wrote:
What's my wrong assumption?
That browser indeed treats quoted part of DTD as a unit (a la opaque
strings in namespace declarations). Sorry if I'm wrong and it was not
your assumption.
FWIW, I have read the relevant code from the Gecko and WebKit codebases.
(Have you?) I don't have access to the code of Opera, Mac IE 5 or
Windows IE 6, so I could only speculate based on black box testing.
While it would be interesting for the curious, I fail to see why J.
Random Web author would need to see that speculation.


I see... Ignorance is the bless ;-)
Your table also doesn't tell anything about "Unrecognized DTD"
situation, thus about even perfectly valid DTD but not from W3C lists.


I have left it out deliberately in order to discourage people from using
them.


I see... Ignorance is the bless ;-)
It is often forgotten but DTD files creation is not an exclusive right
of W3C. Everyone is welcome (and it's widely used in XML) to create own
DTD's for a particular set of documents.


Homegrown DTDs for XML are legitimate for XML (but still arguably a bad
idea on the Web). It is not so clear whether homegrown DTDs are
appropriate for text/html.


Proprietary DTD's are fully OK for XML, thus for XML+XSL transformers.
It can be a transformer producing the resulting document of type
text/foobar and respective DTD defining element <foobar> with allowed
attributes CDATA foo and logical bar. That is pretty close to how
Windows Vista file management will work - thus some part of Web
resources. But you may expect at the very least another year of
peaceful life :-)
http://ln.hixie.ch/?start=1144794177&count=1

But I would guess that the author simply mis-interpreted the
rumors about hackers attacks using Content-Type tricks.


He wasn't going by rumors. He has actually worked for Netscape and Opera
and also followed the bug database of Safari.


Then his statement gets really strange - especially when anyone can
prove it wrong. The very same intentionally broken XHTML document (no
closing tag in list elements) demostrates completely different behavior
if served with Content-Type text/html:
<http://www.nskom.com/external/tmp/html/xhtml.html>
and with Content-Type application/xhtml+xml
<http://www.nskom.com/external/tmp/xhtml/xhtml.html>

I'm very far of thinking that the author is not current on the subject.
Then it may be explained by his bias. Maybe it's all about your
discussions here about XHTML served with text/html Content-Type. In
such case the mentioned article would be an attempt to "bring a peace
into starving souls" :-) Like if Content-Type is meaningless and
disregarded anyway, then it's not important what Content-Type to use.
The next logical conclusion out if it would be to try to serve
documents without Content-Type at all - let UA bothers with it by
formal signs. Anyone tryed it already?

May 5 '06 #26
On 05/05/2006 17:45, VK wrote:
Henri Sivonen wrote:
What's my wrong assumption?
That browser indeed treats quoted part of DTD as a unit [...]


You still have your terms confused. The DTD is the document type
definition; the syntax, if you will. The 'doctype', or document type
declaration, is the <!DOCTYPE ...> notation near the start of a document.

[snip]
http://ln.hixie.ch/?start=1144794177&count=1
That entry makes my skin crawl. I can understand Ian's reasoning, but
still... *ick*
But I would guess that the author simply mis-interpreted the
rumors about hackers attacks using Content-Type tricks.


He wasn't going by rumors. He has actually worked for Netscape and Opera
and also followed the bug database of Safari.


Then his statement gets really strange - especially when anyone can
prove it wrong.


This'll be interesting...
The very same intentionally broken XHTML document (no
closing tag in list elements) demostrates completely different behavior
if served with Content-Type text/html:
<http://www.nskom.com/external/tmp/html/xhtml.html>
and with Content-Type application/xhtml+xml
<http://www.nskom.com/external/tmp/xhtml/xhtml.html>


And in what context are you making that statement?

Does Firefox exhibit very different behaviour? Sure, but Ian stated that
browsers "*largely* ignore the HTTP Content-Type header" (emphasis mine).

Does IE exhibit very different behaviour? No. It ignores the
Content-Type HTTP header and parses the document as tag-soup HTML (as
indicated by the meta element, even though it should have been superseded).

[snip]

Mike
c.l.javascript has been removed from follow-ups.

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
May 5 '06 #27
In article <11*********************@g10g2000cwb.googlegroups. com>,
"VK" <sc**********@yahoo.com> wrote:
Henri Sivonen wrote:
What's my wrong assumption?
That browser indeed treats quoted part of DTD as a unit (a la opaque
strings in namespace declarations). Sorry if I'm wrong and it was not
your assumption.


Gecko and WebKit indeed extract the public id as a string, fold it to
lower case and match the resulting string as an opaque string against a
list of known lowercased quirky public ids and almost standards mode
public ids. Like I said, I have not seen the source of IE, so I'm
refraining from claiming to know how exactly it does what it does.
I see... Ignorance is the bless ;-)
ITYM bliss. ;-)
Homegrown DTDs for XML are legitimate for XML (but still arguably a bad
idea on the Web). It is not so clear whether homegrown DTDs are
appropriate for text/html.


Proprietary DTD's are fully OK for XML, thus for XML+XSL transformers.


DTDs on the Web are a bad idea, because processing them is optional and
DTDs cause infoset augmentation, so the infoset reported to the
application may be different depending on whether the DTD was processed
or not.
That is pretty close to how Windows Vista file management will work


Eh?
> http://ln.hixie.ch/?start=1144794177&count=1

But I would guess that the author simply mis-interpreted the
rumors about hackers attacks using Content-Type tricks.


He wasn't going by rumors. He has actually worked for Netscape and Opera
and also followed the bug database of Safari.


Then his statement gets really strange - especially when anyone can
prove it wrong.


He said "largely ignore". Your example is one of the cases not covered
by "largely".

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
May 6 '06 #28
VK wrote:
Richard Cornford wrote:
VK wrote:
<snip>
Change <!DOCTYPE FOOBAR "Micro$oft must die!" HTML 3>
back to <!DOCTYPE FOOBAR "Micro$oft must die!"> - and
the parser will hit a match right away.
And change it to:-

<!DOCTYPE FOOBAR "Micro$oft must die! HTML 30">

- and we are back to quirks mode.


and change it to <!DOCTYPE FOOBAR "Micro$oft must die! XHTML 30">
and we are back to CSS1Compat mode.

and now remove "DOCTYPE" word: <!FOOBAR "Micro$oft must die!
XHTML 30"> and we are back to BackCompat mode.


Yes. When you attempted to dismiss formulations of DOCTYPE that were
"Unknown DTD" but still resulted in quirks mode because they were "Not a
DTD declaration at all" due to their format you were demonstrably wrong.
And similarly a DOCTYPE that you consider did not qualify as "Not a DTD
declaration at all" (had what you consider an acceptable format) but was
still an "Unknown DTD" could also result in IE operating in quirks mode.

They prove that your original assertion, the one that you suggested was
so self-evidently true that being asked to prove it was akin to being
asked to "prove me that the sky is blue", is in fact utterly false. That
it was, as expected, another fiction that you made up off the top of
your head.
Someone (not me) just refuses to read the relevant
producer's documentation and prefers to make up her
own picture.
You are the individual here making false claims about IE's behaviour and
assessing that they are as true as "the sky is blue". I couldn't care
less about the exact algorithm IE uses. Any interest in that detail, and
time expended trying to deduce it from the behaviour, is utterly wasted.
It doesn't matter because:-

1. No other browser is likely to use precisely the same algorithm
to make similar determinations.
2. There is nothing that can be done with the information that
cannot be done without it (that is, an author may take total
control of which of the two modes apply to a particular HTML
document with no more information that that the DOCTYPEs
proposed in the HTML specifications will result in standards
mode and that no DOCTYPE at all will result in quirks mode. No
more than that can be achieved by knowing the precise location
and shape of the demarcation that IE draws between the two).
And the needed reading is ...
.... not needed. The falsity of your "the sly is blue" assertion has
already been demonstrated.
But I can make the challenge even less challenging :-)
by giving you a plain words summary:

1) IE treats any string starting with <!DOCTYPE before
<html> tag as a DTD
In the parsing of HTML documents what would qualify as "any string
starting .. "? Or even as a "string"?
2) If it meets such string then it looks for substring
HTML<space><number>

<snip>

So you are describing behaviour that is utterly different from your
original "the sky is blue" assertion? That was a fiction, and its being
questions was completely reasonable.

This, where are we now, third - fourth, formulation is as likely to be
guess-work as any of the preceding ones (even if you could express it in
suitable terminology). Without seeing Microsoft's source code the
reality of the precise behaviour would be difficult to deduce, and
particularly by someone with as little talent for analyses and logic as
you demonstrate. But above all, the pursuit of that information is an
irrelevance; a waste of time and effort that, even if successful, could
not result in anything of any greater use than knowing how to control
the outcome, as we already do.

Richard.
May 6 '06 #29
Henri Sivonen wrote:
In article <11*********************@j73g2000cwa.googlegroups. com>,
"VK" <sc**********@yahoo.com> wrote:
Randy Webb wrote:
> So you are saying it totally disregards the DTD and any hints from the
> server how to handle the document?
Except server reported Content-Type (text/plain, text/html, text/xml,
application/xhtml+xml etc.)
DTD string itself is irrelevant (and this string by itself is not a
"hint from the server" but a "hint from the document").


The DTD is irrelevant


Not at all.
(it is not fetched).


It is not fetched by tagsoup parsers in many known Web browsers because it
is built-in there. It is definitely fetched by XML parsers in known Web
browsers.
> > And if anyone curious: the build in DTD of IE6 is
> > <http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd> This is
> > the only one it's aware of and the only one it uses.


IE does not have built-in DTDs at all. The parsing is not DTD-based.


I would like to see proof of this. However, since we are talking about
closed source, I don't think there will be any. Still, even IE's parser
MUST implement a set parsing rules, as they are described by a DTD.
F'up2 ciwam

PointedEars
--
There are two possibilities: Either we are alone in the
universe or we are not. Both are equally terrifying.
-- Arthur C. Clarke
May 13 '06 #30

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

Similar topics

21
by: Dave | last post by:
After following Microsofts admonition to reformat my system before doing a final compilation of my app I got many warnings/errors upon compiling an rtf file created in word. I used the Help...
9
by: Tom | last post by:
A question for gui application programmers. . . I 've got some GUI programs, written in Python/wxPython, and I've got a help button and a help menu item. Also, I've got a compiled file made with...
6
by: wukexin | last post by:
Help me, good men. I find mang books that introduce bit "mang header files",they talk too bit,in fact it is my too fool, I don't learn it, I have do a test program, but I have no correct doing...
3
by: Colin J. Williams | last post by:
Python advertises some basic service: C:\Python24>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) on win32 Type "help", "copyright", "credits" or "license" for more information. >>> With...
7
by: Corepaul | last post by:
Missing Help Files When I enter "recordset" as the keyword and search the Visual Basic Help index, I get many topics of interest in the resulting list. But there isn't any information available...
5
by: Steve | last post by:
I have written a help file (chm) for a DLL and referenced it using Help.ShowHelp My expectation is that a developer using my DLL would be able to access this help file during his development time...
8
by: Mark | last post by:
I have loaded Visual Studio .net on my home computer and my laptop, but my home computer has an abbreviated help screen not 2% of the help on my laptop. All the settings look the same on both...
10
by: JonathanOrlev | last post by:
Hello everybody, I wrote this comment in another message of mine, but decided to post it again as a standalone message. I think that Microsoft's Office 2003 help system is horrible, probably...
1
by: trunxnirvana007 | last post by:
'UPGRADE_WARNING: Array has a new behavior. Click for more: 'ms-help://MS.VSCC.v80/dv_commoner/local/redirect.htm?keyword="9B7D5ADD-D8FE-4819-A36C-6DEDAF088CC7"' 'UPGRADE_WARNING: Couldn't resolve...
0
by: hitencontractor | last post by:
I am working on .NET Version 2003 making an SDI application that calls MS Excel 2003. I added a menu item called "MyApp Help" in the end of the menu bar to show Help-> About. The application...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
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...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
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...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

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.