Re: XHTML with Internet Explorer

"Steven Pemberton" <steven.pemberton@cwi.nl>
> From: "Jim Ley" <jim@jibbering.com>
>> This normative part requires that documents served as text/html must
>> "follow the guidelines set forth in Appendix C".  If this incorrect this
>> needs clarifying.
>
> It says that if you follow the guidelines in Appendix C you may serve it
as
> text/html. That is just a matter of fact.

So to be clear on this the normative part of XHTML 1 is putting a
requirement that if you serve it as text/html you must follow Appendix C.
The lack of clarity in the specification is what it means to "follow the
guidelines of Appendix C"  as they are couched in suggestions, and as has
been said are contradictory, for example (C.1 and C.14)  It is therefore not
possible to follow all of the guidelines of Appendix C (if you're using
CSS).

However the HTML WG do serve XHTML 1.0 as text/html and do specifically
ignore C.14, on some pages, but don't on others (compare
http://www.w3.org/MarkUp/  and http://www.w3.org/TR/xhtml1/ )  So we cannot
even guess the mechanisms from the Groups own behaviour.  As I've made clear
the problem is with the poorly drafted Appendix when it is referenced as a
requirement from a normative part of the specification.   Appendix C. if it
was purely informative it doesn't matter that it's contradictory (although I
don't see the value of it in a specification at all)  however its citing by
a normative part of the specification means it is entirely inappropriate,
since you cannot follow the guidelines.

> It is even more trivial to serve the same document in two different ways,
as
> many people do.

Yes, such clever ways as the http://www.w3.org/MarkUp/Activity/  which when
requested with my accept header gives me a document.

[[
Not Acceptable
An appropriate representation of the requested resource /MarkUp/Activity
could not be found on this server.
Available variants:

Activity.html , type application/xhtml+xml, charset utf-8
Activity.html.ascii , type application/xhtml+xml, charset utf-8
]]

Which aswell as being rather odd (offering up two representations with
reportedly identical types) it is also untrue as requesting either of the
actual documents, what I get is a text/html representation which is
something I would've accepted in the first place, it's all rather strange,
and I think demonstrates how difficult this actually is.

> > > Which outstanding issues are those?
> >
> > XHTML-1.0/6232   for example.
>
> In what sense has that not been answered? I even pointed you to the
general
> answer the HTML WG created to this class of questions.

You consider that it has been formally addressed?  I'm afraid I don't, and
http://hades.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.0?expression=appendix%20c;user=guest
still lists it as OPEN.  I had considered that the WG still had this under
consideration and as it is very similar to many of my issues, I had waited
to add mine, if you are saying it's not still under consideration to be
formally addressed in time, then I will have to raise my issues.

> Ian Hixon suggested changes to Appendix C which the HTML Working Group
> largely did not agree with.

"largely" indicating that they did agree with some - I note in your response
you agreed with at least one of them, yet no action has been taken, and the
issue is still OPEN.

> Well, it may also be labelled as "text/plain". It is the RFC for the media
> type that defines what happens.

RFC 2854 simply refers to the HTML4, XHTML1 etc. mime-types it does not
define behaviour any more than that.

> It is a document bringing together pointers to normative documents. It
> introduces no new normative text, it summarises current normative text.

No it does not!  5.1 of XHTML 1 as I have noted says "MAY to both text/html
and application/xhtml+xml" the note says "MAY to text/html and SHOULD to
application/xhtml+xml"  - if it's a summary, it's an inaccurate one.

Jim.

Received on Wednesday, 5 November 2003 05:55:52 UTC