By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,563 Members | 1,058 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,563 IT Pros & Developers. It's quick & easy.

?xml Prolog & Box Model Issues in IE6

P: n/a
CJM
I'm in the process of partially revamping a corporate website. My main brief
was to reorganise much of the content and to update a lot of the copy, but
in the process I'm also trying to correct some of the technical aspects. The
site looks OK, but under the hood it is an abomination; it was designed by a
marketing company seemed to thing they were also web designers because they
owned a copy of Dreamweaver.

Amongst other things, I've replaced most of the images that were there
instead of headers(!); and I'm tackling the menu system that consisted
entirely of images (of text) with javascript rollovers.

But I can't change it all at this stage, so I'm still constrained by much of
the original design. I've replaced the image rollovers with the expected
html+css alternative. However, I'm finding a small problem under IE6 (I'm
testing under IE6, IE7, FF2 & Opera9); when I expand the menu to reveal the
sub-menu items, the background for these items is not full shaded.

I've bodged up a page to demonstrate:
http://www.brightnorth.com/cjm/emx/apps2.html

I assumed it was some sort of Box Model issue, and after a bit of
investigation I found that it indeed was... apparently IE6 reverts to the
quirky box model behaviour of IE5 if you include the ?xml prolog in an XHTML
page.

So I remove the offending line (ie the first) from the page and tested. Et
Voila! It works fine: http://www.brightnorth.com/cjm/emx/apps2.html

I've read in one place that this line is optional anyway, and can be
ignored; but lots of guides behave as if it compulsary. But I was wondering
what conventional wisdom says. Surely missing the prolog out it the best
options? Or are there reasons to keep it in? I don't fancy the idea of
inserting hacks to compensate.

Any thoughts?

CJM
Jan 11 '07 #1
Share this Question
Share on Google+
39 Replies


P: n/a
Scripsit CJM:
apparently IE6 reverts to
the quirky box model behaviour of IE5 if you include the ?xml prolog
in an XHTML page.
Indeed. _Anything_ before the DOCTYPE declaration causes that. I don't think
there's any other explanation than lazyness: people who wrote the "DOCTYPE
sniffing" code in IE didn't bother looking past the first line to find a
DOCTYPE declaration.
I've read in one place that this line is optional anyway, and can be
ignored;
By XML specifications, it SHOULD be there, but it is not required, if one of
the following is true:
a) the document's encoding is UTF-8
b) the document's encoding is UTF-16 (and the document starts with BOM)
c) there is an HTTP header specifying the encoding.

For an "official" tutorial on specifying the encoding, see
http://www.w3.org/International/tuto...rial-char-enc/
Surely missing the prolog out it the best options?
It's a simple one, but it's really feasible only when UTF-8 is used. Option
b, using UTF-16, is not practical on the web, due to poor support in
browsers and search engines. Relying on c) is somewhat risky, since the
document might be saved locally (e.g., by a user) in a manner that loses
information about HTTP headers.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 11 '07 #2

P: n/a

CJM wrote:
I'm in the process of partially revamping a corporate website. My main brief
was to reorganise much of the content and to update a lot of the copy, but
in the process I'm also trying to correct some of the technical aspects. The
site looks OK, but under the hood it is an abomination; it was designed by a
marketing company seemed to thing they were also web designers because they
owned a copy of Dreamweaver.

Amongst other things, I've replaced most of the images that were there
instead of headers(!); and I'm tackling the menu system that consisted
entirely of images (of text) with javascript rollovers.

But I can't change it all at this stage, so I'm still constrained by much of
the original design. I've replaced the image rollovers with the expected
html+css alternative. However, I'm finding a small problem under IE6 (I'm
testing under IE6, IE7, FF2 & Opera9); when I expand the menu to reveal the
sub-menu items, the background for these items is not full shaded.

I've bodged up a page to demonstrate:
http://www.brightnorth.com/cjm/emx/apps2.html

I assumed it was some sort of Box Model issue, and after a bit of
investigation I found that it indeed was... apparently IE6 reverts to the
quirky box model behaviour of IE5 if you include the ?xml prolog in an XHTML
page.

