Problem with styles converting from HTML to XHTML

O

Oli Filth

I'm in the process of converting a website from HTML 4 (Transitional) to XHTML
Transitional. It all validates fine, but I now have a problem with the CSS
styles thar are being inherited.

Take a look at the sample page at http://olifilth.co.uk/test.htm.

==== BEGIN HTML CODE ====

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Test CSS in XHTML</title>
</head>
<body style="background-color: #666">
<div style="color: #FFF; font-size: 24px">
Some text that is white and 24px (and should be).
<table><tr><td>
Some text that is black and small (should be white and 24px ???).
</td></tr></table>
</div>
</body>
</html>

===== END HTML CODE =====

Both lines of text are within a <div> element with some styles defined; the
second line is nested within a <table><tr><td> element. In Firefox 1.0, both
lines of text take on the styles defined in the <div> tag. However, in IE6, only
the first line takes on the style, the second line reverts to a default format.

Both lines took on the defined style when the document was defined as HTML 4
(Transitional) in IE6. So which browser is showing the XHTML version correctly?

Thanks in advance,
Oli
 
S

Steve Pugh

I'm in the process of converting a website from HTML 4 (Transitional) to XHTML
Transitional.

Converting from HTML 4 Transitional to HTML 4.01 Strict would be a
better use of time.
It all validates fine, but I now have a problem with the CSS
styles thar are being inherited.

Take a look at the sample page at http://olifilth.co.uk/test.htm.

==== BEGIN HTML CODE ====

<?xml version="1.0"?>

This causes IE to go into quirks mode.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Test CSS in XHTML</title>
</head>
<body style="background-color: #666">
<div style="color: #FFF; font-size: 24px">
Some text that is white and 24px (and should be).
<table><tr><td>
Some text that is black and small (should be white and 24px ???).
</td></tr></table>
</div>
</body>
</html>

===== END HTML CODE =====

Both lines of text are within a <div> element with some styles defined; the
second line is nested within a <table><tr><td> element. In Firefox 1.0, both
lines of text take on the styles defined in the <div> tag. However, in IE6, only
the first line takes on the style, the second line reverts to a default format.

Yep. IE6 is in quirks mode so emulates the bugs of IE5. Get rid of the
XML declaration and IE6 will behave itself (IE5 will still get things
wrong though).
Both lines took on the defined style when the document was defined as HTML 4
(Transitional) in IE6. So which browser is showing the XHTML version correctly?

If were using a HTML 4 Transitional doctype that triggers standards
mode then yes IE6 would get things right in that case.

Steve
 
O

Oli Filth

Steve said:
Converting from HTML 4 Transitional to HTML 4.01 Strict would be a
better use of time.

I've chosen the XHTML route after reading up that XHTML 1.0 is the W3C's
recommendation for adopting standards, according to their own website and
others. As far as I can make out, it's basically a cleaner, stricter and more
standardised definition of HTML 4.01, which appeals to me as an anal retentive.
Yep. IE6 is in quirks mode so emulates the bugs of IE5. Get rid of the
XML declaration and IE6 will behave itself (IE5 will still get things
wrong though).

Aha, indeed it does. Thank you!

Oli
 
T

Toby Inkster

Oli said:
<table><tr><td>
Some text that is black and small (should be white and 24px ???).
</td></tr></table>

IE/win has some inheritance problems inside tables.

Try dropping the XML prologue -- that shoulf flick it into standards mode
and you may get better results.
 
N

Neal

I'm in the process of converting a website from HTML 4 (Transitional) to
XHTML Transitional.

Why?

Your problems stem from IE's inability to handle valid XHTML. As such,
it's really no more than an academic exercise to use XHTML at all at this
point. It offers no extra value to most UAs in use.

I'd work on upgrading to HTML 4.01 Strict and separating the
decoration/presentation from the meaning/content, and putting that in an
external CSS stylesheet. Far better use of your time.
 
C

C A Upsdell

Neal said:
Why?

Your problems stem from IE's inability to handle valid XHTML.

Why is it that, having used xHTML since it came out, I have NEVER had a
problem with how IE handles it? I must be living a blessed life, never
having had a problem with "IE's inability to handle valid XHTML".
 
C

C A Upsdell

Neal said:
Why?

Your problems stem from IE's inability to handle valid XHTML.

