CSS error?

[Ned Harkey]

My pages give the following unexplianed error;

I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

Does anyone have a clue what this means and or how to fix it?

[Peter Foti]

"Ned Harkey" <ne****@logicsouth.com> wrote in message
news:54**************************@posting.google.c om...

My pages give the following unexplianed error;

I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

Does anyone have a clue what this means and or how to fix it?

Did you try validating both your HTML and CSS?

http://validator.w3.org/
http://jigsaw.w3.org/css-validator/

Regards,
Peter Foti

[Alan J. Flavell]

On Wed, 15 Oct 2003, Ned Harkey wrote:

My pages give the following unexplianed error;
If you provided a URL, we could all see the problem for ourselves.
I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

Does anyone have a clue what this means
Seems to me to mean precisely what it says. The first byte indicated
that the utf-8 sequence was going to be 4 bytes long, but the second
byte was inconsistent with that hypothesis.
and or how to fix it?

If you're aiming to send utf-8 coding, make sure it's valid utf-8:
for security reasons the rejection of invalid utf-8 sequences is
mandatory.

If you weren't aiming to send utf-8 coding, then investigate why
the software got the idea that it was. Without seeing the actual
situation, I wouldn't care to guess at the details - or rather, any
guess I might make could be wrong and liable to only mislead you
further.

[David Dorward]

Ned Harkey wrote:

My pages give the following unexplianed error;

I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

Does anyone have a clue what this means and or how to fix it?

A vague memory says: Use the same character encoding for your HTML and CSS
and make sure the server is claiming the right encodings.

--
David Dorward http://dorward.me.uk/

[Ned Harkey]

Dear Alan,
Sorry, should have given you the examples. The web site that won't
validate is; "http://www.gijoelinks.com/". Also, check one of my other
sites which validates with no errors despite extremely similar html
code; "http://music.deadbeatclub.com/". Note that both of these sites
validated without error until just a few days ago. Not sure what is
causing the error since the validator does not give any clues..?
Sincerely,
Ned

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message news:<Pi*******************************@ppepc56.ph .gla.ac.uk>...

On Wed, 15 Oct 2003, Ned Harkey wrote:

My pages give the following unexplianed error;

If you provided a URL, we could all see the problem for ourselves.

I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

Does anyone have a clue what this means

Seems to me to mean precisely what it says. The first byte indicated
that the utf-8 sequence was going to be 4 bytes long, but the second
byte was inconsistent with that hypothesis.

and or how to fix it?

If you're aiming to send utf-8 coding, make sure it's valid utf-8:
for security reasons the rejection of invalid utf-8 sequences is
mandatory.

If you weren't aiming to send utf-8 coding, then investigate why
the software got the idea that it was. Without seeing the actual
situation, I wouldn't care to guess at the details - or rather, any
guess I might make could be wrong and liable to only mislead you
further.

[Ned Harkey]

Dear David,
How do I check that? The site in question is
"http://www.gijoelinks.com/" if you want to have a look at my html
code.
Sincerely,
Ned

David Dorward <do*****@yahoo.com> wrote in message news:<bm*******************@news.demon.co.uk>...

Ned Harkey wrote:

My pages give the following unexplianed error;

I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

Does anyone have a clue what this means and or how to fix it?

A vague memory says: Use the same character encoding for your HTML and CSS
and make sure the server is claiming the right encodings.

[Peter Foti]

"Ned Harkey" <ne****@logicsouth.com> wrote in message
news:54**************************@posting.google.c om...

Dear Alan,
Sorry, should have given you the examples. The web site that won't
validate is; "http://www.gijoelinks.com/". Also, check one of my other
sites which validates with no errors despite extremely similar html
code; "http://music.deadbeatclub.com/". Note that both of these sites
validated without error until just a few days ago. Not sure what is
causing the error since the validator does not give any clues..?

Funny, I have no problem validating http://www.gijoelinks.com/, nor do I see
any errors. Did you fix it?

Regards,
Peter Foti

[Jim Dabell]