So I remove the offending line (ie the first) from the page and tested. Et
Voila! It works fine: http://www.brightnorth.com/cjm/emx/apps2.html

I've read in one place that this line is optional anyway, and can be
ignored; but lots of guides behave as if it compulsary. But I was wondering
what conventional wisdom says. Surely missing the prolog out it the best
options? Or are there reasons to keep it in? I don't fancy the idea of
inserting hacks to compensate.

Any thoughts?

CJM
I tend to leave it out.
Although, you should use a Strict Doctype, as it will keep all the
browsers that support XHTML out of quirks mode.
Oh and you have 19 validation errors, you might as well fix those as
well.

--
Regards Chad. http://freewebdesign.cjb.cc

Jan 11 '07 #3

P: n/a
And lo, CJM didst speak in
alt.http://www.webmaster,comp.infosystem...uthoring.html:
I've bodged up a page to demonstrate:
http://www.brightnorth.com/cjm/emx/apps2.html

I assumed it was some sort of Box Model issue, and after a bit of
investigation I found that it indeed was... apparently IE6 reverts to the
quirky box model behaviour of IE5 if you include the ?xml prolog in an
XHTML
page.

So I remove the offending line (ie the first) from the page and tested.
Et
Voila! It works fine: http://www.brightnorth.com/cjm/emx/apps2.html

I've read in one place that this line is optional anyway, and can be
ignored; but lots of guides behave as if it compulsary. But I was
wondering
what conventional wisdom says. Surely missing the prolog out it the best
options? Or are there reasons to keep it in? I don't fancy the idea of
inserting hacks to compensate.

Any thoughts?
You say you're using ISO-8859-1 (elsewhere in the thread)? On the one
hand, you've got IE6 problems if you leave it in, on the other hand you've
got to switch to UTF-8 and go through your pages making sure there aren't
any encoding errors. On the third hand, you could rig up a server-side
sniffing script to try adding and removing the prolog depending on which
browser you think is visiting.

Whew, what a headache.

Just stick with HTML 4.01 and you avoid all these issues. It's a no
brainer.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine
Jan 11 '07 #4

P: n/a
Jukka K. Korpela wrote:
By XML specifications, it SHOULD be there, but it is not required, if one of
the following is true:
a) the document's encoding is UTF-8
b) the document's encoding is UTF-16 (and the document starts with BOM)
c) there is an HTTP header specifying the encoding.
Your wording here is ambiguous, Jukka. When I first read this, I thought,
"no, Jukka has it the opposite way around" until I figured out which way
you meant it to be read.

What I initially thought Jukka was saying (which is wrong) was:

If your document is in UTF-8 or UTF-16 (with BOM), or you
specify the encoding in the HTTP headers, then you are not
required to include the prologue, but you SHOULD.

What Jukka meant (and is correct) is:

If your document is in UTF-8 or UTF-16 (with BOM), or you
specify the encoding in the HTTP headers, then you are not
required to include the prologue. Otherwise, you SHOULD
include it.

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

Jan 11 '07 #5

P: n/a
Scripsit CJM:
Currently I'm using ISO-8859-1 which is a subset of Unicode.
The character repertoire of ISO-8859-1 (and virtually any character encoding
in use) is a subset of the reportoire of Unicode, but as an encoding, it is
quite different. For ASCII characters, there is no difference, but all other
characters have different representations.
Should I use UTF-8 instead?
Probably not. You can probably make the server specify the encoding in HTTP
headers. Or maybe you can use HTML 4.01 and avoid the whole problem.
If so, what issues do I need to be aware of when
moving across?
You would need to perform character encoding conversions for all pages.
Are Content-Type META tags insufficient?
They cannot be used to override HTTP headers, if the headers specify the
encoding.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 11 '07 #6

P: n/a
CJM
"Chaddy2222" <sp***********************@yahoo.com.auwrote in message
news:11*********************@i56g2000hsf.googlegro ups.com...
Although, you should use a Strict Doctype, as it will keep all the
browsers that support XHTML out of quirks mode.
Oh and you have 19 validation errors, you might as well fix those as
well.
As I said before, this is a partial 'rescue' of the site. There was so much
wrong with, it wasn't all going to be sorted in this phase. But, assuming
the man at the top will let me, I'll be tackling validation, accessability
and the many other issues in good time; at least to the extent where I would
be prepared to admit I was involved with the site at some stage. Perfection
is against company policy, so I'm holding out for Good Enough.