Why is it that, having used xHTML since it came out, I have NEVER had a
problem with how IE handles it? I must be living a blessed life, never
having had a problem with "IE's inability to handle valid XHTML".
 
N

Neal

C A Upsdell:
Why is it that, having used xHTML since it came out, I have NEVER had a
problem with how IE handles it? I must be living a blessed life, never
having had a problem with "IE's inability to handle valid XHTML".

Mind you, IE can handle XHTML well provided:

1) You serve it as text/html, which is really the wrong MIME for XHTML
2) You omit the prolog which knocks IE into quirks

But by doing that, you serve a bastardized version of XHTML. Why bother?

In other words, what benefit does XHTML provide in that event?
 
R

rf

C said:
Why is it that, having used xHTML since it came out, I have NEVER had a
problem with how IE handles it? I must be living a blessed life, never
having had a problem with "IE's inability to handle valid XHTML".

Then you have not been sending true XHTML to the browsers.

IE can only accept XHTML if it is served up as HTML. If you send a page to
IE with a MIME type of application/xhtml+xml then IE will ask you if you
want to download it.

Visit this page with firefox, just to reassure yourself that it is, in fact,
a true XHTML page.
http://juicystudio.com/mimetest/xhtmldoc.asp

Then visit it with IE.
 
O

Oli Filth

Neal said:

This is what I'm in the process of investigating (i.e. seeing whether it's worth
it). Personally, I prefer the "move towards an integrated standards" approach,
in the hope that in the future it (as valid XML) can be used interchangeably
with many other data-types stored as XML.
Your problems stem from IE's inability to handle valid XHTML. As such,
it's really no more than an academic exercise to use XHTML at all at
this point. It offers no extra value to most UAs in use.

I see your point, but we all know that IE does loads of stuff wrong; that
doesn't mean we should be content with IE-happy-crappy HTML forever :). The more
people that move and push for the standards, the more Microsoft (and others)
will have to pull their socks up and become standards-compliant.
I'd work on upgrading to HTML 4.01 Strict and separating the
decoration/presentation from the meaning/content, and putting that in an
external CSS stylesheet. Far better use of your time.

I may change approach and do this, seeing as my website as it stands is fairly
small and still under construction.

Oli
 
O

Oli Filth

Spartanicus said:

Not according to http://www.w3.org/MarkUp/2004/xhtml-faq#need.

I'd argue with quite a few of the points put forward in that article.

- "There's nothing to stop an author from applying the same "strictness" to HTML."

Whilst that may be true, there's also nothing to stop someone writing a really
crappy HTML document that a lot of browsers (i.e. IE) will still display ok.
This hinders other browser developers because they have to be
"backwards-compatible" with a load of web-pages written by complete amateurs (or
generated in FrontPage, etc.) using the older unwieldy, bloated HTML standards,
aimed at wildly non-standards-compliant nonsense UAs like IE.
Surely as site developers we should we trying to move away from this scenario
and towards a neater, stricter standard where everyone knows how to use the
language?

- "Lot's of other sites use it, so it must be good. Lot's of Lemmings are
jumping off cliffs, do you want to be a Lemming?"

You could apply that argument to HTML 4.01, PHP, JavaScript, anything.

- "It's the future, I want to prepare for it now."

Quite frankly, yes. I'd rather try and push for a stricter, well-defined
language that fits in with the XML standard/paradigm as a whole than continue to
use HTML (+ hacks/kludges) purely to pander to IE's inadequacies.

- "Given that Opera has proven that it's possible to use a full blown HTML
client onto current day mobile devices, how likely do you think it is that we'll
see mobile devices with a XML only parser?"

True, but it's also true that PDAs, mobiles, etc. are inherently
resource-strapped (compared to PCs). Why waste their resources on having to
parse incorrect HTML documents? Have you seen the speed at which Opera runs (and
the memory it uses) on even the fastest phones, compared to the older WAP WML
(which is XML) browsers?
Again, surely we should be moving away from this sort of situation towards a
cleaner, more efficient standard which is easier to develop browsers to, and
easier to write web-pages in (in terms of the standard being well-defined).


However, I do agree with the current problems caused by non-compliance, but
again most of this boils down to IE not playing ball. IE doesn't support all of
HTML 4 or CSS2 properly, does that mean we shouldn't bother to use them either?
To say "Just say no to XHTML" seems a very luddite mind-set.

