- From: Jim Ley <jim@jibbering.com>
- Date: Mon, 22 Sep 2003 15:44:56 -0000
- To: <public-evangelist@w3.org>
From: "Richard Ishida" <ishida@w3.org> >[mailto:public-evangelist-request@w3.org] On Behalf Of Jim Ley >>(rather than content which is only compatible with some html >>user agents) > >I guess I don't see why you should go to so much trouble. If it's in >xhtml for good reasons, as you mention, and if you can successfully >serve it as xhtml, why change it to html? (also see below) Because you can't "successfully serve it as xhtml" in all cases. Appendix C text/html content is only "compatible with most HTML browsers" For me, most is not successfully serving it, consider WAI, a much more important requirement than HTML validity for me - yet that requires things such as "ensure that pages featuring new technologies transform gracefully" and "Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)" by sending text/html you are not really telling the truth about the content-type of your document, (See RFC 3236 for the correct one). The W3 HTML WG has also published a note http://www.w3.org/TR/xhtml-media-types/ , where it says xhtml SHOULD be served as application/xhtml+xml - I don't think "I'm not willing to go to the trouble" is really an appropriate reason for ignoring W3 SHOULD's. >>as soon as UA's >>start being application/xhtml+xml user agents exist, people >>will change the mime-type and the UA manufacturers will have >>to start adding tag-soup parsing of it too. > >I don't think that the mime-type indicates what DTD to use. So I'm not >sure that this is a valid argument. Indeed it doesn't, but if you serve XHTML 1.0, XHTML 1.1 and XHTML 2.0 all with the same mime-type then future user agents will have to support all of those, there being no current mechanism for the UA to express a preference for a particular dialect of XHTML - given that XHTML content is almost always invalid now (but people don't notice this as they only view it in tag-soup UA's) moving this content over will force those XHTML 2.0 UA's to support XHTML 1.0 tag-soup - or not render existing pages. Not rendering existing pages has not proven a good survival strategy in UA authoring. I see xhtml as text/html being a danger, it allows people to author invalid XHTML and see it render, most people don't seem to be equipped to author valid documents, but if it renders, then they'll expect it to render in the next version of a UA, or indeed all. >I think my definition of 'tag soup' may be different from yours. I think we can agree that XHTML 1.0 rendering in IE is down to the fact it has a tag-soup parser, and not an SGML validating one. I call XHTML in text/html as tag-soup because of that, it being reliant on tag-soup parsers not anything else. >For my setup I find that I need an xml declaration in XMetal to ensure >that the file is read in correctly by the editor. It can also be >important for indicating the character encoding of xml files. However when deploying it as text/html you either have to set it in the charset parameter or it's ISO-8859-1, you can't set it in the XML PI, it's too late, HTML's rules take precedence. Practically this means you have to use UTF-8 or UTF-16. So I'm afraid that's not an argument I can accept. > So I >personally tend to keep it at the top of my files until I decide to >serve them as html. That's good - and it just shows how having a publishing process can work well - if you just extend your script to also do an XHTML->html conversion, it'll cost you a few moments now, but will save your clients a lot of hassle, and will mean you won't have to disregard the shoulds of the HTML WG. Jim.
Received on Monday, 22 September 2003 11:48:10 UTC