CJM
Jan 11 '07 #7

P: n/a
CJM

"Jukka K. Korpela" <jk******@cs.tut.fiwrote in message
news:vP****************@reader1.news.saunalahti.fi ...
>
By XML specifications, it SHOULD be there, but it is not required, if one
of the following is true:
a) the document's encoding is UTF-8
b) the document's encoding is UTF-16 (and the document starts with BOM)
c) there is an HTTP header specifying the encoding.
Currently I'm using ISO-8859-1 which is a subset of Unicode. Should I use
UTF-8 instead? If so, what issues do I need to be aware of when moving
across?
It's a simple one, but it's really feasible only when UTF-8 is used.
Option b, using UTF-16, is not practical on the web, due to poor support
in browsers and search engines. Relying on c) is somewhat risky, since the
document might be saved locally (e.g., by a user) in a manner that loses
information about HTTP headers.
Are Content-Type META tags insufficient?

I can anticipate that the odd page *will* be stored off-line given the
nature of some of the content.
Jan 11 '07 #8

P: n/a
Scripsit Chaddy2222:
>Any thoughts?

CJM
I tend to leave it out.
"It"? Due to pointless fullquoting, it's unclear what you were referring to.
Perhaps the last item mentioned, as quoted above. :-)

What you do in this respect is as such irrelevant. What might matter to
others is _why_ you do so, i.e. your reasons or arguments, if any.
Although, you should use a Strict Doctype, as it will keep all the
browsers that support XHTML out of quirks mode.
That's one possible strategy, but if the markup is not really as defined in
Strict, you would need a DOCTYPE override in validation.
Oh and you have 19 validation errors, you might as well fix those as
well.
Well, yes. Some errors relate to missing alt attributes, so they are quite
relevant. (Some syntax errors don't really matter in actual practice; this
one does.) Moreover, there are <imgtags without end tags and there's
onMouseOut which is invalid in XHTML (onmouseover is the only correct
spelling there).

This raises the question whether the OP should actually move to HTML 4.01,
which is the practical choice in HTML authoring. At worst, the pages are now
a mixture of classic HTML and XHTML, which doesn't really matter much (as
long as you don't try to make any use of XHTML being XML, and virtually
nobody does), but it makes it more difficult to detect (from validator
reports) the syntax errors that might really matter.

Of course, if the OP is now far beyond halfway converting the site to XHTML,
he should probably continue that. If not, it's probably better to return to
HTML 4.01.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 11 '07 #9

P: n/a
CJM

"GreyWyvern" <sp**@greywyvern.comwrote in message
news:op***************@news.nas.net...
>
You say you're using ISO-8859-1 (elsewhere in the thread)? On the one
hand, you've got IE6 problems if you leave it in, on the other hand you've
got to switch to UTF-8 and go through your pages making sure there aren't
any encoding errors. On the third hand, you could rig up a server-side
sniffing script to try adding and removing the prolog depending on which
browser you think is visiting.

Whew, what a headache.
Indeed! :)

Option 3 sounds fun.
Just stick with HTML 4.01 and you avoid all these issues. It's a no
brainer.
The assumption you (and Jukka) have made is that I'm converting from
HTML4.01 to XHTML, whereas I am not. For there record, I never use any
flavour of 'Transitional'.

The original developers developed in XHTML 1.0 Transitional; well, that was
the doctype they had at least, though the code bore only a passing
resemblance. I am just trying to make a few content changes on behalf of the
marketing department (the custodians). Unfortunately, I've had to dig
through a lot of crap in order to make the simplest of changes, so it's much
more time-consuming that I'd hoped for - I didn't quite realise how bad the
site was. I mean, images for headers FFS!

I can't possible convert the whole site to either UTF-8 or to HTML 4.01 at
the moment, so it will have to remain 'sub-optimal'. However, I'm due to be
reviewing the site for SEO soon enough, so I think another clean-up session
(read: conversion to HTML4.01) is in order. I should be able get this past
the bean counters hopefully.