[Please don't post upside down]

Ned Harkey wrote:
[snip]

> I/O Error: Invalid byte 2 of 4-byte UTF-8 sequence.

[snip] Sorry, should have given you the examples. The web site that won't
validate is; "http://www.gijoelinks.com/".

[snip]

You aren't telling user-agents what character encoding you are using via
HTTP. You appear to be using ISO-8859-1, and that is confirmed with a
<meta> element within the document. The problem is that <meta> elements
are a poor way of informing user-agents which character encoding you are
using, and it seems that at least the CSS validator assumes that any given
HTML document is encoded as UTF-8 unless told otherwise by an appropriate
header. Thus, when it runs into ISO-8859-1 characters that aren't valid
UTF-8 characters, it throws a wobbly.

You can put the URL of the stylesheet itself into the validator, then it
won't have to parse the HTML to get it. This will allow you to validate
the CSS in the short-term, however the real fix is to configure your server
appropriately to advertise the correct character encodings. This is done
with the charset parameter of the Content-Type header. Talk to your admin
(or read the manual).
--
Jim Dabell

[Alan J. Flavell]

On Thu, 16 Oct 2003, Ned Harkey blurted out atop a fullquote:

Sorry, should have given you the examples. The web site that won't
validate is; "http://www.gijoelinks.com/".
This appears to be a very common blunder. You're trying to send out
XHTML/1.0 under the provisions of Appendix C, but you're not
conforming to its rules. An XML processor is entitled to assume (in
fact, its own rules say it must assume) that this HTML document is
coded in utf-8, because there's no HTTP header charset and there's no
<?xml charset specification (and there's no BOM).

The meta http-equiv means nothing to XML, and in any case comes too
late. It's there only for compatibility with HTML user agents.

The consequence is that the W3C CSS validator, in trying to parse the
document as utf-8, finds something which couldn't possibly be utf-8,
and bails out.

[...] validated without error until just a few days ago.
My suspicion is that you've just added some 8-bit character, where
there weren't any before.
Not sure what is causing the error since the validator does not give
any clues..?

It's not being very helpful, is it?

The proper solution will be to put a charset specification onto the
real HTTP header. http://www.w3.org/International/O-HTTP-charset may
be of help.

It's unfortunate that the HTML validator doesn't pick it up. It seems
to be applying the rules of HTML in this regard, but the CSS validator
is handling the XHTML according to the rules of XML.

good luck

[Jim Ley]

On Thu, 16 Oct 2003 16:35:34 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

It's unfortunate that the HTML validator doesn't pick it up. It seems
to be applying the rules of HTML in this regard, but the CSS validator
is handling the XHTML according to the rules of XML.

Which would be a bug, as it's an HTML document, and it should not be
applying the rules of XHTML.

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

[Jim Dabell]

Jim Ley wrote:

On Thu, 16 Oct 2003 16:35:34 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

It's unfortunate that the HTML validator doesn't pick it up. It seems
to be applying the rules of HTML in this regard, but the CSS validator
is handling the XHTML according to the rules of XML.

Which would be a bug, as it's an HTML document, and it should not be
applying the rules of XHTML.

It looks like an XHTML document to me:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

--
Jim Dabell

[Jim Ley]

On Thu, 16 Oct 2003 17:38:03 +0100, Jim Dabell
<ji********@jimdabell.com> wrote:

Jim Ley wrote:

Which would be a bug, as it's an HTML document, and it should not be
applying the rules of XHTML.

It looks like an XHTML document to me:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

but it's being sent as text/html so we know it's an html document, if
you expect it to be treated as xhtml, you need to send it with an
appropriate mime-type, whilst 5.1 allows you to send it as text/html
if you follow Appendix C.

Appendix C. 13 number 5 says:

CSS defines different conformance rules for HTML and XML documents; be
aware that the HTML rules apply to XHTML documents delivered as HTML
and the XML rules apply to XHTML documents delivered as XML.

So if you're serving it as text/html _HTML rules apply_

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

[Jim Dabell]

Jim Ley wrote:

On Thu, 16 Oct 2003 17:38:03 +0100, Jim Dabell
<ji********@jimdabell.com> wrote:

Jim Ley wrote:

Which would be a bug, as it's an HTML document, and it should not be
applying the rules of XHTML.

It looks like an XHTML document to me:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

but it's being sent as text/html so we know it's an html document, if
you expect it to be treated as xhtml, you need to send it with an
appropriate mime-type, whilst 5.1 allows you to send it as text/html
if you follow Appendix C.

Appendix C. 13 number 5 says:

CSS defines different conformance rules for HTML and XML documents; be
aware that the HTML rules apply to XHTML documents delivered as HTML
and the XML rules apply to XHTML documents delivered as XML.

So if you're serving it as text/html _HTML rules apply_

Yes, in the context of CSS, user-agents apply the special-case HTML rules.
But that doesn't mean that the document actually _is_ HTML and not XHTML,
and CSS is pretty irrelevant as the problem is with the XHTML parsing to
find the URL to the stylesheet (or style element).

[Followups set.]

--
Jim Dabell

[Alan J. Flavell]

On Thu, 16 Oct 2003, Jim Ley wrote:

On Thu, 16 Oct 2003 16:35:34 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

It's unfortunate that the HTML validator doesn't pick it up. It seems
to be applying the rules of HTML in this regard, but the CSS validator
is handling the XHTML according to the rules of XML.
Which would be a bug,

Hmmm...
as it's an HTML document,
I'd rather characterise it as an Appendix C compatibility document.
and it should not be applying the rules of XHTML.

That's a very delicate point.

But whichever position one takes, it seemed to me that the document is
aiming to take advantage of Appendix C, and this incident has revealed
that it's not following Appendix C closely enough.

Just exactly how to break that news to the punter is evidently in
dispute, in the sense that your position, as I understand it, is that
this issue is not a failure of validation as such, and so shouldn't
be reported as a validation error, yes?

[Alan J. Flavell]

On Thu, 16 Oct 2003, Jim Ley wrote:

Appendix C. 13 number 5 says:

CSS defines different conformance rules for HTML and XML documents; be
aware that the HTML rules apply to XHTML documents delivered as HTML
and the XML rules apply to XHTML documents delivered as XML.
At risk of descending to the level of counting angels on pinheads...
you've accurately quoted C.13 point 5:

| CSS defines different conformance rules for HTML and XML documents

but then you seem to have made a statement quite outside of that
CSS-specific context:
So if you're serving it as text/html _HTML rules apply_

Really, the decision of what character coding default applies to
an Appendix-C-compatibility document is not decided by reading
CSS-defined conformance rules.

Just what exactly _does_ determine that decision, beyond the
non-normative "Appendix C", is a sensitive point. If there _was_ such
a rule, it would surely have to be in the XHTML/1.0 specification,
just as there were (different and incompatible) rules in HTML/2.0 and
HTML/3.2 on the one hand, and HTML/4 and 4.01 on the other hand.

The only normative statement about this issue in XHTML/1.0 is in
3.1.1, as you know:

Such a declaration is required when the character encoding of the
document is other than the default UTF-8 or UTF-16 and no encoding
was determined by a higher-level protocol.

My position on this would be that the mandate of 3.1.1 doesn't
suddenly evaporate when you send the XHTML document out as text/html,
and that the "meta charset" comes too late for XHTML to take advantage
of it (it's there only as a compatibility feature for HTML-aware
clients).

But the practical implications are clear enough, I think, no matter
what the legalistic details.