I also agree with the fact that HTML 4.01 Strict seems an equally valid route
for developers to go down. However, to me, XHTML (being XML, and therefore
interoperable with a whole load of other XML stuff) seems the more sensible
paradigm to adopt in the long-term (in a perfect world :)).

Oli
 
R

rf

Oli said:
seeing as my website as it stands is fairly
small and still under construction.

If it's under construction it should have been strict (html or xhtml) to
start with.

It's *much* harder going from transitional (assuming you have used stuff
that requires transitional) to strict than it is going from html to xhtml.

The former may require re-design of parts of the page. The latter is simply
correcting the errors (missing closing tags etc) that the validator tells
you about.
 
O

Oli Filth

rf said:
Oli Filth wrote:




If it's under construction it should have been strict (html or xhtml) to
start with.

It's *much* harder going from transitional (assuming you have used stuff
that requires transitional) to strict than it is going from html to xhtml.

The former may require re-design of parts of the page. The latter is simply
correcting the errors (missing closing tags etc) that the validator tells
you about.

Thank you for the advice, I will attempt to go with Strict then.

oli
 
C

C A Upsdell

rf said:
Then you have not been sending true XHTML to the browsers.

IE can only accept XHTML if it is served up as HTML. If you send a page to
IE with a MIME type of application/xhtml+xml then IE will ask you if you
want to download it.

So what? The W3C is quite content with this situation. As their FAQ says "
XHTML 1.0 was carefully designed so that with care it would also work on
legacy HTML user agents as well". So we can reasonably use xHTML now, warts
and all.
 
S

Spartanicus

Oli Filth said:

Just the usual hullabaloo about xhtml, only a non knowledgable reader
could interpret that as advocating serving xhtml to clients.
I'd argue with quite a few of the points put forward in that article.

- "There's nothing to stop an author from applying the same "strictness" to HTML."

Whilst that may be true, there's also nothing to stop someone writing a really
crappy HTML document that a lot of browsers (i.e. IE) will still display ok.
This hinders other browser developers because they have to be
"backwards-compatible" with a load of web-pages written by complete amateurs (or
generated in FrontPage, etc.) using the older unwieldy, bloated HTML standards,
aimed at wildly non-standards-compliant nonsense UAs like IE.
Surely as site developers we should we trying to move away from this scenario
and towards a neater, stricter standard where everyone knows how to use the
language?

What brought on the illusion that this is even remotely related to
xhtml? Are you really so naive to think that people will author xhtml
any differently than html?:
http://www.goer.org/Journal/2003/Apr/index.html#results
- "Lot's of other sites use it, so it must be good. Lot's of Lemmings are
jumping off cliffs, do you want to be a Lemming?"

You could apply that argument to HTML 4.01, PHP, JavaScript, anything.

I'm glad you got it, or did you?
- "It's the future, I want to prepare for it now."

Quite frankly, yes. I'd rather try and push for a stricter, well-defined
language that fits in with the XML standard/paradigm as a whole than continue to
use HTML (+ hacks/kludges) purely to pander to IE's inadequacies.

Nothing to do with xhtml again.
- "Given that Opera has proven that it's possible to use a full blown HTML
client onto current day mobile devices, how likely do you think it is that we'll
see mobile devices with a XML only parser?"

True, but it's also true that PDAs, mobiles, etc. are inherently
resource-strapped (compared to PCs). Why waste their resources on having to
parse incorrect HTML documents? Have you seen the speed at which Opera runs (and
the memory it uses) on even the fastest phones, compared to the older WAP WML
(which is XML) browsers?
Again, surely we should be moving away from this sort of situation towards a
cleaner, more efficient standard which is easier to develop browsers to, and
easier to write web-pages in (in terms of the standard being well-defined).

XHTML 1.x is only a reformulation of HTML into XML. No magic benefits
result from it.
However, I do agree with the current problems caused by non-compliance, but
again most of this boils down to IE not playing ball. IE doesn't support all of
HTML 4 or CSS2 properly, does that mean we shouldn't bother to use them either?
To say "Just say no to XHTML" seems a very luddite mind-set.

I also agree with the fact that HTML 4.01 Strict seems an equally valid route
for developers to go down. However, to me, XHTML (being XML, and therefore
interoperable with a whole load of other XML stuff) seems the more sensible
paradigm to adopt in the long-term (in a perfect world :)).

Unless you actually use XML tools this "interoperable" claim is just hot
air, and if you do use XML tools then this does not form an argument for
*serving* xhtml to *clients*.
 