On a side-note: this project has been a bit of a boost for my ego. I know I
have plenty to learn compared to some, but it's good to have a reminder
about how many people there are who earn a living in web development without
really having even the most basic skills or knowledge.
Jan 11 '07 #10

P: n/a
CJM

"Toby Inkster" <us**********@tobyinkster.co.ukwrote in message
news:os************@ophelia.g5n.co.uk...
Jukka K. Korpela wrote:
>By XML specifications, it SHOULD be there, but it is not required, if one
of
the following is true:
a) the document's encoding is UTF-8
b) the document's encoding is UTF-16 (and the document starts with BOM)
c) there is an HTTP header specifying the encoding.

Your wording here is ambiguous, Jukka. When I first read this, I thought,
"no, Jukka has it the opposite way around" until I figured out which way
you meant it to be read.
It's OK. It made perfect sense, without even considering
English-as-a-foreign-language.

It's also what I expected, if not what I wanted.
Jan 11 '07 #11

P: n/a
Scripsit Toby Inkster:
Jukka K. Korpela wrote:
>By XML specifications, it SHOULD be there, but it is not required,
if one of the following is true:
a) the document's encoding is UTF-8
b) the document's encoding is UTF-16 (and the document starts with
BOM)
c) there is an HTTP header specifying the encoding.

Your wording here is ambiguous, Jukka.
It's ambiguous as regards to what the "if" clause applies to, but the
obvious (and intended) interpretation is that it applies to "it is not
required" only.
What Jukka meant (and is correct) is:

If your document is in UTF-8 or UTF-16 (with BOM), or you
specify the encoding in the HTTP headers, then you are not
required to include the prologue. Otherwise, you SHOULD
include it.
No, that's not what I meant and that's not a correct description.

"XML documents SHOULD begin with an XML declaration which specifies the
version of XML being used."
http://www.w3.org/TR/REC-xml/#sec-prolog-dtd

It is required (i.e. it MUST be used) whenever none of the above-mentioned
cases applies, as the XML specification explicitly says:

"In the absence of external character encoding information (such as MIME
headers), parsed entities which are stored in an encoding other than UTF-8
or UTF-16 MUST begin with a text declaration (see 4.3.1 The Text
Declaration) containing an encoding declaration"
http://www.w3.org/TR/REC-xml/#charencoding

The words SHOULD and MUST are used in the XML specification as in "RFC
language", i.e. as defined in RFC 2119,
http://www.ietf.org/rfc/rfc2119.txt
This means:

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 11 '07 #12

