I'm trying to get my head around a problem that has me baffled.
The following element:
#wrapper {border:1px solid #000;background:#fff;}
Renders as expected when using this DTD:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
But when switching to this DTD:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Neither the outline or background colour is rendered.
What am I missing?
34  4293 
On Wed, 08 Jun 2005 13:50:04 +0200, The Good Son <go******@freeuk.com>
wrote: I'm trying to get my head around a problem that has me baffled.
The following element:
#wrapper {border:1px solid #000;background:#fff;}
Renders as expected when using this DTD:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
But when switching to this DTD:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Neither the outline or background colour is rendered.
What am I missing?
DOCTYPE switching. See for example http://gutfeldt.ch/matthias/articles/doctypeswitch.html
Browsers are less forgiving of syntax errors, and some CSS properties are
interpreted more strictly, when you trigger Stabdards mode rendering by
using a 'modern' Doctype.
--
Get Opera 8 now! Speed, Security and Simplicity. http://my.opera.com/Rijk/affiliate/
Rijk van Geijtenbeek
Rijk van Geijtenbeek wrote: On Wed, 08 Jun 2005 13:50:04 +0200, The Good Son <go******@freeuk.com>
wrote:
I'm trying to get my head around a problem that has me baffled.
The following element:
#wrapper {border:1px solid #000;background:#fff;}
Renders as expected when using this DTD:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
But when switching to this DTD:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Neither the outline or background colour is rendered.
What am I missing?
DOCTYPE switching. See for example
http://gutfeldt.ch/matthias/articles/doctypeswitch.html
Browsers are less forgiving of syntax errors, and some CSS properties
are interpreted more strictly, when you trigger Stabdards mode
rendering by using a 'modern' Doctype.
Why are you using XHTML? Personally I would go from
transitional to strict, but not HTML 4.0 Transitional to
XHTML 1.0 Strict. Please read: http://www.hixie.ch/advocacy/xhtml for more info on the
problems this will create. Correct me if I'm wrong, but
going to XHTML and sending as text/html triggers quirks mode
on most browsers.
JL
Justin Lieb wrote: Correct me if I'm wrong, but going to XHTML and sending as
text/html triggers quirks mode on most browsers.
Consider yourself corrected. This only happens with IE6 when the <?xml
line appears prior to the DOCTYPE.
C A Upsdell > wrote: Justin Lieb wrote:
Correct me if I'm wrong, but going to XHTML and sending as text/html
triggers quirks mode on most browsers.
Consider yourself corrected. This only happens with IE6 when the <?xml
line appears prior to the DOCTYPE.
Regardless, when sending XHTML as text/html, browsers will
treat it as "tag soup". That is why I made the assumption
that XHTML sent as text/html would trigger quirks mode.
Thank you for correcting though!
JL
Justin Lieb wrote: C A Upsdell > wrote:
Justin Lieb wrote:
Correct me if I'm wrong, but going to XHTML and sending as text/html
triggers quirks mode on most browsers.
Consider yourself corrected. This only happens with IE6 when the
<?xml line appears prior to the DOCTYPE.
Regardless, when sending XHTML as text/html, browsers will treat it as
"tag soup". That is why I made the assumption that XHTML sent as
text/html would trigger quirks mode. Thank you for correcting though!
Quirks Mode is standard with legacy browsers since they have only that.
IE 6 will trigger Quirks if the XML Declaration is used, otherwise it is
in Standards Mode. Gecko based, Opera, Safari and IE5/Mac will be in
Standards Mode.
As long as the document is compliant with Appendix C of XHTML 1.0 it
will be compatible with Tag Soup processors. You have to read the whole
document which you quoted.
--
Gus
Gus Richter wrote: Justin Lieb wrote:
C A Upsdell > wrote:
Justin Lieb wrote:
Correct me if I'm wrong, but going to XHTML and sending as text/html
triggers quirks mode on most browsers.
Consider yourself corrected. This only happens with IE6 when the
<?xml line appears prior to the DOCTYPE.
Regardless, when sending XHTML as text/html, browsers will treat it as
"tag soup". That is why I made the assumption that XHTML sent as
text/html would trigger quirks mode. Thank you for correcting though!
Quirks Mode is standard with legacy browsers since they have only that.
IE 6 will trigger Quirks if the XML Declaration is used, otherwise it is
in Standards Mode. Gecko based, Opera, Safari and IE5/Mac will be in
Standards Mode.
Understood.
As long as the document is compliant with Appendix C of XHTML 1.0 it
will be compatible with Tag Soup processors. You have to read the whole
document which you quoted.
Read the whole document before quoting it, still didn't
understand quirks vs. standard in that context. Now I do.
But my original point still stands, XHTML is basically
pointless at this point in time, unless they want to use xml
tools with it.
JL
"Justin Lieb" <ju**************@adelphia.net> wrote in message
news:t9********************@adelphia.com... Gus Richter wrote:
<snip> Read the whole document before quoting it, still didn't understand quirks
vs. standard in that context. Now I do. But my original point still
stands, XHTML is basically pointless at this point in time, unless they
want to use xml tools with it.
JL
I disagree. My PHP web application has output XHTML for over two years, and
renders in IE, Opera and Firefox. The differences between "proper" HTML and
XHTML are minor.
--
Tony Marston http://www.tonymarston.net
Thanks for the replies.
It's a requirement of the CMS we are using that our templates conform to
XHTML 1.0 strict.
Funny thing is, whilst the stylesheet entry is being ignored, I can add the
attributes to the element within the template and it adds the border and
background colour.
in comp.infosystems. www.authoring.stylesheets, Tony Marston wrote:
"Justin Lieb" <ju**************@adelphia.net> wrote in message XHTML is basically pointless at this point in time, unless they
want to use xml tools with it.
Actually, people that use xml tools often say that is is easier to output
html than appendix C conforming xhtml...
I disagree. My PHP web application has output XHTML for over two years, and
renders in IE, Opera and Firefox. The differences between "proper" HTML and
XHTML are minor.
And point of using xhtml is? You could just fine use plain html4, right?
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera: https://secure.bmtmicro.com/opera/bu...tml?AID=882173
The Good Son wrote: Thanks for the replies.
It's a requirement of the CMS we are using that our templates conform to
XHTML 1.0 strict.
Funny thing is, whilst the stylesheet entry is being ignored, I can add the
attributes to the element within the template and it adds the border and
background colour.
Here is a W3C test case of an XHTML 1.0 Strict document demonstrating,
among other things, the use of border and background-color. http://www.w3.org/QA/2004/02/object/test-case-008
--
Gus
Thanks for the link, but it doesn't help much.
The problem I have is one of specific entries in the stylesheet being
completely ignored. If I take those entries and add them directly to the
element in the page template the page renders correctly in the browser
window.
"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t... in comp.infosystems.www.authoring.stylesheets, Tony Marston wrote:
"Justin Lieb" <ju**************@adelphia.net> wrote in message > XHTML is basically pointless at this point in time, unless they
> want to use xml tools with it.
Actually, people that use xml tools often say that is is easier to output
html than appendix C conforming xhtml...
I disagree. My PHP web application has output XHTML for over two years,
and
renders in IE, Opera and Firefox. The differences between "proper" HTML
and
XHTML are minor.
And point of using xhtml is? You could just fine use plain html4, right?
Because I can. I could use plain old HTML, but that is so-o-o-o-o last
century. One must keep up with the current standards, mustn't one?
--
Tony Marston http://www.tonymarston.net
The Good Son wrote: Thanks for the link, but it doesn't help much.
The problem I have is one of specific entries in the stylesheet being
completely ignored. If I take those entries and add them directly to the
element in the page template the page renders correctly in the browser
window.
You provide a selector with declaration and you say that it does not work.
I give you an example where it does work.
You say that it does not help much - it still does not work.
Do you see anything at all odd in this scenario?
The link proves that it works, therefore there is something amiss in
your document and you should be able to troubleshoot it. If you're
looking for someone to do it for you, then you haven't provided enough
information.
--
Gus
Tony Marston wrote: "Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...
in comp.infosystems.www.authoring.stylesheets, Tony Marston wrote:
"Justin Lieb" <ju**************@adelphia.net> wrote in message
XHTML is basically pointless at this point in time, unless they
want to use xml tools with it.
Actually, people that use xml tools often say that is is easier to output
html than appendix C conforming xhtml...
I disagree. My PHP web application has output XHTML for over two years,
and
renders in IE, Opera and Firefox. The differences between "proper" HTML
and
XHTML are minor.
And point of using xhtml is? You could just fine use plain html4, right?
Because I can. I could use plain old HTML, but that is so-o-o-o-o last
century. One must keep up with the current standards, mustn't one?
Of course you can, but serious web developers will use what
works properly with current browsers! Remember browser will
treat what you claim is valid XHTML as tag soup or HTML 3.2
if you will.
JL
On Thu, 9 Jun 2005, Tony Marston wrote: "Lauri Raittila" <la***@raittila.cjb.net> wrote in message
And point of using xhtml is? You could just fine use plain html4, right?
Because I can. I could use plain old HTML, but that is so-o-o-o-o last
century. One must keep up with the current standards, mustn't one?
That rather depends on whether you're trying to communicate your
content to the web, or to make a fashion statement.
Statistically, like it or not (personally I don't like it, but it's
reality nevertheless), the majority of users are browsing with a
browser-like object from the last century that doesn't even conform to
mandatory IETF interworking rules, let alone the W3C ones.
Let me put it this way. You might have your own good reasons for
emitting XHTML, but you don't seem to have actually revealed them here
yet. That it is feasible (relying on a widespread browser bug
relative to SGML) to feed XHTML to browsers which were designed for
HTML, using the provisions of Appendix C, is not contentious: we all
know about it. It's just that some draw different conclusions from
that observation.
in comp.infosystems. www.authoring.stylesheets, Tony Marston wrote: And point of using xhtml is? You could just fine use plain html4, right?
Because I can.
I would say that it is not very good argument. So it is pointless, at
least you find one reason (point), why it would be better.
I could use plain old HTML, but that is so-o-o-o-o last
century. One must keep up with the current standards, mustn't one?
I am almost 100% sure that valid XHTML strict will never be as well
supported as HTML4 strict. If done like appendix C, support is not
currently much worse, but Appendix C is non normative, and thus not
standard. Anyway, if you would use current standard, that would be
XHTNL1.1, which don't work in IE.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera: https://secure.bmtmicro.com/opera/bu...tml?AID=882173
Lauri Raittila wrote: in comp.infosystems.www.authoring.stylesheets, Tony Marston wrote:
And point of using xhtml is? You could just fine use plain html4, right?
Because I can.
I would say that it is not very good argument. So it is pointless, at
least you find one reason (point), why it would be better.
I could use plain old HTML, but that is so-o-o-o-o last
century. One must keep up with the current standards, mustn't one?
I am almost 100% sure that valid XHTML strict will never be as well
supported as HTML4 strict.
I am 100% certain that is true for legacy browsers, although somewhat of
an odd statement since XHTML incorporates HTML 4.
If done like appendix C, support is not
currently much worse, but Appendix C is non normative, and thus not
standard.
Appendix C is used to support non-standard legacy browsers.
Anyway, if you would use current standard, that would be
XHTNL1.1, which don't work in IE.
This site, served as text/html, does not work on your IE? http://www.w3.org/TR/xhtml11/
Please expand on what does not work.
--
Gus
in comp.infosystems. www.authoring.stylesheets, Gus Richter wrote: Lauri Raittila wrote: in comp.infosystems.www.authoring.stylesheets, Tony Marston wrote:
And point of using xhtml is? You could just fine use plain html4, right?
Because I can.
I would say that it is not very good argument. So it is pointless, at
least you find one reason (point), why it would be better.
I could use plain old HTML, but that is so-o-o-o-o last
century. One must keep up with the current standards, mustn't one?
I am almost 100% sure that valid XHTML strict will never be as well
supported as HTML4 strict.
I am 100% certain that is true for legacy browsers although somewhat of
an odd statement since XHTML incorporates HTML 4.
There are differences. Just enough to make browsers have problems, but
not enough to actually give any benefits...
If done like appendix C, support is not
currently much worse, but Appendix C is non normative, and thus not
standard.
Appendix C is used to support non-standard legacy browsers.
Yes. Remembering that legasy browsers is also IE6, which is 80% of
current browsers
Anyway, if you would use current standard, that would be
XHTNL1.1, which don't work in IE.
N->M of course
This site, served as text/html, does not work on your IE?
http://www.w3.org/TR/xhtml11/
Please expand on what does not work.
It is supposed to be served in text/xhtml+xml. You can serve it using
text/html, it is bad thing to do, but you can. But that won't mean
XHTML1.1 works in IE, done as it should be done. Just as IE doesn't
support XHTML1.0 either, unless appendix C is followed. So, IE clearly
don't support XHTML - you can't just make correct xhtml document and
think that it works in IE.
But if you make document following the spec, you find out that IE won't
support it. And that it don't work.
And that document you refer gets quirks mode in IE...
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera: https://secure.bmtmicro.com/opera/bu...tml?AID=882173
> You provide a selector with declaration and you say that it does not work. I give you an example where it does work.
You say that it does not help much - it still does not work.
I have plenty of examples, formatted in the same way, within the original
stylesheet that do work.
Do you see anything at all odd in this scenario?
Yes, you don't seem to be with me. I'm trying to understand why the change
in doctype would cause this problem.
The link proves that it works, therefore there is something amiss in
your document and you should be able to troubleshoot it.
If I switch the doctype back, it works. I want to understand why it is just
these two declarations that are ignored by the new doctype.
The Good Son wrote: Thanks for the replies.
It's a requirement of the CMS we are using that our templates conform to
XHTML 1.0 strict.
Funny thing is, whilst the stylesheet entry is being ignored, I can add the
attributes to the element within the template and it adds the border and
background colour.
Please provide the url of the page in question, I can't seem
to duplicate your problem. Here is the code I used with
both doctypes:
<html>
<head>
<title></title>
<style>
<!--
#wrapper {border:1px solid #000;background:#fff;}
-->
</style>
</head>
<body>
<div id="wrapper">Some Text...</div>
</body>
</html>
and it works fine for me in FF and IE6. I think you may
have stumbled upon an IE layer bug. Have a look at the
following page in two different browsers and notice how the
layers differ in color. http://webdesign.crissov.de/temp/table-layers.html
JL
Lauri Raittila wrote: If done like appendix C, support is not
currently much worse, but Appendix C is non normative, and thus not
standard.
Appendix C is used to support non-standard legacy browsers.
Yes. Remembering that legasy browsers is also IE6, which is 80% of
current browsers
Agreed - IE6 is the NS4 of today.
This site, served as text/html, does not work on your IE?
http://www.w3.org/TR/xhtml11/
Please expand on what does not work.
It is supposed to be served in text/xhtml+xml.
I accept this, but can you give an authoritive reference?
On the other hand, if XML is not incorporated in the document as well?
Also, the quoted page works well on all browsers, served as text/html.
You can serve it using
text/html, it is bad thing to do, but you can.
Can you be specific as to why it is a bad thing?
But that won't mean
XHTML1.1 works in IE, done as it should be done. Just as IE doesn't
support XHTML1.0 either, unless appendix C is followed. So, IE clearly
don't support XHTML - you can't just make correct xhtml document and
think that it works in IE.
But if you make document following the spec, you find out that IE won't
support it. And that it don't work.
What are you expecting XHTML to do at this point in time beyond making
sure that the document is conforming? How does it not work?
The way that I see it, XHTML 1.0 (and XHTML 1.1 for that matter), for
those of us that are not into incorporating XML, it is simply complying
with W3C by using the latest Recommendation, waiting for the browsers to
catch up by applying Appendix C and serving it up as text/html, which I
believe is W3Cs intension.
I have found in the past some rendering differences in some instances
(Opera for example, although this was some versions ago) when serving up
as text/xhtml+xml so I stayed with text/html.
If moving into the true XML world, with XML incorporation, then it must
be served up as text/xhtml+xml. I for one am not there yet, nor do I
have the need for now. I suspect that most people are in the same position.
And that document you refer gets quirks mode in IE...
Agreed - due to the XML declaration which is optional for the default of
UTF-8 or UTF-16. I guess that W3C wants the same rendition for IE5.5 and
IE6.
--
Gus
> Lauri Raittila wrote:
You can serve it using text/html, it is bad thing to do, but you can.
Gus Richter wrote:
Can you be specific as to why it is a bad thing?
I have already answered this before: http://www.hixie.ch/advocacy/xhtml
JL
On 10/06/2005 18:01, Gus Richter wrote: Lauri Raittila wrote:
[snip]
[A XHTML 1.1 document?] is supposed to be served in text/xhtml+xml.
application/xhtml+xml
I accept this, but can you give an authoritive reference?
I don't believe there is one, though
<URL:http://www.w3.org/TR/xhtml-media-types/> is probably as close as
you'll get.
[snip]
You can serve it using text/html, it is bad thing to do, but you can.
Can you be specific as to why it is a bad thing?
Appendix C was specified for XHTML 1.0, but no other versions. Whilst
one can serve a XHTML 1.0 document with the text/html content type
(though it's not recommended), one should only serve documents written
in other XHTML versions with application/xhtml+xml.
[snip]
What are you expecting XHTML to do at this point in time beyond making
sure that the document is conforming? How does it not work?
If an XHTML document is served as HTML, then all user agents will treat
it as such, whether they support XHTML or not. This means user agents
cannot utilise a simpler parser, and neither can they conform to the XML
parsing rule.
The way that I see it, XHTML 1.0 (and XHTML 1.1 for that matter), for
those of us that are not into incorporating XML, it is simply complying
with W3C
As far as I know, the W3C have not stated that documents should be
migrated to XHTML, so using HTML would still constitute some misguided
notion of compliance. Moreover, if you're that concerned about complying
with what the W3C recommends, you would accept that using the wrong
content type is, well, wrong.
by using the latest Recommendation
I'd say that's jumping on the latest bandwagon. Nothing more. XHTML
might be good for content management, and for serving documents to
mobile devices that can't handle a tag soup (HTML) parser, but not for
the Web in general. After all, what's the point in forcing every single
user agent to error correct every one of your documents?
[snip]
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
The Good Son wrote:
If I switch the doctype back, it works. I want to understand why it is just
these two declarations that are ignored by the new doctype.
Unless you post a URL, all you'll get are guesses, albeit educated ones.
BTW, posting code instead of a URL isn't the same. People don't want to
be bothered having to make their own page from your code. Make it easy
for us to help you and you'll get better results. Posting a URL makes it
easier for us.
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Justin Lieb wrote: Can you be specific as to why it is a bad thing?
I have already answered this before:
http://www.hixie.ch/advocacy/xhtml
A couple of questions:
1. Does using <meta http-equiv="Content-Type"
content="application/xhtml+xml; charset=iso-8859-1" /> make any difference
to how the document is handled if the server header is "content-type:
text/html"?
2. How do I tell what moe IE6 is using for any given document?
--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
Jim Moe wrote: Justin Lieb wrote:
Can you be specific as to why it is a bad thing?
I have already answered this before:
http://www.hixie.ch/advocacy/xhtml
A couple of questions:
1. Does using <meta http-equiv="Content-Type"
content="application/xhtml+xml; charset=iso-8859-1" /> make any
difference to how the document is handled if the server header is
"content-type: text/html"?
Not on my server, Apache 1.3.33. Maybe there is a setting
in the Apache config file, I don't know. I guess it may be
different on other servers, but I can't answer that.
2. How do I tell what moe IE6 is using for any given document?
Basically anytime there is a !DOCTYPE at the beginning of a
document, you will be in standards mode.
Maybe someone knows an easier way to tell, but I would do it
buy reading here to be safe: http://msdn.microsoft.com/library/de...hancements.asp
JL
Justin Lieb wrote: Lauri Raittila wrote:
You can serve it using text/html, it is bad thing to do, but you can.
Gus Richter wrote:
Can you be specific as to why it is a bad thing?
I have already answered this before:
http://www.hixie.ch/advocacy/xhtml
I have read the document and highly respect Ian Hixie's opinion.
The following section taken from the document probably should have been
at the very beginning:
"(Yes, I said _most_ authors. If you are one of the few authors who
understands how to avoid the issues raised in this document and does
validate all their markup, then this document probably does not
apply to you -- see Appendix B.)"
The gist of the document, as I read it, is the separation of authors
into two categories. The conscientious and the not-so-conscientious with
the hypothesis that most are of the latter type. The document goes on
outlining pitfall scenareos involving the not-so-concsientious as well
as specific problems and how to take care of them.
A second quote in the document that I would like to comment on:
"Sending XHTML 1.1 as text/html is NEVER fine. There is no spec that
allows this."
On the other hand, neither does the spec require the use of
application/xhtml+xml.
So there we have it. Ian and I are in agreement. XHTML served as
text/html is perfectly acceptable, but is _not_ for the
_not-so-conscientious_ and they should stick with HTML or serve up their
documents as application/xhtml+xml, which forces them to be
conscientious, but lose out with legacy browsers.
An item I would like to address as used elsewhere in this thread:
"Tag soup" as used in the document refers to SGML features which are not
supported by browsers and are taken advantage of by Appendix C.
The question, if browsers should support these SGML features, is
actually beside the point. The fact is that browsers don't and members
of the W3C agreed to take advantage of this.
A second item used elsewhere in this thread that I would like to address
is the suggestion that moving to XHTML is not recommended by W3C and
that it is ok to stay with HTML:
XHTML 1.0 does not deprecate HTML since that is not the intent. XHTML
1.0 is a reformulation of HTML 4 which means that HTML 4 is carried
forward, but slightly (or not so slightly depending on your point of
view) modified by, and into, XHTML 1.0 which therefore, and in other
words, replaces/modifies/changes/appends the latest HTML 4.01
recommendation with what is stated in XHTML 1.0.
I quote from XHTML 1.1 which cleanly seperates/removes/deletes:
"... the *deprecated* , legacy functionality of HTML 4 that
was brought forward into the XHTML 1.0 ..."
Whereas HTML 4 itself is not deprecated, the deprecated elements and
attributes are removed in XHTML 1.1.
It is clear to me that HTML 4 has been replaced by XHTML 1.0 and it in
turn has been replaced by XHTML 1.1.
A third and last item, suggested elsewhere in this thread, that I would
like to address is that Appendix C of XHTML 1.0 is not applicable to
XHTML 1.1:
I quote once more from XHTML 1.1:
"This document type [XHTML 1.1] is essentially a reformulation of
XHTML 1.0 Strict ..."
I will not repeat what I said in the second item, immediate above,
except to say that likewise, XHTML 1.0 is brought forward in its
entirety and changed per what is stated in XHTML 1.1.
Perhaps the difficulty is that XHTML recommendations are not completely
separate/self-standing documents as we were used to with HTML 3.2 to 4
to 4.01 and with CSS 1 to CSS 2 to CSS 2.1. With XHTML 1.0 we have to
look at HTML 4.01 *and* XHTML 1.0 and with XHTML 1.1 we have to look at
HTML 4.01, XHTML 1.0 *and* XHTML 1.1. (I know that I am leaving out SGML.)
Pardon me if I may sound like an authority. That is not my intent, and
God knows that I am not. I read and come to conclusions. I really long
to learn, to be corrected if I am wrong, or affirmed in my understanding.
--
Gus
Gus Richter wrote: <snip>
So there we have it. Ian and I are in agreement. XHTML served as
text/html is perfectly acceptable, but is _not_ for the
_not-so-conscientious_ and they should stick with HTML or serve up their
documents as application/xhtml+xml, which forces them to be
conscientious, but lose out with legacy browsers.
So, are you for or against using XHTML? Please point to the
location in that article where Ian says serving XHTML as
text/html is perfectly acceptable. I gathered that he is
quite against it!
JL
Justin Lieb wrote: Gus Richter wrote: > <snip>
>
So there we have it. Ian and I are in agreement. XHTML served as
text/html is perfectly acceptable, but is _not_ for the
_not-so-conscientious_ and they should stick with HTML or serve up
their documents as application/xhtml+xml, which forces them to be
conscientious, but lose out with legacy browsers.
So, are you for or against using XHTML? Please point to the location
in that article where Ian says serving XHTML as text/html is perfectly
acceptable. I gathered that he is quite against it!
I regret that I have not been able to be clearer. Allow me to expand.
You have read Ian's document and have quoted it, but have not understood
it. He is against XHTML because he does not trust authors to be
consciencious in their work. So he advises against serving XHTML up as
text/html because there is no assurance that such authors will produce a
proper document by not validating their document and not properly
applying Appendix C. In fact, he provides scenarios where such authors
are likely to produce improper documents. He advises to either serve the
document up as application/xhtml+xml whereby they will be forced to
create a proper document or to forget about XHTML and stick with HTML.
Since support by IE for application/xhtml+xml is non-existant, he is in
favor of HTML. In his document, he says that if you are a conscientious
author, then his document can be disregarded (since you will assuredly
create a proper XHTML document served up as text/html).
I agree with him that desiring support for legacy browsers, which
includes all IE products, discounts XHTML served up as
application/xhtml+xml at this time. Where he and I part ways is that he
does not trust authors to be trustworthily conscientious in the creation
of XHTML documents and I on the other hand discount this notion and
treat authors alike with the understanding that their XHTML documents
account for all issues raised in Appendix C (and in Ian's document).
What he forgets is that such an untrustworthy type of author will also
likely fail to create a proper document with HTML by not validating
their document, so his solution to assuring a proper document creation
is really no perfect solution.
Ian does not say that serving XHTML up as text/html is illegal, which it
is not. What he does say is exactly what the title of the document says:
"Sending XHTML as text/html Considered Harmful"
<http://www.hixie.ch/advocacy/xhtml>
His opinion as to why text/html should not be used - why he believes
that its use is harmful/unacceptable. On the other hand, he also says
[search for "(yes" in the document] that if the reader of this document
is a conscientious author, then the document does not apply to the
reader. Ergo, for such an author, text/html is *not* harmful, therefore
is perfectly acceptable, as it is legal. In fact, Appendix C.11 suggests
that an XHTML document may be served as text/html.
What he does go on about are reasons (which I have tried to capsulate)
as to why he believes one should not do so. I believe that I am a
conscientious author, as all authors *should* be, and as such, following
his advice, his document does not apply to me, nor *should* it to all
other authors (although the pitfall scenareos and specific problems
outlined are well received and appreciated).
I hope that I have been able to make my position clearer. In a nutshell,
I am *for* XHTML 1.0 served up as text/html at this time (for documents
not using XML tools), only due to lack of support for
application/xhtml+xml by IE. Ian is as well, as I read it, except for
non-conscientious authors for which type he advises HTML. Ian wants to
save the web from faulty new XHTML documents. I believe that his
solution, if followed, will only shift the problem and create faulty new
HTML documents instead.
I repeat as in my previous posting, I am no authority. I long to learn,
to be corrected if I am wrong, or affirmed in my understanding. I
therefore am surprised that I have not been corrected within the last 18
hours since my last posting, so I shall be responding to it with changes.
--
Gus
Gus Richter wrote:
I have read the document and highly respect Ian Hixie's opinion.
The following section taken from the document probably should have been
at the very beginning:
"(Yes, I said _most_ authors. If you are one of the few authors who
understands how to avoid the issues raised in this document and does
validate all their markup, then this document probably does not
apply to you -- see Appendix B.)"
The gist of the document, as I read it, is the separation of authors
into two categories. The conscientious and the not-so-conscientious with
the hypothesis that most are of the latter type. The document goes on
outlining pitfall scenareos involving the not-so-concsientious as well
as specific problems and how to take care of them.
A second quote in the document that I would like to comment on:
"Sending XHTML 1.1 as text/html is NEVER fine. There is no spec that
allows this."
On the other hand, neither does the spec require the use of
application/xhtml+xml.
Thanks to Michael, I have the missing link of:
<http://www.w3.org/TR/xhtml-media-types/>
which says that text/html for XHTML 1.0 _may_ (optional) be used, and
that text/html for XHTML 1.1 _should not_ be used (not recommended, but
could be used after due considerations and need).
So there we have it. Ian and I are in agreement. XHTML served as
text/html is perfectly acceptable, but is _not_ for the
_not-so-conscientious_ and they should stick with HTML or serve up their
documents as application/xhtml+xml, which forces them to be
conscientious, but lose out with legacy browsers.
An item I would like to address as used elsewhere in this thread:
"Tag soup" as used in the document refers to SGML features which are not
supported by browsers and are taken advantage of by Appendix C.
The question, if browsers should support these SGML features, is
actually beside the point. The fact is that browsers don't and members
of the W3C agreed to take advantage of this.
A second item used elsewhere in this thread that I would like to address
is the suggestion that moving to XHTML is not recommended by W3C and
that it is ok to stay with HTML:
XHTML 1.0 does not deprecate HTML since that is not the intent. XHTML
1.0 is a reformulation of HTML 4 which means that HTML 4 is carried
forward, but slightly (or not so slightly depending on your point of
view) modified by, and into, XHTML 1.0 which therefore, and in other
words, replaces/modifies/changes/appends the latest HTML 4.01
recommendation with what is stated in XHTML 1.0.
I quote from XHTML 1.1 which cleanly seperates/removes/deletes:
"... the *deprecated* , legacy functionality of HTML 4 that
was brought forward into the XHTML 1.0 ..."
Whereas HTML 4 itself is not deprecated, the deprecated elements and
attributes are removed in XHTML 1.1.
It is clear to me that HTML 4 has been replaced by XHTML 1.0 and it in
turn has been replaced by XHTML 1.1.
The section below is *way incorrect* and I wish to retract it in its
entirety since nobody has corrected me within the last 18 hours, so
disregard it with my appologies.
A third and last item, suggested elsewhere in this thread, that I would
like to address is that Appendix C of XHTML 1.0 is not applicable to
XHTML 1.1:
I quote once more from XHTML 1.1:
"This document type [XHTML 1.1] is essentially a reformulation of
XHTML 1.0 Strict ..."
I will not repeat what I said in the second item, immediate above,
except to say that likewise, XHTML 1.0 is brought forward in its
entirety and changed per what is stated in XHTML 1.1.
Perhaps the difficulty is that XHTML recommendations are not completely
separate/self-standing documents as we were used to with HTML 3.2 to 4
to 4.01 and with CSS 1 to CSS 2 to CSS 2.1. With XHTML 1.0 we have to
look at HTML 4.01 *and* XHTML 1.0 and with XHTML 1.1 we have to look at
HTML 4.01, XHTML 1.0 *and* XHTML 1.1. (I know that I am leaving out SGML.)
Permit me to restate what I hope is correct:
XHTML 1.0 is the only document which incorporates another, specifically
that of HTML 4.01.
XHTML 1.1 led me astray by the mention of its own Appendix C which I
wrongly took to be that of XHTML 1.0 due to ever presence in mind.
XHTML 1.1 is once again a separate/self-standing document and does *not*
carry forward XHTML 1.0 with its Appendix C, nor HTML 4.01, but uses
Modules to redefine elements and attributes.
I now agree that Appendix C of XHTML 1.0 is not applicable to XHTML 1.1.
Although XHTML 1.1 has the XHTML Legacy Markup Module for legacy browser
support, I fail to find anything regarding empty elements, minimized
tag syntax, or space before the trailing /> (and other XML conforming
and compatibility guidelines), so we are left to apply Appendix C of
XHTML 1.0 on our own, assuming that it also applies to XHTML 1.1? [All
this because of the legacy IE 6/5.5 browsers' popular usage to-date.]
I left the bottom section, since it still applies and gives an excuse.
Pardon me if I may sound like an authority. That is not my intent, and
God knows that I am not. I read and come to conclusions. I really long
to learn, to be corrected if I am wrong, or affirmed in my understanding.
Hoping for comments and/or corrections,
--
Gus
Gus Richter schrieb: Justin Lieb wrote: Gus Richter wrote:
XHTML served as text/html is perfectly acceptable,
With all the ifs and whens, I wouldn't use the word "perfectly".
[Ian] is against XHTML because he does not trust authors to be
consciencious in their work.
And from my observations he is fucking right about that.
he says that if you are a conscientious author, then his document can be disregarded
Yes, but ...
(since you will assuredly create a proper XHTML document served up as text/html).
.... that's only one option.
The perfectionist creates two (cached) versions on the browser's demand
('Accept'): XHTML 1.1 and HTML 4.01 Strict. (I have sometimes advocated
to combine this with other "advanced" technologies, such as
uncompromised use of Unicode and CSS-P.) At some point he will realize,
though, that just one version yields the least problems (e.g. with
caching) and thus become a realist. If he's not that much of a
perfectionist anyway, he will perhaps choose to use the version in
between the two aforementioned ones, HTML 1.0, then chop that down to
HTML4 tagsoup compatibility (Appendix C), losing in practice the one
real difference between them, well-formedness, but still has the
size-Xtended, readability-reduced code (closing tags are often).
Otherwise he'll choose well-written HTML4.
[i] treat authors alike with the understanding that their XHTML documents
account for all issues raised in Appendix C (and in Ian's document).
What he forgets is that such an untrustworthy type of author will also
likely fail to create a proper document with HTML by not validating
their document, so his solution to assuring a proper document creation
is really no perfect solution.
He does not forget that. HTML parsers are already tagsoup parsers,
actually ever have been. Current XHTML parsers are way less
error-forgiving, but as long as they are not invoked, there's appearing
more and more mal-formed XML material on the Web. So chances grow that
in a few years a very strict XML parser isn't usable anymore, because,
although it is invoked more often, there's so much legacy pseudo-XML
content, that needs error-tolerant handling, which than will be added in
different ways in different browsers. And history repeats itself. Just
imagine Internet Explorer 7 would accept a/x+x, but put it through a
forgiving parser ... The whole reason for XHTML was lead ad absurdum.
Therefore all XML content should be parsed by XML parsers.
Ian just wants to keep XHTML clean (IMVHUnderstanding).
If you don't need the X, don't use XHTML!
Ian does not say that serving XHTML up as text/html is illegal, which it
is not.
Note that the inversion is not true, it is not always legal to send
XHTML as text/html. In fact that legality is the exception.
Use text/html for HTML and XHTML 1.0 Appendix C only.
Only use X1C, if you gain any benefit from it---which pretty much nobody
actually does. For those using XML tools in the content generation
process, conversion/output to HTML is in general quite simple (it's for
instance a standard feature of XSLT). Many tools still only output HTML
out of the box, many others only broken XHTML (which is worse).
In fact, Appendix C.11 suggests that an XHTML document may be served as text/html.
Yes, one, and only one, that is adhering to the (informative) rules of
that very appendix (which I wish had never existed, at least not inside
the XHTML1 spec).
I believe that I am a conscientious author,
Too many do believe that about themselves. Life seems simpler that way.
(I'm not doubting your judgment, but don't acknowledge it either.)
Christoph Päper wrote:
Ian just wants to keep XHTML clean (IMVHUnderstanding).
If you don't need the X, don't use XHTML!
I understand where you and Ian are coming from, but here is the problem;
I wish to conform with W3C guidance and not stagnate with the stagnant
IE thereby allowing it to overrule and dictate. I believe that choosing
the former as the lesser of the two evils.
Use text/html for HTML and XHTML 1.0 Appendix C ...
Agreed.
... only.
Actually, as I mentioned in my other posting:
<http://www.w3.org/TR/xhtml-media-types/>
says that text/html for XHTML 1.1 _should not_ be used (not recommended,
but _could_ be used after due considerations and need).
Although XHTML 1.1 has the XHTML Legacy Markup Module for legacy browser
support, I fail to see how this can be useful without serving the
document up as text/html if such support is desired.
--
Gus
Christoph Päper wrote: he says that if you are a conscientious author, then his document can
be disregarded
Yes, but ...
(since you will assuredly create a proper XHTML document served up as
text/html).
... that's only one option.
The perfectionist creates two (cached) versions on the browser's demand
('Accept'): XHTML 1.1 and HTML 4.01 Strict.
Danke Christoph,
I have investigated this first option and believe this to be the ideal
solution along with some PHP. With all the negative talk in newsgroups,
I had not realized that there were people that actually covered this
ground and have come up with a working solution.
Now I have more investigation ahead of me and more testing. Thank you
for the prod in the right direction.
--
Gus
> Unless you post a URL, all you'll get are guesses, albeit educated ones.
Guesses, educated or not, are not what I was after. I posted as my
searching had proven fruitless. If it was a known issue then the replies
would have been thick and fast. I'm trying to fill a gap in my knowledge.
BTW, posting code instead of a URL isn't the same.
The idea of the code was to show there is nothing clever being attempted ie
no hacks, and after a change to the doctype the element lost it's border
and background colour.
People don't want to be bothered having to make their own page
from your code. Make it easy for us to help you and you'll
get better results. Posting a URL makes it easier for us.
I don't expect anyone to write a page...well...a few lines...anyhoo...I
posted as I am trying to understand why the change in doctype would do
this, not to get help with the markup. It could be the CMS we are using
which already has a number of quirks and this would be another to add to
the list. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
9 posts
views
Thread by Robert Misiorowski |
last post: by
|
6 posts
views
Thread by Patrick |
last post: by
|
2 posts
views
Thread by Dominic Myers |
last post: by
|
31 posts
views
Thread by Arthur Shapiro |
last post: by
|
31 posts
views
Thread by Greg Scharlemann |
last post: by
|
8 posts
views
Thread by Bosconian |
last post: by
|
13 posts
views
Thread by amykimber |
last post: by
|
reply
views
Thread by =?Utf-8?B?SGFyZHkgV2FuZw==?= |
last post: by
|
17 posts
views
Thread by seajay |
last post: by
| | | | | | | | | | | | | | | | | | | |