O

Oli Filth

Spartanicus said:
What brought on the illusion that this is even remotely related to
xhtml? Are you really so naive to think that people will author xhtml
any differently than html?:
http://www.goer.org/Journal/2003/Apr/index.html#results

I know it's not directly related to XHTML, but it was in answer to the point in
your article stating that HTML can be written strictly too. Yes it can, but the
standards also allow it to be badly written too. In a perfect world, browsers
would only accept well-formed markup (in whatever language, not necessarily
XHTML), so there'd be no ambiguities or inconsistencies for UA-developers and
page-authors to worry about; consquently authors would be forced to write
strict/well-formed/valid markup if they wanted their pages to render. Is that
such a bad ideal to aim for? It may be unrealistic now or in the near future,
but that's why new standards get proposed.

At the moment people are able to write bad XHTML (as the article at the link has
found); but that is because current browsers allow them to get away with it (to
a certain extent), or even force them to (e.g. IE not supporting
application/xhtml+xml).
XHTML 1.x is only a reformulation of HTML into XML. No magic benefits
result from it.

As it stands, yes. But part of the XML paradigm is that documents must be
well-formed. If they're not, the application dealing with the document is
perfectly entitled to just give up; its parser isn't obliged to deal with dozens
of special cases (e.g. having to infer closing tags like </p>, working out what
to do with badly-nested tags, overlapping elements, missing <tr></tr>, etc.),
it's allowed to just say NO. Therefore, a true XML parser could be made much
smaller and easier to maintain than an SGML parser, so there would be a
considerable benefit for embedded browsers with their inherently tighter
resource restrictions.
Unless you actually use XML tools this "interoperable" claim is just hot
air, and if you do use XML tools then this does not form an argument for
*serving* xhtml to *clients*.

It's not just the tools. It's also the language consistency and compatibility
and integration with other XML-based languages, like MathML, etc. (admittedly,
I've never used any myself, or had any need to), where there would be an
argument for serving XHTML (or more generally, XML) to clients/users.
 
S

Spartanicus

Oli Filth said:
I know it's not directly related to XHTML, but it was in answer to the point in
your article stating that HTML can be written strictly too. Yes it can, but the
standards also allow it to be badly written too. In a perfect world, browsers
would only accept well-formed markup

Dealt with and dispelled as a bogus argument on the page that apparently
you haven't read properly.
At the moment people are able to write bad XHTML (as the article at the link has
found); but that is because current browsers allow them to get away with it (to
a certain extent), or even force them to (e.g. IE not supporting
application/xhtml+xml).

I'm not going to repeat here what is clearly dealt with on the page I
provided.

You need to make up your mind about what you are arguing about:
1) Serving XHTML 1.0 as text/html
2) Serving XHTML as application/xhtml+xml
3) Content negotiation

The document provides an entrance for all three positions and provides
arguments applicable for each case.
 
A

Andy Dingley

I've chosen the XHTML route after reading up that XHTML 1.0 is the W3C's
recommendation for adopting standards,

Unfortunately you've chosen to rattle a particular local cage.

I disagree completely with Steve Pugh's "Better to move to HTML strict
instead" comment, although I have the greatest respect for his
reasons.

What you, and all of us, should strive for is accurate compliance to
_some_ standard. This is useful and valuable. OTOH, it doesn't matter
whether it's HMTL 4 Transitional or XHTML 1.0 Strict - the pros and
cons of _which_ standard to choose of the four [*] are almost
negligible in comparison to the benefits of just being compliant.

Strict vs. Trans loses some deprecated markup. This markup is still
supported though, will be supported for the forseeable future, and
doesn't cause problems. I'm still waiting to hear of one good useful
reason why Strict is "better" than Transitional for new authoring, and
it's certainly not worth doing as a retro-fit.

XHTML has some advantages for giving you XML in the authoring stream
and some potential for content management techniques that rely on it.
IMHO, for my projects, this is itself sufficient reason. XHTML also
has the "Appendix C" issues (threads passim). Now IMHO these issues
are over-rated and they just don't cause problems in the real world.



[*] HTML 4.01 or XHTML 1.0, either as Transitional or Strict. Ignore
3.2, ignore frames, ignore XHTML 1.1 and especially 2.0.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,990
Messages
2,570,211
Members
46,796
Latest member
SteveBreed

Latest Threads

Top