P: n/a
"CJM" <cj*******@REMOVEMEyahoo.co.ukwrote:
>I can't possible convert the whole site to either UTF-8
As noted previously for ASCII characters there is no difference in
encoding between ISO-8859-1 and UTF-8, unless you are using non ASCII
characters no encoding conversion is required.
>[can't possibly convert to] HTML 4.01 at the moment
This should be a trivial thing to do, it probably doesn't require more
that getting rid of the silly self closing backslashes with a site wide
S&R and replacing the doctype. Not that it matters in practice, if you
serve it as text/html, that is how it will be treated.

--
Spartanicus
Jan 11 '07 #13

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fiwrites:
Scripsit CJM:
<snip>
>Are Content-Type META tags insufficient?

They cannot be used to override HTTP headers, if the headers specify
the encoding.
Of course, but CJM's comment was to your paragraph about the case when
headers are not available (e.g. when the page is saved) so he may have
been asking: "is an http-equiv charset insufficient when the headers
have been lost"?

A quick experiment suggests that it does cause at least one browser to
get the encoding right (and wrong without it). I had always
discounted meta http-equiv as a useless extra but this suggests one
real use: for UTF-8 encoded XHTML saved pages that don't have an xml
declaration.

--
Ben.
Jan 11 '07 #14

P: n/a
"CJM" <cj*******@REMOVEMEyahoo.co.ukwrote:
I assumed it was some sort of Box Model issue, and after a bit of
investigation I found that it indeed was... apparently IE6 reverts to
the quirky box model behaviour of IE5 if you include the ?xml prolog
in an XHTML page.
IMO: move to HTML 4.01 strict. I read somewhere down that your page has
validation errors, which is a bit of a joke when one uses XHTML. Most
people have jumped (sadly) on the XHTML bandwagon (been there done that),
without understanding the implications. W3C "selling" XHTML as the
successor of HTML can be blamed partially for that.

HTML 4.01 strict with optionally the use of microformats is probably
sufficient for most circumstances.

--
John Need help with SEO? Get started with a SEO report of your site:

--http://johnbokma.com/websitedesign/seo-expert-help.html
Jan 11 '07 #15

P: n/a

CJM wrote:
I can't possible convert the whole site to either UTF-8 or to HTML 4.01 at
the moment,
Of course you can - just label it as this and you're there. It might
not be valid, but it's as good (if not better) to have an invalid HTML
4.01 Strict site as an invalid site in something else. At least you
know where you're going, you won't have to change direction afterwards
and you're already seeing a rational CSS rendering behaviour.

Jan 12 '07 #16

P: n/a

John Bokma wrote:
Most people have jumped (sadly) on the XHTML bandwagon (been there done that),
without understanding the implications.
No-one has jumped on the XHTML bandwagon yet, because it hasn't even
left the garage and won't be able to until IE starts parsing web
content as XML and not SGML / HTML.

At most they're running alongside it wearing XHTML cheerleader outfits
and shouting loudly. They'd _like_ to be doing XHTML, but for as long
as they're still serving it as text/html, that's just HTML in a silly
hat and not anything like XML itself.

Jan 12 '07 #17

P: n/a
On Thu, 11 Jan 2007 11:43:15 +0000, CJM wrote:
But I can't change it all at this stage, so I'm still constrained by much of
the original design.
One thing it would be easy to do is add a <noscriptversion of the
navigation.
Jan 12 '07 #18

P: n/a
CJM

"Andy Dingley" <di*****@codesmiths.comwrote in message
news:11**********************@v45g2000cwv.googlegr oups.com...
>
CJM wrote:
>I can't possible convert the whole site to either UTF-8 or to HTML 4.01
at
the moment,

Of course you can - just label it as this and you're there. It might
not be valid, but it's as good (if not better) to have an invalid HTML
4.01 Strict site as an invalid site in something else. At least you
know where you're going, you won't have to change direction afterwards
and you're already seeing a rational CSS rendering behaviour.
Ah.. the power of search and replace....

Tis done. Down to 13 validation errors for the typical page. For reasons I
can't fathom, the original developers have repeatedly given different
elements the same IDs.
Jan 12 '07 #19

P: n/a

Jukka K. Korpela wrote:
Scripsit Chaddy2222:
Any thoughts?

CJM
I tend to leave it out.

"It"? Due to pointless fullquoting, it's unclear what you were referring to.
Perhaps the last item mentioned, as quoted above. :-)
The ?XML section of the doctype.
What you do in this respect is as such irrelevant. What might matter to
others is _why_ you do so, i.e. your reasons or arguments, if any.
Although, you should use a Strict Doctype, as it will keep all the
browsers that support XHTML out of quirks mode.

That's one possible strategy, but if the markup is not really as defined in
Strict, you would need a DOCTYPE override in validation.
Oh and you have 19 validation errors, you might as well fix those as
well.

Well, yes. Some errors relate to missing alt attributes, so they are quite
relevant. (Some syntax errors don't really matter in actual practice; this
one does.) Moreover, there are <imgtags without end tags and there's
onMouseOut which is invalid in XHTML (onmouseover is the only correct
spelling there).

This raises the question whether the OP should actually move to HTML 4.01,
which is the practical choice in HTML authoring. At worst, the pages are now
a mixture of classic HTML and XHTML, which doesn't really matter much (as
long as you don't try to make any use of XHTML being XML, and virtually
nobody does), but it makes it more difficult to detect (from validator
reports) the syntax errors that might really matter.
It might also make some more compliant browsers trip up though.
Of course, if the OP is now far beyond halfway converting the site to XHTML,
he should probably continue that. If not, it's probably better to return to
HTML 4.01.
Yes, I would agree in that sence.
--
Regards Chad. http://freewebdesign.cjb.cc

Jan 12 '07 #20

P: n/a

CJM wrote:
"Andy Dingley" <di*****@codesmiths.comwrote in message
news:11**********************@v45g2000cwv.googlegr oups.com...

CJM wrote:
I can't possible convert the whole site to either UTF-8 or to HTML 4.01
at
the moment,
Of course you can - just label it as this and you're there. It might
not be valid, but it's as good (if not better) to have an invalid HTML
4.01 Strict site as an invalid site in something else. At least you
know where you're going, you won't have to change direction afterwards
and you're already seeing a rational CSS rendering behaviour.

Ah.. the power of search and replace....

Tis done. Down to 13 validation errors for the typical page. For reasons I
can't fathom, the original developers have repeatedly given different
elements the same IDs.
I would say it's probably due to cluelessness, on the old developers
part, on that note, why on earth would you want to do that anyway? it
would get confusing if you needed to change a part of your CSS, or
maybe they were confusing ID with Class.
--
Regards Chad. http://freewebdesign.cjb.cc

Jan 12 '07 #21

P: n/a
CJM

"Chaddy2222" <sp***********************@yahoo.com.auwrote in message
news:11*********************@i15g2000cwa.googlegro ups.com...
>
I would say it's probably due to cluelessness, on the old developers
part,
'Clueless' flatters them.
on that note, why on earth would you want to do that anyway? it
would get confusing if you needed to change a part of your CSS, or
maybe they were confusing ID with Class.
I'm guessing that is the case, since they are using the ID to manipulate
multiple elements as a group.
Jan 12 '07 #22

P: n/a
"Andy Dingley" <di*****@codesmiths.comwrote:
>
John Bokma wrote:
>Most people have jumped (sadly) on the XHTML bandwagon (been there
done that), without understanding the implications.

No-one has jumped on the XHTML bandwagon yet, because it hasn't even
left the garage and won't be able to until IE starts parsing web
content as XML and not SGML / HTML.
Let's hope that never happens. I can clearly recall the days that Netscape
showed a blank page (well, grey) when the HTML file it was parsing had one
error.
At most they're running alongside it wearing XHTML cheerleader outfits
and shouting loudly. They'd _like_ to be doing XHTML, but for as long
as they're still serving it as text/html,
There are people who get that part, but still manage to serve up XML that
is not well-formed.
that's just HTML in a silly
hat and not anything like XML itself.
XML IMNSHO is for development, and shouldn't leave the garage at all.

--
John Need help with SEO? Get started with a SEO report of your site:

--http://johnbokma.com/websitedesign/seo-expert-help.html
Jan 12 '07 #23

P: n/a
Scripsit Chaddy2222:
>"It"? Due to pointless fullquoting, it's unclear what you were
referring to. Perhaps the last item mentioned, as quoted above. :-)
The ?XML section of the doctype.
There is no such thing. Knowing the correct terms might not be crucial in
general, but when commenting on matters like this in public, incorrect
terminology is one of the surest way to tell that you don't understand what
you are talking about.

Continuing massive unnecessary quoting is of course a useful auxiliary
method.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 12 '07 #24

P: n/a

Jukka K. Korpela wrote:
Scripsit Chaddy2222:
"It"? Due to pointless fullquoting, it's unclear what you were
referring to. Perhaps the last item mentioned, as quoted above. :-)
The ?XML section of the doctype.

There is no such thing. Knowing the correct terms might not be crucial in
general, but when commenting on matters like this in public, incorrect
terminology is one of the surest way to tell that you don't understand what
you are talking about.

Continuing massive unnecessary quoting is of course a useful auxiliary
method.
Oh picky picky.
I am quite serton I understand what i'm talking about (I just worded it
really poorly.)
It is true what you say about useing the correct termonology though.
--
Regards Chad. http://freewebdesign.cjb.cc

Jan 13 '07 #25

P: n/a
VK
Ben Bacarisse wrote:
I had always discounted meta http-equiv as a useless extra
Yes, it is a common misconception floating by WWW-related newsgroups. I
guess people mixing http-equiv content meta tag with different author,
keywords, description and such.

content-type and charset indicated over http-equiv is an important and
well specified part of web standards. It also well defined what the
header sent by server always has higher priority then http-equiv. So
say if http-equiv says ISO-something and server says UTF-something, the
encoding will be UTF-something.

On virtual servers is often not an option to set charset in responce,
because each folder and even different pages in the same folder may
contain text on all different languages in all different encodings.
This is why a properly configured collocation server follows the
principle "verbatim send": it never sets charset, only content-type.
Otherwise such server would be one huge source of borken pages.

Respectively a properly prepared page must always contain http-equiv
with matching charset. To know what happens with bad girls and boys not
doing it - surf a bit by Internet or search clj for "Korean issue"
samples.

Jan 15 '07 #26

P: n/a
"CJM" <cj*******@REMOVEMEyahoo.co.ukwrites:
[...] the ?xml prolog [...]
<http://www.w3.org/TR/REC-xml/#xmldoc>
[...] but lots of guides behave as if it compulsary.
A lot of 'guides' just make up everything at write time.

(it is generally easy and sufficient to identify pure BS, e.g.
<http://www.webstandards.org/learn/articles/prolog_problems/>
simply by the absence of editorial contact information)
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jan 16 '07 #27

P: n/a
On Thu, 11 Jan 2007 14:11:46 +0200, Jukka K. Korpela <jk******@cs.tut.fiwrote:
Scripsit CJM:
apparently IE6 reverts to
the quirky box model behaviour of IE5 if you include the ?xml prolog
in an XHTML page.

Indeed. _Anything_ before the DOCTYPE declaration causes that.


Unless it is <!-- thusly commented out -- ??

Is that is correct?
--
// rj@panix.com //

Jan 20 '07 #28

P: n/a
On Thu, K. Korpela <jk******@cs.tut.fiwrote:
Scripsit CJM:
apparently IE6 reverts to
the quirky box model behaviour of IE5 if you include the ?xml prolog
in an XHTML page.

Indeed. _Anything_ before the DOCTYPE declaration causes that.


Unless it is <!-- thusly commented out -- ??

Is that correct?
--
// rj@panix.com //

Jan 20 '07 #29

P: n/a
On Sat, 20 Jan 2007 05:47:10 +0000 (UTC), Russell Hoover <rj@panix.com>
wrote:
>On Thu, 11 Jan 2007 14:11:46 +0200, Jukka K. Korpela <jk******@cs.tut.fiwrote:
> Scripsit CJM:
> Indeed. _Anything_ before the DOCTYPE declaration causes that.

Unless it is <!-- thusly commented out -- ??

Is that is correct?
No, it isn't. Anything *at* *all* before the doctype declaration puts
IE6 into quirks mode, where it uses an incorrect box model.
Jan 20 '07 #30

P: n/a
Ed Seedhouse <es********@shaw.cawrites:
Anything *at* *all* before the doctype declaration puts
IE6 into quirks mode, where it uses an incorrect box model.
<http://bednarz.nl/tmp/compat.html>
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jan 20 '07 #31

P: n/a
On Sat, 20 Jan 2007 21:47:59 +0100, "Eric B. Bednarz"
<be*****@fahr-zur-hoelle.orgwrote:
>Ed Seedhouse <es********@shaw.cawrites:
>Anything *at* *all* before the doctype declaration puts
IE6 into quirks mode, where it uses an incorrect box model.

<http://bednarz.nl/tmp/compat.html>
Too bad Internet Explorer doesn't know about this, but the fact is, it
doesn't, at least IE6 doesn't.

Jan 20 '07 #32

P: n/a
Ed Seedhouse <es********@shaw.cawrites:
"Eric B. Bednarz" <be*****@fahr-zur-hoelle.orgwrote:
>Ed Seedhouse <es********@shaw.cawrites:
>>Anything *at* *all* before the doctype declaration puts
IE6 into quirks mode, where it uses an incorrect box model.

<http://bednarz.nl/tmp/compat.html>

Too bad Internet Explorer doesn't know about this, but the fact is, it
doesn't, at least IE6 doesn't.
It doesn’t what?
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jan 20 '07 #33

P: n/a
On Sat, 20 Jan 2007 22:54:31 +0100, "Eric B. Bednarz"
<be*****@fahr-zur-hoelle.orgwrote:
>Too bad Internet Explorer doesn't know about this, but the fact is, it
doesn't, at least IE6 doesn't.

It doesn’t what?
Understand how to go into standards rendering mode when there is
anything at all before the doctype declaration, or in general, anything
at all about xml.

Ed
Jan 21 '07 #34

P: n/a
Ed Seedhouse <es********@shaw.cawrites:
"Eric B. Bednarz" <be*****@fahr-zur-hoelle.orgwrote:
>>Too bad Internet Explorer doesn't know about this, but the fact is, it
doesn't, at least IE6 doesn't.

It doesn.t what?

Understand how to go into standards rendering mode when there is
anything at all before the doctype declaration, or in general, anything
at all about xml.
Oh, that.

Over here, the page in question renders in CSS1Compat mode in IE 6 as a
standalone on XP SP2 Pro and in IE 6 as default browser on the XP SP2
VPC image Microsoft provides (last time I looked it also did in IE 6 as
default browser on 98 SE, now in the basement, and in IE 6 as default
browser on 2000 at work; I can check on ME tomorrow just to make sure
that it is my fault :).
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jan 21 '07 #35

P: n/a

Eric B. Bednarz skrev:
>Anything *at* *all* before the doctype declaration puts
IE6 into quirks mode, where it uses an incorrect box model.

<http://bednarz.nl/tmp/compat.html>
Too bad Internet Explorer doesn't know about this, but the fact is, it
doesn't, at least IE6 doesn't.

It doesn't what?
Maybe IE doesn't know that HTML 4 documents has three sections that may
have spaces, new lines, tabs and components before and after each
section. And maybe it doesn't know that a valid html document declares
what version of HTML is used. And maybe it doesn't know how to process
malformed crap.

Jan 21 '07 #36

P: n/a

Roy A. skrev:
Eric B. Bednarz skrev:
Maybe IE doesn't know that HTML 4 documents has three sections that may
have spaces, new lines, tabs and components before and after each
comments not components
section. And maybe it doesn't know that a valid html document declares
what version of HTML is used. And maybe it doesn't know how to process
malformed crap.
Jan 21 '07 #37

P: n/a

Eric B. Bednarz skrev:
>Anything *at* *all* before the doctype declaration puts
IE6 into quirks mode, where it uses an incorrect box model.

<http://bednarz.nl/tmp/compat.html>
Too bad Internet Explorer doesn't know about this, but the fact is, it
doesn't, at least IE6 doesn't.
Maybe IE doesn't know that HTML 4 documents has three sections that may

have spaces, new lines, tabs and comments before and after each
section. And maybe it doesn't know that a valid html document declares
what version of HTML is used. And maybe it doesn't know how to process
malformed crap.

Jan 21 '07 #38

P: n/a
On 20 Jan 2007 18:27:59 -0800, "Roy A." <ro*********@gmail.comwrote:
>have spaces, new lines, tabs and comments before and after each
section. And maybe it doesn't know that a valid html document declares
what version of HTML is used. And maybe it doesn't know how to process
malformed crap.
Well, the observed fact is that IE6 renders in quirks mode with the
incorrect box model if the first line of the file doesn't contain the
right doctype. Stupid, but a fact.

Jan 21 '07 #39

P: n/a

Ed Seedhouse skrev:
have spaces, new lines, tabs and comments before and after each
section. And maybe it doesn't know that a valid html document declares
what version of HTML is used. And maybe it doesn't know how to process
malformed crap.

Well, the observed fact is that IE6 renders in quirks mode with the
incorrect box model if the first line of the file doesn't contain the
right doctype. Stupid, but a fact.
That some browsers doesn't understand SGML white spaces when serving a
document as text/html, that imply an SGML declaration, my be
reasonable. Including an XML declaration in such a document, is stupid.

Including the right doctype won't work if the browser doesn't recognise
the html version.

Jan 21 '07 #40

This discussion thread is closed

Replies have been disabled for this discussion.